Pillar
Engineering Leadership
The job changes from writing code to deciding what gets written.
- 31Articles
- 5 hrsOf reading
- 3Videos
Nobody gets promoted for the job they are about to start doing. You get promoted for writing good code, and then the work becomes deciding what gets written, by whom, and in what order. Very little of the first skill transfers to the second.
I have been the engineer waiting on a decision and the person who had to make it, and the habit I trust most from both sides is shaping the work before anyone opens an editor. A surprising amount of what presents as a delivery problem is a question nobody asked four weeks earlier.
Technical debt belongs here too, as a dated decision rather than a moral failing. So does psychological safety, which is a thing you do in code review rather than a poster in a corridor, and the uncomfortable middle of a career where the next title is not the point.
Start here
A route through it, in order.
- 1
Stop Writing Code First
Think through requirements, assumptions, and structure before you open your editor.5 min read - 2
Technical Debt: When to Fix, When to Ship
Technical debt is inevitable. What matters is managing it deliberately. Here is a practical framework for prioritisation and stakeholder communication.10 min read - 3
Building Psychological Safety in Engineering
How to create a culture where engineers feel safe to take risks, speak up, and make mistakes without fear of punishment.10 min read - 4
The Mid-Level Mindset
A practical mindset shift for turning thinking-first habits into mid-level engineering judgment.6 min read
Same subject
Engineering Leadership, in every other format.
Archive
Everything in Engineering Leadership, newest first.
How to Write Specs, RFCs and ADRs
Spec driven development in practice: what an RFC, an ADR and a spec are each for, the templates I use, and one feature taken through all three from a blank page.
From Diagram To Implementation Plan
Turn your diagrams and design notes into a clear build order that respects dependencies.
Introduction To Systems Architecture
Learn how to map application components, layers, and dependencies before you start building.
Reading Between the Lines
Learn how to spot hidden assumptions in a brief before you turn it into code.
Relationships, Cardinality, and the Questions Your Schema Is Asking
Understand relationship types and cardinality so your schema reflects how your data really connects.
Shaping Before You Build
Shape features before coding so scope, approach, and boundaries are clear from the start.
Stop Writing Code First
Think through requirements, assumptions, and structure before you open your editor.
The Mid-Level Mindset
A practical mindset shift for turning thinking-first habits into mid-level engineering judgment.
Thinking In Layers
Use layered thinking to place logic in the right part of your application before it turns into a mess.
Writing Features Not Tasks
Turn vague tasks into user-focused features with clearer outcomes and better stories.
Your First ERD
Map entities and relationships before you write migrations so your schema starts on solid ground.
Managing Expectations in the AI Era
How to have honest conversations with stakeholders about AI productivity - what actually changes, what doesn't, and how to set realistic expectations.