In this article
Before you start
This page is one question from the engineering manager interview questions guide.
Why interviewers ask this
The consequence of a weak answer is simple: the interviewer cannot tell whether you manage people or only react to problems. The question is broad on purpose. It lets the interviewer see what you reach for first, and whether your answer covers the whole team or only the worst performer.
A weak answer lists one tool: "I did one-on-ones" or "I tracked velocity." A strong answer describes a loop with a start (expectations), a middle (measures and feedback) and an end that feeds the start (development and action). A Staff-level answer adds what you refused to measure, how you handled both ends of the team, and one thing you changed after the data surprised you. This is part of what the people management round tests.
Managing team performance from first principles
- Performance management
- Performance management is a repeating cycle in which a manager agrees expectations with each person, measures how the team's work is going, gives regular feedback and acts on the gaps through support and development, so that results improve over time.
In plain words
Think of coaching a running team. You agree a target time with each runner. You watch the splits, not just the finish. After each run you say what you saw, and you plan the next block of training. The analogy breaks in one place. Engineering work is shared, so no single split belongs to one person, and a slow team can be a slow system rather than slow people.
In one precise sentence, you manage performance by agreeing what good looks like, measuring the system and the people's experience of it, giving feedback close to the work, and acting on what you learn.
Step 1: Set clear expectations and goals
Performance management starts with a written, shared picture of what good looks like. For each person that means the scope and quality expected at their level. For the team it means a few goals specific enough to check.
Locke and Latham (2002) summarize decades of goal-setting research: specific, difficult goals with feedback lead to higher performance than vague "do your best" goals. So "improve reliability" becomes a goal with a measure and a date that the team chose together.
Input: the team's mission and each person's role. Output: expectations people can repeat back to you. Check by asking in a one-on-one, "What do you think I expect from you this quarter?" A mismatch is a finding, not a failing. You now have a baseline that every later step compares against.
Step 2: Measure the system across several dimensions, not one number
Measuring performance means looking at the team's delivery system and at how people experience it, with more than one kind of measure. Forsgren and colleagues (2021) describe five dimensions: satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow. One activity count misses most.
For delivery, the DevOps Research and Assessment (DORA) guide (as of October 2026) groups five delivery metrics into throughput (change lead time, deployment frequency, failed deployment recovery time) and instability (change fail rate, deployment rework rate); it grew from the original four keys. They describe a delivery system, so ask where it is slow; do not rank people.
A worked example, with illustrative numbers: weekly lead times in days were 9, 7, 8, 12, 6 and 10 before the team fixed its review queue and 6, 5, 7, 4, 6 and 5 after. Median lead time fell from 8.5 to 5.5 days.1 Change fail rate went from 8 failures in 40 deployments, or 20.0%, to 4 in 44, or 9.09%.1
Text description of the diagram
- Illustrative median lead time falls from 8.5 days to 5.5 days.
- A team-level trend shows whether the system improved without scoring any one person.
A team-level trend shows whether the system improved without scoring any one person. That answers the follow-up: you knew it worked because the trend moved and people agreed it felt better.
Step 3: Coach with regular feedback
Coaching is the step that changes behavior. Weekly or fortnightly one-on-ones carry it, with feedback given close to the event and tied to a specific behavior and its effect. "Your design note listed the trade-offs, which let the reviewers decide fast" teaches more than "good job."
Feedback only works if people can hear it and speak back. Psychological safety matters here: Edmondson (1999) studied it as a condition for learning in work teams. As a manager you build it by admitting your own mistakes, asking for dissent, and responding to bad news with questions before blame.
Input: what you observed this week. Output: one specific piece of feedback and one question about what is in their way. Write it down. The notes become the evidence for step 4, and for any later hard conversation covered in one-on-ones and hard feedback.
Step 4: Develop people and act on the gaps
Development closes the loop. For someone below expectations, the action is a clear, written gap, support, a timeframe and honest check-ins; the dedicated pages on handling a low performer and managing underperforming employees cover that path.
For strong performers, the action is scope: a stretch assignment, ownership of a risky area, a chance to mentor. Without it they stagnate or leave. Watch for the opposite trap too. Strong people can become bottlenecks and carry too much, so spread knowledge and protect their time. The growing engineers page goes deeper.
Everything you learn here resets step 1: expectations change as people grow and as the team's goals change. That is why performance is managed as a loop, and each pass of it feeds what you learn into the next set of expectations.
Step-by-step description
- Agree what good looks like.
- Track the system and how people feel.
- Coach close to the work.
- Act on gaps, then reset expectations.
- Performance is managed as a loop of expectations, measures, feedback and development.
- Each pass of the loop feeds what you learn into the next set of expectations.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →The Staff-level answer
How did you manage performance of your team?
I ran it as a loop. First I agreed expectations with each person and set a few team goals specific enough to check. Then I looked at the delivery system, such as lead time and change fail rate, next to how people said they felt, and I used those as questions about the system, never as a ranking of individuals. I deliberately did not track commits or tickets per person, because those counts reward activity, not outcomes. I coached in weekly one-on-ones with feedback close to the work. Then I acted: a written plan with support for anyone below expectations, stretch scope for strong people. I checked that the trend moved and reset expectations.
What makes it Staff-level: it names what you refused to measure, covers both ends of the team, and ends with the loop closing rather than a single tool. In the round, add one real example from your own team.
The rubric
| Dimension | Weak answer | Strong answer | Staff answer |
|---|---|---|---|
| Correctness | One tool, such as one-on-ones or velocity | Expectations, measures, feedback and action | The full loop, reset by what you learned |
| Depth | "I tracked output" | Several dimensions of performance named | Distinguishes system measures from individual judgment |
| Trade-offs | None stated | Notes a metric can be gamed | Says what you chose not to measure and why |
| Communication | Generic, no example | One concrete example | Example with the result and what you changed |
| Follow-up readiness | Stuck on "how do you know it worked?" | Points to a trend | Pairs the trend with how people felt |
Three variants of this question
If you joined a new team with low morale after the previous manager left, how would you set it up and bring it back, and manage the high performers on it?
Start by listening: a one-on-one with everyone, asking what slows them down, then fix one visible blocker quickly. Rebuild expectations and psychological safety, and give high performers real scope and a mentoring role rather than only extra load. The inheriting a team page covers the first weeks.
What do you do if your team missed its goals?
Review what happened against the plan with the team before judging anyone. Unclear goals, shifting priorities or a blocked dependency can all be causes. Reset the goals, fix the biggest constraint and agree how you will check progress.
How do you know your team is performing well?
Combine a team-level trend in delivery with how people say they feel and whether goals were met. The team health page covers the second part.
Common mistakes
- "I measured performance by commits and tickets closed." (wrong) Activity counts miss most of what performance is. (right) "I looked at delivery, quality and how people experienced the work, and used the numbers to find system problems."
- "I managed performance by managing my low performers." (wrong) That covers one end of the team. (right) "I ran the same loop for everyone, with a support plan for those below expectations and stretch scope for the strong."
- "I put the delivery metrics on a leaderboard." (wrong) The metrics describe a system, and a leaderboard invites gaming. (right) "We reviewed the trend together and chose one fix."
- "We did annual reviews." (wrong) Feedback a year late changes little. (right) "Feedback was weekly and the review was a summary of what they already knew."
Follow-up questions
How do you measure the performance of an engineering team?
Use several dimensions rather than one number: delivery measures such as lead time and change fail rate, quality, and how people report their experience. Look at trends over time, and compare a team with its own past, not with another team.
Should you use DORA metrics to rate individual engineers?
No. DORA's metrics describe how a team's delivery system behaves, so a slow lead time may come from review queues, tooling or approvals. Use them to find the constraint, and judge individuals on agreed expectations and observed behavior.
What if you have no data to show for your team?
Say so, then describe what you did have: goals set, feedback given, outcomes shipped and what people told you in one-on-ones. Then name the one measure you would add first.
How often should you review performance?
Continuously in small ways. Weekly or fortnightly one-on-ones carry feedback, and a formal review should hold no surprises. Adjust the cadence to the person's experience level and the stage of the project.
- Managing performance is a loop of expectations, measures, feedback and development.
- Measure across several dimensions, and treat delivery metrics as questions about the system, not a ranking of people.
- Coach with specific feedback close to the work, in a team where people feel safe to speak.
- Act at both ends of the team: support for those below expectations, scope for the strong.
- A Staff answer says what you chose not to measure and how you knew the trend moved.
Sources
- The SPACE of Developer Productivity — ACM Queue (Forsgren, Storey, Maddila, Zimmermann, Houck, Butler), 1 Feb 2021
- DORA software delivery performance metrics — DORA, Google Cloud, 26 Oct 2026
- Psychological Safety and Learning Behavior in Work Teams — Administrative Science Quarterly (Edmondson), 1 Jun 1999
- Building a practically useful theory of goal setting and task motivation — American Psychologist (Locke and Latham), 1 Sep 2002