Josh Lane — Writing

How You Do It Is Part of the Decision

Fri, 11 Sep 2026 00:00:00 +0000

The necessity of an outcome does not justify every method used to reach it.

Leadership sometimes requires decisions that leave people worse off. Avoiding those decisions can be a failure of responsibility. But so can treating their necessity as permission to stop examining our choices.

Establishing that something must change answers only part of the question. We still have to justify the approach, account for the people who bear its costs, and take responsibility for what follows. Those are not matters to settle after the decision. They are part of what we are deciding.

That is where our standards become more than statements of intent. Integrity has to govern choices that are costly and contested, not only choices that are easy to defend. The goal is not to avoid hard decisions. It is to remain accountable for the whole decision.

You do not get to delegate the weight

The person who passes judgment should swing the sword.¹

The authority to impose a consequence comes with a responsibility to answer for it. That responsibility does not depend on who delivers the news.

You can ask someone to coordinate a transition. You can rely on people with the right expertise to carry it out. But you still owe the people affected an explanation you are willing to give yourself. You still have to own the consequences, including the ones that make your decision harder to defend.

A leader can attend every conversation and still evade responsibility. Another can appropriately delegate those conversations while setting the standard, providing resources, and correcting failures. The test is whether we remain answerable for what happens.

“I made the decision; someone else can deal with the people” is not a complete account of leadership. Distance can remove precisely the information that should inform our judgment: what the plan actually asks of someone, and where it leaves them.

The minute you start delegating away the hard part—not because someone else is better equipped to do the work, but because you do not want to face it—you start dying as a leader.

Delegate the work, not the weight

DecideMake the call.
ExplainFace the consequences.
Carry outDelegate the work.
Follow throughRemain accountable.

Responsibility

The work can change hands. Responsibility for the decision does not.

Be precise about what was necessary

“We had no choice” deserves a more specific question: no choice about what?

Ending an investment? Acting before a deadline? Giving people little information? Leaving them to work out the consequences themselves?

A necessary objective is not the same as a necessary intervention. Needing to reduce costs does not establish that a particular staffing reduction is the right plan. We still have to compare it with other ways of meeting the need.

Consider a project that no longer warrants its investment. Continuing would consume resources needed elsewhere. Stopping it may be the right call.

That does not tell us when to inform the team, how to represent their work, or how to handle commitments made to customers. It does not tell us what support people need to move to their next responsibilities. Those choices face their own constraints and need their own justification.

The standard cannot be that nobody is upset. Someone may understand a decision and still strongly oppose it. Their disappointment does not establish that the decision was wrong; their acceptance does not establish that it was handled well.

Crucial Conversations calls the supposed choice between honesty and respect a “Fool’s Choice.”² We can be clear about what has been decided without dismissing what it costs the person hearing it. A gentle but evasive answer can leave someone unable to plan.

Support costs money. A transition takes time. Some information cannot yet be shared. We should weigh those constraints before approving the change, with a dependable standard for how people will be treated.

Avoidable harm is not always unjustified harm. One consequence may be avoidable only by imposing a greater cost elsewhere. The obligation is to examine the alternatives, make defensible tradeoffs, and own their costs. Calling the overall decision necessary does not make every choice about its execution inevitable.

Composure is not indifference

Experience should make us better at carrying the responsibility, not more willing to disregard it. You may become less anxious before a difficult conversation, more precise in your explanation, and better able to listen without becoming defensive. You may stop confusing your discomfort with evidence that the decision is wrong.

Personal distress is not evidence that we acted well. A composed leader can take another person’s loss seriously; an anguished one can still treat them carelessly. Someone else’s loss should carry moral weight without making the event about our own feelings.

In Meditations 5.20, Marcus Aurelius describes turning an impediment into material for action. In 6.30, he puts kindness alongside disciplined action.³ I take those ideas together: the difficult conversation is part of the work of leadership. Here, the obstacle to overcome is our temptation to avoid responsibility, not the person affected by our decision.

That gives us something to practice: explaining the reasoning, hearing an angry response without retaliating, and correcting a consequence we could reasonably have prevented. Composure helps us do that work. Indifference gives us permission to skip it.

Character is in the choices

Character shows in what we choose when we have room to choose differently.

It is relatively easy to speak well of people while their work serves our needs. The more demanding test comes when our interests diverge. Their contribution does not disappear because their project, role, or agreement no longer fits our plans. People should not have to remain useful to us to be treated with care.

Epictetus argues in Discourses 2.18 that our actions strengthen the corresponding habits.⁴ Each decision is practice for the next one. Facing consequences and arranging not to face them are both things we can become practiced at. Experience alone does not tell us which we are learning.

The pattern matters as much as the individual call. If urgency repeatedly becomes our reason to break a commitment or refuse to hear the consequences, we should question what we are practicing. Expedience cannot become a standing permission to abandon our standards.

Those choices become evidence for other people, too. Do we keep an inconvenient commitment? Acknowledge an error? Apply a standard consistently when the circumstances are comparable? People see whether our account of ourselves survives contact with a difficult situation.

A colleague can dislike my decision and still have reason to trust my conduct. Earning that trust requires more than being agreeable. It requires judgment they can rely on and commitments that hold under pressure.

Resolve is not hostility

A leader can end an argument by making disagreement unpleasant. That does not establish that the decision improved. Even when aggression secures a concession, the concession does not account for what happened to cooperation or the information available next time.

James Detert and Ethan Burris found that managerial openness was associated with employees speaking up with suggestions for improvement, with perceived safety helping explain the relationship.⁵ My concern is the reverse incentive: when bringing a problem means inviting a confrontation, silence can become the easier choice. A meeting with fewer objections may contain less information.

In three experiments, Christine Porath and Amir Erez found that rudeness reduced task performance and helpfulness.⁶ Contempt can carry an immediate cost to the work. I want the person who sees a flaw in the plan to bring it forward while we still have time to act.

We can set demanding targets, negotiate firmly, stop failed investments, and terminate employment when the reasons warrant it. Listening does not give someone a veto; correcting an error does not mean abandoning the goal. The work still has to meet the requirement.

A successful outcome does not establish that aggression caused it, let alone that aggression was necessary. We have to ask what a different approach might have achieved and what information or cooperation we sacrificed along the way.

Play the long game

A business needs capable people who will choose to join, stay, and do difficult work together. Losing people can disrupt execution; attracting replacements depends on more than having a vacancy. Turnover and recruiting research give us reason to include the people needed for continued execution in the business case for change.⁷

Enjoying our colleagues matters, but trust asks more than whether we like them. The distinction between ability, benevolence, and integrity is useful here: can you do the work, do you care about my interests, and do you follow principles I can accept?⁸ A demanding colleague can earn that confidence while making decisions I dislike.

Research associates trust in leadership with commitment, job performance, and lower intention to quit.⁹ Pay, workload, growth, and the work itself still matter. Trust belongs among the conditions that make staying worthwhile; it cannot stand in for all of them.

A layoff makes this concrete. Research on layoff survivors found worse reactions among remaining employees who identified with departing colleagues and perceived the departing employees’ compensation as inadequate.¹⁰ Removing an expense leaves a team that still has to believe it can work effectively together.

Adam Grant’s Give and Take describes how generosity can build trust and reputation, and how givers can burn out or be exploited without boundaries.¹¹ The longer horizon includes both what others learn from our conduct and what we practice through our choices. That is the practical sense in which I think about karma: we carry those relationships and habits into the next decision.

Decency deserves no less consideration when its return is uncertain. Integrity cannot guarantee commercial success. It can help preserve conditions the business needs to succeed, while meeting obligations that matter in their own right.

What carries forward

A decision

OutwardRelationships

What others learn from our conduct

The trust they bring next time

InwardCharacter

What we practice through our choices

The habits we bring next time

The next decision

We carry forward both the trust we leave with others and the habits we build in ourselves.

Finish the decision

Before approving a consequential change, we should be able to explain why this approach is justified, who bears its costs, and which alternatives we considered. That includes choices about timing, communication, and support. Where a responsible approach costs more or takes longer, that belongs in the proposal.

