Filed under
Engineering Leadership
17 pieces on this topic, newest first — essays, notes, and case files in one stream.
Every Technical Role Is Now Product-Accountable
EssayAI is lowering the cost of building software. That does not remove the need for architects, managers, or technical leads. It removes the excuse for any of them to stay distant from user value.
The Cost of Unclear Ownership
NoteUnclear ownership is not primarily a people problem. It is a system design problem, and its costs are almost always invisible until they are expensive.
Small Teams Have Never Had More Leverage
NoteAI tools do not flatten the difference between strong and weak teams. They amplify it. A disciplined small team with clear scope and high standards will compound faster than ever.
The Decision Hierarchy Problem
NoteMost organizational friction is not a communication problem. It is a decision authority problem that has been relabeled as a communication problem.
The Technical Leader in an AI-Accelerated Team
EssayAI tools speed up first-pass implementation, but leadership leverage is moving toward problem framing, system judgment, and team clarity.
How to Run an Architecture Review That Actually Helps
TutorialMost architecture reviews are either rubber stamps or political obstacles. This is a practical guide to running reviews that improve technical decisions without slowing teams down.
Make Decisions Legible
PrincipleLeadership is not primarily about making better decisions. It is about making decisions that the people executing them can understand, trust, and act on with confidence.
Protect the Team's Attention
PrincipleThe real constraint in an engineering team is not time — it is focused attention. A leader who protects uninterrupted deep work creates more leverage than one who optimizes scheduling or headcount.
The Delivery Triangle
FrameworkA framework for understanding why engineering teams miss estimates — and why the fix is almost never "better estimation." It is almost always clarity on one of three inputs.
Earn Complexity
PrincipleComplexity is not inherently bad. Unearned complexity is. The difference is whether the complexity was added to solve a real, present problem — or to prepare for a future that may not arrive.
Architecture Decision Records as Team Communication
FrameworkADRs are widely prescribed and rarely used well. The reason is almost always that teams treat them as documentation artifacts instead of communication tools. Here is how to use them as the latter.
Optimize for Reversibility
PrincipleNot all decisions are equally expensive to undo. The highest leverage engineering discipline is not making better decisions — it is preserving the ability to change them when you learn more.
How to Write a Technical Spec That People Actually Read
TutorialA technical spec is a decision document, not a documentation artifact. This guide covers how to structure one so it surfaces disagreement early, builds shared understanding, and creates a durable record of why the system was built the way it was.
What AI Changes About What It Means to Be a Senior Engineer
NoteAI tools compress the gap between junior and senior for implementation tasks. The remaining gap — and its value — is shifting toward judgment, problem framing, and the ability to recognize when the code is solving the wrong thing.
Build for the Team That Will Maintain It
PrincipleThe best architecture for a system is the one the team that will maintain it can understand, debug, and change confidently. A technically superior architecture that the team cannot navigate is not superior.
Signal vs. Noise in Engineering Metrics
FrameworkMost engineering metrics measure activity, not outcome. A framework for identifying which metrics carry real signal, which generate noise that looks like signal, and how to build a measurement system that actually improves decisions.
Estimation Is a Communication Problem, Not a Math Problem
NoteTeams that struggle with estimates usually struggle with something deeper — unclear scope, missing context, or distrust between engineering and the business. The estimate is just where the problem surfaces.