Proximity to value isn’t the same as fluency in value. RIVER tries to give organizations both.

I’ve been thinking about the flow of value through software organizations for a long time. The thinking comes out of my particular career arc, and RIVER (Realized Impact and Value Evolution Reporting), the framework I’m now building with Dr. Linnéa Parsons Willis, is the result.

I started my career in IT operations. Operations is a cost center. The work matters, the work is constant, but the work sits at a distance from the parts of the business that leadership recognizes as generating value. That distance creates a chronic communication problem. The team is under pressure to justify the organization’s investment in them, but lacks the vocabulary to do it cleanly.

After a few years, I moved to Red Hat as part of Professional Services. Anyone working for a vendor in a customer-facing role sells to some extent. Selling to and working with IT organizations meant addressing that same cost-center pressure from the outside, ideally with an executive’s ear. The buyers I worked with were trying to justify infrastructure investment to leaders who wanted to hear about impact on revenue, and the lack of a shared lexicon was real.

At LaunchDarkly, the variables changed somewhat. I started selling a vision to developers, and developers sit right next to the business unit. Sometimes they’re inside it. The work they do is directly entangled with the work that generates value. I assumed the communication problem would dissolve in that proximity.

It does not. Proximity to value-generation only buys you proximity for the work that directly maps to it. The feature that ships, the experiment that runs, the rollout that touches customers, those things travel cleanly back to the organization’s stated objectives. Everything else does not.

The cleanest example is technical debt. A developer who knows that a deferred refactor is increasing on-call load, slowing future delivery, and raising incident risk often cannot make that case in language the business will fund. Not because the work doesn’t matter; because the link between the work and the value it preserves is implicit. It lives in the engineer’s head. It does not survive the trip up.

I want to be careful about where this failure sits. It is not a failure of the engineer who can’t translate the work. It is not a failure of the manager trying to advocate for it. It is a failure at the top. If a CEO or a CTO cannot account for why deferred reliability work increases risk, lengthens incident recovery, and depresses delivery throughput, then the organization is not actually running on a value model. It is running on the parts of the value model that are easy to see.

The same shape of failure shows up at every level. Anyone with management responsibility, from a tech lead up to the C-suite, is responsible for being able to describe how the work of their people connects to the company’s stated objectives. When that description doesn’t exist, the people doing the work are misrepresented and the organization can’t actually evaluate them. Both sides lose.

So, what’s the answer?

That’s where RIVER starts. The framework’s premise is that the unit of value-tracking should not be the feature, the project, or the deploy. It should be a small, declared artifact created before a release begins: the release intent. The intent names what the team thinks shipping this thing will change, which metric will show that change, on what time horizon, for which audience. It is stated as a hypothesis, not a guarantee. It can fail.

That last part matters more than it sounds. If a release is treated as a guarantee, the organization cannot afford to be wrong, and so it commits more than it should before it learns anything. If a release is treated as a hypothesis with a defined success signal and a defined horizon, the organization can run experiments at the scale of an actual experiment. It can let some of them fail. It can learn.

When it works, RIVER gives the whole organization a shared structure for declaring intent. The C-suite can describe what it expects to be true. The director can describe how a roadmap maps to it. The senior engineer can describe what the platform investment is buying. The operations engineer can describe why the rebuild of an aging system will reduce mean-time-to-resolution and raise reliability over the next quarter, and that description has the same shape as everything else in the org. That symmetry is the point.

RIVER is not a dashboard. It is a way of writing things down before you do them, in a structure that lets the work be evaluated honestly afterward. It draws on the discipline that DORA (the DevOps Research and Assessment program) brought to delivery measurement, and it extends past the deploy boundary, into the part of the value chain where releases meet customers and the business actually changes.

There is much more to say, and the RIVER framework site says it. This post is the personal version of the same argument, in the language it started in. If the problem above is one you recognize in your own organization, the framework site is the place to go next.