Ask six people in the same department to walk you through the same task. You will get six answers. Not six wrong answers. Six answers that each work, that each came from somewhere sensible, and that nobody has ever compared side by side.
That is not dysfunction. That is what a company looks like after a few years of doing real business. People joined at different times and learned from different people. Someone hit an edge case in 2021 and invented a workaround that is now just how it is done. A process document was written once, was accurate for about eight months, and has been quietly wrong ever since. Nobody is doing anything wrong. There is simply more than one right answer in circulation, and no way to tell which one you are getting.
The work still gets done. That is the part that fools everyone.
Why nobody sees it
A company running this way does not look broken from the top. The orders ship. The invoices go out. The month closes. What you feel instead is a set of symptoms that look unrelated to each other:
The same request produces different outcomes depending on who picks it up. You ask two people for the same number and the numbers do not match, and both of them can defend how they got there. Something takes four days when it obviously should take one, and when you follow it you find the request went to the wrong person first, then to a second person who did not have authority, then back to the first. New hires take much longer to become useful than anyone expects, because there is no one version to teach them. And when you ask for a report on any of it, it turns out the work is hard to capture, because it was never done the same way twice.
Every one of those reads like a separate problem. They are all the same problem. The company is running several dialects of the same process at once, and no one has ever written down which one is the language.
Why buying software makes it worse
This is the part that costs real money, so I want to be direct about it.
When those symptoms get bad enough, the natural response is to go buy something. A new system. A better platform. Lately, something clever bolted on top of it. The pitch is always some version of: this will standardize how you work.
It will not. A system does not decide how your business runs. It stores what you put into it and enforces what you configure. So the first thing that happens is somebody sits down to configure it, and they have to answer a question the company has never actually answered: which version of this process is the real one?
Usually nobody knows. So the configuration gets built from whoever was in the room, or from whoever is loudest, or from a vendor template that matches nobody. And the other five versions do not disappear. They move. They become spreadsheets kept alongside the system, notes in a comment field, an email chain that runs parallel to the workflow, a person who has learned that the official path does not work for their edge case and quietly does it the old way.
Six months later you have the same disorder, plus a subscription, plus a migration you have to live with. The problems did not get solved. They got a new place to live.
I want to be careful here, because this is not an argument against systems. Good systems are worth a great deal. It is an argument about order of operations. Software is very good at enforcing a decision. It is terrible at making one. If you hand it an unmade decision, it will hand the mess back to you with better formatting.
What translation actually means
The work that has to come first is not technical, and that surprises people. It is closer to interviewing than to engineering.
You watch the work as it is actually done, not as it is described. Those are different things, and the gap between them is not dishonesty. People describe the version they believe they follow, and then they do the version that works. You have to see the second one.
You record every version in use, without deciding yet which is best. This matters more than it sounds. The moment you start judging, people stop showing you the real thing and start showing you the compliant thing, and you lose the only data that mattered. The goal at this stage is a complete inventory, not a verdict.
Then you find where the versions diverge, and more importantly, why. Most divergence is not laziness. It is somebody solving a real problem that the standard version did not account for. That workaround from 2021 usually exists because the official path genuinely broke on a case that still happens. If you standardize without understanding the divergence, you will standardize a process that is worse than what people are actually doing, and they will find their way around it. They will be right to.
Only then do you decide the standard. One version, written down, with the edge cases folded in rather than ignored. And crucially, one clear answer to who decides when a new edge case shows up, because there will be one.
That is the translation. Several dialects into one language, in writing, agreed by the people who actually do the work.
What you get
The output is not a document nobody reads. It is a company where the same request produces the same outcome regardless of who picks it up, where a new person can be taught one version instead of absorbing six by osmosis, where work can finally be captured because it happens the same way twice, and where the chain of command is short enough that nobody loops.
And then, if you want to automate something, you can. Not because you bought a better tool, but because you finally have something worth encoding. Configuration stops being an argument. The system enforces a decision the business already made, which is the only thing software is genuinely good at.
That is why adoption fails so often, and the tool is often not the only problem. People do not reject good systems. They reject systems built on a version of the process that does not match their reality. Translate first and adoption gets easier, because the system reflects a process the people using it helped define. There is far less to convince anyone of.
Where to start this week
You do not need a project to begin this. You need one process that annoys you, and three conversations.
Pick something small and irritating. Not the biggest process in the company. Something that takes too long or produces inconsistent results and that you touch often enough to notice.
Then ask three people who do it to walk you through it, separately, without telling them why. Do not correct anyone. Do not compare them in the room. Just write down what each one actually does.
If all three match, you have found a healthy process and learned something useful about your company. If they do not match, you have just found your first divergence, and you now know something concrete that no dashboard was going to tell you.
Either way you will know within a week whether this is a problem you have.
If you are about to buy a platform to fix something that looks like this, that is the week I would spend before signing anything.
If you have run into this, I would rather hear how it showed up in your business than pitch you anything. That is genuinely the more interesting conversation.