How You Should Approach Managing a New Engineering Team

There’s a common mistake I see new engineering leaders make—especially those who’ve had success before.

They show up to a new team, armed with something that worked at a previous company or with a different crew. And because it worked before, they assume it’s gold. It must work here too, right?

But the truth is: it doesn’t. Every team is different. Every context is different. That playbook you love? It’s just a guess until you take time to understand the people and the problems in front of you.

So here’s how I actually do it when I take over a new team:

Start With 1:1s (My Leader and Team)

Before anything else, I schedule two things:

• A 1:1 with my leader
• A 1:1 with every person on the team

In my first meeting with my leader, I want to know:

• What are the goals for this team?
• Where are we falling short?
• What direction should we be heading?
• What are the guiding principles we should be using to filter decisions?

This gives me a north star—and a sense of what success actually looks like.

When I meet with the team, I ask each person:

• What are your strengths?
• Where do you feel you’re falling short?
• Where has the team been successful? Where has it failed?
• What’s your take on our current processes?
• What do you need from me?

I also ask about team ceremonies:

• Do you like daily standups?
• What kind of planning sessions have worked best for you?
• Are we overdoing meetings, or do people feel like they’re flying blind?

Some teams love long backlog grooming. Others want none of it. You have to learn the rhythm before trying to impose your own.

Watch First, Lead Second

In the first couple weeks, I do a lot of listening, watching, and digging.

• Is there good documentation?
• What tools are we using—Jira, Azure DevOps, Notion?
• What does the recent work look like?
• What projects have shipped? What’s stuck?

I write my own queries to see completed epics. I review code and delivery pipelines. I’m not just asking what we do—I’m seeing it for myself.

Get the Outside Perspective

Once I have a handle on the team, I talk to other teams.

It’s important to understand how this team is perceived in the broader org.

• What do stakeholders say?
• Do other teams love working with us, or dread it?
• Where have we historically dropped the ball?

Some of what you hear will be wrong or outdated—but some of it will be pure gold.

Especially the criticism. That’s where improvement lives.

Start Setting Expectations

After the 1:1s, after the observation phase, after I’ve talked to the org—I start to define how we work.

That means setting expectations. Not just the obvious stuff (show up, communicate, manage your calendar), but the real stuff:

• How do we handle ownership?
• What’s our bar for quality?
• What are the principles we use when making trade-offs?

These expectations become the scaffolding for everything we build going forward.

The One Thing You Don’t Want to Do

The worst move you can make as a new manager? Coming in with all the answers.

You don’t know the dynamics yet. You don’t know the people, the history, the pain points, or the politics.

If you impose your vision too early, even with the best intentions, you risk alienating the very people you’re here to support.

Listen first. Learn first. Then lead.

Final Thought

Your job isn’t to be the hero—it’s to create the conditions where the team can win.

That takes humility, patience, and a willingness to be wrong before you’re right.

It’s not flashy. It’s not fast. But it works.

What would you add?
What’s worked for you when taking over a new team?