Early in my run managing network operations for a Saskatchewan telecom, I sat in a design review where a senior engineer walked the room through a routing failover plan I did not fully understand. I could follow maybe 70 percent of it. The other 30 percent involved protocol behavior he had spent a decade learning and I had spent zero days learning. He knew his corner of the business better than I ever would, and everyone in that room, including me, knew it.
That is not a problem to solve. That is the job.
If you manage knowledge workers of any kind, engineers, analysts, clinicians, accountants, designers, you will eventually run a team where several people know their craft far better than you do. Most managers treat that gap as a threat. The good ones treat it as the normal condition of leading skilled people. The difference between those two responses shapes whether your best people stay and do their best work, or quietly decide you are dead weight.
The reflex that ends careers
There is a predictable moment in a management career, usually the first time you supervise people whose specialty is not yours, where the ground shifts. Someone asks you a question you cannot answer and, worse, cannot fully understand. Wanda Wallace and David Creelman, writing in Harvard Business Review, call this the point where careers derail. Their observation matches everything I have watched over 25 years: leaders who came up on an expertise track react by leaning on the very thing that got them promoted. They go home, read the manuals, and try to claw their way back to being the smartest person in the room.
It never works. You cannot out-study a specialist who does the work eight hours a day while you are in budget meetings. Every hour you spend trying to match their depth is an hour you are not spending on the things only you can do. And your team notices immediately. Nothing tells a senior engineer you are insecure faster than watching you pretend to understand a system you clearly do not.
An earlier HBR piece from 2010 put it plainly: when your employees know more than you, the instinct to dive into the details is the road to disaster. The authority you are reaching for was never going to come from technical mastery. It has to come from somewhere else.
But “just facilitate, you don’t need to know anything” is also wrong
Here is where most of the advice on this topic goes soft. The comfortable version says your job is purely to remove obstacles and inspire people, and technical understanding does not matter at all. That is not what the evidence shows.
Benjamin Artz, Amanda Goodall, and Andrew Oswald ran one of the first serious economic studies on how bosses affect the quality of employees’ working lives. Their finding, published as Boss Competence and Worker Well-Being, was blunt: a boss’s technical competence is the single strongest predictor of a worker’s well-being, ahead of pay, ahead of education, ahead of industry. Even when a worker stayed in the exact same job, getting a more competent supervisor measurably improved their satisfaction.
Goodall’s broader body of work, what she calls the theory of expert leadership, points the same direction. In healthcare, hospitals led by physicians rather than career administrators posted roughly 25 percent higher quality scores across the specialties she studied. The pattern repeats in universities, in professional services, even in Formula 1 and basketball. Leaders who genuinely understand the core work tend to run better organizations. Economists have found the association between physician leadership and hospital performance robust enough to take seriously.
So we have a real tension. Trying to be the deepest expert derails you. Being technically clueless makes you a worse boss. Both things are true, and the space between them is where the actual skill lives.
The kind of competence that matters is not the kind you think
The resolution is that “competent” does not mean “most expert.” It means you understand the work well enough to make good judgment calls about it. You do not need to be able to configure the router. You need to understand what a routing failover is for, what happens to customers when it fails, roughly how long a fix takes, and what a good plan looks like versus a rushed one.
Wallace and Creelman describe leading these broad roles as developing enough understanding to be a credible participant in the conversation without being the one holding the wrench. I think of it as the difference between watching a sport closely for years and playing it professionally. A serious fan cannot take the field, but they can tell you when a play was smart, when a call was lazy, and when something is off. That is the level of understanding you are aiming for: enough to ask a sharp question, enough to smell a shortcut, enough to tell the difference between a hard problem and an excuse.
That understanding is completely achievable, and it comes from paying attention, not from cramming. In my telecom years I never learned to write the engineer’s configs. But after enough failover reviews I could tell when a plan had a gap, because I had learned what good ones sounded like. That was enough to be useful, and my engineers could tell the difference between a boss who was engaged and one who was faking it.
What your job actually is when they know more than you
Once you let go of being the expert, the real work gets clearer. It is not glamorous and it is not technical, and almost none of it shows up in your team’s specialty.
Set direction they cannot see from where they sit. Your specialists are heads-down in their craft. You are the one who knows what the business needs next quarter, which customer is about to churn, why the priority just changed. Translating that into a clear destination is your work, and it is the foundation of giving a team commander’s intent instead of step-by-step instructions. You supply the where and the why. They own the how.
Judge outcomes, not methods. This is the discipline most former specialists struggle with. You are not qualified to evaluate whether they chose the right protocol. You are entirely qualified to evaluate whether the failover worked, whether it shipped on time, whether customers noticed. Manage to results and let people who know more than you decide the path. This is also the cleanest antidote to becoming the bottleneck your team has to route around.
Remove the obstacles only you can remove. Budget, headcount, the cross-team dependency that keeps stalling, the executive who keeps changing the spec. Your experts cannot fix any of that. You can. Clearing the road is often the single most valuable thing you do all week.
Build the team’s judgment, not just its output. The strongest technical people still need someone developing their ability to prioritize, to communicate, to make tradeoffs. You may not out-code them, but you have almost certainly seen more projects succeed and fail than they have. That perspective is worth a great deal, and it is the heart of coaching people rather than just directing them.
Credibility comes from candor, not from faking it
The fastest way to lose a room full of experts is to bluff. They will catch it, and once they catch it, everything else you say gets discounted.
The move that actually builds authority is the opposite of what insecurity tells you to do. Say the true thing: “You know this far better than I do. Walk me through it, and tell me where I’m wrong.” I have said versions of that sentence hundreds of times, to network engineers, to database administrators, to senior developers as a fractional COO. It never once cost me credibility. It bought it. People trust a leader who is honest about the edges of their knowledge far more than one who pretends there are no edges. If that honesty feels risky, it is worth reading why asking for help tends to raise your standing rather than lower it.
Candor also protects the relationship in the other direction. When you are transparent that they are the expert, you make it safe for them to tell you hard truths, which is exactly what you need from people who can see problems you cannot. That kind of two-way trust is the whole foundation, and it is worth being deliberate about how you earn it as a manager.
The questions that do the work
If you are not supplying answers, you had better be asking good questions. Over the years these are the ones that consistently earned their keep with people who knew more than me:
- “What are you most worried about with this plan?” It surfaces the risk the expert already senses but has not said out loud.
- “If this fails, where does it fail first?” It separates people who have thought it through from people who are hoping.
- “What would you do if it were entirely your call?” It tells you what they actually believe, before politics sands it down.
- “What does this cost us if we wait a month? A quarter?” It converts technical depth into business terms you can act on.
- “What would have to be true for this to be the wrong approach?” It invites the smartest people in the room to stress-test their own thinking.
None of these require you to know the domain. All of them require you to have thought seriously about how work succeeds and fails, which is the thing you are actually paid for.
The reframe
The manager who fears being outclassed by their team has the relationship backwards. You did not get hired to be the best individual contributor. If you were, promoting you was a waste of a great specialist. You got hired because setting direction, clearing obstacles, judging outcomes, and developing people is a different job, and a genuinely hard one.
The engineer who walked me through that failover plan stayed on my team for years. Part of the reason, he told me much later, was that I never once pretended to know his job better than he did, and I never once got in his way when he did it well. That is the whole arrangement. Your people bring depth you will never match. You bring the judgment, direction, and cover that lets that depth turn into results. Stop trying to be the smartest person in the room. Be the reason the smartest people in the room can do their best work.