Early in my time running engineering at a payments company, I sat in a design review for a ledger rewrite and realized, about ten minutes in, that I could not follow the argument. Two of my engineers were debating idempotency keys and reconciliation windows, and I was quietly nodding while my brain buffered. I had written ledgers before. I was still lost.
That was the moment I stopped thinking of my job as being the best engineer in the room. It was a relief, honestly, and also a small grief. If you lead long enough, you will manage people who are flatly better than you at the thing you were hired for. The question is whether you treat that as a threat or as the point.
The day I got outgrown
The engineer in that review, I will call her Priya, joined us as a senior and was a staff engineer within eighteen months. She reasoned about distributed failure the way I reason about grocery lists. My first instinct, which I am not proud of, was to compensate by reviewing her pull requests more aggressively. I wanted to find something. I wanted to prove I still belonged in the conversation.
It took me two or three weeks of leaving nitpicky comments before I saw what I was doing. I was spending my scarce attention trying to look smart in front of the one person who least needed me to be smart, and in the process I was slowing down our most valuable work. That is a lousy trade. The math on a CTO's time does not support it.
Hiring up is the actual job
Every leadership book says hire people smarter than you, and then most leaders quietly don't, because it is uncomfortable. I get it. There is an ego cost. But the alternative is worse: you become the ceiling of your organization. If nobody on the team knows more than you about anything, you have built a company that can only be as good as one tired human who also has to sit in board meetings.
I now measure my own hiring by a blunt test. In the interview, did the candidate teach me something I did not know, or correct a wrong assumption I held? If yes, that is a strong signal. Some of my best hires made me slightly uncomfortable in the loop, because they pushed back on my framing of the problem before they had the job. The ones who only agreed with me were easier to talk to and much less useful later.
You cannot review everything anymore
There is a fantasy some technical leaders hold onto where they stay across every meaningful decision by reading enough code and sitting in enough reviews. At a team of five, maybe. At thirty, it is a delusion, and a dangerous one, because your half-informed opinion carries the weight of your title. You can casually derail a good decision with a comment you would never have made if you had the full context the team spent two weeks building.
So I changed what I review. I stopped trying to verify correctness on things the team clearly understood better than me, and started reviewing for a different set of questions: is this reversible, is it observable, does it fail safely, and who is on the hook when it breaks at 2am. Those are leadership questions, not cleverness questions. They are also, conveniently, the ones where my broader view of the business actually adds something.
Ask more, decree less
When you don't fully grasp the technical detail, the worst move is to fake it and issue a verdict. The second worst is to go silent and rubber-stamp. The thing that works is asking real questions, the kind that expose your gaps honestly. "Walk me through what happens if the downstream provider times out mid-settlement" tells the team both that you don't know and that you care about the right failure mode.
Good engineers respect a leader who asks a sharp question far more than one who pretends to already know the answer. And a genuinely dumb-sounding question from the person in charge gives everyone else permission to admit they were confused too. I have watched a whole room exhale after I said "I don't actually understand why we need two queues here" and it turned out three other people didn't either, including one who had already started building the second queue.
Credibility is a ledger you can overdraw
The tricky part of managing people who outclass you technically is that your authority is not automatic. It is earned and spent, and you can go bankrupt. Every time you overrule an expert on their home turf and you turn out to be wrong, you make a withdrawal. Do it a few times and your input gets quietly routed around. They will nod politely and then do the right thing anyway.
The fastest way to lose a brilliant team is to keep winning arguments you had no business entering. Save your capital for the calls only you can make.
So I try to be deliberate about where I plant my flag. On a pure technical detail where a staff engineer disagrees with me, my default is to assume I am the one missing something and to say so out loud. On questions of risk tolerance, sequencing against a regulatory deadline, or which customer commitment we are willing to break, that is my ground and I will hold it firmly. Knowing which is which is most of the skill.
Your job is to clear the road
Once you accept you are not the smartest technical person on the team, a much better use of your time appears. Smart engineers are usually blocked by things that have nothing to do with intelligence: a procurement process that takes six weeks, a security review with no owner, a second team that will not prioritize an API change, a vague requirement from a product manager who is themselves getting vague answers from sales.
These are problems I am actually good at, because they are organizational and political, and I have positional power the engineers do not. The most concrete value I added last quarter was not a line of code. It was getting a compliance sign-off unstuck by walking down the hall and having a fifteen-minute conversation that an engineer would have waited three weeks for over email. That is the kind of pull only I have, and it is invisible unless you go looking for it.
When you overrule them anyway
Deferring to expertise is not the same as abdicating. There are moments where I overrule the smartest person in the room on purpose, and I want to be honest about when. It is rarely because I think their engineering is wrong. It is almost always because they are optimizing for something that is not the thing the business needs right now.
A few situations where I will pull rank even against a better engineer:
- When the elegant solution takes six weeks and a rougher one ships in five days before a regulator's deadline that is not moving.
- When a decision quietly increases our blast radius in a way the person proposing it is not weighing, because it is not their pager that rings.
- When two strong engineers are deadlocked and the cost of the debate now exceeds the cost of picking a direction and correcting later.
- When the choice locks us into a vendor or an architecture that constrains options I can see coming and they cannot, because they are not in the commercial conversations.
When I do overrule, I explain the reasoning fully, and I name it as a business call rather than dressing it up as a technical one. Pretending I won on the merits when I actually won on authority is how you turn a smart engineer cynical. They can tell the difference. Respect the fact that they can tell.
Be the shield, not the funnel
A team of very capable people attracts demands. Executives want their pet project fast-tracked, sales wants a bespoke integration for a deal that may not close, another department wants to borrow your best person for a quarter. If all of that flows straight to the team, your smart people spend their genius on context-switching and defending their time instead of building.
Part of managing up-talent is absorbing that pressure and metabolizing it before it lands. I say no on their behalf a lot. I take the awkward meeting so they don't have to. When something does have to interrupt the roadmap, I try to bring them the why, not just the what, so it feels like a decision they were part of rather than a demand dropped on their desk. People who could work anywhere stay for the feeling that their time is treated as precious.
Stay technical enough to be dangerous
None of this means letting your own skills rot. If you drift too far from the work, you lose the ability to ask the sharp question, and then you are just a manager with a title reacting to summaries. I still read designs. I still occasionally pick up a small, unglamorous task, partly to feel the friction of our own tooling, partly to remind myself what it is like to wait forty minutes for a flaky test suite that everyone has learned to tolerate.
The goal is not to keep pace with your best engineers on their deepest specialty. You won't, and chasing it is vanity. The goal is to stay technical enough that you can smell when something is off, translate between engineering and the business without garbling it, and earn the standing to be listened to when you do use your one big veto. Fluency, not mastery.
Conclusion
Here is the thing nobody tells you: managing people smarter than you is not a problem to be solved, it is the sign you did the earlier part right. If you find it threatening, you will hire down, protect your ego, and slowly build a mediocre team that makes you feel comfortable. If you find it exciting, you get to spend your days around people who make you sharper and build things you could not have built alone. I know which of those I would rather run. Priya is a principal engineer somewhere better than us now, and I count that as a win, not a loss. Your job was never to be the smartest person in the room. It was to make sure the smartest people in the room could do their best work, and then to get out of the way with the good grace to enjoy it.