Most Teams Have Two Operating Systems

Your org chart is a work of fiction.

The real workflow lives in Slack DMs, hallway conversations, and whatever spreadsheet Dave in ops has been quietly maintaining since 2019.

Most teams are running two parallel operating systems at the same time. There is the official one, the one that lives in Confluence, gets referenced in onboarding docs, and gets presented to executives in quarterly reviews.

Then there is the real one.

The one that your most experienced people actually use. The one that never got written down because the person who built it was too busy keeping the whole thing from falling apart to document it.

Both systems are running simultaneously. Most leaders only know about one of them.

Why Shadow Workflows Exist in the First Place

Here is what nobody wants to say out loud: shadow workflows do not form because your team is lazy or resistant to process. They formed because the official process failed people, and nobody fixed it.

Someone hits a wall. The documented process says to submit a request through the ticketing system, wait for approval, and receive a response within 3 to 5 business days. But the deadline is tomorrow. So they walk over to the person they need, have a five-minute conversation, and the thing gets done.

It works.

They remember that.

Next time, they skip the ticket entirely.

Then they mention it to a teammate over lunch.

"Hey, just go directly to Marcus; the ticket system is basically decorative."

The teammate tries it. It works for them too. Word spreads. Now half your team is operating under an undocumented protocol that nobody sanctioned and that everyone depends on.

People are not routing around your official process because they enjoy chaos. They are doing it because the official process has friction that nobody in a position to fix it ever bothered to address.

The shadow workflow is a symptom. The broken official process is the disease.

And in many organizations, leadership unintentionally creates the very conditions that force these systems to emerge. Every incident adds another approval step. Every escalation adds another checkpoint. Every metric is optimized for reporting rather than flow. Eventually, the official process becomes so heavy that the only way work gets done is by quietly bypassing it.

Most shadow workflows are not rebellion.

They are organizational scar tissue.

What It Actually Costs You

Shadow workflows are expensive because they create invisible dependencies that leadership does not even know exist.

The gap between documented process and real process is not just an organizational quirk. It is a hidden operational risk.

New people struggle for months longer than they should. They follow the official process because that is all they have access to. They wonder why everything takes so long, why they keep hitting dead ends, why their more experienced colleagues seem to operate in a completely different reality.

The answer is that their colleagues do operate in a different reality.

Nobody told the new hire about it because it was never written down, and the people who know it are too busy using it to explain it.

Then Marcus leaves.

Or Dave in ops finally gets that job he wanted.

And suddenly, the entire informal system that half your team was depending on evaporates. The spreadsheet Dave maintained since 2019 is gone. The relationships Marcus had that made the five-minute conversation possible are gone.

What you are left with is the official process. The same process that was broken enough for people to stop using it in the first place.

You have a single point of failure that never showed up on any risk register because nobody officially acknowledged it existed.

There is also the quieter cost.

The resentment that builds in people who know how things actually work but cannot say so in official settings.

They sit in process review meetings, watching leadership discuss a workflow that bears no resemblance to reality. They know the documented version is wrong. Raising it feels risky, pointless, or both. So they say nothing. They go back to their desks and keep running the real system in the background while nodding along to the fiction.

Chronic, low-grade frustration is one of the more underrated contributors to burnout.

It is exhausting to live in the gap between what is officially true and what is actually true.

You Will Not Find the Real Workflow in Confluence

If you are a manager or a tech lead and you want to understand how work actually moves through your team, stop reading the documentation alone. It will not tell you what you actually need to know.

The real workflow reveals itself in low-stakes conversations.

Lunch.

A casual Slack thread.

The kind of chat that happens when someone is not worried about being evaluated.

That is where people tell you what they actually do, not what they are supposed to do.

It is also where you hear the small complaints that are actually large signals:

"Oh, I never use that system, I just ask Priya directly."

"That process technically requires three approvals, but nobody has actually done all three in like two years."

Those offhand comments are gold.

They are telling you exactly where your official process broke down and what your team built in its place.

Watching how work moves is even more revealing than asking about it.

Pay attention to who messages whom before a decision actually gets made. Notice which meetings people prep for versus which ones they show up to cold. Watch where the real debates happen, because they are usually not in the meeting itself.

You will learn more about your team's actual workflow in a week of observation than from six months of reading documentation.

What To Do With What You Find

First, do not overreact.

When you discover a shadow workflow, the instinct is usually to either shut it down or immediately formalize it into an official process. Both responses tend to make things worse.

Shutting it down tells your team that finding a way to make things work is punishable. You are penalizing the people who kept your system functioning despite its flaws.

That is a fast way to kill initiative.

Immediately formalizing it carries its own risks. Shadow workflows work partly because they are informal and flexible. The moment you put them in Confluence with a required approval chain, you have recreated the conditions that led people to circumvent the official process in the first place.

What actually helps is surfacing it, naming it, and figuring out what problem it was solving.

If your team invented an informal process to get around a broken official one, the question worth asking is why the official process broke.

Fix the root cause, not the workaround.

That means talking to the people who actually run the shadow workflow and treating what they built as useful information instead of a compliance violation.

"Hey, I noticed most of the team goes directly to Priya instead of filing a ticket. Walk me through how that started."

One conversation like that will tell you more than any process audit ever will.

You also need to make it safe to surface these things.

If people believe that telling you about the gap between documented and real process will result in punishment, defensiveness, or another meeting where leadership pretends to be surprised and then changes nothing, they will stop telling you.

You do not need a formal reporting structure for this.

You just need to be the kind of leader who responds with curiosity instead of ego.

The Real Problem Is Not The Shadow Workflow

Most shadow workflows are a sign that someone did the hard work of solving a problem your organization was not solving.

The problem is not that they built it.

The problem is that it lives somewhere no one can see, which means it cannot be improved, cannot be handed off, and falls apart the moment the person carrying it in their head walks out the door.

Your job is not to eliminate shadow workflows.

Your job is to understand them well enough to decide which should be deprecated, which should be officially absorbed into how your team operates, and which point to a broken system that actually needs fixing.

The third one matters most. It is usually the most important one.

If a large part of your team has built a workaround for the same broken process, you do not have a discipline problem.

You have a systems problem with a very loud signal attached to it.

The org chart is the map.

The shadow workflow is the territory.

If this resonated, I write about leadership, tech culture, and the stuff nobody puts in the job description. No newsletters full of fluff. Just the actual thing, when I have something worth saying.