Engineering Management

Engineering management is a distinct profession from software engineering. The skills that make a great IC — deep focus, individual problem solving, technical depth — are necessary but insufficient for managers. The manager's job is to create conditions where the team produces excellent work consistently, grow each person on the team, and act as a translation layer between technical reality and business goals. This skill covers the practices that distinguish excellent engineering managers from those who are just "senior engineers who run meetings."

Core Mental Model

Your output as an engineering manager is not code — it's your team's output. This is a fundamental identity shift many new managers struggle with. Your job is force multiplication: what levers can you pull so the team produces 10× more value than if they worked independently?

The EM's three core responsibilities:

1. People: Growing each person, building trust, removing friction from their work


2. Process: Ensuring the team can execute predictably and improve continuously


3. Product: Partnering with PM/design to ensure the team builds the right things

Most new managers over-index on process (meetings, rituals) and under-invest in people (individualized growth, career conversations). The best engineering managers spend more time on 1:1s than sprint planning.

1:1 Meeting Structure

The 1:1 is your highest-leverage management activity. It builds trust, surfaces problems early, and creates space for career conversations that don't happen in group settings.

Format

Frequency: Weekly (non-negotiable for direct reports)
Duration:  30 minutes (new/struggling team members: 45-60 min)
Ownership: THEIR agenda, not yours
Cadence:   Never cancel — rescheduling is acceptable, canceling sends 
           a message about priorities

