Month: October 2026

My mum had a phrase for most things, but one of her favourites was:

“Least said, soonest mended.”

It was usually deployed when something had gone wrong, somebody had said something they shouldn’t have, or a situation had reached the point where further discussion was unlikely to improve it.

In other words: stop talking about it, get on with things, and it’ll probably be fine.

There is something wonderfully economical about it. Four words which can bring an entire argument to a halt. I suspect generations of Scottish family diplomacy have been built on considerably less.

But since my mum died, I’ve thought about those four words rather more than I ever did when she was here.

Because it turns out that grief doesn’t pay much attention to family sayings.

Least said, soonest mended.

I’m not sure about that one, Mum.

The strange thing about losing someone is that the enormous things aren’t always the things that get you. You prepare yourself, as much as anyone possibly can, for the funeral. You know the first birthday, Christmas and anniversary will be difficult. You expect the obvious moments.

It’s the ordinary ones that ambush you.

Something happens and you think, “I’ll tell Mum that.”

You remember something ridiculous she once said.

You see something she’d have liked, or something she’d have absolutely hated and would have told you about at considerable length.

And then, for a fraction of a second, everything is normal.

Until you remember.

That’s the peculiar cruelty of grief. The person can be gone for weeks or months, but some part of your brain hasn’t received the memo. It still occasionally behaves as though they’re just somewhere else.

And perhaps that’s because, in a sense, they are.

My mum is still there in the phrases I use, the things I find funny, the stories I tell and probably in a hundred little habits I don’t even realise came from her.

Including, of course, “least said, soonest mended.”

I’ve wondered whether she was right.

Perhaps there are things in life where saying less really is the wisest course. Arguments. Petty disagreements. The things we say in anger and would be better allowing to disappear rather than examining them endlessly.

But grief isn’t an argument to be resolved.

There isn’t a clever thing you can say that fixes it. There isn’t a point at which you’ve thought about somebody enough and can put them neatly away. And I’m increasingly unconvinced that “mending” is even the right ambition.

Because to mend something is to try to return it to how it was before.

This can’t be.

My mum died, and the world is therefore permanently different from the world in which my mum was alive. That’s not melodrama. It’s simply a fact.

So perhaps the job isn’t to mend.

Perhaps it’s to learn how to carry the difference.

To talk about her when I want to talk about her. To laugh at the things that were funny. To remember the things that weren’t. To occasionally hear her voice in my head telling me what she would have made of whatever nonsense I’m currently involved in.

And sometimes to say nothing at all.

Not because saying less will make the grief disappear sooner, but because silence can be a form of remembering too.

I still like her phrase.

I’ll probably keep using it.

But on this one, Mum, I think you might have been wrong.

Some things aren’t meant to be mended.

Some people mattered far too much for that.

And perhaps grief is simply the price of having had someone in your life whose absence is worth noticing.

Although I can already imagine what she’d say about me writing all of this.

“Least said, soonest mended.”

Fair enough, Mum.

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.