About seven years into my career in organizational development, I moved into a role that required me to manage a team of people whose specific domain expertise — behavioral economics, computational organizational science, advanced learning design — significantly exceeded mine. In the roles I'd held previously, I'd been at least as technically knowledgeable as the people I managed in most areas, and there was something comfortable in that. I could evaluate the quality of their work directly, offer substantive guidance on their approaches, and intervene when I saw a better path. With this new team, I couldn't do any of those things reliably. I could sense when something seemed off, but I couldn't always explain why, and I was genuinely dependent on people whose expertise I could evaluate only in aggregate, through outcomes, rather than at the level of specific decisions.
My instinct in the early months was to compensate through what I did understand: process, structure, and integration. I focused on how the work was organized and coordinated, on the interfaces between the team's work and the rest of the organization, on the conditions that would let experts do their best work. I worried that this was a deficiency — that I was managing around my knowledge gap rather than closing it. In retrospect, it was exactly the right approach, and it produced the best team outcomes I've been part of. What took me longer to understand was why.
The management of people with domain expertise that exceeds the manager's is not a deficient version of the management of people whose expertise doesn't exceed it. It's a different kind of management that requires a different orientation and a different set of practices — one in which the manager's role is enabling rather than directing, and where the value the manager adds has nothing to do with technical knowledge. Understanding this distinction clearly is the most important thing a manager in this situation can do, because the manager who tries to compensate for their knowledge gap by over-directing produces outcomes that are consistently worse than the manager who understands their actual contribution.
What you actually add
The manager who is less expert than the people they manage adds value in three specific areas that have nothing to do with technical knowledge.
Context and translation. The manager understands the organizational environment — the political dynamics, the competing priorities, the decision-making patterns of senior leadership — in ways that domain experts typically don't and often can't, because their energy is correctly invested in their domain. The manager's ability to translate between the domain expert's work and the organizational context it operates in — to help the expert understand what matters to key stakeholders and why, and to represent the expert's work in terms that organizational stakeholders can evaluate — is genuinely valuable. It's not glamorous, but it's the management function that most directly enables expert work to have organizational impact.
Resource and obstacle management. The manager's access to organizational resources, relationships, and decision-making authority gives them the ability to clear the path for expert work in ways the expert often can't. The expert who needs a budget line that requires executive approval, a cross-functional partnership that requires a relationship the manager has and the expert doesn't, or protection from organizational pressures that would compromise the integrity of their work — these are management contributions that don't require domain expertise and that the expert is poorly positioned to provide for themselves.
Outcome evaluation and integration. The manager who can't evaluate the quality of an expert's process can often evaluate the quality of the outcomes it produces in terms of organizational impact — whether the work is actually serving the purposes it was intended to serve, whether it's being understood and used by the people who need to use it, whether it's connecting to the right problems. This outcome-level evaluation is different from the process-level evaluation that domain expertise enables, but it's not less valuable — it's a different angle on quality that the domain expert is often poorly positioned to provide for themselves.
The questions that work regardless of expertise
The manager of domain experts who doesn't have domain expertise needs a set of questions that are genuinely useful across domains — questions that help the expert think more clearly, that surface important considerations, and that enable the manager to contribute without requiring them to have knowledge they don't have.
"What's the key assumption here, and what happens if it's wrong?" This question doesn't require domain expertise to ask and is often among the most valuable questions in any domain, because expert work tends to rest on assumptions that are worth surfacing and stress-testing. The expert who is asked this question clearly, from a position of genuine curiosity, will often find that articulating the key assumption is itself clarifying.
"Who needs to understand this, and what does their version of the question look like?" This question uses the manager's organizational knowledge to help the expert think about how their work translates to different audiences. The expert who is excellent at the domain often needs help thinking about how to communicate their work to people who don't share their domain knowledge — and this is precisely the area where the manager's organizational knowledge is an asset.
"What would make you more confident in this direction?" This question is useful in any domain and from any position of expertise because it surfaces what the expert themselves sees as the limiting uncertainty in their current thinking. It gives the manager visibility into where the expert's own confidence is highest and lowest, which is genuinely useful for decisions about how much to invest in additional validation before proceeding.
"What do you need from me to do this well?" This question is direct and produces actionable information. It positions the manager correctly as an enabler and gives the expert the opportunity to specify the kind of support that would actually be useful, rather than receiving the kind of support the manager thinks they need. The answers are often surprising and almost always more useful than the generic support the manager would have offered without asking.
The authority question
The most common mistake managers make with domain experts is using positional authority to override domain judgment in situations where the domain judgment is better. The manager who doesn't understand why an expert is recommending a particular approach and redirects based on their own instinct — which is not informed by domain expertise — is substituting organizational authority for domain knowledge in a way that produces worse outcomes and erodes the relationship.
The appropriate use of positional authority in the management of domain experts is narrower than most managers exercise: decisions about organizational priorities, resource allocation, and outcomes are legitimately the manager's. Decisions about how to achieve those outcomes in a domain where the expert's knowledge is superior are not. The manager who has clarity about this distinction — who can say "my job is to be clear about what success looks like and to create the conditions for you to achieve it; your job is to determine how to achieve it" — enables expert work in a way that the manager who conflates organizational authority with domain authority cannot.
This doesn't mean the manager never pushes back on domain decisions. When the manager has genuine organizational knowledge that's relevant — about what stakeholders will accept, about precedents that constrain what's possible, about how similar work has played out in the past — that input is valuable and should be offered. But it should be offered as information, not as direction: "here's a consideration that might be relevant to your recommendation" rather than "here's what I think you should do." The expert receives information better than they receive override, and the distinction between the two is exactly the discipline that makes managing from self-awareness rather than from the discomfort of not-knowing possible.
Building credibility without domain expertise
The most durable form of credibility available to a manager of domain experts is not technical credibility — it's judgment credibility: the track record of making good organizational decisions, navigating the organizational environment effectively on behalf of the team, and being reliable about what you commit to. Experts quickly learn to distinguish between managers who are adding genuine value and managers who are consuming the team's time and energy without returning it in organizational value. The manager who is consistently clearing obstacles, accurately representing the team's work to stakeholders, and making good calls about priorities and resources will earn credibility that doesn't require technical expertise. The manager who is trying to seem technically capable while providing organizational value they're not actually delivering will not.
The most direct path to that credibility is doing the things that are actually the manager's job well — and resisting the pull toward the things that feel more substantial but aren't actually the manager's contribution. The conditions that make teams high-performing are the manager's responsibility to build regardless of whether the manager has domain expertise; the specific path to those conditions when the team has expertise the manager lacks is clarity about role, excellent enabling questions, and consistent follow-through on the organizational obligations the manager is actually best positioned to fulfill.