In the last six months, I've generated over $2M of software development labor solving problems I and others in the organization had. Things that had been on my "TODO" for literally years, unapproachable because the cost of not addressing them had not yet exceeded the cost of addressing them. Every effort aligned to generating direct value to a problem owner.
This summer, we took the same methodology and applied it to two of our intern teams. Give them a problem. Align with the customer. Use modern tooling to get to results as quickly as possible. A month later, starting from zero, they're deploying to production, creating a flywheel that will immediately generate value for the problem owners and the organization.
When it works, it's obvious. So why is it so hard?
The Hidden Risk
The purpose of software is to provide value to another person through the solution of a problem. Every modern engineering methodology orbits this thesis. And yet, organizations routinely construct systems that actively work against it.
The risk they don't see is the risk of not changing. Every day software doesn't reach the hands of someone facing the problem, the organization accrues debt: misaligned assumptions compound, user needs drift, competitors learn faster. But this risk is invisible because the status quo is what people expect. A bad process gets a shrug. An ineffective program gets a "Pobody's Nerfect!" response. The comparison isn't to a better solution; it's to nothing at all.
The risk of change, on the other hand, is vivid. Decades of data point to how hard it is. Failed implementations. Millions poured into solutions that never saw daylight. Entire careers built on cautionary tales. So the organization aligns around managing the visible risk and ignoring the invisible one.
This creates a clean dividing line. On one side: organizations that understand speed to user as a survival metric. On the other: organizations accruing hidden risk daily, unable to see what's compounding because they've optimized for a different threat entirely.
The Structural Trap
Why does this happen? Especially in large organizations and highly regulated industries, bad organizational design has created siloed power structures under the guise of efficiency and domain knowledge. Engineering is its own group. Security its own group. Finance its own group. Procurement its own group.
Each silo optimizes for its own risk surface. Security optimizes for zero vulnerabilities. Finance optimizes for budget predictability. Procurement optimizes for compliance. None of them optimize for the thing that justifies their existence: value delivered to the person facing the problem.
The organization, through its structural design, is disincentivized to solve the actual problem because the visible risk — the risk of change — is the only acknowledged risk. Every silo has veto power over delivery. None have accountability for delay. The result is an organization that moves slowly by design and calls it governance.
This isn't theoretical. It's been proven in every failed modernization effort, every multi-year program that delivered shelfware, every transformation that transformed nothing except the org chart.
The Practitioners Already Solved This
Smart leaders and technologists have been at this problem for decades. The solutions exist. They've always existed.
The Agile Manifesto's specific call for "working software" wasn't a call to prototype quickly. It was a statement that software without input from the problem owner is irrelevant. The emphasis on customer collaboration over contract negotiation was a direct challenge to the silo model.
DevOps positioned technical development and operations together to remove barriers and speed delivery. The insight was simple: separating the people who build from the people who run creates a handoff that delays feedback.
Continuous Integration and Continuous Deployment created patterns to automate code merge and build processes, recognizing that risk lives in the delay between building software and receiving feedback. Continuous Delivery enshrined the idea that pushing software to production safely, with quality control baked in, was not only possible but preferable.
An entire commercial industry supporting a significant portion of U.S. GDP depends on these engineering approaches. Because in competitive markets, the risk of not changing is massive and immediately visible. Revenue disappears. Users leave. The hidden risk becomes very un-hidden, very fast.
Bryan Finster talks about this in his writing on "The Three Wrongs," challenging the assumptions organizations make about what constitutes safe delivery. Bryon Kroger's Rise8 quip captures it perfectly: "Prod or it didn't happen." Value Stream Mapping and Lean methodologies take the same principles that made Toyota the global manufacturing powerhouse it is and bring them into an operational context for any industry. Gene Kim and Steve Spear documented this in Wiring the Winning Organization, showing how even government organizations can adopt these principles when leadership commits to the structural changes required.
The pattern is consistent across all of these: get to the problem owner faster. Everything else is subordinate.
What You Actually Do
No matter what your organization looks like, there are concrete moves available.
Define the only metric that matters. Software in the hands of people facing the problem. Not stories completed. Not velocity. Not lines of code. Not compliance checkboxes. The metric is: did the person with the problem get something that helps them today?
Get software to the users. Why is your development environment inaccessible? Does it matter? Why do you have multiple staging environments? Why are you keeping software away from your users? Maybe it isn't ready to replace what they use today. That doesn't mean you should hide it. The first lesson of modern software delivery is to solve the problem. The only way you do that is through having a problem owner use it. Every gate between your code and their hands is a gate that delays learning.
Break down silos, or route around them. Create high-trust value streams across the organization for all the components involved in delivering value. If you can't dissolve the boundaries, create corridors through them. Cross-functional teams with delivery authority, not cross-functional committees with advisory roles.
Get uncomfortably close to the problem owners. Embed in the mission. Understand it inside and out. Work with others to communicate it actively. The best solutions come from people who work the problem every day but have the space to step back and think differently.
Subordinate pride of ownership to the metric. Affiliation, success, even failure — all secondary. The only thing worth embarrassment is how long it takes to get feedback from problem owners. The team wins together or fails together, and the determining factor is whether the solution solves for the problem.
The Hard Part
None of these are easy. All require a high-trust, high-performing organization staffed with people committed to the mission. They require buy-in at every level.
Because of that, start at the operational level. Find small problems to solve quickly. Demonstrate the feedback loop working. Build evidence that speed to user doesn't mean recklessness; it means learning faster than the risk can compound.
And understand that a failure doesn't mean the approach failed. It means there's learning to be done. Try again. The organizations that internalize this — that treat every deployment as a hypothesis and every user interaction as data — are the ones that stop accruing hidden risk and start compounding value instead.
Prod is the only test that matters. Everything else is rehearsal.