When a proposal only works because we have left out the costs of carrying it out responsibly, the proposal is not finished.

For a reduction in staff, I would want a plan for the business that remains: what work stops, which commitments continue, and who has the capacity to meet them. The plan should specify how people will be told and what transition support is reasonably possible. Someone needs the authority and resources to carry that work through.

Then judge the result beyond the announcement. Did the savings materialize after transition costs? Can the remaining team meet its commitments? Are important risks still raised early? Are we losing effective people the plan depended on retaining? Retaining everyone is not the objective; sustaining the capabilities the business needs is.

We must remain available to hear consequences we failed to anticipate and correct what we can. An explanation that was defensible at approval does not relieve us of responsibility for how the plan works in practice.

How you do it is part of the decision. Being willing to face what you decided is part of the job.

A Game of Thrones
George R. R. Martin · 1996, Bran’s first chapter

The sentence adapts Ned Stark’s maxim about passing sentence and swinging the sword. Its application here concerns accountability, not literal punishment. The opening image evokes a different story: in Cicero’s Tusculan Disputations, Book Five, §§61–62, the suspended sword reveals the peril accompanying power. Neither metaphor establishes the essay’s business claims. ↩︎
Crucial Conversations: Tools for Talking When Stakes Are High
Joseph Grenny, Kerry Patterson, Ron McMillan, Al Switzler, and Emily Gregory · Third edition, 2021

The “Fool’s Choice” rejects treating honesty and respect as incompatible; see also Crucial Learning’s glossary. This supports the distinction between candor and disrespect, not a guarantee that painful decisions can leave relationships unchanged. Applying it to the responsibilities around a decision is the argument made here. ↩︎
Meditations, Book Five, §20
Marcus Aurelius · Translated by George Long

In 5.20, an impediment to action can become material for an appropriate response. Book Six, §30 places kindness and social duty alongside disciplined action. The application to difficult leadership conversations is mine, not a claim that Marcus wrote about modern employment decisions or promised commercial success. ↩︎
Discourses, Book Two, Chapter 18
Epictetus · Translated by George Long

Actions maintain and strengthen their corresponding habits; Epictetus specifically warns that repeatedly acting in anger reinforces anger. This is the philosophical basis for the character-formation argument, not empirical evidence of a financial return or a doctrine of guaranteed reward and punishment. ↩︎
Leadership Behavior and Employee Voice: Is the Door Really Open?
James R. Detert and Ethan R. Burris · 2007

A two-phase field study in a restaurant chain linked managerial openness with improvement-oriented employee voice, with perceived psychological safety mediating the relationship. This is evidence about speaking up, not a randomized test of leadership styles or a direct estimate of company profits. The author’s full-text copy is also available. ↩︎
Does Rudeness Really Matter? The Effects of Rudeness on Task Performance and Helpfulness
Christine L. Porath and Amir Erez · 2007

Three experiments found reduced routine and creative task performance and reduced helpfulness under rude treatment. The findings concern rudeness in experimental settings, not firm standards, lawful terminations, or a quantified effect on long-term business performance. ↩︎
Turnover Rates and Organizational Performance: A Meta-Analysis
Tae Youn Park and Jason D. Shaw · 2013

Turnover rates were negatively associated with organizational performance on average, with differences by turnover type and context. This does not establish that every departure harms performance or that necessary terminations should be avoided.

Derek S. Chapman and colleagues’ Applicant Attraction to Organizations and Job Choice (2005) synthesizes 71 studies. Recruiting outcomes were associated with job and organizational characteristics, recruiter behavior, process perceptions, and perceived fit. Connecting these findings to how consequential decisions are implemented is the essay’s inference, not a measured effect of a particular layoff on hiring. ↩︎
An Integrative Model of Organizational Trust
Roger C. Mayer, James H. Davis, and F. David Schoorman · 1995

This conceptual model distinguishes perceived ability, benevolence, and integrity as contributors to trustworthiness. Trust involves willingness to accept vulnerability; it is distinct from liking, cooperation, or a guaranteed outcome. ↩︎
Trust in Leadership: Meta-Analytic Findings and Implications for Research and Practice
Kurt T. Dirks and Donald L. Ferrin · 2002

The meta-analysis draws on 106 samples. It reports associations with outcomes including commitment, job performance, and intention to quit. Intentions are not actual departures, and the findings do not establish that integrity causes retention or financial success through the entire chain proposed here. ↩︎
Survivors’ Reactions to Layoffs: We Get By with a Little Help for Our Friends
Joel Brockner, Steven Grover, Thomas Reed, Rocki DeWitt, and Michael O’Malley · 1987

The strongest negative reactions occurred when survivors identified with those laid off and perceived the departing employees’ compensation as inadequate. Outcomes were work performance in a laboratory study and organizational commitment in a field study. The result supports considering treatment of departing colleagues, not a universal severance amount, a guaranteed return on support, or a claim that all layoffs have identical effects. ↩︎
Give and Take: A Revolutionary Approach to Success
Adam Grant · 2013

Grant describes both the long-term value of trust and reputation and the risk of burnout or exploitation. His Wharton interview discusses those mechanisms and the importance of boundaries. This informs the long-game argument; it is not evidence that every act of generosity earns a return. ↩︎

Systems That Remember

Tue, 08 Sep 2026 06:15:00 -0700

On August 27, a deployment briefly degraded EasyPost’s Core APIs. At 10:26 AM, the change was identified and rolled back. By 10:40, the APIs were back to normal.¹

The interesting part is that rollback was already available.

EasyPost deploys through a system built around canary traffic, retained previous versions, and immediate rollback.² Those mechanisms did not make failure impossible. They changed what happened after failure.

They show what durable learning looks like once it has been encoded into the system, regardless of whether a particular mechanism came from an incident or deliberate design.

What matters after 10:40 is whether this incident leaves another durable change behind.

Start with the system

When something goes wrong, my starting assumption is that the person nearest the failure is giving me evidence about the system around them.

That does not mean people never make mistakes, judgment does not matter, or performance problems should be ignored. It means that blaming the person who happened to trigger a failure is usually a poor way to understand why the failure was possible.

A deploy reaches too much traffic before anyone can see the effect. A dependency can stall every request thread. An operator has to remember an unusual recovery sequence. A dangerous state is technically valid because nothing rejects it.

The person is visible. The conditions that made the failure likely are less visible.

Google’s SRE practice makes blamelessness part of the mechanics of learning, not just a preference about tone. Its postmortem guidance starts from the assumption that people acted in good faith with the information available to them, then looks for changes to systems, procedures, and training that reduce recurrence.³

I like that framing because blame distorts signal. If surfacing a mistake is personally expensive, people become rationally selective about which mistakes they surface. Near misses stay private. Ambiguous evidence gets cleaned up before it is shared. The organization learns less because it has made learning risky.

Blamelessness is useful because it makes the system easier to investigate honestly.

A postmortem can still forget

Writing down what happened is better than relying on memory. It is not the end state.

A postmortem can explain that a rollout needed better isolation. Six months later, a new engineer can ship without reading it. A runbook can explain the recovery sequence. At 3 AM, somebody can miss step seven. A document can say that a particular configuration is unsafe while the API continues to accept it.

The lesson still depends on a person remembering the lesson.

When possible, I want the learning to move closer to the place where the failure occurred.

What we learned	What the system can remember
We could not see the failure early enough	Instrumentation, alerting, health checks
A change could affect too much traffic at once	Canarying, staged rollout, blast-radius controls
Recovery depended on a person remembering what to do	Automated rollback or recovery
A dependency can fail in a predictable way	Timeout, retry, fallback, isolation
An invalid state was allowed	Validation, invariant, test, policy
A procedure was repeatedly performed by hand	Automation
The interface made the wrong action easy	A simpler interface

Not every lesson belongs in code. Some failures expose ambiguous goals, bad incentives, missing expertise, or genuinely contextual decisions. Those still require judgment.

But repeated mechanical corrections are a smell. If the same failure keeps producing the same reminder, the reminder is probably living at the wrong layer.

A postmortem records what happened. A system change records what was learned.

Learning changes tools

Encoding a lesson changes more than the implementation. It changes the environment the next person operates inside.

