“Supervisors are not supposed to know more about the work than the people doing it.” Peter Cappelli said that. He directs the Center for Human Resources at Wharton, and he was quoted in SHRM’s piece on managing workers who are older and more experienced than you from 2020.
If you’ve just been put in charge of people who know the work better than you do, that sentence is worth sitting with. It’s tempting in this spot to assume the gap is the problem and that the fix is to close it. That would mean reading everything and learning the tools until nobody can ask a question you can’t answer. You won’t get there, and you don’t need to. The people on your team have years on you in their craft, and they’ll keep those years. But closing that gap isn’t what you’re there for. You decide what the team works on and in what order, and what it commits to other teams and to customers. You also set the standard for what counts as finished, and you hold people to it. None of that requires you to be the best at the work itself.
This guide is about making that split clear and then living with it. It starts with what to do in your first two weeks and what to say in the first conversation with someone who knows more than you. Next it gives a plain way to decide who recommends and who decides. After that comes the hardest case, which is managing the person who wanted your job. It also covers where this advice stops working, because there are a few places where it does.
Why is it hard to manage people more experienced than you?
Part of the difficulty is that two different problems usually get lumped together under one heading, and they need different fixes.
The first is an experience gap, where your team knows the work better than you. A senior engineer has been reading this codebase for eight years. A compliance specialist has seen every audit the company has been through. You came from a neighboring function or from a smaller version of the job, and now you’re expected to lead people whose decisions you can’t fully check. You solve this one mostly by being clear about who decides what, and that’s what most of this post is about.
The second is an age gap, where some of the people you manage are older than you. SHRM’s 2020 piece also cites a Harris Interactive survey for CareerBuilder, which found that “nearly 4 in 10 U.S. workers had a younger boss.” That’s US data, and SHRM doesn’t give the survey’s year. Even so, it’s enough to say that a younger manager is ordinary and isn’t a sign that something has gone wrong. You solve this one mostly by how you talk. Show the same respect you’d give any capable colleague, and give direction plainly. Don’t make assumptions about what someone wants or can do because of how old they are.
The two don’t always travel together. A 28-year-old can lead a 24-year-old specialist who knows far more about the work. Or a 45-year-old new manager might lead a 55-year-old colleague who has no more experience in the function than they do. That’s why it matters which one you’re facing. If you treat an expertise problem as an age problem, you’ll end up being careful about tone when what the person actually needed was a clear answer about who makes the call. If you treat an age problem as an expertise problem, you’ll defer on decisions that were yours to make.
The experience gap is also more common than it looks, because it happens to good specialists too. Wanda Wallace and David Creelman put it bluntly in their HBR article on leading people who know more than you: “If you’re a manager in a knowledge-driven industry, chances are you’re an expert in the area you manage.” The trouble starts when you’re promoted into an area outside that expertise. “This is the point where careers can derail,” they write.
If the people you now manage were your peers last month, that brings its own awkwardness. Our guide to moving from peer to manager covers it. The gap might also show up mostly as a quiet feeling that you were promoted by mistake. That’s imposter syndrome after a promotion, and it has its own guide.
What should you do in your first two weeks?
Ask before you direct. This advice gets repeated a lot, usually as a way of showing humility. But that’s the wrong reason to do it. You’re asking because you need information that only your team has, and you need it before you change anything.
What you’re trying to learn is how the work really runs, which is rarely the way the process document says it does. You want to know who people go to when something breaks. You want to know what has already been tried and why it failed, and which problems everyone has stopped mentioning because they’ve given up on them. You also want to know what your experienced people were promised by your predecessor or by someone above you. That matters because a promise you don’t know about is one you’ll break by accident. Finally, find out what each of them needs from you. It’s often less than you’d expect, and more specific. One person needs someone to fight for headcount. Another needs someone to keep a noisy stakeholder off their back. A third needs someone to make a decision that’s been sitting open for months.
Listening well here is a skill, and active listening in these early meetings mostly means asking a second question instead of moving to the next topic. When someone says “we tried that in 2023 and it didn’t work,” the useful follow-up is “what went wrong with it?” The first answer tells you a fact, but the second tells you how the team thinks.
None of this means you hold back on direction for two weeks, because you can listen and still set expectations from the first day. If a deadline matters, say so. If you need status updates in a certain form, ask for them. Your team will be watching whether you’re willing to make decisions while you’re still learning. A manager who waits until they know everything will be waiting a long time. Listening is how you make those decisions better.
Our script for a new manager’s first 1:1 gives you the structure of that first one-on-one meeting with each person. The next section is about the part of that conversation that’s specific to someone who knows more than you.
What do you say in the first conversation?
This section and the next follow one illustrative example. Ingrid is a composite, not a real person.
Ingrid is a senior pricing analyst. She’s been doing pricing work for fourteen years, the last six at this company. She built the discount approval model that the whole sales team uses, and she has been through three pricing changes here. You came from sales operations, and now you’re her manager. You know how deals get done, but you’ve never set a price or had to defend a pricing model to finance.
The first thing to say is what you see in her work, and it needs to be specific. “You’ve been here a long time and you know a lot” sounds like praise. But it’s a sentence you could say to anyone, and experienced people hear that right away. What works is something only she has done: “Ingrid, the discount approval model is the reason sales can close a deal without waiting three days for finance. You’ve been through three pricing changes here. I haven’t been through any.” That tells her you’ve actually looked at her work. It also says plainly that you know where the gap is, so she doesn’t have to wonder whether you’ll pretend it isn’t there.
Next, say what you own and what she owns. This is the part that’s easiest to skip, because it feels presumptuous to say out loud. But if you leave it unsaid, she’ll work it out from how you behave. Her guess will probably be wrong in one direction or the other. Something like this works: “Here’s how I see the split. How we price is yours: the model and the analysis. You know it far better than I do, and I’m not going to second-guess the method. What I own is what we commit to. That’s which changes go out when and what we promise sales and finance, plus what the team works on first. When those two overlap, I’ll ask for your recommendation and the trade-offs. I’ll make the call after that, and I’ll tell you why.”
Saying “I’ll tell you why” matters because it’s a promise that a decision against her advice won’t come with silence, and it’s one you’ll be held to.
The last step is to ask how she wants to work with you. “How would you like to work together? What did you find useful from the last manager, and what got in your way?” Experienced people usually have a clear answer to this, and the answer saves you weeks of guessing. Some want a weekly check-in, while others want to be left alone until they need a decision. So ask, and then do what they say unless you have a reason not to.
When you don’t know the answer
Ingrid will ask you something you can’t answer at some point in the first month. Maybe it’s whether a legacy contract clause lets you change prices mid-term, or how much churn she should assume when modeling a price rise. The pull is to give an answer anyway, because not knowing feels like losing standing.
But bluffing is what costs you standing. She’ll probably know the answer is wrong within a sentence, and from then on she’ll check everything you say. It works much better to admit it plainly and turn it straight into a question: “I don’t know. What’s your read? What would you need from me to act on it?” The second question is the important one, because it moves the conversation from what you don’t know to what you can do. You might clear a blocker or get a decision from finance. Or you might tell her the call is hers to make.
There’s one limit to this. “I don’t know” is the right answer for questions about her craft, but it’s the wrong answer for questions that are your job. Say she asks what the team’s priority is this quarter or what you’ll accept as a finished analysis. If you say “I don’t know,” you’ve handed her the part of the role that was yours. So find out, and come back with an answer.
Rehearse it before you say it. Telling someone with fourteen years on you what you own is easier the second time. You can run the first conversation with Merlin first in Slack or Microsoft Teams, until the words sound like you. Self-driven sessions are private, so nobody at work sees what you practiced.
Who recommends, who decides, and who gets consulted?
This is the part of the job where the experience gap shows up most, and where clarity helps most. Almost every decision on an expert-heavy team has two layers. One layer is the best technical answer: which pricing model or architecture to use, or which way to read the regulation. That layer belongs to the person who knows the craft. The other layer is what the team does with that answer. That depends on what the answer costs and how risky it is. It also depends on when it can happen and how it affects other teams. That layer belongs to you, and sometimes you share it.
A lot of the friction between new managers and experienced people comes from mixing these up. If a manager weighs in on the method, they look like they’re second-guessing work they can’t judge. On the other side, an expert who expects to settle the commitment too ends up frustrated that their right answer wasn’t followed. What they haven’t seen is the constraint that made it the wrong move this quarter.
Peter Cappelli offers a useful picture of this from outside business. A Wharton piece on engaging older workers has Cappelli as its contributor. It notes that “The Marines tell their new Lieutenants to form a partnership with their Sergeants and work together to make decisions.” The lieutenant has the authority and the sergeant has the years, but neither does the job well alone.
Delegation gives you the vocabulary to make the split concrete. The 7 levels of delegation run from you deciding alone to them deciding alone, and three of the middle levels do most of the work on a team like this. Consult means you ask for their input and then decide. Agree means you land on an answer together and both own it. Advise means they decide, and you give your opinion first. The table below shows how that usually maps onto the decisions an expert team makes:
| Type of decision | Who recommends | Who decides | Who’s consulted | Level |
|---|---|---|---|---|
| How the work is done (method, model, technical approach) | The expert | The expert | You, when it changes cost, risk or timing | Advise |
| What the team commits to (dates, scope, promises to other teams or customers) | The expert, with trade-offs | You | Leads of the teams affected | Consult |
| Priorities and who works on what | You, after asking | You | The team | Consult |
| Standards (what “finished” means, review rules) | The expert drafts | You and the expert together | The rest of the team | Agree |
| People decisions (hiring, ratings, assignments) | You | You, with your manager or HR | The expert, on hiring for their craft | Consult |
The table is a starting point. Its value is that you can show it to your team or say it out loud. That way you can argue about it before a real decision is on the line, rather than during one.
A worked example: when the right answer meets a constraint
Back to Ingrid, who brings you a recommendation three months in. The mid-tier plan has been underpriced for two years. She wants to move every existing customer on it to new pricing at their next renewal, starting next month. Her analysis is careful. She’s modeled churn and checked it against the last price change, and she estimates the change will add meaningful revenue over the year.
You don’t doubt her numbers, but you know two things she may not have weighed. First, sales leadership has told the company’s largest mid-tier customer that their price won’t change before the second quarter. That renewal is worth more than the rest of the list put together. Second, the support team is halfway through a system migration. That means a wave of billing questions next month would land on people who can’t absorb it.
The tempting response is to argue the content by questioning her churn assumption or suggesting the uplift is too optimistic. That’s a mistake on two counts. You’d be challenging the part of the decision that’s hers, on ground where she’s stronger. It also isn’t your real objection.
Instead, ask about her reasoning and about how it could fail. “Walk me through what happens if churn comes in higher than your model. What would you watch, and how early would you know?” After that, state your constraint plainly: “Here’s what I’m weighing that isn’t in your model. We’ve promised our biggest mid-tier customer no change before Q2, and support can’t take a billing wave while the migration’s running. Does either of those change your recommendation?” This keeps the two layers separate, because you aren’t telling her the analysis is wrong. Instead you’re giving her the information she needs to recommend well, and giving her a chance to adjust before you decide.
Suppose she doesn’t adjust. She says the promise to the big customer can be honored with an exception and that support will cope. But you still think the timing is wrong. Now it’s your call, so you make it out loud: “I’m going to go with new pricing for new customers from next month, and existing customers from Q2. Your analysis is the basis for the new prices and I’m not changing them. I’m moving the timing because of the support load and the promise sales made. I’d rather lose a quarter of uplift than have support fall over in the middle of a migration. If I’ve got that wrong, it’ll show up in the numbers, and I’ll own it.”
Three things in that statement do the work. It starts with what you’re keeping from her recommendation, which is most of it. It gives the actual reason for the part you changed, instead of “I just think it’s better.” It also says who carries the risk of being wrong, which is you.
Here’s one way this kind of call can play out. Two quarters later, the numbers show the delay cost about what Ingrid said it would. She mentions it in a one-on-one, without much warmth. The honest response is to agree with her: “You were right about the cost. I’d still make the timing call again because of the migration, but I’d have pushed harder to change what sales promised.” That isn’t a comfortable conversation, but it’s the one that makes her more likely to bring you her next recommendation straight. Otherwise she may bring you one she’s already watered down to get past you.
Decision making on a team like this is mostly about being clear which layer you’re deciding. When you decide the commitment and leave the craft alone, experienced people can disagree with you and still trust you.
What if the person you manage wanted your job?
This is the hardest version of the situation, and it doesn’t always resolve. Here’s another illustrative example. Gareth is a composite, not a real person.
Gareth has been on the team for eleven years. He applied for the manager role when it opened, but the company gave it to you. Everyone on the team knows. He hasn’t said anything about it. He’s been polite in meetings, and his work is as good as it has ever been. But he’s stopped offering opinions unless asked, and he answers your messages with a sentence where he used to write a paragraph. Twice now you’ve heard about a problem from someone else that he must have known about first.
Cappelli’s Wharton piece puts the general point carefully: “Supervisors must understand that more experienced subordinates may have a problem being supervised by someone with less experience.” The word that matters there is “may,” because not everyone does. But when the experienced person also wanted the job, it would be surprising if there were no problem at all.
Have the conversation once, privately, and early
It’s tempting to hope this will settle on its own if nobody mentions it, but it rarely does. The situation is obvious to everyone. If you pretend it isn’t there, Gareth is left to guess what you think of him. That’s rarely kind to either of you.
So raise it once, in private, within the first few weeks. Say what happened, without apologizing for getting the role: “Gareth, I know you went for this role, and I know it went to me. I’m not going to pretend that didn’t happen. I’d rather talk about it once, openly, than have it sit between us.” That opening matters because it names the thing, and because it says you’re raising it to clear the air rather than to make him talk about his feelings.
Next, ask about him rather than about you: “What do you want from the next couple of years here? If it’s still a management role, I’d like to know because I can help with that.” This is the question that changes the conversation. It treats his ambition as reasonable, which it is, and it gives you something real to work on together. Some people will tell you exactly what they want. Others will say “I’m fine” and mean “not now.” You’ve said it either way, so you don’t need to raise it again unless he does. If you want more help with how to open a conversation like this, our examples of difficult conversations at work include several that follow the same shape.
What not to do
There are a few common ways to make this worse, and most come from trying too hard to keep the peace.
The first is overcompensating. That means praising everything he does, checking in constantly and going out of your way to show you value him. He’ll read it for what it is, which is you managing your own discomfort. The second is deferring on everything, so that he becomes the manager in practice and you become the person who signs off. That feels generous, but it leaves the rest of the team unsure who’s actually in charge, and it doesn’t solve anything for Gareth either. The third is handing him your hardest problems as a way of buying goodwill. If the difficult stakeholder or the messy project goes to him because you’d rather not face it, he’ll know, and so will everyone else. Our guide to the mistakes first-time managers make covers a few close relatives of these.
The opposite mistake is pulling rank to prove a point, such as overruling him on something small in front of others to show who’s in charge. It doesn’t work, and it makes it much harder to have the honest conversation you’ll need later.
What does work is ordinary, consistent management. Give him the same standards, the same feedback and the same access to good work as everyone else. Make decisions the way the table in the previous section says you will.
Giving him real scope, if he wants it
There’s often a way to use someone like Gareth that’s good for him and for the team. He might own the standard for a part of the work, such as the review rules for the team’s analysis or the onboarding plan for new hires. Or he might mentor the newest person on the team. Done well, this is real responsibility with his name on it, and it’s also the kind of experience that helps if he goes for a management role again.
Two conditions apply. The first is to offer it only if he wants it, so ask rather than assign. The second is to make sure it’s real work that matters and not a consolation prize, because people can tell the difference between a role and a title.
Resentment you can’t fix
Some of this you can address, and some you can’t. You can name the situation and be fair. You can keep your promises and help with his career. But you can’t make him glad you got the job. Some people stay cool for a long time, and some never warm up. That’s allowed, because your job is to keep the standards and the fairness rather than to win him over.
Coolness and undermining are different things, though. Shorter replies, skipping team lunches and not volunteering ideas are coolness, and you live with it. Undermining looks like contradicting your decisions in front of the team or telling people to ignore a new process. It also includes sitting on information that the team needs. Undermining calls for a direct conversation about conduct. Once you’ve had that conversation and it’s still happening, bring in your own manager or your HR partner. At that point it has become a performance problem, and a record kept from then on protects both of you.
It’s also possible that Gareth stays polite and distant while doing good work for another year, and then takes a management job somewhere else. You may never know whether anything you did made a difference.
Where this advice breaks
Everything above assumes the main risk is a new manager who defers too much or bluffs too much. There are three situations where that assumption fails, and it’s worth knowing them in advance.
The experienced person is simply right. Asking for someone’s reasoning and their failure case is not the same as overriding them. If Ingrid’s recommendation holds up and your constraint turns out to be smaller than you thought, the right move is to defer openly: “I’ve thought about it, and you’re right. Let’s do it your way.” A manager who never defers is making a different mistake, and a more expensive one. That’s because an expert team stops bringing real recommendations to someone who always finds a reason to change them.
This is where the first conversation pays off. You said in week one which decisions are yours and which are hers. That made deferring possible without it looking like weakness. Because the split was said out loud, choosing her answer on a commitment that’s yours reads as a decision you made rather than as a manager who couldn’t hold the line. If you hadn’t had that conversation, every time you agreed with her would look like you gave in.
Your “fresh eyes” idea is one they’ve already seen. New managers are often told they bring a fresh perspective, and sometimes they do. But someone who has been through the company’s last three reorganizations may recognize your new idea as the second of them, and know exactly why it didn’t stick. So when an experienced person pushes back with “we tried this,” treat it as information you need, and check it. Ask what happened, what’s different now and whether the reason it failed still applies. Sometimes the answer is that the conditions have changed and it’s worth another try, but often it isn’t.
The gap is too wide for the role. In some jobs you’re expected to evaluate technical work you can’t judge. You might have to approve a security design or sign off on a model, or rate an engineer’s code. If the gap is so wide that you can’t tell good work from bad, you may have been put in the wrong role. Or you may have been put in the right one without the support it needs. That’s not a personal failing, and bluffing won’t fix it. Have a candid conversation with your own manager: “There’s a part of this role I can’t judge yet, which is the technical quality of the work. I need help with that.” After that, ask for something specific. That could be a technical lead whose judgment you can rely on or a skip-level review for high-stakes work. It could also be a review process that doesn’t depend on you. Our guide to managing up covers how to frame that kind of request.
There’s one more limit. Everything here assumes the people you manage are working with you in good faith, even when they disagree. If someone consistently stonewalls or undermines despite all of this, it has stopped being about experience. At that point it’s a performance or conduct issue, so handle it that way.
Some of these situations work out and some don’t. Sometimes the experienced person becomes your strongest ally on the team. Other times the arrangement stays workable but never comfortable.
If you’re in HR or L&D, how do you set a manager up for this?
Promoting someone over more experienced colleagues is predictable, which means you can prepare them for it instead of watching them find out.
Tell the new manager in advance who on the team is more experienced and who applied for the role. It also helps to say what that’s likely to mean in the first few months. A manager who has been warned handles the first awkward meeting very differently from one who’s surprised by it.
Give them the decision-rights conversation as a tool. The table in this post is something a new manager can take into their first one-on-ones, and so is your own version of it. It turns “I’m your manager now” into a specific statement about who decides what, which is much easier for experienced people to accept.
Pair them with a senior sponsor. That should be someone outside the reporting line who has managed experts before and can be called when a decision feels shaky. Schedule check-ins at 30, 60 and 90 days rather than waiting for a complaint.
Watch the first round of performance ratings, too. The same Wharton piece says that “Younger supervisors tend to give lower appraisals to older subordinates independent of the quality of their work.” It states this as an observation and doesn’t cite data for it, so treat it as a possible bias to check for rather than a known fact about any particular manager. The check itself is simple: when a new manager rates someone more senior, ask what the rating is based on. If the answer is about the work, good. But look more closely before the rating goes final if the answer is about attitude, speed of adoption or “fit” with the new way of doing things.
The first conversation with each experienced person is the one a new manager most needs to get right. Rehearse it with Merlin in Slack, Teams or the web app before having it for real. Say the split out loud until it sounds like something you’d actually say.