Outcome Engineering
A movement (O16g / Outcome Engineering Manifesto, alongside moldable development and Wardley maps) holding that software development was never about the code, prioritizing desired business results and measurable user impact over software delivery itself.
Also known as: Outcome Engineering Manifesto, O16g, moldable development, it was never about the code
Part of: Code Was Never the Bottleneck
How authors use it
Oldest first (extraction date when no publication date is known).
| Author | Their term | Their meaning |
|---|---|---|
| The "funhouse mirror": How AI reflects the hidden truths of your software pipeline Rachel Laycock (interviewed by The New Stack) · 2026-07-07 | Outcome Engineering (O16g) | A manifesto/movement (alongside moldable development and Wardley maps) holding that development 'was never about the code' and prioritizing desired business results and measurable user impact over software delivery |
Documents (2)
- The "funhouse mirror": How AI reflects the hidden truths of your software pipeline Rachel Laycock (interviewed by The New Stack) · 2026-07-07 source ↗ Reader 🖥️
AI is not a disruptor but an amplifier of your existing pipeline, so because writing code was never the bottleneck, its coding speed turns a velocity multiplier into a debt accelerator wherever software-delivery fundamentals, guardrails, and stewardship of newcomers are not already in place. - CannotMeasureProductivity Martin Fowler · 2003-08-29 Reader 🖥️
Software productivity cannot be measured because its true output — delivered business value — cannot be measured, so every popular proxy (lines of code, function points, feature counts, project 'success' rates) either measures the wrong thing or measures it too late to be useful.
Propositions touching this concept (1)
By publication month, oldest first (extraction month when no publication date is known).
2026-07
- explicitThe future of development may shift from code-centric to outcome-centric — moldable development, Wardley-map-driven decisions, and the Outcome Engineering (O16g) movement prioritize business results and measurable user impact over software delivery itself.
Tensions
How should newly-empowered citizen developers be made safe — constrained platform, human stewardship, or supported API-first tooling?
from: What is the future of software development in the agentic/AI age?
- Looking back at the Future of Software Engineering unconference (Bartosz Ocytko): A tightly-constrained, self-healing platform — not universal upskilling — should absorb citizen developers.
- The "funhouse mirror": How AI reflects the hidden truths of your software pipeline (Rachel Laycock (interviewed by The New Stack)): Senior technologists must act as stewards — teaching the 'why' and building guardrails, not gatekeeping or replacing juniors.
- AI Is Changing Software Engineering. The Fundamentals Still Matter. (Abby Bangser): Support, don't restrict — provide API-first, MCP-accessible tooling that non-engineers can safely consume.
Assessment: All three agree citizen developers are inevitable and must not be blocked, but the safety mechanism differs — encode it in a constraining platform (Ocytko), transfer it through human relationships (Laycock), or expose it as consumable interfaces (Bangser). Ocytko's platform-first case is strongest on the specific failure mode both he and Ördög name (non-engineers leaking or bypassing production-data access), which stewardship alone cannot prevent at scale. Laycock's stewardship answers a different problem — sustaining the junior-to-senior pipeline — that a platform does not. The positions are complementary in principle but compete for the same finite investment, and none supplies a concrete governance model for vibe-coded shadow IT.
Open gaps (1)
- incompleteThe essay treats 'business value' as if it were a single, well-defined, eventually-knowable quantity, but never grapples with whose valuation counts, how value is attributed when multiple systems/teams/market factors combine, or how to handle value that is negative, deferred, or optionality-based (e.g., a platform investment whose value is future flexibility).CannotMeasureProductivity — read next: This gap becomes sharper, not smaller, twenty years on: modern outcome-vs-output debates (e.g., the corpus's John Cutler outcomes/outputs material) show that 'outcome' metrics are themselves gameable and contested, suggesting Fowler's proposed alternative to LOC/FP is not obviously more tractable than the problem it replaces.