Lesson 01 of 10 · Part 1 — Decisions
The lead engineer's job
What changes when you become the technical anchor of a platform team: what you own, what you deliberately give away, how you multiply the team instead of out-coding it, and what a good week looks like.
From senior engineer to lead
| As a senior engineer you… | As a lead engineer you also… |
|---|---|
| Deliver complex work well | Make sure the team delivers well |
| Own a component | Own the architecture and its non-functional qualities (reliability, security, cost, operability) |
| Solve the problem in front of you | Decide which problems are worth solving, and when |
| Review code | Set standards and use reviews to teach |
| Know your area deeply | Connect the platform to product needs and other teams |
The title varies (lead, staff, principal, technical anchor); the shift is the same: your output becomes the team's output.
A senior engineer is a great player. A lead engineer is a playing captain: still on the pitch and still scoring sometimes, but mostly making sure the whole team plays well together, knows the plan, and gets better every match.
What you own
- Architecture: the current design, its known weaknesses, and where it's heading.
- Technical decisions: made well, written down, revisited when facts change (lesson 02).
- Quality bar: standards for code, reviews, testing, operability.
- Technical risk: upgrades, deprecations, security, capacity, single points of failure.
- Alignment: with product, other platform teams, security and operations.
What you give away
Hand the interesting work to others, with support: a design you'd have done in a day might take someone else a week, and that week is how they grow (lesson 09). Keep for yourself the work only you can do, plus some hands-on time so your judgement stays grounded in the real system.
How you multiply
| Lever | Example |
|---|---|
| Decisions | A written decision unblocks three engineers who were waiting for direction |
| Unblocking | Ten minutes on someone's stuck problem saves them a day |
| Reviews | Design reviews early, when changes are cheap |
| Standards and templates | A golden path that makes the right way the easy way for every team |
| Teaching | Pairing, brown-bag sessions, written guides |
| Shielding | Saying no to distractions so the team can finish what matters |
A healthy week
- Some deep technical time (design, a hard bug, a prototype).
- Reviews and unblocking, spread through the week, not batched to Friday.
- Alignment with the manager, product and neighbouring teams.
- Looking ahead: risks, roadmap, the next quarter's big problem.
- People: one-to-ones or pairing with the engineers you're growing.
Try it: audit your own week
- Write down how you spent the last two weeks, in hours, in the categories above.
- Mark which tasks only you could have done, and which someone else could have done (perhaps more slowly).
- Pick two tasks to hand over next week, with a short brief and a check-in.
- Block two half-days for deep technical work and one hour for looking ahead.
- Repeat in a month and compare.
Going deeper: leading without authority
Lead engineers usually have no reporting lines. Influence comes from credibility (being right often, and admitting when you're not), clarity (writing things down), generosity (helping others succeed) and consistency (the same standards for everyone, including yourself).
Recap
- The shift: your output becomes the team's output.
- Own architecture, decisions, quality, risk and alignment.
- Give away interesting work with support; keep what only you can do.
- Multiply through decisions, unblocking, reviews, standards, teaching and shielding.
This site is a public version of my personal engineering knowledge hub. It intentionally excludes confidential company information and internal operational details.