Reading the Drift

Over time, I have started to think of organisations as running two systems at the same time. I did not arrive at this as a theory. I arrived at it from inside the work, by seeing the same mismatch between process and practice repeat across different contexts.

The first one is easy to describe. It is the org chart, the planning cadence, the written process, the metrics that get reported, the roles that have job descriptions, the language used in steering committees, and the diagrams pinned up on the wall. This is the version of the organisation that fits in a slide. I call it the Stated System.

The second one is harder to describe, because it lives in nobody’s documentation. It is where the real decisions get made, how priorities actually get set, who carries what knowledge in their head, whose calendars quietly decide how fast certain work can move, which channels carry the truth, and which forums make people careful about saying it. You can only see this version of the organisation after working inside it for long enough. I call it the Lived System.

The distance between the two is what I call the Drift. Reading the Drift is the leadership practice this article is about, and the framework is the spine of my forthcoming book, Leading Agile When No One Agrees. I have been observing the pattern for fifteen years, partly through my own experiences across two engineering organisations, partly through conversations with contacts spanning numerous industrial and academic organisations. Once you start seeing it, the Drift becomes difficult to unsee.

Some Drift is normal, and frankly it is even healthy. Organisations adapt to context faster than their stated processes can update. A team finds a workaround. A backchannel forms because the official channel is too slow. Someone learns that the planning meeting is the place to look engaged, but the corridor afterwards is the place where the actual call gets made. None of that is dishonest. It is how living systems handle the lag between what was decided last quarter and what reality is asking for today.

The problem is not that the Drift exists. The problem is that the Drift can keep widening in a direction nobody chose. Over time, the Stated System becomes more useful for reporting than for describing how the work actually happens. And in most organisations, nobody can point at the day on which that happened.

How the Drift becomes invisible

When I first started noticing this gap, I assumed it was a sign that something was broken. The process was wrong, or the team was not engaged, or the leaders were not aligned. I would propose fixes, push for adherence, and feel frustrated when the fixes did not stick. I realise now that the gap was not the problem. The gap was the message. The frustration I was feeling was the cost of not yet being able to read what the gap was telling me.

The reason the Drift is so hard to see is that the Stated System keeps producing reassuring output the whole time it is drifting. The status on the deck is still green. The cadence still runs. The roles are still on the org chart. But the work has moved somewhere else. It is being carried by people who are not named in the process, in forums that are not in anyone’s calendar, through channels the formal system does not always see. For a long time, this can be invisible to anyone who is not doing the work.

This is the moment that matters for leaders, because everything downstream of it gets harder. Decisions made only on the basis of the Stated System can become decisions made on an incomplete picture. Risks can look settled in slides while still needing attention in the work. Improvements agreed in retrospectives never reach the place where they would change anything, since the place where they would change anything is not where the retrospective is happening.

The first temptation, at this point, is to try and close the Drift by tightening the process. Add governance. Demand stricter adherence. In my experience, this rarely works. The Drift exists in the first place because the Stated System was insufficient. Tightening the insufficient part does not make it sufficient. It usually produces more performance around the process without resolving the underlying mismatch.

The opposite temptation is to declare the Stated System dead and let the Lived System run unchecked. This rarely works either. The Lived System often knows what is really happening, but it does not tell everyone equally. Without a Stated System to anchor against, each group starts optimising for the reality it can see. That may make sense locally, but it becomes almost impossible to steer across the whole organisation.

What does work is to read the Drift instead of trying to close it.

The three Drift questions

When I face a problem like this, I run it through three questions.

The first one is: what does the Stated System say should happen here? This question almost always has an answer in writing somewhere. The framework says one thing. The policy says another. The org chart implies a third. Whichever it is, I can find it, and I write it down in the words the system itself uses, since my own paraphrase would already be adding my interpretation.

The second one is: what does the Lived System actually do here? This question only has answers in the heads of the people who do the work. The way to surface those answers is to ask in private, of the people who carry the load. Not in a workshop, and not in a town hall. I do not ask “how does our process handle X”. I ask “what happens when X comes up”. The answers come back in specifics. Names. Channels. Calendars. The Lived System reveals itself in the specifics, not in the summaries.

The third one is: who pays for the gap, and what would close it? Drift is not free. Someone always absorbs the cost. Usually it is the people closest to the work, because they are the ones who carry the difference between what was promised and what is possible by working harder, by working later, and by working around.

For example, take a case I have come across more than once. A team had a recurring type of work that kept appearing late in the delivery cycle, not because people were careless, but because the process had never really been built to make that work visible early enough. The Stated System said the process was sufficient. In practice, the work was being quietly absorbed by a small number of experienced people near the end of every cycle, often at the cost of their evenings.

Naming who was paying for that gap was the move that turned the Drift from an abstract structural feature into a concrete leadership decision. Once you know who is paying, you can decide whether the cost is acceptable, whether it can be reallocated, or whether something needs to move.

What Reading the Drift gives you

Reading the Drift is not another process to roll out. What it gives me is a way of sitting through a status meeting and knowing, for each green light and each amber, which version of the project the colour is describing.

It changes how I handle escalations. Instead of asking whether the team is following the process, I find myself asking whether the process is describing the work. It changes how I run retrospectives. I no longer go fishing for improvement actions. Instead, I ask which forum the team thinks would actually surface the real issues. It changes how I read a roadmap. I do not trust the dates on their own anymore. I ask which decisions are hidden inside those dates, and which of those decisions live in the Stated System versus the Lived one.

Most of all, it changes what I do with my authority. I stop spending it on closing the Drift, because closing the Drift is mostly impossible, and start spending it on making the next decision more honest than the last one was.

It is not glamorous, and it rarely looks like transformation while it is happening. Most days it looks like asking one more uncomfortable question before the room accepts the easy version of the status.

The examples in this article are anonymised and, where necessary, composited from multiple professional contexts. They are intended to illustrate organisational patterns, not to describe a specific employer, product, programme, or team.

This is one chapter, condensed, from my forthcoming book Leading Agile When No One Agrees, which works through the Drift framework across twenty-two chapters of scenes drawn from fifteen years inside agile transformations. If the framework resonates, the book is the longer treatment.

More writing and book launch updates at kylehauslaib.com.