07 · Technical Leadership

Level: Advanced — Leadership & Influence Pre-reading: 01 · Roles & Responsibilities · 04 · Team Effectiveness · 05 · Negotiation & Stakeholders

Technical leadership is the practice of shaping the technical direction of an organisation through influence, vision, and the systematic raising of engineering quality — without the authority of line management. It is what distinguishes a Principal Engineer from a brilliant Senior Engineer.

What Technical Leadership Is Not

The Staff Engineer Archetypes (Will Larson)

Will Larson's Staff Engineer (2021) identifies four common archetypes for how staff/principal engineers operate. Understanding these helps you identify your natural mode and develop the others.

Which archetype does which company need?

The Technical Vision Document

A Principal Engineer's most durable output is a technical vision — a written description of the desired state of the system and organisation 2–5 years from now, and the path to get there.

Why it matters

• Enables independent decision-making by teams without constant consultation
• Aligns dozens of teams around a shared direction without heavy governance
• Provides a framework for evaluating trade-offs consistently
• Creates organisational memory that survives personnel changes

Structure of a Technical Vision Document

# Technical Vision — {System/Domain Name}

**Owner:** {Principal Engineer Name}
**Date:** {Date} | **Horizon:** {e.g., 2025–2027}
**Status:** Draft | Under Review | Adopted

---

## 1. Context
What is the current state? What business challenges does this vision respond to?

## 2. Target State
What does great look like in 3 years? (Not how — what)

## 3. Principles
What principles guide our decisions on the path? (3–7 specific, non-obvious principles)

## 4. Strategic Bets
What are the 3–5 major architectural choices we are committing to? Why?

## 5. What We Are NOT Doing
Explicit de-prioritisation — as important as what is included

## 6. Migration Path
How do we get from current state to target state? Phases, milestones, decision points.

## 7. Success Metrics
How will we know we are on track? (DORA metrics, quality attributes measured)

Technical Debt Governance

Technical debt is inevitable — the discipline is in making it visible, intentional, and managed.

The Technical Debt Quadrant (Martin Fowler)

                    DELIBERATE          INADVERTENT
                ┌──────────────────┬──────────────────┐
                │                  │                  │
  RECKLESS      │  "We don't have  │  "What's layered │
                │  time to design" │  architecture?"  │
                │                  │                  │
                ├──────────────────┼──────────────────┤
                │                  │                  │
  PRUDENT       │  "We must ship   │  "Now we know    │
                │  now; we'll fix  │  how we should   │
                │  later"          │  have done it"   │
                │                  │                  │
                └──────────────────┴──────────────────┘

The Technical Debt Register

A principal engineer should advocate for a Technical Debt Register — a maintained, visible inventory of known technical debt:

Influence Without Authority

The defining challenge of Technical Leadership is achieving change without the ability to command it. This requires a distinct set of skills from management.

The Influence Model

Influence Tactics That Work at Principal Level

Mentorship and Growing Principal-Level Engineers

A principal engineer who cannot grow the next generation is hoarding their value rather than multiplying it.

The Four Stages of Competence (for Mentoring Framework)

Mentoring Ladder

A structured approach to growing engineers toward staff/principal level:

1. Expose — invite them to architecture reviews, design sessions, RFC discussions
2. Explain — articulate your reasoning out loud, especially when making trade-off decisions
3. Involve — give them ownership of a component of an RFC or ADR with your guidance
4. Delegate — let them own a complete RFC/ADR; you review and coach
5. Sponsor — actively advocate for their promotion and expanded scope

The On-Call and Incident Response Culture

A principal engineer shapes how the organisation responds to production incidents.

Blameless Post-Mortem Structure

# Incident Post-Mortem: {Incident ID}

**Date:** {Date}
**Severity:** SEV1 | SEV2 | SEV3
**Duration:** {Start time} → {End time} ({duration})
**Impact:** {User impact; number of affected users; data affected}
**Owner:** {Named engineer}

---

## Timeline
| Time | Event |
|:-----|:------|
| HH:MM | Alert fired |
| HH:MM | On-call engineer paged |
| HH:MM | Root cause identified |
| HH:MM | Mitigation applied |
| HH:MM | Service restored |

## Root Cause Analysis
5 Whys or fishbone: what was the actual root cause?

## Contributing Factors
What systemic conditions made this possible?

## What Went Well
What worked during the incident response?

## What Could Be Improved
Systemic improvements — not personal failures.

## Action Items
| Action | Owner | Due date | Priority |
|:-------|:------|:---------|:---------|
| Add alerting for X | @engineer | {date} | P1 |
| Implement circuit breaker for Y | @engineer | {date} | P2 |

Technology Radar — Governing the Technology Portfolio

The Technology Radar (popularised by ThoughtWorks) is a tool for visualising an organisation's technology portfolio and providing guidance on adoption.

Four Rings

Four Quadrants

A principal engineer should be able to justify where every significant technology in their domain sits on the radar, and why.