Inheriting a team: what do you do in the first 90 days?

In this article

1. Before you start
2. Why interviewers ask this
3. Inheriting a team from first principles
4. Worked example
5. Trade-offs and edge cases
6. How to answer it in an interview
7. Common mistakes
8. Follow-up questions
9. Sources

Before you start

This page belongs to the engineering manager interview questions guide. It assumes no management experience.

Why interviewers ask this

The question tests judgment under uncertainty. A new manager who does not know the people, the code or the history is tempted to act fast to look decisive, and interviewers want to see whether you resist that.

Michael Watkins, author of the international bestseller The First 90 Days, describes transitions as a chance to start fresh that also leaves a leader acutely vulnerable. The same page warns that missteps in the first three months can derail you. A Stanford Social Innovation Review notice of the book makes a similar point about the first 90 days.

A weak answer lists changes: new process, new standup, new roadmap. A strong answer shows an order of work: listen, diagnose, agree one early win, fix the structure, measure. A Staff-level answer adds how you tell whether the plan is working. A reliability version of the scenario is reported by candidates in engineering manager loops at large tech companies: incidents are up 40% and the on-call rotation is burning people out.

Inheriting a team from first principles

Inheriting a team

Inheriting a team is a leadership transition in which a manager takes over an existing group of engineers, with its own habits, history and unfinished work, rather than building a team from nothing.

Listening tour

A listening tour is a planned series of short conversations, with each engineer, partner teams and customers, that a new manager holds before changing anything, to learn what works, what hurts and what to keep.

Early win

An early win is a small, visible improvement that the team itself agrees matters, delivered in the first months of a new role, so that people see you can help before you ask them to change.

In plain words

Think of moving into a house where a family already lives. You do not knock down walls on day one. First you learn which doors stick and which rooms they love. The analogy breaks in one place. A house has no deadlines, and a team does, so you cannot listen forever.

In one precise sentence, inheriting a team is a trade of speed for information: you spend a few weeks learning, so that your first change is the right one.

An engineering manager (EM) is responsible for a team's people, delivery and health.

Step 1: Listen before you change anything

The first step is to hold a listening tour of every engineer, then the partners and customers who depend on the team. Input: your questions. Output: a list of problems in the team's own words.

Ask the same few questions of everyone: what slows you down, what should I never change, what worries you, what would you fix first. Using the same questions makes answers comparable. Use the one-on-one format you will keep running later.

Do not announce changes yet. Watkins frames the opening months as a time when missteps can derail you, and a reorganisation before you can name the problem is one such misstep: it spends trust on a guess. Changes made before diagnosis often target the wrong cause and cost credibility. Do fix anything that is on fire, and say so out loud, so that listening is not mistaken for passivity. You now have raw material, and the next step turns it into a diagnosis.

Step 2: Diagnose with data and name the problem

The second step is to turn opinions into a named problem backed by numbers. Input: the listening notes. Output: one sentence saying what is wrong and how you know.

Check what people told you against records: the incident log, the delivery history, the on-call schedule, attrition. If three engineers say the pager is exhausting, count pages and hours per person. A problem you can count is a problem you can show the team and later show improved.

Keep two lists. One is the problems people raised. The other is what the data shows. Where they differ, ask more questions before acting. Measuring team health is a skill of its own. For now, you now know what is wrong, and the next step is to pick the one thing worth fixing first.

Step 3: Pick one early win and agree on it

The third step is to choose one early win and get the team to agree it matters. Input: the diagnosis. Output: one commitment with an owner and a date.

Watkins names securing early wins as an important first step in establishing yourself. Choose a win that is small enough to finish in weeks, that the team already complains about, and that you can measure. Removing a recurring annoyance builds more trust than a new strategy document.

Say the choice and the reason aloud, and say what you are leaving alone for now. Agreement matters because a win the team did not choose is your win, not theirs. If people disagree with your pick, treat that as information, not insubordination. You now have a target, and the next step is to fix the cause rather than the symptom.

Step 4: Fix the structure, not just the response

The fourth step is to change the system that produces the problem, not only how people react to it. Input: the early win. Output: a changed rule, schedule or staffing level.

Take a pager problem. Google's site reliability engineering (SRE) book caps operational work at 50% of an SRE's time and allows no more than 25% on call. It also says its teams write postmortems after significant incidents, and that managers must keep on-call load balanced and sustainable. The lesson for an interview is that heroics and more pagers are not a fix. Rota size, incident volume and follow-up are.

Apply the same shape elsewhere: if the problem is low morale, change what causes it, such as unclear priorities, before running a morale event. You now have a change in place, and the last step proves whether it worked.

Step 5: Measure the change and report it

The fifth step is to measure the result against the number you named in Step 2 and report it to the team. Input: the baseline. Output: a before-and-after figure and a decision about what to widen next.

Report honestly, including a miss. A manager who says "pages per week fell, but the hours did not" earns more trust than one who declares victory. Only after one win is measured do you widen the scope to the next problem, such as a low performer or two engineers who cannot work together.

