The Unofficial Rules
Every organization runs two operating systems. The gap between them is where the waste hides.
I sat through a planning session last week where a team spent forty minutes examining an Epic through a checklist of the Definition of Ready. The template didn’t change what they built. It didn’t surface a risk or clarify an assumption. It didn’t even clearly articulate the user problem they were solving for. It existed because the process requires that Epics be evaluated against DoRs to proceed, and everyone in the room knew that. They filled it out anyway. Then they went back to working the way they were going to work, regardless.
This happens everywhere, and I think we’ve stopped noticing it.
The Unofficial Game
I’ve been mapping how teams work across a large organization, comparing the documented process to what teams do in practice. The patterns are consistent. Every team has two sets of rules: the ones on paper and the ones they follow. Some modify the official process just enough to check the box. Others follow it to the letter. Most fall somewhere in between, bending things to fit their product, their customer, their technology.
We create elaborate processes and then modify them the moment they meet reality. We expect all teams, regardless of their customer, technology, or application context, to follow the same playbook. And when they don’t, we call it a compliance problem instead of a design problem.
Here’s the question that keeps coming up: if we are going to play by the unofficial rules anyway, why maintain the facade of official rules that we pretend to follow?
Where the Waste Lives
Think about how much energy goes into maintaining the gap between the system we document and the system we run.
Status reports are a good example. Teams assemble them weekly, formatting updates into a template that rolls up to a review no leader has time to read in full. The reports don’t change what gets built. They don’t surface risks or shift priorities. They don’t even get questioned. They exist so that someone, somewhere, can say visibility exists. The teams writing them know this. They write them anyway, because the process requires it. And then they go have the real conversation in meetings or a hallway.
Or look at how we handle operational metrics. Say/do ratios, feature completion rates, velocity, all of these get adjusted so the numbers look right at review time. Teams commit to less so the ratio stays high. Features get marked “done” before the outcome is measured. The metric becomes the goal instead of the proxy, and nobody asks whether the thing we shipped made any difference to the customer.
If the waste was justified because we solved customer problems, I could make peace with it. But most of this waste is bureaucracy, not outcome. It would be unacceptable in a market-driven culture, and yet we accept it because it’s how we’ve always operated.
People are working hard. People are often not the issue. The issue is how much of that effort goes into maintaining the gap between the official game and the unofficial one instead of into work that matters.
Why One Process Doesn’t Rule Them All
The instinct behind the standardized process makes sense. At scale, we need some shared way of working. We need to coordinate across teams, maintain dependencies, report progress, and allocate resources. Nobody was fired for wanting consistency.
But consistency of process and consistency of outcomes are different things. When we mandate the same ceremonies, the same templates, the same cadence for every team regardless of context, we’re optimizing for the ability to look across teams and see the same shape. Not for whether those teams are producing good outcomes.
A team building a billing infrastructure in a regulated environment works differently from a team iterating on a consumer app. A team managing a mature platform has different rhythms than a team exploring a new capability. Treating them the same doesn’t create alignment. It creates the appearance of alignment while each team quietly runs its own version underneath.
Consider The Alternative
It’s tempting to swing the other way and say let every team do whatever they want. That’s not the answer either. No shared structure at scale is chaos.
The way I think about it: instead of elaborate processes that no one fully follows, what if we designed a small number of rules that work across diverse teams? Rules that shape behavior without pretending every team is the same.
In my last post, I wrote about enabling constraints, the idea that a spine creates coherence without containing. A few consistent rules that channel behavior toward outcomes instead of compliance.
So what does that look like in practice?
Take a common one: “Every team runs two-week sprints and demos at the end of the sprint.” That standardizes activity. It tells teams when to work and when to present, regardless of whether that cadence fits their problem space. Now replace it with: “Every team can articulate who their customer is and what problem they’re solving this quarter.” That standardizes intent. A billing infrastructure team and a consumer app team would answer that question very differently, and they should. But both teams are forced to be clear about who they serve and why. The constraint doesn’t prescribe how they work. It makes sure the thinking happens.
Or this one: instead of “fill out the feature template before starting work,” try “demo what you learned before you demo the completed feature.” That single shift changes what teams optimize for. When leadership consistently asks “what did you learn?” instead of “what did you ship?”, teams start optimizing to answer those questions. They may run smaller experiments, talk to customers sooner, and bring real evidence to reviews instead of polished demos of features nobody validated. The constraint reshapes the incentive without adding a single new process.
These leave room for teams to figure out how to get there.
How We Got Here
The deeper issue is that most of our processes weren’t designed. They accumulated. Someone needed a template, so one got created. A review cadence made sense three years ago, so it became permanent. A governance step was added after something went wrong, and it never got removed after the risk passed.
Nobody sat down and asked: what are the fewest rules we need that still produce the outcomes we want? Instead, we kept adding. And now we have a system that nobody designed intentionally, that everybody modifies in practice, and that we spend collective energy maintaining the appearance of following.
That’s the real waste. Not that people bend the rules. That we built rules worth bending instead of rules worth keeping.
I’ve been gravitating toward enabling constraints because they offer something different: an intentionally designed set of rules that can apply to diverse teams and raise their capability without pretending they’re all the same.
We already have constraints. And the energy we spend maintaining the gap between official and unofficial could go somewhere more useful, like solving customer problems.
What’s one unofficial rule on your team that works better than the official process it replaced?