The first engineering team I led at scale had two people who were, without question, better engineers than me. One could hold an entire distributed ledger reconciliation flow in his head and spot a race condition by reading a stack trace the way other people read a menu. The other had forgotten more about Postgres query planning than I will ever know. And I was their boss. On paper that looks like a problem. In practice it was the best thing that could have happened to me.
Somewhere along the way we picked up the idea that the person running an engineering org should be the strongest technical mind in it. That belief is quietly destructive, and it gets worse the more senior you become. I want to talk about what actually works when you are leading people who can out-code you, because I have been on both sides of it, and the version most people fear is not the version that happens.
The fear underneath is mostly ego
Let's be honest about what the anxiety really is. It is not "the team will make bad decisions." It is "someone will ask me a question in a meeting and I won't know the answer and everyone will realize I don't belong here." That is a status fear wearing a competence costume. I felt it acutely in my first year as a director, sitting in an architecture review while two staff engineers argued about idempotency keys in our payments API, and I understood maybe seventy percent of the words.
The instinct in that moment is to bluff, steer the conversation somewhere you feel safe, or overrule people to reassert that you are in charge. All three are poison. The team can smell a bluff from across the building, and every time you overrule strong engineers on technical grounds you don't fully grasp, you teach them that being right is less important than reading your mood. That is how you end up with a room full of talented people who have quietly stopped telling you things.
What your job actually is now
Here is the reframe that took me too long to reach. Your job is not to have the best answer. Your job is to make sure the best answer gets found, gets heard, and gets shipped. Those are completely different skills, and the second set is scarce in a way the first is not. Every good company has strong individual engineers. Far fewer have leaders who can turn a room of strong engineers into something coherent.
Concretely, that means you are responsible for the things your best engineer usually is not thinking about, and often does not want to think about:
- Whether the thing we are building is the thing the business actually needs in nine months, not the thing that is most interesting to build this sprint.
- Whether two teams are about to build the same abstraction in slightly incompatible ways.
- Whether the person quietly carrying the on-call load is three weeks from burning out.
- Whether the auditor, the regulator, and the risk team will accept the design before we have poured six months of engineering into it.
- Whether we can actually hire and retain the people needed to run this system once it exists.
None of that shows up in a code review. All of it is the difference between a project that ships and one that dies eighteen months in with a beautiful architecture nobody can operate. That is your terrain now. Own it without apology.
Asking the dumb question is the actual work
The single most useful phrase in my vocabulary is "walk me through that like I'm not going to remember any of it." I say it constantly, in front of everyone, with zero embarrassment. Early on I thought asking basic questions would expose me. The opposite happened. When the person in charge is willing to say "I don't follow, explain it again," it gives everyone else in the room permission to admit they were lost too. And half the time they were.
There is a second, sharper benefit. When a genuinely brilliant engineer has to explain their design to someone who won't just nod along, the explanation itself surfaces problems. I cannot count the number of times a staff engineer got halfway through explaining a scheme to me, stopped, and said "…actually, that doesn't work, does it." The magic was not my technical insight. It was that I made them say it out loud to a skeptical, non-expert audience. Rubber-duck debugging works on architecture too, and you get to be the duck.
The most dangerous person in a technical review is the one who understands enough to sound convincing but not enough to be caught. The safest is the one who freely admits what they don't know and asks until they do.
Judgment is not the same as knowledge
You do not need to know how a Kafka consumer group rebalances to know that a design depending on that behavior being instant is fragile. You do not need to be able to write the retry logic to ask "what happens to a payment that is in flight when this node dies?" The senior skill is knowing which questions have expensive wrong answers, and pointing the strong engineers at them.
I inherited a fraud-scoring service once that the previous team was enormously proud of. Technically it was gorgeous. It was also single-writer, and the whole business plan assumed we would triple transaction volume in a year. Nobody on that team was a worse engineer than me. But they had fallen in love with the elegance and stopped asking the boring operational question. I did not fix it by out-engineering them. I fixed it by refusing to approve the roadmap until someone showed me the load numbers at 3x. That took an afternoon of digging and saved us a very ugly quarter.
Your real currency is trust, not being right
Strong engineers give their best work to people they respect, and they respect leaders who are consistent, who back them in front of other departments, and who don't pretend. The fastest way to lose a great engineer is to take credit for their thinking or to hang them out to dry when something breaks. The fastest way to keep one is to be the person who says "that was my call, not theirs" when the postmortem gets uncomfortable.
I have watched technically weaker leaders build ferociously loyal, high-output teams, and I have watched brilliant ones preside over quiet, resentful ones. The difference was almost never the leader's coding ability. It was whether the engineers felt the leader was on their side and had their back with the parts of the org that engineers can't or won't handle: the budget fight, the pushback on an insane deadline, the difficult conversation with the executive who wants a feature that would violate our licensing terms.
Where you cannot abdicate
Now, this is where some leaders take the wrong lesson and go fully hands-off, treating "I'm not the most technical" as a license to check out of technical decisions entirely. That is its own failure. Deferring to expertise is not the same as abandoning judgment. In regulated fintech especially, there are decisions where the buck genuinely stops with you regardless of who wrote the code.
If an engineer wants to log full card numbers to debug a stubborn issue, "they know more than me" is not a defense you can give a regulator. If someone proposes storing customer funds and operational cash in the same ledger account because it is simpler, that is not a technical preference, it is a compliance line, and you hold that line even when the more technical person in the room is frustrated with you. You need enough literacy to know which conversations are actually about risk wearing a technical disguise. Get that literacy. Read the incident reports. Sit in the reviews. Learn the shape of the system even if you can't build it.
Close the gap, but honestly
I am not arguing you should stay ignorant. I read our codebase. I pair occasionally, badly, and I let people laugh at me for it. I keep a running list of concepts I nodded past in meetings and work through them on weekends. Not so I can win technical arguments, but so I can follow the ones that matter and ask better questions next time. The goal is not to become the best engineer in the room. That ship has usually sailed by the time you are leading a real organization. The goal is to never be so far behind that you can't tell a good argument from a confident one.
There is a tempting shortcut here, which is to lean entirely on one trusted lieutenant to translate all technical reality for you. Be careful with that. A single filter between you and the ground truth becomes a single point of failure and, occasionally, a single point of manipulation. Triangulate. Talk to more than one person. The junior engineer who just joined often sees the thing the tenured architect has learned to stop noticing.
The quiet advantage nobody mentions
Here is something I did not expect. Not being the smartest technical person forced me to build a team that did not depend on me being it, and that team was more resilient than any I had run before. When the leader is the hero engineer, the organization has a ceiling exactly the height of that one person, and a bus factor of one. When the leader's job is explicitly to multiply other people's judgment, the whole thing scales past any single human, including the ones who leave.
My most technical hire ever left after two years for a founder role. It stung. But because I had never built the team around my own or his brilliance, we barely wobbled. Three people had absorbed pieces of what he knew because the culture rewarded explaining over hoarding, and explaining was rewarded because the guy running the place needed things explained. My weakness, if you want to call it that, had accidentally become an organizational strength.
Conclusion
If you are reading this because you just got a title that outranks your ability to code, I will leave you with the thing I wish someone had told me: the engineers you are afraid of impressing are not evaluating your syntax. They are evaluating whether you will make their work matter, whether you will tell them the truth, and whether you will stand between them and the chaos of the rest of the company. Be excellent at that, stay curious enough to follow the hard conversations, hold the line where the line is yours to hold, and the fact that someone in the room can write a tighter loop than you will turn out to be exactly the point. You hired them to be better than you. Now let them, and go do the job only you can do.