A deployment tool that defaults to a canary makes gradual rollout ordinary. An API that rejects an unsafe configuration removes a decision somebody previously had to remember. Better instrumentation puts evidence in front of an operator before they have to remember to go looking for it.

The important mechanism is the default. People tend to take the path a system makes easiest, especially when they are busy, unfamiliar with it, or operating under pressure. A safer procedure that requires remembering an exception is weaker than a tool that makes the safer procedure ordinary.

This is the same idea behind a pit of success: do not merely tell people what the right action is. Shape the environment so that the right action is the natural action, and make the dangerous path harder or impossible when you can.

A postmortem can say, “canary this kind of change.” A deployment system can canary it by default. Training can say, “check this signal before proceeding.” A workflow can put that signal directly in the decision path. Documentation can say, “never create this state.” An API can refuse to create it.

The lesson changes the tool, and the tool changes the behavior that follows from it.

That gives me a useful test for whether an organization has really retained a mechanical lesson:

A system remembers when someone who never learned the lesson still behaves differently because of it.

The next engineer does not need to know which incident produced a guardrail. They inherit the accumulated judgment embedded in the interface, the defaults, the automation, and the constraints around them.

Over time, the operating environment becomes a record of what the organization has learned.

Reliability is accumulated memory

This is the part of incident response that compounds.

A perfectly monotonic uptime graph would be nice, but it is not how complex systems usually improve. Systems change, traffic changes, dependencies change, and new failure modes appear. A better system can still have an incident tomorrow.

What I want to see is accumulation.

EasyPost’s release history includes repeated work on shipment-purchase performance, database-query performance, connection stability, USPS fallback handling, carrier timeout behavior, and other reliability or latency paths.⁴

Not every change is incident-driven. The important pattern is the accumulation of small changes to the mechanisms that determine how the system behaves when reality differs from the happy path.

The rollback path from the August incident shows the other side of that accumulation. The important fact is not that rollback was invented during the outage. It was already there. Some earlier decision had made recovery a capability of the system instead of an improvisation by the operator.²

The capability was part of the system before anyone needed it that morning.

That is the operational version of the learning loop I described in Close the Loop: failure produces evidence, but the loop is not really closed until that evidence changes future behavior.

Make the lesson durable

Incidents already cost something: customer trust, engineering attention, interrupted work, lost sleep, sometimes money.

Restoring service stops the immediate cost. It does not recover it.

The return comes from learning something that changes the next failure. Maybe the next incident is detected earlier. Maybe its blast radius is smaller. Maybe recovery takes one action instead of twelve. Maybe the entire class of failure becomes impossible.

That is why I care more about the action that survives the postmortem than the postmortem itself.

People forget. Systems do not have to.

EasyPost, status page, incident history for August 27, 2026. ↩︎
EasyPost, Shipping API Reliability Guide, July 14, 2025. ↩︎ ↩︎
Google SRE, Postmortem Culture: Learning from Failure and the SRE Workbook chapter on postmortem culture. ↩︎
EasyPost, release history. ↩︎

Minimum Effective Dose

Sun, 06 Sep 2026 18:42:54 -0700

Suppose a customer asks for a report every Monday morning.

Before anyone sends it, the work expands. We need configurable schedules. Different file formats. Saved views. A place to manage all of it. Each addition is reasonable if we are building a reporting product.

But we do not yet know whether the report helps the customer make a better decision.

That is the question I want answered first. Not whether we can build a reporting system. Whether this particular information, delivered to this person at this time, changes something worth changing.

I want the smallest intervention that gives us a credible answer, then I want the answer to determine the next investment.

That is what I mean by minimum effective dose: enough intervention to resolve the uncertainty that matters, without accumulating obligations around an answer we do not yet have.

The thing to minimize is the cost of reaching the next informed decision, not the ambition of the eventual result.

Information that changes a decision

A team can learn a great deal without getting any closer to deciding what to do.

Benchmarking databases might be useful. It does not answer whether anyone needs the report. Interviews might establish that people dislike their current process. They do not establish that our integration can obtain the required data before Monday morning.

I care about decision-relevant information: what we need to know to choose the next action.

Dan North’s Deliberate Discovery frames engineering work around identifying the ignorance constraining progress and deliberately reducing it.¹ Wes Kao uses minimum effective dose for a closely related business idea: do enough work to obtain the insight needed for the decision.²

Before starting, I want three things to be clear: what we do not know, which decision that prevents us from making, and what we would do differently depending on the result.

For the report, we might be deciding whether to invest in recurring delivery. The first useful evidence is whether the customer can use the information, in time, to make the decision they described.

An enthusiastic response is not the same as use. Use is not the same as a better outcome. One customer’s result is not proof of a market. Each observation justifies a different next step.

If every possible result leads to “continue building the original plan,” we are not really running an experiment.

A path through positive space

A project can become an inventory of everything that might eventually be required. Every customer, exception, dependency, failure mode, and future extension gets a place in the design before we have established a useful path through any of them.

I think of positive space as the part of the problem where we have evidence that useful action is possible: a concrete route from a need to an outcome under conditions we understand.

For the Monday report, that route might be one data source, one agreed calculation, one recipient, and one decision. It gives us somewhere to stand. We can then ask what prevents that path from being dependable, repeatable, or useful to someone else.

A failed attempt can locate the path too. If the customer receives correct information and does nothing differently, perhaps the report answers the wrong question, arrives too late, or reaches someone who cannot act.

Positive space is not positive results. It is evidence about where useful action is possible.

Narrow does not mean incomplete

A steel thread is a useful implementation pattern here: build a narrow slice through the relevant parts of the real system rather than building each component extensively and connecting them later.³

For the report, the thread runs from source data to customer decision. A working query is only part of it. So is an email arriving on time. We need enough of the real path to find out whether the information can do the job.

One report. One decision. A complete path.

Test whether the information is useful before building a reporting platform.

Real inputOne relevant data source
Use correct data with appropriate access.
DeliveryOne report, on time
Reach the person who needs to act.
DecisionOne intended use
Observe whether the information changes the decision.
ResultEvidence, not a demo
Decide what to continue, change, or stop.

Figure 1. Narrow across use cases; complete across the path needed to answer the question. A useful result for one customer does not prove general demand or scalable delivery.

This does not require every report format or a scheduling interface. It does require correct data, appropriate access, intelligible output, and delivery early enough to matter. We also need to observe what happens after delivery.

Choose the thread for the uncertainty it encounters, not because it is easy to demonstrate. If the external source is the risk, replacing it with a convenient stub avoids the question. If customer value is the risk, perfecting the integration before anyone sees the result may be the wrong order.

Sometimes the minimum intervention is not software. A manually prepared report can test whether the information is useful. It cannot establish that an automated service is reliable or inexpensive to operate. A technical thread can establish integration behavior without demonstrating willingness to pay.

The test has to reach the thing we claim to be testing.

Follow the constraint

Once a path produces a useful result, what prevents it from doing so reliably or at the required scale?

Goldratt’s Theory of Constraints gives a useful rule for choosing the next intervention: improve what limits the system’s objective rather than whichever component is easiest to optimize.⁴

Suppose the report proves useful but repeatedly arrives after the customer’s decision. Tracing the path suggests that corrections and a shared review queue cause the delay.

The next dose could be a bounded trial with clearer input requirements and checks that prevent avoidable rework before review. That uses the reviewer’s existing capacity better and changes the work upstream. It does not justify a reporting platform or a faster query.

Then measure the path again. Did usable reports reach decisions sooner without worsening errors or delaying other necessary work? Moving this report to the front of the queue may simply transfer the delay.

A steel thread makes the path observable. Constraint thinking helps choose where to intervene. Minimum effective dose keeps that intervention proportionate to what the evidence can justify.

Scope creep spends the answer before we have it

Adding custom schedules to the first report is not just another task. It postpones the value question and commits more effort to an assumption the report was supposed to test.

Martin Fowler’s account of YAGNI includes the carrying cost of speculative capability: even before it is useful, its complexity makes later changes harder.⁵ Here there is another cost too: speculative scope delays the evidence that could redirect the work altogether.

