Your First 90 Days as an Engineering Manager

A few weeks into my first engineering management role, a senior engineer came to me frustrated about a deployment pipeline that kept breaking. I listened for about two minutes, then confidently suggested they “add more integration tests and tighten the CI checks.” The engineer looked at me the way you’d look at someone who tells you to “just exercise more” when you have a broken leg. The pipeline wasn’t breaking because of test gaps; it was breaking because three teams were deploying to the same environment with zero coordination, and the infrastructure team had been asking for help for months with no response.

I’d given advice without understanding context. It was shallow, and the engineer knew it. Worse, I’d burned a small piece of credibility that took weeks to rebuild.

That was the first real lesson: this job is nothing like the one that got you here. Here’s what I actually learned in my first 90 days. Not the sanitized version, the real one.

Days 1-30: Shut Up and Go Deep

Everyone tells new managers to “listen.” That advice is correct but incomplete. I’ve seen plenty of new managers who listen for a month and still walk away with a surface-level understanding of their team. They can tell you what’s on the roadmap and who seems unhappy, but they can’t explain why the team made a particular architectural decision, or why that one process that looks stupid actually prevents a recurring production issue.

Shallow listening is almost worse than not listening at all, because it gives you false confidence.

Here’s what going deep actually looks like:

Sit in on code reviews and design discussions. Not to assert opinions, but to absorb how the team thinks, what they argue about, and what they take for granted. You’ll learn more about the real state of the codebase from a heated PR review than from any architecture document.
Trace a feature end to end. Pick the most recent thing the team shipped and trace it from ticket to production. Where did it slow down? Who had to get involved? What was painful? This gives you a concrete picture that no amount of 1:1 conversations will provide.
Ask “why” until it gets uncomfortable. Not confrontationally, but genuinely. “Why do we do Friday deploys?” “Why does this service have its own database?” Every “because we’ve always done it that way” is a potential insight into a deeper problem. But some of those answers will be “because the last time we tried to change it, production went down for six hours.” You need to know the difference.

The temptation during this phase is to offer quick fixes. A P0 fires and you think, “This is my chance to be useful, let me throw more people at it.” Don’t. Throwing more bodies at a production incident when you don’t yet understand the system will make things worse. You’ll create confusion about ownership, fragment communication, and slow down the people who actually know what they’re doing. Your job during a crisis in month one is to clear the path for the people who can fix it, and to take notes on what you observe.

Days 31-60: Be Their Shield

Trust isn’t built by being reliable, though that matters. It’s built by demonstrating, through action, that you’re on your team’s side, especially when it’s uncomfortable for you.

The moment that defined this for me was when a senior stakeholder wanted my team to drop everything for a “critical” feature request. I was new, I wanted to be seen as cooperative, and my instinct was to say yes. But I’d spent a month watching my team get pulled in ten directions, and I knew adding one more priority would break something. So I pushed back. I said no, offered a timeline that actually made sense, and took the heat.

The team noticed. Not because I announced it, but because people always know when their manager went to bat for them.

Here’s how this looks in practice:

Defend your team’s focus ruthlessly. Every “quick ask” from a stakeholder is a context switch that costs your team far more than the stakeholder imagines. Your job is to be the filter. Some requests are genuinely critical. Most aren’t. Learn the difference fast.
Take the blame publicly, give credit publicly. When something goes wrong, you own it in front of leadership. When something goes right, your team owns it. This sounds like a cliché, but most new managers do the opposite under pressure. They subtly distance themselves from failures and claim proximity to wins. People see through it instantly.
Have the uncomfortable 1:1s. Month two is when you start to see real performance issues: the engineer who’s checked out, the one who dominates every discussion, the one who’s brilliant but can’t work with others. Don’t put these conversations off. The longer you wait, the harder they get, and the more your team resents you for not addressing what everyone can see.

Trust compounds slowly and collapses fast. Every interaction either deposits a tiny amount of credibility or withdraws it. There are no neutral interactions when you’re new.

Days 61-90: Learn the Unsexy Parts

Here’s the thing nobody tells you about engineering management: the hardest part isn’t the people, and it isn’t the strategy. It’s the bureaucratic work that no one romanticizes but that directly shapes your team’s reality.

By month three, you’ll encounter the parts of the job that never appear in management blog posts or leadership podcasts:

Writing job descriptions that actually attract the right people. A bad JD is a filter that screens out your best candidates and invites the wrong ones. Getting this right requires understanding exactly what your team needs, not what HR’s template suggests.
Running performance evaluations that mean something. Perf reviews are where your team finds out if you’ve been paying attention. Vague feedback like “great work this quarter” is worse than no feedback at all. If you can’t cite specific examples of what someone did well and where they need to grow, you haven’t been doing your job.
Navigating budget conversations and headcount planning. Nobody prepares you for how much of your effectiveness depends on understanding the company’s financial planning cycle and knowing when to ask for resources.

These aren’t glamorous skills. They’re not the kind of thing you’ll see in a “day in the life of an EM” tweet thread. But they are the skills that separate managers who actually improve their team’s situation from managers who just hold the title.

Month three is also when you should start shaping, not just observing. But be surgical about it. Pick one thing to change, not five. Choose something that matters to the team, that you can actually deliver, and that demonstrates you understood what you learned in months one and two. A well-chosen first change, grounded in deep context, builds more credibility than a dozen surface-level improvements.

The Real Shift

The moment you truly understand what management is, not intellectually, but viscerally, isn’t during a 1:1 or a strategy session. It’s when you’re staring at a performance review trying to articulate exactly how to tell someone they’re not meeting expectations in a way that’s honest, fair, and motivating. Or it’s when you realize you spent an entire week in meetings and didn’t write a single line of code, and that’s not a failure. That’s the job.

Management isn’t a promotion from engineering. It’s a career change that happens to take place in the same building. The sooner you internalize that, the sooner you stop measuring yourself with the wrong yardstick.

Your technical skills got you the role. They won’t make you good at it. What will is the willingness to go deep before you act, to put your team’s interests above your comfort, and to embrace the unglamorous work that actually moves the needle.