Systems thinking about how engineering teams and organizations work: the design beneath an apparent people problem.
📅 October 19, 2026
⏱️ 7 min read
My spouse recently ended up with two left toe socks and no way to wear them, because each one had lost the only sock that matched it. My drawer, and now our kids' drawers, cannot have that problem: the kids and I wear one style of sock for every occasion, so any two make a pair. Our socks are fungible. Shoes have good reason to come in lefts and rights, but socks do not need that complication, and neither do most of the systems I build. Do not build systems that need a specific matched pair when a part that fits anywhere would do.
Read more →
📅 October 18, 2026
⏱️ 9 min read
I am a good directly responsible individual in an emergency, and I do well against a reasonable deadline. That does not mean I want to live there. Manual toil is shoveling fertilizer: someone has to do it sometimes, it should rotate, and once it passes half the job you stop building. The way out is to build the machine that does the shoveling, and the hardest pile is the one that arrives from another team's pipeline.
Read more →
📅 October 18, 2026
⏱️ 7 min read
Every team change cost me six to twelve months of career momentum while trust and context warmed back up. A decade of those changes also turned adapting into a skill, and that skill matters more now that the way software engineers work is changing fast.
Read more →
📅 October 17, 2026
⏱️ 6 min read
Building a product and running it are two different kinds of work. Development ends when the thing exists; production never ends, and what it teaches has to flow back into the product as its own stream of work. Treating the two as one job hides the second one, and the accounting split between cost of goods sold and operating expenses turns out to describe the same line.
Read more →
📅 October 17, 2026
⏱️ 7 min read
Engineering quality is a property of what ships. Quality engineering is the practice that produces it, and that practice cannot be handed to another team. Quality, security, and documentation belong to the engineer who builds the thing, and the reward system has to pay for those behaviors or they quietly stop.
Read more →
📅 October 15, 2026
⏱️ 9 min read
The first 80% of a feature gets the demo, the congratulations, and the promotion packet. The last 20% (the part that makes the thing actually usable) costs a magnitude more and is rewarded far less. The reason is structural: every additional nine of reliability is a different engineering problem than the one before it, and you cannot reach it by extending a design that was never built for it. In the age of AI, when the token cost of writing the scalable version is roughly the token cost of writing the disposable one, the V1-then-rewrite habit deserves a second look.
Read more →
📅 October 09, 2026
⏱️ 9 min read
You cannot drive a Mars rover with a joystick, because the round trip for a radio signal runs six to forty-four minutes. Distance and delay are one constraint measured in two different units, and once the round trip is slower than the thing you are controlling, central control stops being inefficient and becomes impossible. The physics version of the argument for autonomy at the edge.
Read more →
📅 October 09, 2026
⏱️ 9 min read
People praise someone for having a 100% signal-to-noise ratio. Borrowed back from the field it came from, that is not a compliment, it is an impossible measurement. What SNR actually means, why the opposite of noise is information rather than signal, and what a headset with a microphone on it says about being a transmitter and a receiver at the same time.
Read more →
📅 October 06, 2026
⏱️ 9 min read
A reference write-up of Musk's five-step algorithm and what each step is supposed to mean when the thing being improved is a manual process in software engineering. Question the requirement, delete the step, simplify, accelerate, automate. Mostly a description of what the algorithm claims rather than an argument that it is correct, with a short closing note on where I do agree, in particular the rule that if you are not occasionally adding things back you are not cutting enough.
Read more →
📅 October 06, 2026
⏱️ 13 min read
Elon's algorithm is not really an automation algorithm. It is a procedure for forcing shared understanding of a process, and automation is what it happens to permit at the end. The Quest Engine says the same thing structurally and translates it to a world that is mostly digital, where the walk around the factory floor can be delegated to agents and the goal is not a fully automated process but a self-sustaining one that keeps humans only where judgment genuinely lives.
Read more →
📅 July 23, 2026
⏱️ 7 min read
A long time ago a company I worked at decided that being a Relater (a Dove) was the worst personality to have. I think that judgment is wrong, and I think the whole idea of ranking personalities is wrong. Personalities are contextual: they change with the room you are in and the season of life you are in. But there is a work personality you can learn to switch into, and for engineering the Director and the Thinker are the two worth practicing.
Read more →
📅 July 21, 2026
⏱️ 6 min read
Around 2022, before AI was useful, I onboarded a whole team into a brand new area with two- and three-hour meetings every day. Documentation was thin, the knowledge lived in people's heads, and everyone was drowning. A working session built around user story mapping cut the fog: put every actor (human or system) on a visible surface, walk the flow out loud, and let the shared picture replace the marathon meetings.
Read more →
📅 July 08, 2026
⏱️ 10 min read
A George Washington film handed me a phrase that stuck: 'independent fire.' I cannot vouch that Washington ever said it, but the tactic it points at is real history. The colonists could not win by copying British linear volleys on open fields; they had to use cover and let soldiers pick their own targets. Independent fire is the perfect model for how high-agency engineering teams should be allowed to operate.
Read more →
📅 July 07, 2026
⏱️ 13 min read
Watching World Cup 2026, some squads talk like a single organism and others like strangers in matching shirts. Soccer is a one-dimensional model of a team (one field, one ball, one clock); engineering is played across many planes at once and across time. The lesson: stardom is local, the most valuable star is the versatile generalist who moves between planes and passes the ball six months into the future, and resilient teams rotate that capability instead of betting on one hero.
Read more →
📅 July 03, 2026
⏱️ 6 min read
Blameless engineering, borrowed from Google's SRE culture, is usually filed under postmortems. But the postmortem is only the last place the culture shows up. Blamelessness shifts all the way left into how you design systems, and it lands on one uncomfortable rule: the team is the unit of work, and heroes are a symptom of a system that is not yet well crafted. In the age of agents, where there is no one to blame, that rule stops being a nicety and becomes the only way to debug at all.
Read more →
📅 July 02, 2026
⏱️ 9 min read
I used to say bad version, bad rollout, bad payload. I stopped, because a version isn't good or bad in the abstract. It's a distribution of outcomes across a population of users, configs, and use cases. The same payload can be flawless for 99% and broken for 0.5%, and calling it bad collapses that spectrum onto one label that quietly dictates how you triage, communicate, and remember the incident.
Read more →
📅 July 02, 2026
⏱️ 11 min read
When I was starting out, hesitation held me back from trying things. Over time it faded, not because I got braver, but because I got a better handle on risk. Fearless engineering is not the absence of caution. It is a calculated read of what you know, what you do not, and how far a change can reach.
Read more →
📅 June 28, 2026
⏱️ 5 min read
A reflection on why the word impact is too overloaded for work conversations, and why accomplishments and outcomes are clearer alternatives.
Read more →
📅 June 27, 2026
⏱️ 8 min read
Salty is not the opposite of sweet. They are separate receptors, separate dials, and salted caramel exists because you can turn up both at once. Most 'balance' advice is secretly slider-thinking. The method is to catch the false opposite, test for a real tradeoff, and go to the corner everyone told you was impossible.
Read more →
📅 May 30, 2026
⏱️ 6 min read
Configuration earned its place next to code: versioned, reviewed, owned. The corpus of context that aligns a team (design docs, contextual documents, the why behind the system) deserves the same standard. It's the operating system humans run on, and now the grounding agents read to understand how we work.
Read more →
📅 May 30, 2026
⏱️ 8 min read
Tanya Reilly's 'Being Glue' names the invisible human work that holds a team together but never shows up on your own record. The deeper pattern is the same one behind every high-maintenance system: a person standing in for a fix that was never made. The goal is not to be better glue, it is to build systems that heal themselves so humans are needed as glue as rarely as possible.
Read more →
📅 May 30, 2026
⏱️ 7 min read
Choosing a name is the first step in taking your team's destiny into your own hands. It is the first thing that creates a sense of belonging, and it is often ignored even though it is such a multiplier. Belonging cannot be dictated. It has to be adopted. It has to be organic.
Read more →
📅 May 05, 2026
⏱️ 8 min read
Why the word 'hunting' matters: context doesn't just lie around waiting to be picked up. Real context requires active investigation, tracing code, chasing state transitions, and turning what you found into something the whole team can use.
Read more →
📅 April 26, 2026
⏱️ 11 min read
Archimedes asked for a long enough lever to move the world. Engineering is the discipline of building those levers (correctly sized stairs, daily practice, scaffolded learning, and iterative cycles) so any wall becomes climbable.
Read more →
📅 April 01, 2026
⏱️ 8 min read
Why effort tracking (where is my time going?) needs to be separate from work tracking (what am I building?) and how centralizing effort in one tool provides visibility that scattered work-tracking systems can't.
Read more →