I use a simple test for proposed additions:

Does this help us answer the question in front of us, or is it something we expect to need after that question is answered?

Correctness checks may be necessary to interpret the result. Access controls may be necessary to run the trial responsibly. Instrumentation may be necessary to know whether anything changed. Those belong in the minimum when the experiment depends on them.

Multiple export formats, a configuration interface, and support for other departments need a different argument. “We will probably need them eventually” is not enough.

The boundary protects the question long enough to answer it. It should not protect the original solution from what we discover.

Keep the machinery movable

Kent Beck’s “make it run, make it right, make it fast” is useful to me as an ordering rule, especially when paired with small slices and short feedback cycles.⁶

For the report, establish one useful path. Make it dependable enough for the commitment being tested. Then invest where the evidence says improvement matters.

I think of this as keeping the machinery movable while the requirements are still moving. In software, we can bolt an unsettled answer down with a public interface, a deep dependency chain, or a general-purpose framework. In a business, we can do it with a service promise, a specialized team, or a contract built around the current process.

The implementation may be small while the commitment is large.

That is why the dose includes the cost of changing our minds. A narrow boundary around an uncertain integration, tests around the behavior we need, and enough observability to understand failures can all make the next change cheaper. They may be part of the minimum rather than overhead to remove.

Reducing breadth does not reduce the standard. If the result arrives too late to be useful, performance is already a requirement. If the trial handles sensitive data or moves money, the relevant safeguards belong in the trial.

The business needs a complete path too

The engineering path might end with a correct response. The business path usually does not.

If we are testing a paid service, we may also need to know whether the customer understands the offer, can adopt it, receives the promised benefit, and will pay enough to justify delivering it. Those are separate uncertainties.

For an initial trial, an existing sales process, a straightforward agreement, a standard invoice, and explicit manual work may be enough. There is no reason to build a new commercial system around the first customer.

But count the manual work. If every report needs an hour of intervention, the trial has demonstrated delivery with an hour of labor attached. Hiding that effort does not establish good economics.

Minimum effective dose becomes local cost-cutting when complexity is merely moved into Operations or onto the customer. A system has not become simpler because the obligation changed owners.

Manual delivery may still be the cheapest credible way to test usefulness. Once delivery is understood and recurring, automation may become the smaller continuing burden. The dose changes as the evidence changes.

Make the next commitment earn its place

In Lead With Problems, I argued for a named owner accountable for the outcome, with functions supplying the capabilities needed to achieve it.

That owner also needs to sequence the learning. Otherwise each function can build its part of the imagined final system while nobody resolves the uncertainty that could invalidate the whole effort.

I want the owner to explain what currently limits the outcome, the evidence behind that diagnosis, and the next test. What commitments does it require? What would the result justify? What would cause us to stop?

Earn the next commitment

Each intervention should change what we are justified in doing next.

QuestionWhat blocks the decision?
Name the uncertainty and the outcome that matters.
TestWhat would resolve it?
Choose the smallest credible test, including necessary safeguards.
EvidenceWhat actually happened?
Account for the result, limitations, and all the work involved.
CommitmentWhat does this justify?
Continue, change, or stop. Expansion is not automatic.

Figure 2. The next intervention starts from the evidence, not the unbuilt portion of the original plan.

After the test, return to the claim. What changed? What remains uncertain? What is the strongest conclusion the evidence supports? What did the intervention cost, including work done by other people?

That is where closing the loop matters. The result has to change the next action: stop, strengthen the path, or move attention to a different limitation.

This is not a license for endless experiments. Once the relevant uncertainty is sufficiently resolved, act. The rigor of the evidence should follow the consequences of the decision: one reversible trial may justify another, while a broad customer promise or difficult-to-reverse architecture needs stronger evidence.

Concentration, not austerity

Minimum effective dose does not mean permanently doing less. It means refusing to make every possibility a prerequisite for progress.

Once the original outcome is achieved, additional investment may be worthwhile. Greater reliability, lower operating cost, or a broader offering can justify substantial work. But that work needs an argument of its own.

I want a steel thread through the problem, not a miniature version of every system we might eventually need. Enough of the real path to obtain credible evidence. Enough care to meet the standard of the commitment. Little enough speculative machinery that the answer can still change what we do.

Start narrow. Finish the path. Expand for a reason.

Introducing Deliberate Discovery
Dan North · 2010

Identifies and reduces the specific ignorance constraining delivery. The decision-oriented scope test here is my application of that principle. ↩︎
Use the minimum effective dose
Wes Kao · 2020

Applies the phrase directly to doing enough work to obtain the insight needed for a business decision. ↩︎
Steel threads are a technique that will make you a better engineer
Jade Rubick · 2023

Describes thin, integrated slices through important use cases. ↩︎
Introduction to Theory of Constraints
Goldratt Research Labs

Explains Goldratt’s system-level focus and five focusing steps. ↩︎
Yagni
Martin Fowler · 2015

Explains the build, delay, carrying, and repair costs of speculative capability. ↩︎
Mastering Programming
Kent Beck · 2024

Includes “make it run, make it right, make it fast” alongside slicing and feedback-oriented programming practices. ↩︎

Socrates: Before I Say ‘Go Build It’

Sun, 06 Sep 2026 17:45:00 -0700

I originally told Socrates to ask me fewer questions.

Socrates is a Claude skill I use before planning a piece of work. An earlier version had what sounded like a good rule: read the code, inspect the configuration, look through prior decisions, and try to answer every question before interrupting me. If the agent found a plausible answer, it should record the assumption and move on.

That worked well for facts. It was a bad rule for decisions.

Which language does this repository use? Research it. Does an old restriction still serve a purpose? The repository can tell me that the restriction exists. It cannot tell me whether I still want it.

I had optimized the skill to reduce conversation at exactly the point where the conversation was useful. I did not need a faster requirements form. I wanted the agent to help me think through the work before an implementation gave one interpretation momentum.

So I changed the rule: research should arm the question, not eliminate it. Bring me what you found. Explain why it might matter. Then ask the question that the evidence cannot answer for us.

Why Socrates

The part of the Socratic method I’m borrowing is not “keep asking why.” It is the examination of a claim against the rest of what we think we know. A question exposes an assumption; another commitment puts pressure on it; the contradiction or missing premise becomes visible.

That matters because a request to an AI is not necessarily a correct specification of the problem. I may arrive with a preferred solution and a lot of confidence. The model may have an equally plausible interpretation. Neither deserves to become the plan merely because it was stated first.

The useful outcome is sometimes less certainty, not more. We discover the hole in an answer we were already prepared to act on.

That is different from endless debate. Socrates still has to converge. The current dialogue loop works one consequential topic at a time: research it, ask one informed question, judge the answer, follow up when it is vague or contradictory, and stop when the relevant issue is stable enough to proceed. There is no question quota to satisfy and no prize for making a small task ceremonial.

The useful thing is making the assumption visible before either of us builds on it, not getting the agent to agree with me.

Examining the approval claim

Initial claimThis removes the agent’s ability to approve its own spending.

QuestionWhich routes to the costly tools does this approval actually control?

TensionThe prompt guards one interface. The agent retains other access to the tools.

Revised understandingKeep deliberate human approval in the guarded workflow. State the limit of that control.

Examining the claim established where the approval could be relied on.

From request to clarity

What the lock actually stops

I wanted an AI agent to ask before spending more money. An expensive query or a long analysis session could run past the budget I had in mind. The proposed fix was a biometric approval gate: when the work needed approval, I would authorize it with Touch ID.

The feature’s description went further: it would remove the agent’s ability to approve its own spending.

During review, that claim ran into the rest of the design. The agent retained shell access and other routes to the underlying tools. Requiring a fingerprint in one interface did not put those routes behind the same approval. The useful question became whether the gate was still worth building with that limitation.

I kept it. There was a specific behavior I wanted to stop in the normal workflow: an agent reaching a budget limit, retrying with a larger allowance, and treating its own answer to a confirmation prompt as my permission. Requiring my fingerprint made that approval step mine. It remained useful even though it could not control every action available to the agent.

