I have been thinking about why I love leading engineers.
Excuse me, builders.
Maybe that correction is the whole point.
The engineers I have been fortunate enough to lead have tended to want something quite simple, though not easy: mastery of their craft.
Not status. Not games. Not politics.
They want to understand the problem, make the thing work and make it work well. Then, just when everyone else thinks it is finished, they notice the inelegant bit in the corner and want to make that better too.
I love that about them.
I love the care. The curiosity. The deep emotional attachment to something they have brought into the world.
I also know this is not every engineer. It would be too easy, and probably unfair, to turn a group of interesting, complex, intriguing people into a flattering stereotype. I can only speak about the people I have had the privilege of leading, and what I have noticed while trying to do that job well.
One of those things is a lovely paradox.
They can get completely caught on a noun, on whether we are using precisely the right word for precisely the right thing, and still operate remarkably well in the grey.
They want the language to be exact, even when the work cannot be.
Maybe precision is how they find their footing in all that uncertainty.
Many of them have been far better at building excellent things than at making sure the organisation understands the value of what they built.
Their work speaks for itself, they think.
Sometimes it does.
Sometimes it whispers quietly in a corner while someone else presents a much shinier slide deck.
Helping engineers build their brand inside an organisation is one of the parts of leadership I enjoy most. Not because I want to make them more political or teach them to perform a version of themselves that does not feel true. I want to help them make their contribution visible without asking them to become someone else.
To connect the careful technical decision to the customer experience it protected.
To explain why the invisible work mattered.
To speak about their impact with the same clarity they bring to their code.
And yes, they can also be stubborn little squirrels.
They chase the new thing. They disappear down technical rabbit holes. They become deeply attached to what they have built, sometimes because it is the right solution and sometimes, perhaps, because it is theirs.
I say this with enormous affection. I have also been stubborn about things I have poured myself into. It is difficult to separate the work from yourself when the work carries so much of your thinking, time and care.
AI is making that attachment more complicated.
When code can be generated faster, the uncomfortable question is what, exactly, an engineer’s value becomes. I imagine that question can feel threatening when mastery has been measured, at least partly, through the ability to produce the code itself.
I do not think the answer is that engineers matter less.
I think their value has always stretched far beyond the code. I am just not sure organisations, leaders, or even engineers themselves, have always been very good at recognising it.
The value is in knowing which problem is worth solving.
It is in understanding the trade-offs beneath a seemingly simple decision. It is in noticing what might break, who might be affected and whether the thing being built will produce the outcome everyone keeps saying they want.
It is judgment. Curiosity. Context. Taste. Care.
It is the ability to argue passionately about a noun and still move forward when there is no perfectly correct answer.
It is building, not merely coding.
This next chapter asks something different of the people I lead, and therefore something different of me.
I will need to help builders loosen their grip on the idea that their value lives in the lines of code they personally wrote. That may be harder than it sounds. Code is tangible. It can be inspected and improved. Outcomes are messier. They involve people, competing priorities and variables no one can completely control.
I will also need to be careful not to dismiss the emotion involved. Telling someone that their value is ‘more than the code’ may sound encouraging from the outside. From the inside, it may feel as though the craft they spent years mastering is being quietly taken away.
I do not yet know how to lead perfectly through that.
Perhaps it begins with making room for both things to be true: the craft still matters, and the definition of the craft is expanding.
The builders I know are more than capable of making that shift. But capability does not make change painless.
This is the next positive leadership challenge I am excited to take on: helping people who care deeply about what they build recognise that their greatest value may not be the code itself.
It may be everything they understand well enough to build, and everything they care enough to make better.