Operational Learning: Ownership as Architecture

Look at the org chart and everything’s fine.

Someone owns the forecasting process. A name sits in the R column of the RACI that someone built eighteen months ago. There was a handoff. There was probably even an email. If you asked who’s responsible, three people could point at the same slide and give you an answer.

But the ownership has quietly stopped being exercised.

The metric still gets reported every week, but nobody’s interrogating what it means. The review still happens, but it’s become a readout, not a decision point. The standard still exists on paper, but local variations have crept in across teams, and nobody can explain when or why. Nothing dramatic happened. Nobody dropped the ball in a way that made noise. The ownership just slowly hollowed out, the way a support beam can look solid from the outside while the load shifts somewhere else. The org chart still says everything’s fine. The work tells a different story.

This is the version of ownership failure that most organizations are living inside right now. Not the dramatic kind, where nobody can agree and decisions stall in a conference room. The quiet kind. The kind where ownership technically exists, on paper, in a system, in someone’s job description. And it has stopped meaning anything operational.

I’ve been walking into that room for twelve years.

Throughout my career in information technology, I’ve been the person who inherits the thing nobody else wants to take on. The system too messy to touch. The process too critical to let fail but too tangled to manage cleanly. The platform that everybody depends on and nobody wants to own.

I’ve learned to call it being “lucky,” and there’s real pride in it, but there’s also a pattern that repeats every single time. The first thing I discover is that the ownership I’m inheriting isn’t what it looked like from the outside. Someone technically owned it. But behind the title? No documentation. No triggers. No decision rights. No real understanding of how the thing actually lives in the organization. Just a name on a chart and a gap where the structure should be.

That gap is what this piece is about. Ownership that’s assigned is not the same as ownership that’s designed. And if your learning systems, your operational rhythms, your most critical processes depend on ownership that was never designed to hold weight, they will eventually fail. Not with a bang. With a gradual hollowing that you won’t see until someone new inherits the role and asks a simple question: what exactly am I holding here?

Assigning ownership is easy. Designing ownership that survives a reorg, a leadership change, or a quarter where nobody’s watching is the actual work.

Most organizations assign ownership and believe they’ve solved the problem. A name goes on a chart. A line appears in a RACI. A verbal commitment gets made in a meeting. And the organization moves on, trusting that the assignment is sufficient.

I’ve built RACIs. I’ve built them with care, with the right stakeholders in the room, with clear distinctions between responsible, accountable, consulted, and informed. And I’ve watched leadership never enforce them. Within a quarter, they described relationships and authority lines that nobody followed. Everyone knew it. The document still existed. It just didn’t have teeth.

This is where it breaks.

The RACI isn’t wrong. It’s a useful starting framework for clarifying roles. But it describes responsibility without designing reinforcement. It names an owner without defining what that owner can decide independently, what triggers should force them to act, who checks that they’re still exercising ownership, or what happens when they leave the role. The distance between “we have a RACI” and “we have designed ownership” is where most organizational dysfunction grows unchecked. Not because people are careless. Because the tool that’s supposed to define ownership doesn’t actually design it.

And the consequences show up in patterns that get mislabeled.

Consider the decision that keeps coming back. A customer-facing commitment where sales, operations, and leadership all have a voice. Each function has legitimate perspective. Each has a stake. And nobody has the authority to close the decision when they disagree. So it comes back to the table. Week after week. Each time wearing a slightly different label. “We need better alignment.” “There’s a communication gap.” “Let’s schedule one more meeting to get everyone on the same page.” The room is polite. The frustration is patient. And the real issue never gets named, because naming it would require asking a question nobody wants to answer: who actually gets to decide this?

That re-litigation cycle looks like an alignment problem. It feels like a communication problem. But trace it back and you find an ownership design problem. Three people with shared accountability, no tiebreaker, no escalation path, and no defined decision rights. The decision can’t close because the system has no mechanism to close it. Add a RACI and you’ll clarify who’s responsible. You still won’t have defined who can act when there’s disagreement.

Both versions trace back to the same root: ownership that was assigned, not designed.

What I’ve learned from being the person who always inherits the thing nobody wants is that ownership, real ownership, requires a discipline most organizations skip.

My approach has been the same every time, refined through repetition. First, I resist the urge to change anything. That impulse, the one that says “let me fix this immediately,” is almost always wrong in the first weeks. Instead, I wrap my arms around the technology or process. I spend real time understanding how it’s actually being leveraged and utilized in the organization. Not how the documentation says it should work. How it actually lives. Who depends on it. Where the unofficial workarounds are. What the real operating rhythm looks like versus the one on the process map.

Then I look for the gaps. Not changes for the sake of change. Genuine operational needs. Places where the process has drifted from what it was designed to do, or where the design never accounted for how the organization actually operates. That distinction matters. Changing things to put your stamp on them is ego. Changing things because the gap between design and reality is creating risk, confusion, or rework is operational discipline.

And then I document everything. Everything I know, everything I’ve done, every decision I’ve made and why. Because the person who comes after me shouldn’t have to start from zero. They shouldn’t have to rediscover the workarounds, re-map the dependencies, rebuild the context that I spent months developing. The documentation isn’t a formality. It’s the difference between handing someone a title and handing them actual ownership.