That gave the specification a narrower, testable promise. Within the guarded interface, denying approval or letting it time out must stop the operation. An option that automatically answers yes must not count as authorization. The agent’s access outside that interface remained an explicit limitation.

The gate shipped with that narrower purpose. The review changed what I was prepared to rely on it for. I could require deliberate approval in this workflow without mistaking the prompt for control over all the agent’s spending.

How the acceptance criteria changed

Initial proposal

Build the biometric approval gate

Describe agent self-approval as removed

Ship

After review

Build the biometric approval gate

Define which workflow the gate controls

Require human approval within that workflow

Test denial, timeout, and automated confirmation

Accept the gate with its limits documented

A working prompt is only part of the evidence. Acceptance depends on what the guarded operation does when approval is absent.

Layered reasoning

Make the argument inspectable

Once the dialogue settles, Socrates does something that matters more than producing polished prose: it turns the result into a reasoning chain.

The layers are problem, requirements, constraints, risks, success, validation, and execution readiness. I do not care whether all seven headings are present because seven is a nice number. I care that each layer has to follow from the one below it.

For the cost gate, the problem was spending beyond an intended budget without a deliberate decision from me. That established a requirement: when the guarded workflow asks for approval, only a human can supply it. The constraint was that the agent kept its other access to the tools. Recording that constraint exposed a risk: I might trust the gate to enforce a spending limit beyond the workflow it actually controlled.

From there, success becomes concrete: a denied or unanswered request must leave the costly operation unexecuted. Validation has to force those cases and inspect what happens afterward. A screenshot of the fingerprint prompt establishes that a prompt appeared. It says nothing about whether the operation still ran after the prompt failed.

The specification also records what the executor can decide. Prompt wording and internal code structure leave room for judgment. Continuing after a timeout changes the agreement. So does accepting an automated confirmation as approval. Those choices have to come back to me, even if they make the implementation easier.

The next agent may have none of the conversation that established these limits. The document has to explain why an apparently helpful fallback would violate the requirement.

The seven layers, applied to the cost gate

1Problem
spending beyond the intended budget without a deliberate human decision
2Requirements
require human approval when the guarded workflow reaches its limit
3Constraints
the agent keeps its existing shell access
4Risks
trust in the gate extends beyond the workflow it controls
5Success
the guarded operation stops when approval is denied or absent
6Validation
exercise refusal and timeout; verify that no costly operation runs
7Execution readiness
approval rules, dependencies, and checks are settled

Each layer changes what the next one must prove. A weakness higher in the stack should send us back down, not get papered over in the plan.

Document, sequence, and preserve intent

The output of Socrates is not the conversation. It is a set of artifacts another process can use: an authoritative spec.md, an optional independent critique, a plan.md, and verification evidence when the work is done.

The accompanying decision record illustrates what I want the handoff to preserve: the decision, why it exists, what is delegated, and what evidence would demonstrate it. It is a condensed example for the cost gate, not a copy from a saved Socrates session.

What the handoff preserves

Decision to preserveRequire human approval within the guarded workflow. Other access remains outside its control.

Executor may choosePrompt wording and internal code structure.

Executor must preserveDenial or timeout stops the operation. Automated confirmation is not approval.

Evidence for acceptanceExercise missing approval and automated confirmation; inspect whether the costly operation ran.

The decision record carries the why, the limits, and the proof obligation into the next session.

Once that agreement is stable enough, Socrates freezes and versions the specification before planning. “Frozen” is procedural, not magical file protection. If critique exposes a bad assumption or execution discovers something genuinely new, the specification can reopen. What should not happen is an executor quietly weakening the requirement until its preferred implementation qualifies.

Then sequencing becomes a different problem. Every task in the plan has to trace back through a requirement to the original problem, and the plan gets its own dependency graph. The question is no longer “what do we mean?” but “what has to happen before what?”

In the cost-gate example, independent plan critique exposed the overstated promise. That finding belonged back in the specification, where it could change both the implementation plan and the standard used to judge the result. Leaving the correction in a review comment would make it too easy for a later executor to miss.

That is why I separate specification review from plan review. A specification can be right while the proposed steps fail to preserve it. A plan can be internally coherent while testing the wrong thing.

For the gate, useful verification evidence would show the outcome of denial and timeout, including whether any costly work ran. It would also show that an automated confirmation could not substitute for the required approval. That evidence could establish the agreed behavior within the guarded workflow. The verifier could not turn it into a broader claim about every route the agent could take.

This is an AI workflow, but the underlying discipline is older and broader: examine the claim, make the reasoning explicit, preserve the decisions, sequence the dependencies, and test the thing you actually meant.

I use Socrates because AI makes execution cheap enough that starting the wrong work is increasingly the expensive mistake. Sometimes the outcome is a better plan. Sometimes the outcome is deciding not to build the thing I originally asked for.

Before I say “go build it,” that is exactly the kind of friction I want.

The decision handoff

1Interrogate

Research + dialogue

2Freeze spec

spec.md + authority boundaries

3Critique plan

plan.md + independent review

4Execute

implement the agreed change

5Verify

dogfood the failure paths

Reasoning and execution are different sequences. The documents preserve the decisions while the plan orders the work.

Lead With Problems

Sun, 06 Sep 2026 23:29:00 +0000

If I ask a team to build a dashboard, I have already made several decisions.

I have decided that the problem is missing information. That a dashboard is the right way to provide it. That someone will use the information to make a better decision. And that building software is worth more than the other things the team could do.

Perhaps all of that is true. But if I only communicate the solution, those assumptions arrive as instructions. The team can execute perfectly without testing any of them.

I want the organization to distinguish what we know needs to change from what we currently think might change it.

Marty Cagan makes this distinction in his writing about empowered product teams: their responsibility is to find a solution that produces a useful outcome, not merely implement a feature someone else selected.¹

That requires more than a better problem statement. The funding, decision rights, and definition of success cannot still belong to a predetermined solution.

The problem has to become the unit of ownership, not just the opening paragraph of a project brief.

A missing solution is not a problem statement

“We don’t have a dashboard” describes an absence. It does not establish that the absence matters.

Consider a hypothetical business where new customers stall between signing a contract and completing their first successful transaction. Someone asks for an onboarding dashboard.

The delay could come from unclear requirements, slow access approvals, an unreliable integration, or a handoff nobody owns. A dashboard could make the delay more visible without making it shorter.

Start with who is getting stuck, where they wait, and what we have observed. The dashboard is a hypothesis. So are changing a policy, improving documentation, and eliminating a handoff.

There is a line commonly attributed to Charles Kettering:

A problem well stated is a problem half solved.²

Defining the problem is productive work. Finding that a customer is waiting for an approval, rather than struggling to use the software, can change both the solution and who needs to be involved.

But the clearer definition only matters if the team can act on it. If a team cannot reject the proposed solution while remaining accountable for the problem, it has been assigned a solution.

Putting “improve onboarding” above “build dashboard” does not change that.

Leadership still has to choose

There are more real problems than a company can afford to solve. Reframing a feature roadmap as outcomes does not establish that it contains the most important problems.³

My responsibility is to identify the smallest set whose solution would materially improve the company’s position, then concentrate resources on them. Why this problem? Why now? What are we choosing not to do?

“Grow revenue” and “improve efficiency” name desirable results without explaining the obstacle or a credible way through it. Richard Rumelt’s distinction is useful here: strategy connects a diagnosis to a guiding policy and coordinated actions. A target alone does not do that work.⁴

Teams should surface problems leadership has missed and challenge a diagnosis when the evidence contradicts it. Leadership still has to make the choices and resolve competing claims on resources.

Put the problem where it can be solved

A proposed solution can quietly determine which department receives the work.

“Build a dashboard” goes to a software team. “Hire more implementation engineers” becomes a staffing request. “Train the customer better” goes to customer success. Each narrows the diagnosis before anyone has established where the problem lives.

In the onboarding example, the relevant system runs from what Sales promises to what the customer can successfully do. The owner needs to follow that whole path, not just the part inside one department.

The operating model I want separates two responsibilities: functions develop capabilities and maintain standards; a named problem owner stays accountable for the complete outcome.

That owner needs capacity commitments from contributing functions, authority within agreed constraints, and a named leader to resolve conflicts beyond that authority.

