When I first started leading engineers, I thought my job was making decisions.
I made a lot of them.
I joined one organisation and spent my first quarter trying to make delivery move faster.
Tighter planning. More structure around sprint commitments. Better velocity tracking. From the outside it looked obvious: the business was under pressure, the engineering team was moving slowly, and I'd arrived with tools that could close the gap.
It took me too long to realise the team didn't need speed. They needed confidence.
They'd been through a difficult period before I arrived: missed deadlines, shifting priorities, a loss of trust with their stakeholders. What they needed from me was steadiness and space to rebuild. What I gave them, for the first few months, was more pressure.
At the time, I believed I was responding to what the business needed.
Looking back, I'd read the business and ignored the team.
I've since come to think about this as reading the tide.
Every organisation has one. Some are building momentum and need permission to move faster. Others are tired in a way that does not show up in a roadmap, and need someone to slow things down before something breaks.
The mistake isn't picking the wrong framework. It's assuming the same leadership works in both situations.
I made that assumption more than once. Arrived somewhere that needed slowing down and tried to speed it up. Arrived somewhere that needed confidence and introduced process instead.
Leadership isn't about applying best practice. It's about reading the tide well enough to know whether to push, redirect, or hold steady until the conditions change.
That experience is why, whenever I start somewhere new, I now spend the first few weeks asking questions rather than proposing solutions.
Not because I've read it in a book. Because I have arrived at a team that needed something I did not give them quickly enough, and I would rather understand where an organisation's energy actually is before responding to where I think it should be.
Where do engineers and stakeholders see the same picture? Where do their views quietly diverge?
That gap is almost always where the real work begins.
Working across different organisations has taught me that architecture is rarely what determines whether a transformation succeeds.
Trust is. Shared understanding is. The quality of the conversations people are willing to have with each other.
Technology is one of the tools we use to improve those things. Not always the most important one.
Platforms matter. Architecture matters. Getting the technology right matters.
But in my experience they're usually consequences, not causes.
The real work is helping an organisation understand itself well enough to move with confidence.
The architecture tends to get better once that starts happening.
That's why I've come to think leadership is mostly diagnosis.