Every Team Has Its Own Version of How You Work

Ask three people in a growing business how a new customer gets set up and you will often get three answers. Sales talks you through the handover it does on the day the contract is signed. Operations has a checklist that starts once the first order lands, and finance runs a credit check somewhere in between, or occasionally afterwards. Every one of those answers works, and none of them matches the process document, which was written two years ago by someone who has since moved on.

That is process drift, and it is one of the quieter trigger moments for a mid-market business. Nothing breaks and nobody resigns. The business simply grows past the point where one version of how it works could live in one head, and every team quietly writes its own. Its cousin, the brand voice that wanders between teams and regions, belongs to the wider bill for a business that forgets, and it has a different fix.

What is process drift?

Process drift in growing companies is the gradual gap that opens between the way a business says it works, in its SOPs and process documents, and the way each of its teams actually works. It is the default rather than the exception, because a documented process is a snapshot of the business at the moment somebody wrote it down, and the business keeps moving. New customer types arrive, a supplier changes its terms, a team doubles in size, and each change is absorbed by whichever team meets it first.

Drift is slow and it is traceable, which is what separates it from the day an acquisition lands a second, fully formed set of practice on the business at once. With drift you can usually find the month a variant started and the person who started it, if you go looking. Most businesses never go looking, because every variant arrived as a sensible fix to a real problem.

Why teams stop following the official process

Teams rarely stop following the official process out of carelessness. They stop because it no longer answers the question in front of them. The document says what to do with a standard order, and sales has spent the last six months selling non-standard ones. It describes onboarding for a single site, and the three largest customers now have nine sites each. The team can wait for someone to update the document or solve the problem today, and it solves the problem today, every time.

That is why I treat team variants as signal rather than as disobedience. Each one marks the place where the official version fell behind the business. The extra qualification question in sales exists because a type of deal went badly last spring. The extra sign-off in operations exists because a fitter once turned up without the right access permit. Read together, the variants are a fairly accurate map of everything the business has learned since the process was last written, scattered across a dozen spreadsheets and nobody's job to collect.

This is not an office quirk. The Health and Safety Executive's guidance on revitalising procedures, written for industries where a skipped step can hurt someone, lists the reasons people do not follow procedures, and among them are procedures that are wrong or out of date and easier ways of doing the task. Its advice on the second is the part I find most useful. "The operators may have devised an informal procedure that is quicker/easier and these methods should be incorporated into the formal procedure", as long as safety and quality are not compromised. If the national workplace safety regulator treats the local workaround as material for the official process, a sales team's extra qualification question deserves the same courtesy.

The trouble is that a variant which solves one team's problem is invisible to every other team. Sales does not know that operations added a step, so it keeps promising lead times the new step makes impossible. Nobody is wrong, and yet the business has stopped being able to describe itself.

How tool sprawl turns habits into configuration

For a while the variants live in habits, which at least means a conversation can change them. Tool sprawl ends that. As a business grows, each team picks the tool that suits the way it works and, quite reasonably, sets it up around its own version of the process. Sales builds pipeline stages around its qualification. Operations builds a job tracker with the statuses it actually uses. Finance keeps its own list of customers on account, because neither of the other systems holds what it needs.

None of this is unusual. In the ONS's 2023 management survey of firms with 10 or more employees, cloud-based computing systems and applications were adopted by 69% of firms in the UK, which means nearly every team has somewhere to build its own version. Living across those tools has a cost you can measure. In a study published in Harvard Business Review, which tracked 137 users across three Fortune 500 companies and was co-written by people from the firm whose software did the tracking, the average user toggled between different apps and websites nearly 1,200 times each day, and spent just under 4 hours a week reorienting after the switches. Closer to home, Workday's 2026 survey of 2,400 UK professionals at organisations with 500 or more employees found that "one in four UK workers spend seven or more hours a week copying information between applications, reconciling conflicting data and manually feeding context into AI tools". That is vendor research from large organisations, but the mechanism does not need a large organisation to work.

Once a variant is built into a tool, it changes character. It becomes a required field, a pipeline stage, a status list or a template, and two things happen at once. It gets harder to see, because nobody reads another team's configuration, and it gets harder to change, because the tool now enforces it and reports depend on it. A difference that was once a habit someone could be talked out of is now a schema that three dashboards and a weekly export rely on. The cost shows up as people re-keying the same customer into three places, and as the meeting where two teams discover their numbers disagree because their stages mean different things.

The automation picks a winner nobody chose

This is where drift stops being an irritation and starts compounding. When a business automates a workflow, someone has to decide which version the automation runs. In practice nobody decides. Whoever builds the automation builds it from the version they know, which is their own team's, often without realising the other versions exist.

None of the versions is broken, which is exactly what makes this hard to spot. Each works for the team that wrote it. What the automation does is quietly settle a disagreement nobody knew they were having, and then run the winning version at machine speed while the other teams carry on working around it.

AI agents sharpen the problem. An agent pointed at the process documents reads the official version, which nobody follows. An agent pointed at every team's documents finds four answers to the same question and picks one, fluently, with no sign that it has chosen. Either way it inherits the drift. That is why the rung most businesses skip on the maturity ladder is the one where the business writes down what it actually does, and why a sensible first agentic build works from a documented strategy rather than from whichever team's habits happen to be nearest.