“Own onboarding” is an empty assignment if the owner can change a page but cannot get a decision about the approval process causing the delay. Leadership has to commit the necessary capacity, provide that decision path, or place ownership where the conflict can be resolved.

Individual teams can own bounded contributions. Someone must still own the complete outcome. Every department finishing its task does not help a customer who remains stuck.

The people manager and problem owner can be different people. Their commitments must not create two competing priority queues. Capacity, decision rights, and escalation need to be agreed rather than renegotiated by individual contributors every morning.

Two responsibilities, one outcome

The problem can cross functions. Accountability must follow the complete path.

Functions

Develop capabilities and maintain standards. Commit the capacity the problem needs.

Problem owner

Coordinate the work across functions. Stay accountable for the complete outcome.

Named leader

Resolve policy or priority conflicts beyond the owner's agreed authority.

Capacity, decision rights, and escalation make ownership actionable.

Discover the solution together

Problem ownership is not unilateral solution ownership.

In a product team, Product is responsible for value and business viability, Design for usability, and Engineering for feasibility. Those responsibilities support joint discovery; they are not a sequence in which Product decides, Design decorates, and Engineering implements.⁵

Engineers should help determine what is worth building. Designers should question whether the workflow makes sense. Product needs to understand what can be sold, supported, funded, and operated, not just what a customer requested. Functions outside the team contribute constraints and access to customers and data, not merely a list of features.⁶

A named owner makes accountability clear. It does not make one person’s judgment sufficient.

Make the assignment useful

A problem brief should make the next decision easier. For the hypothetical onboarding problem, it might look like this:

Problem. New customers stall between signing a contract and their first successful transaction. We need to establish where they wait and why.

Why now. Customers cannot use what they bought. Establish the frequency and cost of the delay before committing to the requested dashboard.

Evidence and uncertainty. We have stalled onboarding cases to investigate. We do not yet know whether missing information, approvals, or integration failures explain the delay.

Outcome and guardrails. Reduce time to a successful first transaction without increasing errors or shifting manual work onto customers. Establish a baseline before setting a target.

Ownership and authority. Name an onboarding owner and agree on capacity from the teams needed to investigate. Let the owner choose the approach within those commitments; name the leader who resolves policy or priority conflicts.

Next decision. Trace recent onboarding attempts and review the findings in one week. Decide what to test, who must act, or whether the problem warrants further investment.

Suppose that investigation shows most of the delay sits in an approval queue with no clear owner. The onboarding owner brings the evidence to the policy owner and agrees on a named approver and an escalation deadline for a limited trial. If the functions cannot agree on capacity, the designated leader resolves the tradeoff.

Engineering does not build the dashboard merely because it was the original request. The owner now has a different answer to test against the same outcome.

Change the review, not just the brief

If every review asks only whether the feature shipped, the practical definition of success is still delivery.

Deployment does not end the responsibility. The team still needs to establish whether the intended benefit occurred and respond when it did not.⁷ That is the same discipline I described in Close the Loop: test the result against reality, not just the completion of the work.

For the onboarding trial, assigning an approver is an action; shorter customer waits are the intended result. Compare those waits with the baseline, check errors and support effort, and investigate cases still getting stuck. Then continue, change, or stop the approach.

Outcome measures can move for unrelated reasons. The owner is responsible for distinguishing evidence of improvement from coincidence, escalating blockers, and changing an approach that is not working. Sound process supports that responsibility; it does not replace the result.

Stopping is also a decision. The problem may be smaller than expected, the economics may not work, or another problem may deserve the resources. The owner should be able to make that case without defending the continued existence of a project.

Keep the answer open

Leaders can propose solutions. Constraints can be fixed. Routine maintenance does not require elaborate discovery.⁶ The requirement is to distinguish what is genuinely constrained from what is merely someone’s preferred answer.

“I think a dashboard would help because teams cannot see where customers are waiting” is useful because the explanation makes the idea testable. If the dashboard is mandatory, say so. Do not ask a team to discover a solution while privately expecting it to rediscover yours.

The discipline matters most when substantial effort is at stake: choose the problem deliberately, put it where it can be solved, and give the owner enough authority to let evidence change the answer.

Marty Cagan, Product vs Feature Teams, August 29, 2019. The distinction concerns outcome accountability and authority to discover solutions, not merely team composition. ↩︎
Robert W. Lucky, When the Problem Is the Problem, IEEE Spectrum. Attributes the quotation to Charles Franklin Kettering; this is a secondary attribution, not a verified original Kettering source. ↩︎
Jon Moore and Marty Cagan, Changing How You Decide Which Problems To Solve, September 23, 2022. ↩︎
Richard Rumelt, The perils of bad strategy, June 1, 2011. ↩︎
Marty Cagan, The Four Big Risks, December 4, 2017; and Value and Viability, February 7, 2022. ↩︎
Chris Jones and Marty Cagan, Stakeholders and the Product Model, December 1, 2025. Covers problem framing, sharing potential solutions, business constraints, access to customers and data, and proportionate treatment of operational work. ↩︎ ↩︎
Marty Cagan, Product Model Concepts, January 17, 2024, especially Product Delivery. ↩︎

Harmony

Sun, 06 Sep 2026 18:22:16 +0000

A specification can become incoherent one reasonable answer at a time.

I built Socrates, a Claude skill, to turn ambiguous intent into an execution-ready specification through dialogue. It investigates the problem, challenges assumptions, tests interpretations, and makes success criteria and decision boundaries explicit. The goal is a shared understanding that lets an agent do the intended work rather than execute the wrong task correctly.¹

Harmony is one of the properties Socrates evaluates: whether the problem, requirements, assumptions, constraints, success criteria, and verification strategy still describe the same task as the conversation changes.¹

A requirement can be clear while its acceptance test rewards the wrong behavior. A risk can look acceptable while depending on a fallback another decision removed. Each answer can make sense in isolation. Together, they may no longer describe a viable task.

In Close the Loop, I argued for feedback that tests a result against reality. Harmony applies a complementary check inside the specification.

Do our requirements and checks still describe compatible ideas of success?

What Unix already got right

Unix already gives us narrow purpose and composition together. The 1978 foreword by McIlroy, Pinson, and Tague tells programmers to make each program do one thing well and to expect its output to become input to another program.²

The useful amendment for my own practice is temporal: composition has to remain coherent as its parts change.

A useful interface lets me ignore how another component works. It cannot let me ignore the promises I depend on.

That distinction matters in specifications too. The sections are separate because they serve different purposes, but the promises crossing those sections still have to agree.

The contract between the contracts

Consider a simple job-processing system.

The client may retry a request for up to 24 hours. It uses the same request identifier each time. The service remembers completed identifiers for at least that long, so it can recognize a retry instead of performing the work again.

Now shorten the retention window to 15 minutes to reduce storage.

The service faithfully expires its records after 15 minutes. Its tests pass. The client faithfully retries within its 24-hour window. Its tests pass too.

But a retry arriving after the record expires can be treated as new work.

Both local rules are implemented correctly. The shared promise is broken.

Before

The retention policy covers the retry promise.

Client retry window: 24 hours

Service memory: at least 24 hours

This timing condition holds. Other correctness checks still apply.

After a local optimization

Storage falls. The client's promise stays unchanged.

Client retry window: 24 hours

Service memory: 15 minutes

Contract mismatch: an allowed retry can repeat completed work.

Figure 1. Illustrative example: both local rules can be implemented correctly while the shared retry guarantee fails.

The relationship that mattered was not the request shape. It was the relationship between the retry window and the lifetime of the service’s memory.

Interface theory gives this distinction a formal counterpart. In Interface Automata, Luca de Alfaro and Thomas Henzinger model both a component’s assumptions and guarantees, then reason about whether components are compatible.³ I am borrowing the distinction, not claiming Socrates implements that formalism.

In the retry example, the deduplication window has to cover the retry window. Losing records, changing identifiers, and concurrent requests introduce other requirements, but the timing relationship alone is enough to show why two locally valid decisions can conflict.

