Technical Leadership for Platform Engineers
What changes when an engineer becomes the technical anchor of a platform team: making and recording architecture decisions, handling disagreement, balancing technical debt with delivery, building a roadmap, running the platform as a product with self-service golden paths, winning adoption without authority, leading major incidents and blameless reviews, growing engineers, and measuring whether the platform works.
What you'll be able to do
- Explain what a lead engineer owns and how to act as a force multiplier
- Make, record and revisit architecture decisions, and disagree productively
- Balance technical debt with delivery using visible costs and steady capacity
- Build a platform roadmap from user needs, risks and mandatory work, and communicate it
- Run the platform as a product: golden paths, self-service and adoption
- Lead major incidents and blameless reviews, grow engineers, and measure platform success
Before you start
Some years of hands-on platform or infrastructure work. No management experience needed.
How it works
Each lesson: plain-language idea → how it really works → hands-on. Each section ends with a cheat sheet & self-check.
Curriculum
Lessons marked “Read” are ready; the rest are on the way.
Part 1 — Decisions
- 01The lead engineer's jobTechnical anchor and force multiplier: what you own, what you delegate, how your week changesRead →
- 02Architecture decisions and ADRsOptions, trade-offs, decision records, reversible versus one-way doors, disagree and commitRead →
- 03Leading through technical disagreementSeparating people from ideas, decision criteria, spikes, changing your mind in publicRead →
- 📋Cheat sheet & self-checkEvery command from this section on one page, then 7 questions to check yourself.Open →
Part 2 — Direction
- 04Technical debt versus feature deliveryMaking debt visible, costing it, steady capacity, paying it down with featuresRead →
- 05Building a platform roadmapInputs, themes, prioritisation, mandatory work, communicating and revising itRead →
- 06Platform as a product: self-service and golden pathsUsers, golden paths, onboarding by pull request, guard-rails instead of gatesRead →
- 07Driving platform adoptionInfluence without authority: pilots, migration help, proof, making the right way the easy wayRead →
- 📋Cheat sheet & self-checkEvery command from this section on one page, then 8 questions to check yourself.Open →
Part 3 — People and outcomes
- 08Leading a major incident and the review after itIncident command, communication, stabilise first, blameless reviews that change thingsRead →
- 09Mentoring and growing engineersDelegation, pairing, design reviews as teaching, feedback, stretch workRead →
- 10Measuring platform successDORA metrics, SLOs, developer experience, adoption, toil and costRead →
- 📋Cheat sheet & self-checkEvery command from this section on one page, then 6 questions to check yourself.Open →
Real-world scenarios
Work through each one: symptom → misleading signal → evidence → root cause → prevention.
Both are reasonable; the team is stuck. Get to a decision everyone can commit to.
Six months of work, two teams onboarded. Find out why and turn it around.
This site is a public version of my personal engineering knowledge hub. It intentionally excludes confidential company information and internal operational details.