Re-aligning teams without policing them

The instinctive fix is a standardisation drive, a rewritten manual sent round with an instruction to follow it. It rarely holds, because a manual that ignores why the variants exist is overtaken by the business within a quarter, and the teams drift back with less goodwill than before.

It also does not need to happen all at once. Documentation is an output of automation work rather than a prerequisite for starting it, and the same holds for drift. You find the variants when you map one workflow end to end, and that is the moment to deal with them.

1. Collect every version before you write the official one. Ask each team that touches the workflow to walk through what it actually does, and ask what each extra step is for.
2. Sort each difference into legitimate or accidental. A legitimate variant answers a real question the official version misses, such as a customer type, a regulation or a site condition. An accidental one is habit, a workaround for a tool that has since changed, or a step nobody can explain.
3. Write one source, with the legitimate variants named inside it. "Multi-site customers also need the access-permit check" is a branch of the process, written where everyone can see it, rather than a rival process.
4. Converge the accidental ones, and give the reason. People let go of a habit far more readily when they can see why it no longer earns its place.
5. Point every tool and automation at the source. CRM stages, job statuses and agent instructions should all read from the one written version rather than carry private copies.

The aim is not uniformity. Teams genuinely need different views of the same work. What they should not have is different versions of it.

What this looks like in practice

We saw the shape of this with Designs4You, a UK commercial flooring business running more than 350 jobs a month with eight or nine office staff. Their legacy project system had no API, the team had built workarounds around it for so long that nobody could see the underlying problem any more, and more than half of staff time went on administrative data entry. When we replaced it, the decision that mattered most was not the choice of tool. It was building one set of shared records, four core tables for projects, customers, fitters and activity, with seven interfaces on top, each built for a different team role. There are views for the quote pipeline by sales rep, for the weekly schedule and for what is ready to invoice. Each team got its own view of the work, and nobody got their own version of it.

That distinction is what made the next step straightforward. Within weeks the first automation, an RFQ pipeline, had taken inbound handling from 20 minutes to under 90 seconds, and it existed because there was one structured place for it to read from and write to. Had sales, the office and accounts each kept their own tracker, the first job of that build would have been deciding whose version the automation should follow.

What keeps processes aligned as a company grows

Re-aligning once is the easier half. Holding it while the business keeps growing is mostly a matter of where changes go. When a team finds a case the process does not cover, the fix is written into the shared version first, as a named variant if need be, and someone who owns that process says yes or no to it. The moment to be most alert is when a team adds a tool, a pipeline stage or a required field, because that is when a habit quietly becomes configuration. And instructions for automations and agents should point at the written process rather than restating it, so that changing the source changes every automation at once.

Done consistently, this is a small, practical version of the idea behind an intelligence system, a single maintained record of how the business works that people and tools both read from.

Practical takeaways

1. Treat variants as evidence, not defiance. Every team's own version marks a place where the official process fell behind the business.
2. Decide which version an automation runs before you build it. Otherwise the builder's team decides by default, and the other teams inherit the workaround.
3. Give teams views, not versions. Different screens over one shared set of records holds alignment far better than different tools with their own copies.
4. Treat every new tool or field as a process change. It is the point at which a habit becomes configuration, and the cheapest point to catch it.

Frequently asked questions

What causes process drift?

Growth, mostly. A documented process describes the business at the moment someone wrote it down, and the business keeps changing after that. New customer types arrive, suppliers change their terms and teams double in size, and each change is absorbed by whichever team meets it first. That team adapts its own way of working and rarely updates the shared version, so over a year or two every team ends up running a slightly different process. Tool sprawl then fixes those differences in place, because each team configures its own tools around its own version.

Why do teams stop following the official process?

Because it stops answering the question in front of them. The official process covers the standard case, and a growing business spends more and more of its time on cases that are not standard. Faced with a choice between waiting for the document to be updated and solving the problem today, a team solves it today. That makes each team's variant a useful signal rather than a discipline problem, since it marks the place where the official version fell behind the business.

How does tool sprawl make process drift worse?

It turns habits into configuration. While a team's variant lives in habit, a conversation can change it. Once the team sets up its own tool around that variant, the difference becomes a required field, a pipeline stage, a status list or a template. Other teams cannot see it, because nobody reads another team's set-up, and it becomes harder to change, because the tool now enforces it and reports depend on it. Every automation built on that tool then inherits the variant as well.

How do you re-align teams without policing them?

Collect every team's version before you write the official one, and ask what each extra step is for. Sort the differences into legitimate variants, which answer a real question such as a customer type or a site condition, and accidental ones, which are habit or a workaround for a tool that has since changed. Write the legitimate variants into one shared source as named branches, converge the accidental ones with the reason given, and point every tool and automation at that source. Do it one workflow at a time, as you map each one, rather than as a company-wide programme.

What keeps processes aligned as a company grows?

A handful of habits. Changes go into the shared source first, before they become a local practice. Each process has a named owner whose job is to accept or reject proposed variants rather than to police compliance. Adding a tool, a pipeline stage or a required field counts as a process change and gets checked against the source. Automations and AI agents read the written process rather than holding their own copy of it. Reviews happen when something changes, such as a new market or a team doubling, rather than on a calendar.