The same conflict can exist before any code does. A requirement permits retries for 24 hours. A constraint permits retaining the necessary records for only 15 minutes. Someone has to change the design, change the promise, or reject the optimization.

Untouched does not mean unaffected

The dangerous part of the retry example is the client. Nobody changed it.

A review focused on storage might examine memory usage, expiration behavior, and cleanup performance. All relevant. None tells us whether the client can still rely on the service.

The client’s previous validation depended on an assumption about how long the service remembered requests. When that assumption changed, the justification changed too.

An unchanged component can lose its justification.

I think about conclusions in a design discussion the same way. We decide a requirement is feasible because a constraint holds. We accept a risk because a fallback exists. Later, the constraint changes or the fallback disappears, while the earlier conclusion remains marked as settled.

That conclusion is no longer settled for the same reasons.

Jon Doyle’s A Truth Maintenance System records the reasons behind beliefs so they can be revised when assumptions change.⁴ Socrates does not implement Doyle’s algorithm, but the practical obligation is similar: conclusions should not outlive the premises that justified them.

That is the part of Harmony I care about most. It is not terminology consistency. It is preserving the dependency between a decision and the reasons it was safe to make.

The property and the check

Harmony names the property. The recurring review is how Socrates tries to preserve it.

Requirements engineering has treated inconsistency as useful information rather than merely a defect to erase. Nuseibeh, Easterbrook, and Russo describe evolving specifications, code, tests, and other descriptions that can disagree in ways that expose missing knowledge.⁵

That fits the behavior I want from Socrates. A contradiction should reopen the discussion, not be smoothed over so the plan reads cleanly.

Most checks in the workflow are revisited when the conversation touches them. Harmony runs on every interrogation pass. Its useful question is:

What would this change break somewhere else in the spec that nobody is discussing?¹

In the retry example, shortening retention should reopen the retry promise, its acceptance tests, and migration assumptions—not just the storage paragraph. Socrates should ask whether the promise changes or another mechanism must preserve it.

The process records a Harmony assessment on each pass, including rationale and uncertainty. Contradictions are resolved, bounded, or explicitly left open; a frozen specification can be reopened when later evidence undermines its premises.¹

Harmony in Socrates

Each interrogation pass checks the whole specification, including conclusions nobody edited.

ChangeA requirement, constraint, or assumption changes.
Identify what is different.
TraceWhich earlier conclusions depended on it?
Untouched does not mean unaffected.
ReconcilePreserve the promise—or explicitly revise it.
Reopen decisions when needed.
Verify and recordCheck the relationship. Name the uncertainty.
A recorded review is not a proof.

Figure 2. Harmony checks whether the specification still holds together. This is a review procedure, not a formal proof.

That does not turn the process into a proof system. The verification procedure can check that Harmony was assessed and that required escalations have a recorded resolution.⁶ It cannot prove that the assessment found every contradiction.

The benefit is narrower: the whole specification remains an explicit object of attention, and uncertainty is left visible instead of being converted into false consistency.

The tools have to agree too

The change that introduced Harmony also corrected an inconsistency in the tooling itself.

The specification workflow represented an approved specification with a status of Validated and a separate Frozen: true flag. The orchestration instructions used a different vocabulary: they treated Frozen as the status to wait for.

The producer and consumer disagreed about the same state transition.

The same change aligned that vocabulary and repaired an active-session pointer expected downstream but not written upstream.⁷

Those defects were small. They made the abstraction concrete: separate tools can each do their own job correctly while disagreeing about the protocol between them.

The fix did not copy the entire Harmony process into every command. Specification work kept the reasoning; critique and verification received checks appropriate to their roles; orchestration stayed narrow.⁷

Preserving the whole does not mean making every part do everything. It means making responsibility for the relationships explicit.

Make the review cheaper

If every small change required re-proving the entire system, independent development would disappear.

The practical answer is to make important relationships explicit enough that most checks can stay narrow.

Start with the promise. In the retry example, that is not “the expiration worker ran.” It is “a permitted retry must not repeat completed work.”

Name the assumptions that support it, then give the relationship a check. A test can complete a request, advance a controlled clock beyond the proposed retention window, retry within the client’s allowed window, and verify that the work is not repeated. A configuration check can reject incompatible windows earlier.

Once the relationship is explicit, we do not have to rediscover it in every review.

The harder work is finding relationships we have not represented yet. That is where I still want people and AI reasoning across the changed boundary: which promises depend on this decision, which earlier conclusions may no longer hold, and who can authorize a revision?

Every-pass assessment does not mean exhaustive re-proving. The depth of investigation should follow the consequences of the change, not just the size of its diff.

If every small change genuinely affects everything, Harmony is not the root-cause fix. The boundaries probably need to change.

The organizational version

The same failure appears in organizations.

Suppose a company wants teams to own outcomes but retains central approval for every consequential decision. Each manager can follow the process correctly. The accountability promise and authority model still do not fit together.

Or suppose a company promises faster delivery while adding review stages whose waiting time is excluded from the delivery target.

The question is the same as in the retry example: what has to remain true elsewhere for this local rule to work?

Local autonomy is more useful when teams know which promises they are free to change and which ones other teams rely on. Decomposition should reduce unnecessary coordination. It should not make necessary coordination ownerless.

Preserve the whole

Harmony starts as a property of a Socrates specification. The broader rule I would add to my working version of the Unix philosophy is:

Do one thing well. Compose through clear interfaces. Preserve the coherence of the whole as the parts change.

A new answer can reopen an old conclusion. A locally correct change can invalidate a neighboring promise. A component can remain untouched while the reasoning that justified it disappears.

The useful discipline is to make those relationships visible enough that stable ones become checks and unstable ones remain subjects for judgment.

Close the loop to detect whether the system worked. Use Harmony to keep its parts from pursuing incompatible definitions of success.

My Socrates instructions, particularly the purpose, Harmony commandment, Commandment Scoring, and freeze/reopen semantics. These specify intended behavior; they do not themselves enforce every requirement. ↩︎ ↩︎ ↩︎ ↩︎
M. D. McIlroy, E. N. Pinson, and B. A. Tague, UNIX Time-Sharing System: Foreword, Bell System Technical Journal 57(6), 1978, especially the Style section. Original paper; HTML transcription. ↩︎
Luca de Alfaro and Thomas A. Henzinger, Interface Automata, ESEC/FSE 2001, pp. 109–120. Publication; author-institution record and abstract. ↩︎
Jon Doyle, A Truth Maintenance System, Artificial Intelligence 12(3), 1979, pp. 231–272. Publication and abstract. ↩︎
Bashar Nuseibeh, Steve Easterbrook, and Alessandra Russo, Leveraging Inconsistency in Software Development, IEEE Computer 33(4), 2000, pp. 24–29. Publication; author-hosted paper. ↩︎
My verification instructions, Step 5: Harmony Cadence and Deferral. ↩︎
Add Harmony and per-commandment confidence scoring, September 3, 2026. ↩︎ ↩︎

Close the Loop

Sun, 06 Sep 2026 00:00:00 -0700

Most failures I see in AI-assisted engineering are not failures of intelligence. They are failures of feedback.

A model can reason well about code, write a plausible implementation, run some checks, and confidently say the task is finished.

None of that means the thing actually works.

What signal tells the model that reality moved toward the state I actually wanted?

That is the difference between an open-loop system and a closed-loop one. Once I started thinking about AI this way, a lot of my tooling changed.

Open-loop AI

The naive pattern is simple: give the model a task, let it reason, and let it produce an artifact. Then the model looks at what it produced and effectively asks itself whether it seems right.

A more capable model improves the odds. A better prompt may improve them again. Neither creates a return path from reality.

A closed loop does. The model acts. The environment changes. Something measures the result. That evidence comes back, and the next action can respond to it.

Open loop

Plausible, but unverified.

IntentAIOutput

No return path from reality.

Closed loop

Action informed by evidence.

Intent

AIActionEnvironment

Evidence Verification

Observe the result. Adjust the next action.

Figure 1. The difference is not a better prompt. It is a return path from reality.

Claude Code itself works roughly this way: gather context, act, verify, repeat. Anthropic’s broader agent guidance makes the same point about obtaining ground truth from the environment during execution.¹

