In this article
Before you start
Why interviewers ask this
A manager who fails this question usually fails in one of two opposite ways, and interviewers listen for both. One is the manager who cannot follow a design review, so engineers stop trusting their judgement. The other is the manager who still decides every technical question, so the team waits on them and stops growing. In an engineering-management loop the question appears directly ("how technical are you?") and in disguise, such as "walk me through the architecture of your last project". A weak answer picks a side: "very technical" or "I manage people, not code". A strong answer gives a boundary and a reason. The leadership interviews guide shows where it sits in the wider round.
Technical depth for managers from first principles
- Technical credibility
- Technical credibility is the trust engineers place in a manager's judgement on engineering questions, earned by asking informed questions and understanding trade-offs rather than by writing the most code.
- Critical path
- The critical path of a team is the chain of work that delays the team's delivery if any part of it slips, so code a manager owns there becomes a risk whenever the manager is pulled into meetings.
In plain words
A head chef does not cook every dish. The chef tastes every dish and knows what the kitchen can deliver in an evening. Without that knowledge the chef cannot plan a menu, and the cooks stop trusting the changes the chef asks for. The analogy breaks in one place. Tasting takes seconds, but judging a software design takes reading and questions, so a manager must keep the skill alive on purpose. Reading a design document each week, asking engineers to explain a decision, and following an incident review all keep that judgement in use. Stated precisely, an engineering manager needs enough technical depth to judge and coach. The engineers build the system.
Step 1: Say what the job needs depth for
The first step names the managerial tasks that need technical depth, so the answer is about the job and not about ego. Charity Majors, writing in LeadDev (January 2021), argues that a manager needs solid grounding in engineering fundamentals to help engineers grow and to diagnose problems that are rarely purely social, tooling or technical, and that a manager need not be the best engineer on the team (Majors in LeadDev, 25 January 2021).
Name four: reviewing designs and asking the question that exposes risk, diagnosing why delivery is slow, hiring and coaching engineers, and explaining trade-offs to executives. The input is the job; the output is a short list. What you now know: depth is a tool for judging, not a status symbol.
Step 2: Say where you stop and why
The second step states the boundary, and it is the step that makes the answer Staff-level. In the same LeadDev piece Majors recommends letting engineers own engineering decisions and staying out of the critical path, because the manager's primary job is to be interruptible and available (Majors in LeadDev, 25 January 2021). She adds that splitting social and technical ownership between two people can blur accountability, so the manager stays accountable for outcomes while the engineers decide how to build. Say the cost of crossing the line: a manager who decides everything becomes the bottleneck. What you now know: depth gives you the right to ask questions, not the right to overrule.
Step 3: Say how you keep the skill alive
The third step shows a habit, because skills fade. In her 2017 post on her own site, Majors writes that the best frontline managers are never more than two to three years removed from hands-on work, and that skills decay the longer someone manages (Majors, 11 May 2017, same author). The 2021 LeadDev article suggests small fixes or side projects away from the critical path, and staying on call (Majors in LeadDev, 25 January 2021).
Name two habits you actually have, such as reading design documents weekly and joining the on-call rotation (taking turns to answer production alerts). If you have been out of code for years, say so and say what you are doing to close the gap. What you now know: the answer ends on a practice, not a claim.
Step-by-step description
- Name the tasks that need depth.
- Say where you stop and why.
- Name how you keep the skill alive.
- Name the tasks that need depth, such as reviewing designs, diagnosing slow delivery, hiring and coaching.
- State the boundary: let engineers own engineering decisions and stay out of the critical path.
- Keep the skill alive: design reviews, small off-path fixes, on-call.
What the evidence is, and is not
The evidence is one company's data plus one practitioner's advice. Google's data is correlational, not a controlled study, and Majors' advice is experience. Google's 2009-2011 analysis of its internal performance reviews, feedback and other reports produced eight manager behaviors, and Nextgov reported in March 2011 that "Technical expertise was ranked last on the list" (Nextgov, 21 March 2011). The eight include coaching, empowering the team without micromanaging, and showing interest in people, with key technical skills so you can help advise the team in eighth place (Government Executive, 25 January 2013).
That ranking comes from one company's data, drawn from company-wide reviews, surveys, exit interviews and award nominations as Garvin describes, and it cannot show that technical skill does not matter. It fits Majors' advice that depth supports the people work. Garvin's account notes that Google engineers were sceptical of managers and respected technical expertise more than titles (Harvard Business Review, December 2013). Note that the LeadDev article (2021) and the charity.wtf post (2017) share one author, so they are one voice, not two.
Text description of the diagram
- Let engineers own engineering decisions.
- Stay out of the critical path.
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 technical do you think an engineering manager needs to be?
Technical enough to judge, not to do. I need depth to review a design and ask the question that exposes the risk, to diagnose why a team is slow, to hire and coach engineers fairly, and to explain trade-offs to executives. I keep it by reading design documents, joining the on-call rotation and taking small fixes that are off the critical path. I stop short of owning decisions that belong to the engineers, because a manager who decides every technical question becomes the bottleneck and the team stops growing. If I could not follow a design discussion, I would pair with a senior engineer until I could.
What makes it Staff-level: it names the boundary and its cost, it shows a habit that keeps the skill alive, and it gives a concrete remedy for a gap.
The rubric
| Dimension | Weak answer | Strong answer | Staff answer |
|---|---|---|---|
| Correctness | "Very technical" or "not technical" | Technical enough to judge | Judges, coaches and diagnoses; owns no critical-path work |
| Depth | Slogans | Names tasks that need depth | Ties each task to a team outcome |
| Trade-offs | None | Mentions risk of micromanaging | Names the bottleneck cost of deciding everything |
| Communication | Defensive | Clear and brief | Gives a boundary, a habit and a remedy |
| Follow-up readiness | Surprised by "how?" | Has one habit | Names habits it practises and a remedy for a gap |
Three variants of this question
Should an engineering manager still write code?
Some should, a little, and away from the critical path. Majors suggests in LeadDev bug fixes or side projects, and warns in her 2017 post that skills decay the longer someone is away from code. Say what you do and why it never blocks the team.
Can a non-technical person manage engineers?
It can work, but Majors describes it as rare and fragile. Majors writes in LeadDev that such arrangements usually pair the manager with a tech lead, which means a senior engineer who guides technical decisions, and that this can blur accountability. Say how you would close the gap.
What do you do when the team asks you to settle a technical argument?
Ask each side for the trade-offs and the evidence, name the decision criteria, and let the owning engineers decide, unless the risk is out of their remit. Step in only to unblock, not to overrule, and record the reason.
Common mistakes
- Picking a side. (wrong) "I am hands-on, I still write most of the hard code." (right) "I stay close enough to judge and coach, and I keep off the critical path."
- Hiding behind people skills. (wrong) "I manage people, the engineers handle the tech." (right) "I need enough depth to ask the right questions and to be credible."
- No habit. (wrong) "I am very technical." (right) "I read design documents weekly and join the on-call rotation."
- Taking the decision. (wrong) "I make the final architecture call." (right) "The owning engineers decide, and I make sure the trade-offs are clear."
- No remedy for a gap. (wrong) "I have not used that stack." (right) "I would pair with a senior engineer until I could follow a review."
Follow-up questions
How do you stay technical without taking work from your engineers?
Choose work that is useful but not urgent: reviewing designs, reading incident reports, fixing small bugs and joining on-call. Majors advises in LeadDev staying out of the critical path so that no one waits on you (Majors in LeadDev, 25 January 2021). Tell engineers what you are doing and why.
How do you decide whether to build or buy?
Compare the total cost and risk of each path against the need: what is core to the product, how fast you need it, who maintains it, what it costs to run, and what lock-in you accept. Buy what is not a differentiator, build what is, and write the decision and its review date. The system design guide covers the technical side of such trade-offs.
How would you work with finance to manage the cost of a large system?
Make the cost visible by team and by service, agree a forecast based on expected growth, and review it regularly. Tell finance about the drivers that move cost, such as traffic, data volume and retention, before the bill arrives, and agree who acts when a threshold is crossed.
How would you anticipate cost increases?
Track the drivers of cost, such as traffic, data volume and retention, and build a forecast from expected growth. Set alert thresholds so a rise reaches the owner before the bill does, and agree in advance who acts.
Could two engineers build a new monitoring system in nine months?
Ask what it must do and what could be bought. Then note that two engineers for nine months is 18 engineer-months, before on-call and the cost of running the system, then state the scope they could deliver and offer a staged plan that shows value early. If the scope is larger, say so with reasons and propose a smaller first release. The behavioral interviews guide and the engineering management guide cover related questions. The situation, task, action, result (STAR) structure on the STAR method page helps you tell such a story, and interview loops shows where each round fits.
- An EM needs depth to judge, diagnose, hire and coach, not to build.
- State the boundary: engineers own engineering decisions and the manager stays off the critical path.
- Name a habit that keeps the skill alive, such as design reviews and on-call.
- Google ranked technical skill last of eight in its own data; that is correlational evidence from one company, not proof.
- Close any technical gap with a concrete plan, not a claim.
Sources
- How Google Sold Its Engineers on Management — Harvard Business Review (David A. Garvin, December 2013 issue), 1 Dec 2013
- The Engineer/Manager Pendulum — Charity Majors (first-hand practitioner account), 11 May 2017
- Should engineering managers be technical? — LeadDev (Charity Majors, author), 25 Jan 2021
- Google's recipe for superior managers — Nextgov (Alyah Khan, FCW), 21 Mar 2011
- Google's 8 Simple Rules for Being a Better Manager — Government Executive, 25 Jan 2013
