Leading People
The Engineer You Ignore Today Is the Leader You Need in Two Years
Principal Architect · 4 June 2026 · 5 min read
There was a bloke on a data centre migration I ran who said perhaps four sentences in any given design review. All four were the reason the design worked. I put someone else forward for the team lead role, because the someone else had ideas in meetings and this chap had a monitor full of spreadsheets and a habit of looking at his shoes.
You promote the visible, and visibility is not the skill
Be honest about how you actually pick people. You pick the person who comes to mind. And the person who comes to mind is the one who talks in meetings, who replies to your messages within four minutes, who tells you what they've done rather than just doing it.
None of that is a bad thing. Communicating well is genuinely part of the job. But it's one part, and you are almost certainly weighting it far more heavily than you intend, because it's the part you can see from where you sit.
The things you can't see from where you sit: who the team actually asks when they're stuck. Who quietly rewrites the migration plan the night before because they spotted a dependency nobody else did. Who de-escalates the thing between two engineers that would otherwise have been on your desk by Thursday. Whose changes never come back.
Go and check that last one, seriously. In most teams there's someone whose work simply doesn't generate incidents, and because it doesn't generate incidents, it doesn't generate conversations about them either. They're invisible in exact proportion to how good they are.
Mentoring the quiet one is a resourcing decision, not a kindness
Here's the framing that changed how I spend my time. Developing people isn't a nice thing you do when the delivery pressure eases off. It's the only mechanism you have for increasing the number of situations that don't require you.
A worked version. A 40-person engineering function inside a car parts manufacturer, with one person, the principal, who has to be in every significant design conversation. He's in four workshops a week. He's the review bottleneck. Delivery dates now move based on his annual leave. Everyone can see this and everyone's solution is to hire another principal, which takes nine months and might not work.
The cheaper move sits inside the team already. Two engineers in that function could do most of what he does, in a narrower domain, within a year. They're not short of capability. They've simply never been allowed to be the person in the room who decides.
So you buy that. Not with a course. You give one of them the plant network design workstream, entirely, including the conversation with the vendor and the bit where they defend the choice to the architecture forum. You sit in the room and you keep your mouth shut, which is the hard part, and you debrief for twenty minutes afterwards.
Twelve months of that and your principal is in two workshops a week instead of four, and you have three people who can hold a design conversation instead of one. No hiring process required. The cost was your discomfort and a handful of decisions that came out slightly differently from how you'd have made them.
"Build your confidence" is not a goal and never was
If you're going to mentor someone, the goal has to be a thing that happens in the world, on a date. Most mentoring dies because the goals are weather: grow, stretch, develop, gain exposure. Nobody can tell whether any of that happened, so nobody checks, so the meetings stop.
Compare these.
Weak: "Take on more of a leadership role this year." Nothing is testable. Nothing happens.
Strong: "You run the Thursday change review for the next eight weeks. I'll be there and I won't speak unless you ask me a direct question. After each one we'll spend fifteen minutes on what you'd do differently. At the end of the eight weeks I want you telling me which two of those changes should have been rejected and weren't."
The second one has a date, a scope, a specific behaviour from you, and an outcome you can both look at. It's also mildly terrifying for the person, which is the point. Nobody ever grew into leadership from a position of total comfort.
The rule I'd hold you to: give them something slightly too big, and stay in the room. Too big with no support is abandonment, and people fail in ways that dent them for years. Too small with lots of support is babysitting. The useful zone is the task they think they might not pull off, with you visible, saying nothing, ready to catch the genuinely dangerous mistake and let all the survivable ones happen.
What this costs you, honestly
It costs you decisions you'd have made better. It costs you a slower Thursday. For a while, it costs you the quiet satisfaction of being the person who knows.
And you will be tempted, in week three, in a meeting that's going sideways, to step in and take the pen back. If you do, you've undone most of it, because everyone in the room now knows the mentoring was conditional on it going smoothly.
Let them have the bumpy meeting. Debrief afterwards, in private, and be specific about the two things you'd have done differently. That's the trade: a slightly worse Thursday this quarter in exchange for not being the bottleneck next year.
Monday morning
Write down the name of the person on your team who's least visible to you and whose work never causes you trouble. One name.
Then find a meeting in the next fortnight that you currently run, and give it to them. Tell them you'll be there and you won't speak. Say it out loud at the next stand-up, so the whole team hears whose meeting it is now and you can't quietly take it back in week three.
Principal Architect
Founder of the Institute of Technical Leadership, writing from two decades of technical delivery.


