New Engineering Manager? What to Look At First

TL;DR: Your first 90 days as an engineering manager are a reading assignment, not a writing one. Read the people (one-on-ones about the system, not the person), read the queues (where work actually waits), read the knowledge map (who is the only person who understands what), and read the team's rhythm. Change almost nothing until you can explain why the team works the way it does. The managers who stumble are rarely the ones who acted too slowly.

Congratulations - you now own a team you didn't build, a codebase you've barely seen, and a set of problems everyone assumes you already understand. The instinct is to do something: new process, new dashboard, new structure, visible motion. Resist it. Every team is the way it is for reasons, and until you know the reasons, your improvements are coin flips wearing confidence.

Here's the reading list, in order.

Weeks 1-2: read the people

One-on-one with every person on the team. The sequence of questions matters: they should all point at the system, not the individual.

• "What slows you down most?" The aggregated answers are your real backlog. Industry data says the answers will be blunt: in the 2024 Stack Overflow survey, 63% of professional developers named technical debt their top frustration, and 61% spend more than 30 minutes a day just searching for answers.
• "What would you fix first if you ran the team?" Engineers have usually diagnosed the problems years ago; nobody asked.
• "What's the thing only you know how to do?" Asked kindly, this starts your knowledge-risk map for free.
• "Who do you go to when you're stuck?" If every answer is the same name, you've found the load-bearing person no org chart shows: the glue you must protect before you accidentally spend it.

Write everything down. You're not committing to fixes yet; you're building the map.

Weeks 2-4: read the queues

Teams rarely have a working problem; they have a waiting problem. Before judging anyone's output, find out where work sits:

• Review pickup time. How long does a PR wait for first attention? Industry benchmarks put elite pickup under an hour and flag anything past 16 hours. If your median is measured in days, you've found a lever bigger than any individual's effort. Start with pickup time, the cheapest metric with the fastest payback.
• Work in progress. Count what's open versus what's finishing. A team with everything started and nothing landing has a WIP problem, not an effort problem.
• The stuck and the dead. PRs open for weeks, tickets bouncing between states. Each one is a story about the system.

This is also the honest way to introduce measurement: system metrics, announced openly, with an explicit promise about what you will never measure. The SPACE research gives you the vocabulary: productivity is multi-dimensional and cannot be read off any single activity number. Your team's first, silent question about any new dashboard is whether it's about the work or about them. Answer it out loud before they ask.

Weeks 4-8: read the knowledge map and the rhythm

Now go one level deeper than the queues:

• Knowledge concentration. Which areas can only one person touch? Your predecessor's risk register probably doesn't mention that the deploy pipeline, the billing integration, and the search index are all one resignation away from being orphans. This is bus-factor reading, and doing it in month one - before an exit interview does it for you - is one of the highest-leverage things a new manager can do.
• Load distribution. Who reviews everything? Who gets pulled into every incident? Disproportionate load is a burnout risk and a bus-factor problem wearing a "rockstar" costume, and the warning signs are readable long before the resignation letter.
• The team's honest voice. A short, well-designed developer experience survey triangulates what one-on-ones surfaced, anonymously, so the quiet people get a vote too.

Weeks 8-12: now you may touch things

Pick one or two system fixes from your map (the review queue, the WIP pile, the scariest single point of failure) and fix them visibly, with before/after receipts at the next retro. Early wins built on the team's own diagnoses buy you the trust budget every later change will draw on. Bring the receipts to retro; nothing builds credibility faster than a manager whose first change made the thing the team complained about measurably better.

And rebuild the rituals that shape careers: your first performance-review cycle sets the tone for whether reviews here are evidence-linked support or an annual ambush.

The don't-do list (weeks 1-12)

1. Don't reorganize. You don't know what the current shape is load-bearing for.
2. Don't ship an individual-metrics dashboard. Activity counts read as surveillance because, used that way, they are.
3. Don't judge anyone yet. The "low performer" you inherited an opinion about is, more often than you'd think, a system problem with a person's name attached. Check team health before personnel conclusions.
4. Don't promise what you can't deliver. Unkept week-two promises cost more trust than silence would have.

Ninety days of reading feels slow in a culture that rewards visible motion. But the manager who spends them building the map - queues, knowledge, load, rhythm - gets to spend the next year pulling levers that actually connect to something. The one who skipped the reading gets to spend it apologizing.