Module 5: Technical Leadership & Strategy: Case Studies
These case studies focus on leadership artifacts: strategy, alignment, escalation, stakeholder communication, mentorship, and review follow-through.
Case Study 1: Engineering Strategy That Is Only A Roadmap
Scenario: A platform team publishes a "strategy" that is just a list of projects: migrate CI, improve observability, reduce build times, upgrade Kubernetes. Teams cannot use it to make tradeoffs.
Source anchor: Will Larson's Making engineering strategies more readable, which frames engineering strategy around exploration, diagnosis, policy, and operation.
Module concepts: diagnosis, guiding policy, coherent action, roadmap vs strategy.
Wrong Approach
List actions without diagnosis or policy.
Better Approach
Write the strategy spine:
Diagnosis:
deploy lead time and test flakiness block product teams
Guiding policy:
reduce platform friction before adding new platform features
Coherent actions:
stabilize CI
standardize service templates
create ownership dashboard
Tradeoff Table
| Choice | Gain | Cost |
|---|---|---|
| roadmap list | concrete | no decision guidance |
| strategy doc | alignment | writing/review time |
| broad strategy | inclusive | weak prioritization |
| narrow strategy | focus | says no to good ideas |
Required Artifact
Write a one-page strategy: diagnosis, guiding policy, coherent actions, anti-scope, and success metrics.
Case Study 2: Staff Archetype Mismatch
Scenario: A senior IC is asked to "act like Staff" but receives conflicting expectations: lead one team, unblock an incident, define architecture, mentor engineers, and represent the group to executives.
Source anchor: StaffEng's Staff archetypes, which distinguishes tech lead, architect, solver, and right-hand archetypes.
Module concepts: Staff+ archetypes, altitude, leverage, role clarity.
Wrong Approach
"Staff engineer" means doing every senior task.
Better Approach
Clarify the archetype:
Current need:
architecture across three teams
Primary archetype:
architect
Secondary:
tech lead for migration phase
Not currently:
incident solver for every escalation
Tradeoff Table
| Archetype | Leverage | Risk |
|---|---|---|
| tech lead | team execution | too local |
| architect | cross-team coherence | can detach from delivery |
| solver | unblocks critical problems | becomes bottleneck |
| right-hand | executive leverage | ambiguous ownership |
Required Artifact
Write a role-clarity memo: archetype, scope, non-scope, weekly allocation, stakeholders, and success signal.
Case Study 3: Escalation That Burns Trust
Scenario: Two teams disagree on ownership of an API-breaking migration. One engineer escalates by saying the other team is blocking progress. The escalation creates defensiveness and slows resolution.
Source anchor: Will Larson's Making engineering strategies more readable is a useful anchor for written-first decision framing, especially when escalation must separate facts, options, and asks.
Module concepts: stakeholder map, escalation, disagree-and-commit, framing, trust.
Wrong Approach
Escalate personalities instead of decision constraints.
Better Approach
Escalate the decision:
Decision needed:
who owns v1 compatibility during v2 migration?
Facts:
consumers, dates, breakage risk, support cost
Options:
team A owns adapter
team B owns dual support
shared migration squad for six weeks
Ask:
choose owner and deadline
Tradeoff Table
| Escalation style | Gain | Cost |
|---|---|---|
| blame framing | emotional force | trust damage |
| decision framing | actionable | requires preparation |
| private alignment first | lowers surprise | slower |
| public escalation | creates urgency | social cost |
Required Artifact
Write an escalation brief with decision, context, options, recommendation, and requested decision maker.
Case Study 4: Mentorship Without Sponsorship
Scenario: A tech lead gives a mid-level engineer excellent advice but never creates opportunities for them to lead visible work. The engineer improves but remains invisible in promotion discussions.
Source anchor: StaffEng: Staff archetypes is a useful anchor for Staff+ leverage because mentorship and sponsorship both depend on explicit scope and visible delegated ownership.
Module concepts: mentorship, sponsorship, leverage, bench building, feedback.
Wrong Approach
"I mentored them, so I helped their career."
Advice helps skill. Sponsorship creates opportunity and visibility.
Better Approach
Create a growth plan:
Skill goal:
lead API migration design
Opportunity:
present RFC to architecture review
Support:
review draft, rehearse objections
Visibility:
name their ownership in status update
Tradeoff Table
| Action | Gain | Cost |
|---|---|---|
| advice | low effort | limited visibility |
| code review coaching | skill growth | local scope |
| delegated ownership | real growth | risk and support needed |
| sponsorship | visibility | must be earned and specific |
Required Artifact
Write a growth plan with one delegated artifact, one review checkpoint, and one visibility moment.
Case Study 5: Executive Summary That Loses The Decision
Scenario: A 12-page design doc recommends delaying a launch to fix reliability gaps. The executive summary says "we evaluated reliability concerns" but does not state the decision, risk, or ask.
Source anchor: Will Larson's Making engineering strategies more readable emphasizes readable structure and operational clarity for decision-first writing.
Module concepts: executive summary, audience-aware communication, decision ask, risk framing.
Wrong Approach
Summarize activity instead of the decision.
Better Approach
Write the summary as:
Decision:
delay launch two weeks
Reason:
payment retry path can duplicate charges under timeout
Risk if ignored:
customer-impacting financial incident
Plan:
idempotency keys, replay test, launch gate
Ask:
approve revised date
Tradeoff Table
| Summary style | Gain | Cost |
|---|---|---|
| background-heavy | complete | decision buried |
| decision-first | clear | may feel blunt |
| risk-first | urgency | can sound alarmist |
| ask-first | actionable | needs strong support |
Required Artifact
Rewrite a technical design summary for executive, peer engineer, and junior engineer audiences.
Source Map
| Source | Use it for |
|---|---|
| Will Larson: Making engineering strategies more readable | strategy structure and written leadership |
| StaffEng: Staff archetypes | Staff+ role patterns and leverage |
| Architectural Decision Records | structuring decision briefs and escalation artifacts around options and consequences |
Completion Standard
- At least three leadership artifacts are completed.
- At least one strategy includes diagnosis, policy, and coherent action.
- At least one role memo clarifies scope and non-scope.
- At least one escalation brief frames a decision, not a personality conflict.
- At least one executive summary makes a concrete ask.