One of the things I’ve learned over the years is that some of the hardest technology problems contain surprisingly little technology.
Recently, I found myself leading a conversation around a complex cloud and data engagement involving a client, a major technology partner and a delivery team.
The engineering challenge was real, but it wasn’t the thing threatening to stop the project.
The problem was alignment.
The engagement had evolved. Discovery had uncovered more information. Dependencies had appeared. Access had taken longer than expected. Responsibilities had shifted. Work had already been undertaken, while different parties had slightly different understandings of where discovery ended, where delivery began, and where the associated commercial responsibility sat.
Meanwhile, everyone wanted exactly the same thing.
A successful outcome for the client.
That sounds like it should make things easy.
It doesn’t.
When everyone is right
These situations are difficult precisely because there doesn’t necessarily need to be a villain.
The delivery team wants enough certainty to deliver properly.
The commercial team needs to understand and control financial exposure.
The technology partner has its own contractual commitments and governance processes.
And the client quite reasonably expects the organisations it has engaged to work all of this out.
Each position can be entirely rational while the combination of them creates an impasse.
In this case, the immediate temptation could have been to treat it as a contractual negotiation: argue about language, defend positions and eventually escalate until somebody blinked.
I didn’t think that would get us very far.
Instead, we started internally by asking a more useful set of questions:
What do we actually know? What do we merely believe? What risk are we prepared to accept? And what needs to be true for us to move forward?
That distinction between knowing and believing turned out to be particularly important.
It’s OK to say “I don’t know”
There is a strange expectation of senior technology leaders that we’re supposed to have an immediate answer to everything.
I don’t buy it.
During the discussion there were historical details that I couldn’t state with certainty. I had been involved in the engagement, but it had evolved over a period of months and not every decision predated me or had been made by me.
So when something came up that I couldn’t verify, my answer was essentially:
I don’t know. I think I know, but I’ll check.
That might sound like a small thing.
I think it’s an important one.
There is an enormous difference between confidence and certainty, and pretending to possess the latter is a surprisingly effective way of destroying the former.
In a negotiation, credibility isn’t created by knowing everything.
It’s created by being very clear about what you know, what you don’t know, and what you’re going to do about the difference.
Separate the problems
The breakthrough came when we stopped treating the situation as one big problem.
There were really three.
The first was the commercial and contractual model for the main engagement. Everyone needed the same understanding of how the engagement operated, where the commercial boundaries sat, and what happened if the assumptions underneath it materially changed.
The second was historic discovery effort. Work had already happened, but there was a question about how that work was originally intended to be treated commercially.
The third was forward delivery risk. Access, dependencies, approvals and technical complexity could all affect the plan, regardless of what a contract said.
Trying to solve all three simultaneously meant that disagreement about one could stop progress on everything else.
So we separated them.
The main engagement could move forward under an agreed commercial framework.
The historic discovery question could be investigated separately, with both sides going back through the history to establish what had actually been agreed.
And the delivery team could work from a concrete sprint plan, making dependencies and changes visible early rather than discovering them when the budget had already disappeared.
Suddenly, an argument that could have stopped a project became a collection of manageable decisions.
My job wasn’t to be the smartest technologist in the room
This was perhaps my favourite part of the whole experience.
I was asked to lead the conversation, but that didn’t mean I needed to answer every question.
We had people who understood the commercial mechanics better than I did.
We had people closer to the day-to-day delivery.
We had specialists who understood the detailed technical implementation.
So I used them.
When the discussion moved deeply into commercial mechanics, our commercial expertise came forward.
When it moved into delivery forecasting and dependencies, our delivery specialists took it.
When we needed detailed technical understanding, the appropriate engineers had the floor.
My job was different.
It was to understand enough of all of those dimensions to keep the whole thing joined together.
To represent our position.
To challenge when necessary.
To listen when the other side had a legitimate point.
To make sure we weren’t accepting risks we didn’t understand.
And, perhaps most importantly, to protect the relationship while doing it.
That last part matters.
You can win an argument and still lose a partner.
Firm doesn’t have to mean confrontational
Before the external discussion, we’d had a robust internal conversation.
We knew the risks we weren’t prepared to accept. We knew where we needed clarification. And we knew where our boundaries were.
But carrying a firm position into a meeting doesn’t mean carrying the emotion that created it.
I started instead with the thing everyone could agree on:
We all wanted a successful outcome for the client.
That’s not corporate fluff when you actually mean it.
It changes the nature of the disagreement.
Instead of:
us versus them
the conversation becomes:
all of us versus the problem.
We disagreed on some things. We challenged each other. New information emerged.
But gradually the conversation moved from defending positions towards designing a way forward.
That’s the point of negotiation, surely.
Not winning.
Making something executable.
The outcome
By the end, we had a route forward.
The commercial model for the main engagement was clarified.
The historic discovery effort was separated into its own discussion rather than being allowed to block delivery.
Both sides had actions to establish what had previously been agreed.
The delivery team had a concrete plan for the work ahead.
And there was a mechanism for dealing with material changes in scope, complexity or assumptions rather than allowing them to become nasty surprises at the end.
Most importantly, the relationship remained intact.
Nobody dramatically thumped the table.
Nobody stormed out.
Nobody needed to “win”.
We just needed to get unstuck.
And we did.
Technology leadership happens in the gaps
I’ve spent a lot of my career around architecture, engineering and technology strategy.
But increasingly I think some of the highest-value work a senior technologist can do happens in the gaps between disciplines.
Between technology and commercial reality.
Between sales and delivery.
Between contractual commitments and engineering uncertainty.
Between partners and clients.
Between what everybody thought was agreed six months ago and what everyone discovers they actually need today.
Architecture diagrams aren’t much help in those moments.
What matters instead is being able to bring the right people together, establish the facts, understand the risks, create appropriate boundaries and find a path everyone can actually execute.
The technology still matters enormously.
But sometimes the most important thing a technology leader can do is recognise that the technology isn’t actually the problem.