The "90 days" is a framing, not a deadline. The Stanford Social Innovation Review notice says the first 90 days on a new job are critical, and the sources speak of three months, not a fixed rule.

1 · Listen2 · Diagnose3 · Early win4 · Fix structure5 · MeasureReplay

Step-by-step description

1. Listen to everyone first.
2. Name the problem with data.
3. Agree one small win.
4. Change the cause.
5. Report before and after.

• A new manager listens to every engineer before changing anything.
• The manager diagnoses the problem with data, agrees one early win, fixes the structure and measures the result.

Worked example

Take the reported scenario: incidents rise 40% and the rotation burns people out. The team size, the baseline of 10 incidents a month and 160 working hours per engineer per month are illustrative. The 6 hours per incident comes from Google's SRE book, which says that root-cause analysis, remediation and follow-up take about 6 hours on average.

A 40% rise takes 10 incidents to 14. At 6 hours each, incident work grows from 60 to 84 engineer-hours a month.¹ For a team of five with 800 working hours a month, that is 7.5% of capacity before and 10.5% after.¹ Google's book also gives at most 2 incidents per 12-hour shift; 14 a month is about 0.23 per shift, well inside it.¹

So the incident hours alone do not break the 50% operational cap. The burnout comes from who carries them. A team of five that staffs a 24/7 rota with a primary and a secondary puts each engineer on call 2 weeks in every 5, which is 40% of weeks, above the 25% ceiling.¹ Google says the minimum for a single-site team with two people always on call is eight engineers, one week in every four, which is 25%.¹

The first-90-days answer follows: listen to find out which weeks hurt, count pages and hours per person, pick the rotation as the early win, add engineers or move to a shared rota across sites, and require postmortems so incident count falls. The chart below shows the rota arithmetic.¹

Text description of the diagram

• A team of five puts each engineer on call 40% of weeks.
• Eight engineers bring that to 25%, the ceiling.

Trade-offs and edge cases

Listening costs time, and the cost is real when something is burning. Fix urgent pain at once and defer everything else; the early win is for the problem that is chronic, not acute. A turnaround team in crisis needs faster action than a healthy one, so shorten the listening phase to days and decide sooner, while still telling people why.

A small or newly formed team has the opposite problem: little history to listen to and not enough people. A manager there often has to contribute directly, picking up the work that unblocks others, while still protecting time for people work. Reported candidate questions ask exactly this, including how to cope with too few engineers. A sound answer cuts or sequences scope before adding hours, and names what will not be done.

Staffing a rota has its own trade-off. Google notes that a multi-site "follow the sun" rotation avoids night shifts but adds communication and coordination overhead, so it fixes sleep at a cost in process.²

Some questions have no sourced answer. Bringing a team back to the office five days a week is a policy and judgment matter: a sensible answer listens to the reasons people resist, states the reason for the policy honestly, and does not pretend agreement. The 30, 60 and 90 day split is also a convention, so say it as a plan, not a law.

Text description of the diagram

• The first 90 days on a new job are critical.
• The 30, 60 and 90 day split is a convention for planning, not a rule from the sources.

How to answer it in an interview

The spoken structure: say the order of work, say why you listen first, name one early win with a number, then state the trade-off. If the interviewer asks about philosophy, link it to your management philosophy.

Common mistakes

• "In week one I will reorganise the team." (wrong) You have not yet heard the problems. (right) "I will listen first and change one thing after I can show the evidence."
• "I will fix reliability by being on call myself." (wrong) Heroics hide the structural problem. (right) "I will size the rota, cap the load and require postmortems."
• "The first 90 days is a fixed deadline." (wrong) The sources describe three months as a critical window, not a rule. (right) "I plan in thirds and adjust as I learn."
• "Our early win is a new strategy." (wrong) It is neither small nor measurable. (right) "Our early win is a fix the team asked for, with a before-and-after number."

Follow-up questions

What would you do on a newly formed team if you did not have enough engineering resources?

Cut or sequence the scope before adding hours, and tell stakeholders what will not be done. Contribute directly on the work that unblocks others, but keep time for one-on-ones and hiring.

How would you contribute early while the team is still small?

Take the task with the most blocking effect, not the most visible one, and finish it. Pair that with the listening tour so you learn the team while you help.

Can you tell me about a time your team disagreed with you?

Pick a real case where you listened, changed your mind or held your ground with a reason, and name the result. The people management round guide shows how such stories are used.

How would you bring a team back to the office five days a week?

Ask why people resist, explain the reason for the policy honestly, and agree what you can flex. You cannot promise agreement, only a fair process.

How do you rebuild a team with low morale after the previous manager left?

Hold a listening tour, name the one thing people most want fixed, and deliver it. Then build routines such as regular one-on-ones and support for growing engineers.

Sources

1. Being On-Call (Site Reliability Engineering, chapter 11) — Google (sre.google), 1 Jan 2016
2. The First 90 Days, Updated and Expanded (Michael D. Watkins) — Harvard Business Review Press, 1 Jan 2013
3. Review: The First 90 Days — Stanford Social Innovation Review, 1 Jan 2003