Versioning your processes like code
Code has version history; most processes have folklore. Treating how you work like something that can be versioned changes everything.
When code changes, there's a record: what changed, when, why, and who. When a process changes, there's usually nothing — just a vague sense that 'we do it differently now,' with no history and no clear current version. That gap causes real confusion.
Processes drift silently
Without versioning, processes mutate through hallway decisions and individual workarounds until no two people describe them the same way. There's no canonical 'current version,' so onboarding is folklore and disagreements have no source of truth to settle them.
Borrow from engineering
Treat the process like a document with a current version, a change log, and an owner. When it changes, the change is explicit and dated. People can see what the process is now and how it got there. It sounds bureaucratic; in practice it removes a huge amount of ambiguity.
Code has a history. Most processes have a rumor. Version the way you work and the arguments disappear.