Basic structure:
- 0-20 min:  Their topics (they prepare and lead this section)
- 20-25 min: Your topics (blockers you can help with, feedback, context)
- 25-30 min: Career/growth (at least 20% of your 1:1s — don't let it drop)

Note-taking:
Both maintain a shared doc. Running notes from previous meetings visible to both.
Action items clearly captured with names and deadlines.

Questions That Surface Real Issues

"What's your biggest frustration this week?"
"What's slowing you down that I might not know about?"
"Are there things you'd like more or less of from me?"
"What do you need to be more effective in the next 30 days?"
"Are there decisions being made you don't understand or disagree with?"
"Is there anyone on the team you're having trouble working with?"
"What's exciting you about your work right now?"

For senior engineers / leads:
"What technical decisions are you worried about?"
"Are there technical risks I should know about?"
"How's your energy level? Burning out or feeling good?"

For struggling performers:
"What support do you need to be more effective in [specific area]?"
"How do you see things going with [project/situation]?"
(Never: "Why aren't you performing better?" — creates defensiveness, not insight)

Skip-Levels (Quarterly)

Meet individually with your direct reports' direct reports quarterly.

Purpose:
- Learn what your managers are doing well / where they struggle
- Hear team health signals you might not get filtered through managers
- Show senior ICs that leadership cares about them directly
- Gather feedback on yourself you won't get in direct 1:1s

Sample questions:
"What's one thing your manager does that helps you most?"
"What's one thing that would make the team work better?"
"Is there anything you wish I knew that you think isn't getting to me?"
"What would make this a better place to work?"

Performance Feedback: SBI Model

Situation-Behavior-Impact is the standard framework for delivering feedback that's specific, actionable, and doesn't feel like a personal attack.

SBI Structure

Situation: When/where did this happen? (specific, not "always")
Behavior:  What did I observe? (observable, not interpreted)
Impact:    What was the effect? (on the team, project, relationships)

Template:
"In [SITUATION], when you [BEHAVIOR], I noticed [IMPACT]."

CORRECTIVE FEEDBACK example:
S: "In last Thursday's sprint planning meeting"
B: "you interrupted Jamie three times while she was explaining the customer 
    requirements"
I: "Jamie went quiet for the rest of the meeting, and I'm concerned some 
    important context we needed for estimating may not have been shared."

Full delivery: "In last Thursday's sprint planning, when you interrupted Jamie 
                three times while she was explaining requirements, I noticed she 
                went quiet for the rest of the session. I'm worried we missed 
                important context for our estimates. I'd like to talk about how 
                we can create more space for everyone to contribute."

POSITIVE FEEDBACK example (positive SBI often forgotten):
S: "During the production incident on Wednesday night"
B: "you took the initiative to page in the database team and write the 
    customer-facing status update"
I: "That prevented a potentially much longer outage, and three customers 
    replied thanking us for the transparency."

Feedback Timing Rules

✅ Same day if possible (memory is fresh, behavior is observable)
✅ Private first (NEVER public corrective feedback)
✅ Written confirmation after verbal (for significant issues)
❌ NOT only in performance reviews (annual/quarterly reviews should contain no surprises)
❌ NOT accumulated ("here are 10 things you've done wrong this quarter")
❌ NOT during high-stress moments (post-incident, release day)

The "no surprise" rule:
If someone is shocked by their performance review, 
you failed at giving timely feedback throughout the year.

Hiring Process Design

Job Description

Job description structure:
1. What the role does (not just responsibilities, but impact)
2. Who you're looking for (competencies, not credentials)
3. What they'll own in 30/60/90 days
4. Compensation band (reduces wasted time on both sides)
5. What makes your team worth joining (honest, not marketing)

Common mistakes:
❌ "5 years of experience required" (correlates weakly with ability)
❌ Lists of 25 requirements (intimidates qualified candidates, esp. women)
❌ "Rockstar ninja guru developer" (reveals company culture)
❌ No comp range (signals disrespect for candidates' time)

Phone Screen (30 min)

Goals:
1. Can they do the job? (calibrate level from conversation)
2. Are they genuinely interested? (intrinsic motivation)
3. Are there any obvious disqualifiers?

Screen structure:
5 min:  Introduce the role, set the agenda
10 min: Walk me through your background / most relevant recent project
10 min: 2-3 targeted behavioral questions (STAR format)
5 min:  Their questions + next steps

Pass/no-pass criteria decided within 1 hour after screen.
Feedback sent within 24 hours (respects their time).

Technical Assessment Design

Principles:
1. Test for what the job actually requires (not clever puzzles)
2. Calibrate difficulty to the level you're hiring for
3. Time-box it (take-home: 2-3 hours max; live: 45-60 min)
4. Define scoring rubric BEFORE seeing candidates (prevents bias)

For senior engineers — avoid:
❌ Reversing a linked list (doesn't map to real work)
❌ Algorithmic puzzles they'll never use
❌ Long take-homes > 4 hours (signals disrespect)

Better senior engineer assessments:
✅ Code review: "Here's a PR — what feedback would you give?"
✅ System design: "Design a rate limiter / design a feed system"
✅ Debugging: "This code has a bug, walk me through how you'd find it"
✅ Architecture discussion: "How would you approach migrating from monolith to services?"

Structured Panel and Debrief

Panel structure (2-hour loop for senior eng):
1. [30 min] Engineering values / collaboration (EM or senior IC)
2. [45 min] Technical depth (engineer at/above target level)
3. [30 min] Cross-functional / product thinking (PM or EM)
4. [15 min] Candidate Q&A / sell the role (hiring manager)

Debrief rules:
- Everyone submits written signal BEFORE the group call
- Written signal: Hire / No hire / More info needed + reason
- Debrief moderator asks for input in reverse seniority order
  (juniors first, prevents anchoring on senior opinions)
- Reference calls for finalists (actually call — don't email)

Hiring scorecard format:
| Competency          | Scale | Notes |
|---------------------|-------|-------|
| Technical depth     | 1-4   |       |
| Communication       | 1-4   |       |
| Ownership mindset   | 1-4   |       |
| Collaboration       | 1-4   |       |
| Problem solving     | 1-4   |       |
| Role-specific skill | 1-4   |       |

1=No signal, 2=Below bar, 3=Meets bar, 4=Exceeds bar

Team Health Metrics

ESAT/eNPS (quarterly):
"How likely are you to recommend working here to a friend?" (0-10)
eNPS = % Promoters (9-10) - % Detractors (0-6)
eNPS > 20: Healthy
eNPS < 0:  Serious problem
Run anonymously; act on results within 30 days

DORA Metrics (engineering throughput):
Deployment frequency: How often do you ship? (daily = elite)
Lead time for changes: Commit to production time (< 1 hour = elite)
Change failure rate: % of deployments causing incidents (< 5% = elite)
Time to restore: Mean time to recover from incident (< 1 hour = elite)

Meeting load:
Track % of calendar in meetings (target: < 30% for ICs, < 50% for managers)
Check for: recurring meetings nobody would notice if cancelled
Audit: quarterly "meeting diet" — cancel or reduce any regular meeting

Incident rate:
P1/P2 incidents per sprint
Incident-to-postmortem ratio (100% of P1s should have postmortems)
Repeated incident patterns (same component breaking = not learning)

Technical Debt Communication

Engineers speak in "tech debt"; executives hear "slow team." Bridge this gap.

Framework: Translate debt to business impact

Bad:  "We need to refactor the payment module because the code is messy 
       and tightly coupled."
     → Executive: "sounds like an engineering problem, not my concern"

Good: "Our payment module is built on a 3-year-old architecture that requires 
       5 engineers to manually coordinate every time we add a payment method. 
       It's caused 2 P1 incidents this year ($180K estimated impact), and our 
       estimate for adding ACH support is 8 weeks when it should take 2. 
       A 3-month investment in modernizing the module would cut new payment 
       method integration time by 75% and reduce P1 risk significantly."
     → Executive: "show me the proposal"

Template:
1. Describe the business symptom (slow feature delivery, reliability, CAC)
2. Root cause in plain language (don't need technical details)
3. Quantify current cost (time, incidents, engineer effort)
4. Investment required (person-weeks)
5. Expected outcome (delivery speed, reliability, cost savings)
6. Risk of NOT doing it (grows 2x every year)

The "debt register": Maintain a living document of significant tech debt 
with severity, business impact, and investment estimate. Review quarterly 
with product leadership. Makes debt visible and planning conversations easier.

Project Estimation

Cone of Uncertainty:
At project start:    Estimate accuracy = ×4 to ×0.25 (can take 4x or 0.25x as long)
At requirements done: ×2 to ×0.5
At design complete:   ×1.5 to ×0.67
At prototype:         ×1.25 to ×0.8

Implication: Early estimates should always be ranges, never point estimates.

Range estimate format:
"Our best estimate is 3-6 weeks. Most likely: 4 weeks. 
 The 6-week scenario occurs if we encounter the database migration 
 complexity we're uncertain about. We'll know by week 2."

Estimation best practices:
1. Estimate tasks, not the project (break down first)
2. Have the engineer who will do the work estimate, not the manager
3. Account for: meetings, on-call, reviews, unexpected interruptions (~30% overhead)
4. Reference similar past projects (project tracking history is invaluable)
5. Add explicit discovery/spike time for unknowns ("we don't know until we look")

Planning Fallacy: Humans consistently underestimate. 
Correct for it by: adding 30-50% buffer, using reference class forecasting.

Managing Up

The most neglected skill of new EMs.

Weekly update email to your manager (Fridays):
---
[What shipped this week]
[What's at risk / what I need]
[What I'm focused on next week]
[Team health signal: 1-2 sentences]
---

Keep it under 200 words. Never make your manager ask "how's the team doing?"

Anticipate questions before presentations:
Before presenting roadmap/plan to execs, ask:
- "What would make [CEO/CTO/CRO] say no to this?"
- "What data are they likely to ask for?"
- Prepare for the pushback; don't be defensive

The pre-read:
For complex topics, send a 1-page summary 24 hours before the meeting.
Execs process information better with prep time.
Meeting becomes a decision, not an information delivery.

Disagreement protocols:
"Disagree and commit" — once a decision is made, execute fully, 
don't undermine it. Continued disagreement goes to your manager, 
not the team.
If the decision is wrong enough, escalate with data before consequences, 
not after.

IC vs Management Track

IC (Individual Contributor) Levels:
L3/L4: Software Engineer — executes on defined work
L5:    Senior Engineer — technically leads features, mentors
L6:    Staff Engineer — org-level technical direction, cross-team impact
L7:    Principal/Distinguished — company-wide or industry impact

Management Track:
EM:    Manages 4-8 ICs; individual team delivery
Sr. EM: Manages EMs; multi-team or large team
Director: Manages Sr. EMs; org of 30-100+ engineers
VP Eng: Manages Directors; company-wide engineering

Key distinction: 
IC track maximizes technical impact and expertise
Management track maximizes people/org/systems leverage

Staff Engineer ≠ "Senior Senior Engineer"
Staff engineers primarily create leverage through:
- Technical vision and strategy for the org
- Cross-team architecture and coordination
- Unblocking multiple teams simultaneously
- Building internal platforms/standards
NOT through writing more code than others

Psychological Safety

Amy Edmondson's concept: team members feel safe to take risks, speak up, make mistakes without fear of punishment or humiliation.

Signals of LOW psychological safety:
- Nobody disagrees with the manager in meetings
- Problems are hidden until they become crises
- Postmortems result in blame rather than learning
- Questions sound like "I'm sure this is obvious but..."
- People take fewer risks because failure = career risk

Building it:
1. Model fallibility: Share your own mistakes openly
   "I made a bad call on X last week. Here's what I learned."

2. Respond well when things go wrong:
   "Thanks for flagging this early. What do you need to fix it?"
   NOT: "How did this get past you?"

3. Blameless postmortems (Google SRE model):
   "The SYSTEM failed, not the individual. How do we prevent the 
    system from allowing this failure again?"

4. Acknowledge contribution in public:
   Specific, genuine praise in team settings builds safety by 
   demonstrating that risk-taking is rewarded

5. Create space in meetings:
   "Before we close, does anyone have concerns we haven't addressed?"
   Directly ask quieter team members for their view

Anti-Patterns

❌ Technical nostalgia — EMs who keep jumping in to code undermine team ownership and don't actually improve outcomes at scale.

❌ Avoiding hard conversations — Letting performance issues linger sends a message to the whole team about standards.

❌ 1:1s as status updates — Status updates belong in Slack/Jira. 1:1s are for growth, feedback, and trust.

❌ Hiring for "cultural fit" without defining culture — "Culture fit" is often a proxy for bias. Use structured criteria.

❌ The brilliant jerk exception — A 10× engineer who creates 3× team dysfunction is a net negative. Act on it.

❌ Closed-door estimation — Estimates made by managers without engineers doing the work are fiction. Engineers estimate their own work.

❌ Managing by walking around only — Informal context is valuable; it doesn't replace structured feedback and documented performance conversations.

Quick Reference

1:1 Template

## 1:1 — [Name] — [Date]

### Their topics
- 

### My topics
- 

### Career/growth (rotate focus each session)
- 

### Action items
| Action | Owner | By When |
|--------|-------|---------|

SBI Feedback Format

SITUATION: "In [specific time/place]..."
BEHAVIOR:  "...when you [specific observable action]..."
IMPACT:    "...I noticed / it had the effect of [specific impact]"

Follow with: question ("How do you see it?") or direction ("Here's what I'd like to see instead")

Hiring Scorecard Scale

4 — Strong hire: clearly exceeds bar, would elevate team
3 — Hire: meets bar, would contribute well
2 — No hire: below bar in key area, risk outweighs upside
1 — Strong no hire: significant gaps, would slow team down