Articles
Useful reasoning from real software work.
Each article examines a decision, the constraints around it, and what a practitioner can carry into their own work.
Start here
Three articles that show the range of the work.
How to Write a Technical Spec That People Actually Read
A 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.
How to Run an Architecture Review That Actually Helps
Most 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.
Earn Complexity
Complexity 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.
All articles
11 articles, newest first.
2026
Developer Advocacy Should Ship Working Software
Developer-facing teams build more credible content when their examples survive real implementation, not just polished demos.
Every Technical Role Is Now Product-Accountable
AI 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 Technical Leader in an AI-Accelerated Team
AI 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
Most 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
Leadership 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.
The Delivery Triangle
A 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
Complexity 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.
2025
Architecture Decision Records as Team Communication
ADRs 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
Not 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
A 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.
Signal vs. Noise in Engineering Metrics
Most 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.