It's easy to assume when picturing yourself becoming a manager that you're going to build a brand new team from scratch. A team carefully interviewed and selected by you, engineer by engineer, with no previous history or skeletons in the closet for you to own. That's a real possibility and a very specific way to kick off managing a team. More often, managers take on a new team by inheriting a pre-existing one.
Not every team you inherit will be struggling. Some function remarkably well. But every team has a history and established ways of working, and even a healthy team has to adjust to getting a new manager. I've inherited multiple teams over my management career and realized that, despite different people and different problems, I keep returning to the same fundamental practices.
1. Understand
When I first inherit a team, I try not to change much of anything. I attend their existing ceremonies, set up one-on-one’s with every engineer, and start talking to stakeholders. Mostly, I listen, but I also ask questions.
In team ceremonies, I ask questions about things that everyone else seems to take for granted. Teams accumulate shared context over time. They develop processes, shorthand, and assumptions about why things work the way they do. Eventually, people stop questioning them. As the new person in the room, I have the advantage of not knowing any better. Sometimes I'm asking because I genuinely don't know the answer. Other times, I'm asking because I want the team to think about something from a different angle. I'm learning how the team operates, and they're learning how I lead.
In one-on-ones, my questions take a different approach. I want to know what each engineer thinks the team is struggling with most. Where do they feel stuck? Where could they most use my support? I also want to understand what they enjoy about their work, what frustrates them, and what they're hoping to accomplish. Two engineers on the same team can have very different experiences of working there, and I don't want to assume that understanding the team's problems means I understand the people on it.
I also talk to stakeholders and people who worked with the team before I arrived. Their perspectives matter, but I'm careful about treating their interpretations as facts. When you inherit a struggling team, you're also inheriting someone else's explanation for why it's struggling. That explanation might be right. It might be wrong. Either way, it’s important to hold onto that information while making space to actually observe the system yourself.
2. Build Trust
Trust is foundational to everything else on a team. Without it, feedback can feel threatening, accountability can feel punitive, and even well-intentioned changes can be met with resistance.
I don't expect a team to trust me simply because I've been assigned as their manager. I have to earn that trust through consistency over time. Do I do what I say I'm going to do? Do I follow through when someone raises a concern? Am I willing to advocate for the team when necessary? How do I respond when someone brings me bad news? These are the things people notice, and they're far more meaningful than anything I could say about my leadership philosophy in an introductory meeting.
The one-on-one’s and conversations I start during those first weeks are as much about building relationships as they are about gathering information. I'm learning what matters to each engineer, what they need from me, and where I can help. They're learning whether I'm someone they can rely on.
Earning the team's trust in me is only part of the equation. The engineers need to trust one another, too. Being assigned to a team doesn't mean that everyone operates as a team. If they've been under pressure before you arrived on the scene, chances are some damage control is necessary on that front too. Are they collaborating? Are they comfortable asking one another for help? Do they talk to each other about things besides just the work? I pay attention to the little things that tell me whether people are starting to feel comfortable with one another. My favorite moment when working with a team that's struggled is hearing them crack an inside joke. It's a small thing, but there's something wonderful about hearing a group of people who were once struggling together start to enjoy being a team.
3. Establish the Bar
One of the challenges of inheriting a team is that everyone comes with an existing understanding of what good performance looks like. Some of those expectations may have been explicitly communicated by their previous manager. Others may have been inferred from what was rewarded, tolerated, or overlooked.
There are expectations at both the team and individual level. As a team, we need a shared understanding of what ownership means, how we communicate risks, how we handle commitments, and how we work with other teams. Those expectations develop through conversations about how we work together. For individual engineers, I use our engineering career ladder to establish a shared understanding of what's expected at each level.
I don't want engineers to feel like getting a new manager means suddenly being held to an arbitrary set of new rules, so I anchor conversations about expectations and performance in the engineering career ladder. Sometimes that means doing an explicit exercise together, looking at the expectations at different levels and discussing what they look like in practice. Other times, it happens organically, connecting feedback about an engineer's work to the expectations of their role.
Career ladders aren't perfectly objective, and they still require interpretation, but they do give us a shared reference point. We're not debating whether I personally prefer someone to work a certain way. We're discussing the expectations of their role and how they're demonstrating them.
That shared understanding also makes it easier to have difficult conversations when performance isn't meeting expectations. Approaching a team without preconceived judgments doesn't mean avoiding accountability. Everyone deserves to understand what's expected of them and to be held to consistent standards.
4. Focus the Work
One of my responsibilities as a manager is to make sure my engineers have the clarity and space they need to actually get their work done. What that looks like varies from team to team, but at a minimum, everyone should understand what our priorities are and where we're focusing our efforts.
Sometimes the biggest problem on a team is too much work in progress. It’s one of those traps where doing more things at once feels faster but actually slows a team way down. Engineers are spread across multiple projects, context switching constantly, and making incremental progress on everything without finishing much of anything. In those cases, we need to make deliberate decisions about what we're going to focus on and, just as importantly, what we're not. That can mean resetting commitments with stakeholders rather than continuing to promise delivery against a plan that isn't realistic.
Other times, the problem is interruptions, unclear ownership, or work arriving without well-defined scope or boundaries. Engineers shouldn't have to spend their days negotiating competing stakeholder demands or figuring out whether something is even their team's responsibility. Part of my job is to shield the team from that organizational friction, while still making sure they have the context and relationships they need to do their work.
I've found that creating focus often requires changes outside the team as much as within it. It's not always enough to ask engineers to concentrate on fewer things if the organization keeps handing them more.
5. Create the Feedback Loop
Not to over-reference Ted Lasso (but seriously, if you're a people manager and haven't watched at least the first season, you're missing out), one of the first things Ted does when he takes over AFC Richmond is create a suggestion box. Most of what he gets back is insults, but one suggestion mentions the terrible water pressure in the showers. So he fixes it. It's a small thing, but it shows the team that he's listening and that positive changes can happen as a direct result of people speaking up.
I think about retrospectives in much the same way. When I inherit a team, I want to make sure there's a regular opportunity for engineers to talk about what's working, what isn't, and what we might do differently. The stakes should be low, and people need to feel safe enough to actually say what they think. Creating the space isn't enough. If people raise concerns and nothing changes, eventually they'll stop raising them.
I like approaching improvements as experiments. We're not declaring that everything needs to change or that every decision we make is permanent. We're trying something different and seeing whether it helps. If it works, great! If it doesn't, we'll talk about it at the next retro and adjust. And if it's really not working, we don’t even have to wait that long.
That approach makes change less intimidating, especially for teams that have been through a lot of disruption. It also starts shifting ownership of improvement back to the team. I might help identify problems or get the first few changes moving, but I don't want to be the person everyone waits on to fix things.
The Work Doesn't End Here
None of these practices is particularly revolutionary. They're not meant to be. And they're not "Five Steps to Declare a Team Fixed." The work is ongoing, and what each team needs will change over time.
The interventions themselves aren't always complicated. The harder part is figuring out what a particular team needs, recognizing which things are already working, and knowing when to intervene and when to get out of the way.
There's a really big difference between inheriting a team and earning the ability to lead it.