That methodology, earn understanding before you change anything, change only what the operation genuinely needs, and document so the next person inherits something real, is what I think about when I think about designed ownership. It isn’t a framework you fill out once. It’s a discipline you build into how roles carry weight.

This is also where the stakes become clear for everything else we care about in operational learning. Organizations don’t forget because they’re careless. They forget because learning isn’t portable. And one of the biggest reasons learning isn’t portable is that it’s trapped inside ownership that depends on a specific person’s knowledge, relationships, and institutional memory. When that person moves on, the ownership transfers. The learning doesn’t.

If we’re serious about building systems that keep lessons alive under pressure, ownership has to be designed to carry those lessons forward, not just assigned to whoever is standing closest when the music stops.

The same logic applies to cadence. An operating rhythm only functions as a control system if someone within that rhythm is accountable for what it reveals. Without designed ownership, cadence is just meetings.

So what separates ownership that holds from ownership that hollows out?

Start with what was missing in the tiebreaker scene: decision rights. The owner has to be able to act without convening a committee. They need to know what’s within their authority to close, what requires escalation, and where the boundary sits. There’s a reason Rogers and Blenko’s work on decision roles resonated so widely when it was published: organizations with clearly defined decision rights outperformed those without, not because they had better people, but because their people could actually move. Without clear decision rights, ownership is advisory. Advisory ownership generates recommendations. It doesn’t generate outcomes.

But decision rights alone aren’t enough if nobody checks whether they’re being exercised. That’s what the opening scene revealed: ownership that looked fine on the chart but had stopped meaning anything in practice. The missing element was reinforcement through cadence. Ownership has to show up in the operating rhythm. When a metric is reviewed in a weekly cycle, the owner isn’t just presenting. They’re accountable for what the metric says and what they’re doing about it. If ownership isn’t visible in cadence, it becomes something that happens when someone remembers, which means it eventually stops happening at all.

Then there’s the question that keeps surfacing every time I inherit something new: what actually transfers when the owner changes? DeLong called it “lost knowledge,” and the phrase is more precise than it sounds. The risk isn’t just losing a person. It’s losing the context, the decision history, the understanding of how the thing actually lives. Succession without substance is how ownership becomes hollow. And it’s where most organizations cut corners, because documenting for succession feels like overhead until the day it’s the only thing standing between continuity and chaos.

What ties all of this together is decay detection. A way to know that ownership is still being exercised before the consequences of its absence arrive. Are the reviews still generating decisions, or have they become readouts? Are exception patterns shifting in ways that suggest the owner has stopped watching? Is the standard still being reinforced, or has drift settled in without anyone noticing? Decay detection is the leading indicator. Without it, you discover ownership failure the same way you discover a cracked foundation: after the damage is visible to everyone.

These qualities cost more to build upfront. Designed ownership is slower to stand up than assigned ownership. It requires conversations that feel like overhead when things are going well. The trade-off is that designed ownership survives. It survives a reorg. It survives a leadership change. It survives a quarter where attention shifts somewhere else. Assigned ownership is faster to set up. It’s also faster to collapse. And when it collapses, it usually takes institutional learning with it.

The test is simple, and you can run it Monday.

Pick one outcome that matters to your organization right now. Not the easy one. The one where you already sense the ownership might be thinner than it looks. Then ask four questions.

Who can close a decision about this without escalating? If the answer is unclear, or if the answer is “everyone needs to agree,” you have distributed responsibility without decision rights.

Where does ownership of this outcome show up in your operating cadence? If it’s not in a regular review cycle with real accountability, it’s optional. Optional ownership decays.

If the current owner left tomorrow, what would actually transfer with them? If the answer is “their knowledge,” you don’t have succession logic. You have a single point of failure wearing a job title.

And how would you know if this ownership has already started to hollow out? If there’s no mechanism to detect decay, you won’t find out until something breaks.

Four questions. One outcome. The gaps will tell you whether you have ownership that’s designed to hold weight, or ownership that’s assigned and waiting to hollow out. And once you see the gaps, the design work starts: defining the rights, building the reinforcement into cadence, documenting for succession, and putting a mechanism in place to catch decay before it becomes crisis.

Which outcome matters most in your organization right now, but has no single role accountable for reinforcement and no mechanism to detect when reinforcement stops?

Sources

DeLong, D. W. (2004). Lost knowledge: Confronting the threat of an aging workforce. Oxford University Press.

Katzenbach, J. R., & Smith, D. K. (2003). The wisdom of teams: Creating the high-performance organization. Harvard Business Review Press.

Miles, S. A., & Watkins, M. D. (2007). The leadership team: Complementary strengths or conflicting agendas? Harvard Business Review, 85(4), 90–98.

Neilson, G. L., Martin, K. L., & Powers, E. (2008). The secrets to successful strategy execution. Harvard Business Review, 86(6), 60–70.

Rogers, P., & Blenko, M. (2006). Who has the D? How clear decision roles enhance organizational performance. Harvard Business Review, 84(1), 52–61.

Simons, R. (2005). Levers of organization design: How managers use accountability systems for greater performance and commitment. Harvard Business School Press.

Weill, P., & Ross, J. W. (2004). IT governance: How top performers manage IT decision rights for superior results. Harvard Business School Press.