Outcome Development
Outcome Engineering depends on engineers who have leaned into agentic development. It works. It also puts pressure on everything around those engineers: testing and tooling built for human-scale velocity, the line between demo and production, and the norms a team develops for working together.
The best way to relieve that pressure — to build paths enabling the entire team to better deliver outcomes for the customer — is to move outcome thinking beyond engineering. Welcome to Outcome Development.
If Outcome Engineering — o16g — is about writing code with agentic support, Outcome Development is about the development methodology, the processes, and systems for agentic development. It starts with recognizing the dramatic difference in the cost of product development and opening the aperture, because once it’s not about typing, everyone can rethink how they’re executing and delivering outcomes.
It’s a natural outcome of embracing outcome engineering and unlocks the next level of capabilities. Yes, agents can remove the constraints of human bandwidth, but until that capacity is focused through risk and quality gates, until code review, testing, and o11y are as advanced as prototyping, we’re only capturing partial wins.
Outcome Development — like Outcome Engineering — is about building systems, processes, and tools to move as fast as you can identify the need. No worrying about backlogs, no waiting on resources.
We’re not there. But we can see the playbook. Where Outcome Engineering has 16 principles, Outcome Development is simpler.
The five principles
Speed of learning in production is the gate. Features, rewrites, experiments are all orders of magnitude cheaper than a year ago, so the actual limit on product improvement is how quickly you can learn in production. Anything that limits that — coordination costs, misaligned goals, flaky tests, product infra decisions that confuse agents, weaksauce o11y, poor capture of user feedback — limits your ultimate development speed.
Minimize global coordination needs. Even agentic development speed can’t overcome the O(n^2) cost of coordination, but the best way to optimize something is to not do it. Almost any investment in alignment, goal setting, product architecture, team communication, and customer understanding that reduces the need for global coordination is worth doing.
Code is worth $0. This is not a statement about developers or personal value. It’s a reminder that there are no technical moats anymore. No reason to be scared of a rewrite. No reason not to explore different language options. No reason to treat any subsystem or feature as sacred because of the code.
Try to have an agent do it. If it’s an inefficient task or one that is still scaling with people, at least try to have an agent do it. And keep trying, because the agents are getting better and better. Consider code review. It’s expensive and challenging to do a truly great agentic code review, one that not only reviews the code, but also considers long-term company and technology goals, and shares knowledge with team members. But what gets unlocked once you do it?
Everyone learns by building. Outcome Development organizations welcome everyone to explore, communicate, and learn by creation. Why debate two ideas when you can build and deploy both? Why not show a prototype to a customer in the field? Why not ask an agent to help remove some impediment or inefficiency that’s only obvious in your corner of the company? Outcome Development welcomes this because whoever started the work on an idea, the team needs a way to deliver it safely to production and learn. Inevitably, this means outcome roles move beyond outcome engineers. Why not add Outcome Designers, Outcome Managers, Outcome Reliability?
This started as the July update on cory.news, six months after the o16g Manifesto. The next update comes at the end of the year. If you want to join us on this journey, we’re hiring.