During my time with the Enterprise Architecture team for one business unit, we were heavily involved at the beginning of projects. Throughout the project we were sometimes consulted. We knew the architecture would drift during development due to any number of possible constraints. So we built a process modeled loosely on construction permits. Once the architecture was established and agreed upon we would issue a “Permit to Build”. When the team was nearing production they would come back for a “Permit to Operate”. This is where we reviewed what was actually built and documented the differences. Teams had the guidance they needed, the latitude to do the work, and the accountability for the decisions they made.

The process worked well enough that the larger organization decided to adopt it. That is when the process began to change.

Security added a mandatory review. Cloud costs were increasing, so the process gained another required sign-off. Some parts of the organization had a history of poor quality, so evidence of that work was added to the process. The tool that managed the process made it difficult to see which reviews were still open and who was responsible for the current step. A reorganization blurred the responsibilities even more and one of the gates became orphaned. And during all of this, the process became mandated for every project. Within a few months, it nearly stopped all development in the organization.

The process that was designed to control entropy almost became the blocker for every change. Everything added was reasonable. Every concern needed to be managed. Adding them to the “Permit to Build” process changed the intent of the process. The original intent was never forgotten. It was documented. The people who created it were still involved.

This is not to say that processes cannot evolve. Intentional changes to a process will consider the tradeoffs and often result in some form of a process redesign. Drift is different. Drift happens when the process accumulates changes without those intentional changes. My manager and I could see this happening to the “Permit to Build” process. However, we no longer had authority over the process. That had moved to a different part of the organization.

I witnessed a rare challenge to a process in the same organization a few years earlier. The architecture team was required to sign off on every project before it could be deployed to production. We were not involved in many of the projects. The new Head of Architecture asked a deceptively simple question: “What happens if we don’t sign off?” Nobody could provide a clear answer. The approval existed because it had always existed until that moment. The approval was removed and projects continued to deploy successfully. The architecture team recovered capacity for work where our involvement actually reduced risk.

Removing that approval required someone willing to accept the risk of changing the process and the authority to make the decision. I believe this is part of why processes remain in place for a long time. Changing a process introduces uncertainty, and if the change results in an incident, the person who made the change is on the hook.

Processes can accumulate unnecessary friction without anyone deciding that it needs to be changed. One signal I look for is the way that people begin treating the process. Are they following because it serves a purpose, or because they have to follow it? Eventually, there may be enough evidence that the process needs to change to warrant a decision. That requires someone with authority to make it.

The process does not have to remain exactly as it was when it was created. Organizations change, and their processes should change with them. However, when the process drifts instead of evolving, what risks are we introducing?