OWNERSHIP / OPERATIONAL TRUTH

Just Ask Dana

“Why does this report exclude those accounts?”

I don't know. Ask Dana.

“What happens when an enterprise customer renews early?”

Dana knows.

“Why does Operations calculate utilization differently than Finance?”

Ask Dana. She’ll explain it.

Every company has a Dana. And Dana is usually very, very good at her job.

She is patient, razor-sharp, and remarkably reliable. In a complex organization, she feels like a competitive advantage—a living encyclopedia who keeps the gears turning when formal processes stall.

When an edge case breaks the workflow, someone asks Dana, and the problem quietly disappears.

It feels like institutional knowledge.

Look more closely, though, and sometimes it's something else entirely:

Undocumented architecture.

Dana, The Human Middleware

A Dana dependency doesn't begin as a failure. It begins as a convenience.

When a process breaks, a database evolves, or an integration doesn't account for an exception, fixing the underlying problem takes time, prioritization, and resources.

Asking Dana takes five minutes.

So the organization routes the exception to her.

At first, Dana is simply a subject matter expert. But as the organization evolves, her role can subtly change.

First, she functions as documentation. No one is completely sure what the process says, but Dana knows.

Then she becomes the semantic layer. The system says one thing, but Dana knows what the number actually means.

Next, she becomes the exception engine. The official workflow doesn't cover this situation, so Dana knows how to route it.

Eventually, she can become the decision authority. People stop trusting themselves to act without checking with her first.

At some point, Dana isn't just working within the operating system—the systems, data, processes and ownership structures that run the business.

The operating system is using Dana.

When Dana Is the Executive

The dependency becomes much harder to see when Dana is also the executive who helped build the function.

I watched a version of this happen at one organization.

A leadership question about uneven product performance triggered a request for a new diagnostic. The goal was to trace performance across the customer journey, with product as the common dimension.

The BI team built it.

The numbers were wrong.

So we corrected them.

They were still wrong.

Again and again, the executive responsible for the function identified discrepancies. Product totals weren't right. Average order values didn't match what she knew. Leads classified into certain categories weren't actually comparable.

Her frustration was understandable. She knew the numbers were wrong.

The BI team's frustration was understandable too. They were working from the available source data, validating logic with functional leaders, and repeatedly adjusting the model based on the feedback they received.

We went through at least a dozen iterations.

And we still couldn't get to a version everyone trusted.

Eventually, the disagreement became important enough that we got an hour with the executive and the BI team together.

That's when the real problem surfaced.

The CRM had accumulated years of changes. Fields had been renamed. New dimensions had been introduced while similar legacy fields remained. Some API names reflected definitions the business no longer used.

The executive knew that history.

Most of her team didn't.

She had also previously commissioned a report that she trusted to validate the major product KPIs. When we examined it, we found nearly 30 transformations encoding exception logic that wasn't apparent from the underlying systems.

The BI team wasn't missing a table.

We were missing history.

Once that knowledge was made explicit, the team could formalize the definitions, productionize the transformations, and use what we learned to clean up legacy workflows.

The reporting problem became solvable.

But the more important realization was that the executive had effectively been carrying part of the organization's semantic layer with her.

She hadn't left. The knowledge hadn't disappeared.

The organization simply couldn't reliably access it when it needed it.

Where Is Your Dana Compensating?

When operational truth breaks, it's tempting to look for a broken tool or a poorly performing team.

A Dana dependency suggests another diagnostic.

Instead of asking only where the organization is failing, ask where Dana is actively compensating for it.

Systems: Is she remembering what the software doesn't encode?

Data: Is she translating what a metric actually means before anyone can trust it?

Process: Is she correcting how the workflow functions in reality versus how it was designed on paper?

Ownership: Is she resolving questions no clear operational owner can answer?

These aren't four independent problems.

When Systems don't contain the rules, Data doesn't preserve the definitions, Processes don't capture the exceptions, and Ownership doesn't distribute authority, Decisions begin migrating toward the person who can make sense of all four.

Dana becomes indispensable not simply because she knows so much.

She becomes indispensable because the organization knows too little without her.

The Goal Isn't to Replace Dana

The solution isn't to eliminate Dana's expertise.

It's to stop spending that expertise on problems the organization already knows how to solve.

Some of what Dana knows belongs in system logic. Some belongs in governed definitions. Some belongs in documented processes or clearer ownership. And some genuinely belongs with an experienced leader exercising judgment.

The work is figuring out which is which.

Every time the organization accepts Dana's explanation without asking where that knowledge should live, the dependency deepens.

And when Dana is an executive, the pattern can become self-reinforcing:

Weak Infrastructure → Ask Dana → Dana Resolves It → Problem Disappears → Infrastructure Remains Weak → Ask Dana Again

Dana doesn't have to be territorial for this to happen. She may be working late trying to keep the organization from stalling.

But every successful intervention teaches the organization the same lesson: Asking Dana works.

That works remarkably well—until access to Dana becomes the bottleneck.

We usually think about this as key-person risk: What happens if Dana leaves?

But Dana doesn't have to leave.

Sometimes she just has to become too busy for the organization that depends on her.

If your Dana left tomorrow, what would break first?

The answer may tell you which part of the business she's already holding together today.

Best,