STS The working library
Field Notes.
Practical frameworks for people building consequential systems.
25 published notesDecision Altitude: Why Good Technology Ends Up in the Wrong Layer
Three tests for deciding when a local solution should remain with a product team—and when it should become a shared platform capability.
When Coordination Becomes the Work
A practical diagnostic for recognizing when repeated coordination means a capability is owned below the level of its consequences.
Who Owns the System When the Model Is Wrong?
A diagnostic for finding the ownership gap between model operation and responsibility for the customer outcome.
AI-Enabled Can Be the Right End State
Primary-source evidence for keeping model dependency bounded when deeper integration does not justify the added maintenance, governance, and exit obligations.
Five Questions Before Calling a System AI-Native
A decision review for testing model dependency, system redesign, learning loops, evaluation ownership, and fallback before adopting an AI-native label.
A Platform Should Sell a Capability, Not Its Machinery
A diagnostic for finding where an internal platform transfers its implementation complexity, support burden, and migration cost to product teams.
A Capability Contract Makes the Platform Testable
A four-test review for turning an internal platform promise into observable behavior, explicit ownership, and a controlled change policy.
The Migration Test for an Internal Platform
A review for separating necessary contract change from consumer work caused by platform machinery leaking through the boundary.
Self-Service Without Product Ownership Creates an Orphan
A source-backed ownership review for determining whether an internal platform is a product or an unattended interface.
Review the Contract Before Adding Another Platform Feature
A source-backed roadmap review for separating consumer friction caused by a weak platform contract from a genuine need for another shared technical component.
Available Is Only the First State
A five-state diagnostic for finding where an internal data capability stops turning platform access into useful, repeated work.
Treat Data Enablement as a Product Funnel
A cohort-based review for turning data-platform adoption evidence into one bounded product decision.
Measure the Transition That Is Actually Breaking
Why aggregate platform adoption counts can send roadmap capacity toward the wrong problem.
More Documentation Does Not Repair Every Adoption Failure
DORA evidence shows that documentation matters, but the failing user transition should determine whether documentation is the right remedy.
A Platform Roadmap Needs an Adoption Hypothesis
A seven-part hypothesis that connects platform roadmap work to one user transition, one mechanism, and a decision rule.
Decision Effort Should Follow Reversal Cost
A practical way to match architecture review, rollout, and ownership to reversal cost and blast radius.
Reversibility and Blast Radius Belong in the Same Review
A two-axis architecture review for choosing the right commitment, rollout, and exit path.
An Exit Path Is an Architectural Requirement
Public engineering evidence shows why a credible migration claim needs compatibility states, rollout signals, ownership, completion evidence, and a visible cost of leaving.
Do Not Slow Every Decision
Evidence from DORA and Google SRE supports a selective review system that protects flow for contained changes and concentrates scrutiny on durable or broad commitments.
Five Questions for High-Blast-Radius Choices
A five-question pre-mortem for exposing reversal cost, inherited consequences, detection limits, ownership, and smaller commitment options before a broad technical decision is approved.
Every Architecture Contains an Incentive System
How architecture boundaries change incentives, transfer work, and create ownership obligations across teams.
Five Economic Lenses for Engineering Decisions
A practical review of flow, option value, coordination cost, displaced work, and delay in engineering decisions.
Local Efficiency Can Reduce System Flow
How shared constraints turn local activity into waiting, and how to choose a bounded improvement to delivery flow.
Cost Reduction Is Not the Only Economic Question
Compare complete operating arrangements, including consumer work, useful options, and the consequence of delay.
Put the Economic Consequence Next to the Technical Choice
Preserve economic assumptions, transferred work, owners, and review triggers beside an architecture decision.
+ Continue the system
Two useful systems syntheses each week.
Tuesday develops a costly operating problem. Friday turns the week's evidence, boundary, and practical conclusion into one synthesis.