The engineering question is what counts as ground truth for the requirement at hand.

Verify where the requirement lives

I recently rediscovered this while rebuilding this website.

The agent changed the source and committed it. The static-site build passed. The deployment completed.

The image on the actual mobile site was broken.

The uploaded image was corrupted, but none of the intermediate checks looked at the user-visible result. They established that source could build and deploy, then those successes were treated as evidence for a different claim: that the page worked.

The requirement did not live in Hugo. It was that a person opening the site on a phone should see the right page.

So verification had to happen on the deployed domain, in a browser, at the relevant viewport.

That leads to a rule I use aggressively now: verify at the layer where the requirement exists.

If the requirement is visual, inspect the rendering. If it is an API contract, exercise the API. If it is a deployed service, observe the deployed service. If it is a data pipeline, check the resulting data.

Intermediate checks are useful. They establish narrower claims.

Design the feedback loop before the implementation

This changed how I think about specification.

Before writing code, I increasingly want to know what done means, what could create a false green, what signal we can observe while work is underway, how expensive that signal is, and what fallback exists when there is no cheap automated check.

A final acceptance test tells you whether you arrived. A feedback loop tells you whether you are still driving in the right direction.

I eventually made this explicit in my Socrates tooling. Earlier versions concentrated on end-state validation. Later versions required a Feedback Loop Design: a signal, its cost and cadence, and a fallback when no fast automated check exists.²

That change came from watching execution discover too late that it had no useful way to tell whether it was making progress.

The verification path is part of the design.

A green signal you have not tried to break is weak evidence

Tests are the obvious feedback mechanism for code. But a test harness can itself be wrong.

A selector can match the wrong element. A mock can hide a disconnected integration. A regression test can be green because it was never wired into the suite.

For a new or uncertain harness, I want to deliberately break the relevant behavior, confirm the signal turns red, restore the implementation, and confirm green.³

The point is not ritualistic TDD. It is to demonstrate that the verifier can detect the failure it claims to detect.

The same principle applies outside tests. If a browser check is supposed to catch horizontal overflow, create overflow and make sure it catches it. If a policy gate claims to prevent a class of writes, try the prohibited write in an isolated environment.

A signal is useful only if it discriminates between success and failure.

Use AI to discover the process

There is a recurring pattern in my workflow.

At first, the process exists only as conversation. I tell Claude to inspect the rendered output rather than trust the build.

The next time, I say it again. Eventually I encode the procedure in a skill. If the procedure becomes stable and mechanical enough, I stop asking AI to perform that part at all.

Progressive formalization

As uncertainty falls, move behavior from language into software.

PromptDiscover behavior
Flexible. Good for exploration.
Repeated correctionIdentify patterns
The same feedback, again and again.
SkillEncode procedure
Reusable, with judgment.
Program / hookEnforce the check
Fast, consistent, mechanical.

Figure 2. Every repeated correction is a candidate for compilation—not an instruction to automate every judgment.

I think of this as progressive formalization.

Natural language is useful while we are still learning the problem. Software becomes preferable once the behavior is understood well enough to encode.

Every repeated correction is therefore a candidate for compilation. Not every correction should become code; some expose a misunderstood goal. But if I keep reminding the model to perform the same mechanically checkable action, I should ask whether I am fixing the wrong layer.

Unix has something to say about this

There is a temptation with AI to construct increasingly capable monoliths: more tools, more context, more rules, more responsibility concentrated in the agent.

That is not how I generally like to build software.

The Unix instinct is to decompose: narrow jobs, explicit interfaces, specialized tools, inspectable behavior. My own Constitution for Claude tooling carries that forward.⁴

So I increasingly put formatters, validators, tests, browser checks, and policy enforcement outside the model’s reasoning. The model calls those tools, reads their results, and handles the parts they cannot settle.

The interesting direction is not necessarily a smarter monolith. It is carving deterministic pieces out of the agent until the model is concentrating on work that genuinely requires judgment.

Skills are for procedures. Programs are for invariants.

A skill is a good place for a procedure that still requires reasoning: investigate the codebase, challenge assumptions, inspect several sources, decide which validation strategy applies, and adapt based on what you find.⁵

But there is a boundary.

If a skill says “always run the formatter,” why should that remain a reasoning task? If it says “never write to these paths,” why should that depend on remembering prose?

The table maps each concern to the mechanism I use.

Concern	Mechanism
Durable context	Documentation
Reusable reasoning	Skill
Contextual judgment	AI or a person
Hard policy	Enforced permissions, hooks, or CI gates
Mechanical correctness	Test or program

Claude’s documentation makes a useful distinction here too: instructions such as CLAUDE.md are context, while hooks run at defined lifecycle events instead of depending on the model to remember to invoke them.⁶

A hook is not automatically a security boundary, and code is not automatically correct. The useful distinction is whether compliance still depends on remembering an instruction at the right moment.

When wording stops being the bottleneck

I learned this one empirically.

I had a rule that forked agents should not write files under certain circumstances. The rule was clear. An agent violated it.

I strengthened the instruction. It happened again. I documented the failure. It happened again, including immediately after an agent had read the history explaining that exact failure.⁷

At that point the wording was no longer the useful place to invest. The boundary belonged in the harness.

This is a systems-design lesson that predates AI. Policy and mechanism are different things. If correctness requires a model to remember an instruction at the right time, what you have is a preference, not an invariant.

The worker’s self-report is not verification

One of my newer tools makes the distinction explicit.

I have a small bug-and-feature dispatcher for a scoped set of repositories. An AI worker receives the task, investigates it, writes the change, and adds a test.

But its claim that it succeeded is not evidence for the merge decision.

A separate script inspects the worktree. It reruns the test suite, checks whether the diff includes a test file, and flags changes to sensitive paths. Independent code review remains a judgment step. The dispatcher combines that review with the mechanical results instead of trusting the worker’s completion message.⁸

The current checks are useful but not omniscient. Touching a test file does not prove meaningful coverage, and a passing suite does not prove the tests measure the right requirement.⁹

That boundary is the point: conventional software obtains observations that conventional software can obtain consistently; the model handles interpretation and judgment around them.

But don’t mechanize judgment

There is an opposite failure mode.

At one point I added a hard gate requiring an independent high-capability model to critique every plan before Claude could exit plan mode.

It also fired for small, obvious, low-risk plans where the second review added little. I removed the universal gate and made additional critique contextual instead.⁷

The lesson is not “turn everything into hooks.” Mechanize invariants. Preserve judgment for decisions that depend on context, risk, ambiguity, or competing goals.

Two loops

There are really two timescales here.

The execution loop is act → observe → correct → verify.

The learning loop is failure → reflection → lesson → skill, rule, or mechanism → future behavior.

My tooling has gradually accumulated both. Incidents become lessons. Repeated lessons become operating rules. Repeated procedures become skills. Mechanically checkable boundaries become candidates for enforcement.⁴

That is the part of AI-assisted engineering I find most interesting. A model can help discover which parts of our own reasoning should eventually stop being model work.

When I build an AI-assisted workflow now, I want to know the desired state, the observation that tells us whether we are getting closer, what could create a false green, and which parts of the procedure still require judgment.

Then I want the repeated mechanical parts to migrate outward into ordinary software.

The goal is not an AI that never makes mistakes. It is a system where mistakes become observations, observations improve the process, and repeated process eventually becomes mechanism.

Anthropic, How Claude Code works and Building effective agents. ↩︎
Add in-progress feedback-loop design to the Socrates lifecycle, September 1, 2026. ↩︎
My methodology skill, particularly Feedback Loop Design and harness verification. ↩︎
My tooling Constitution, particularly Root Cause and Technical Integrity, Unix Philosophy, and the distinction between durable principles and mechanisms. ↩︎ ↩︎
Anthropic, Extend Claude with skills. ↩︎
Anthropic, How Claude remembers your project and Automate actions with hooks. ↩︎
My operating rules, including the recorded no-write failures and removal of the universal plan-critique gate. ↩︎ ↩︎
The bug-and-feature dispatcher protocol. ↩︎
The corresponding mechanical worker script. ↩︎