Changing an existing process is perhaps one of the most challenging undertakings a person can do in a company. It matters not how antiquated, inefficient, or counter-intuitive the procedures, inertia and prestige keep people compliant with the status quo. And if that is not enough, add company size to the complications; the larger it is, the more intransigent to change it becomes. 

One could argue that the reason may be due to the collective risk aversion to altering how things are done; others may say that complacency is the culprit; many more plausible explanations can be added to this list. The definitive answer is likely forever unknown. 

This post, however, is about how to refactor an existing process. I will tell the story and the steps that me and two other colleagues took to refactor and modernize how products were released. How we identified and replaced a process that was universally disliked with one that was immediately adopted and significantly simplified shipping products to customers. 

In the book Men, Machines, and Modern Times, Elting Morison asked readers, and some of his colleagues, about the definition of the word “bureaucracy.” He argues that although we all intrinsically know what it means, and have experienced it in our lives, most of us are unable to satisfactorily define it. Terms like “red tape,” “paperwork,” and “governance by bureaus” come to mind, but these are all fuzzy definitions, lacking clarity. Morison proceeds to tell a few stories illustrating bureaucracy in the U.S. Navy (good subject for observation since it is a somewhat controlled environment), then proposes that a bureaucracy is a “data-processing machine.” A machine that follows a rigid set of rules, with little to no room for flexibility. Like a computer system, “it is designed to take in and digest different pieces of information,” regardless of whether it still makes sense or not. However, there is hope. Morison provides examples of how bureaucracies were transformed. 

Back to this article, the process in question was making a software product generally available to all customers. The earlier practice involved presenting a product to a committee of stakeholders, composed of representatives from:

There were several challenges associated with it: 

Time for obtaining approval would take anywhere from 18 to 50 weeks–with an extreme case of over 70 weeks (that is almost a year and a half). Needless to say, this was an unnecessary delay in launching a product. Remember, this was not the time it took to build a product, this was how long it took to receive approval to release a product after it had been built. 

Several AI and ML products were in the pipeline to be released and we refused to wait the time it took to navigate the bureaucracy. 

The main purpose of the approval committee was to make sure that the company’s products were compliant to certifications such as SOC, ISO 27001, and so on. The internal process was well meaning, however immensely disruptive. And because of this level of abstraction and lack of transparency to its purpose, people were under the impression that products needed to be compliant to the internal requirements, rather than the ones from the certifications.

Implementing change

Once the explanation to the process, its purpose, and unintended consequences were understood, it was time to explore a path to build something better. 

The first step was to share the current situation with an executive at the company, explain the negative impacts we were experiencing, and the proposed solution. Next, I asked the executive to be the sponsor (champion) of the initiative. This was of fundamental importance, because it gave me air cover to reach out to the many stakeholders and to carry on the conversations. 

This task was too big for a single person, a single voice. Plus, it was unlikely that I would be able to do it all on my own. I shared the idea and mission with two colleagues whom I trusted. They had gone through the internal certification ordeal and the pain of doing so was still vivid in their memories; they were willing to walk the walk with me. 

There will always be intrapreneurs in every company, you just need to discover them. What’s more, you will have others to talk to, bounce off suggestions, distribute responsibilities, and prune off lousy ideas. 

Next was where we found the most resistance. Scheduling separate conversations with each custodian and gathering what were their requirements for approving a release. This is much easier said than done. There were claims of need for domain expertise in the matter, lack of documentation, outdated documentation, and many other “excuses” not listed here. 

Irrespective of the attempted refusals, we held our ground, and felt emboldened. We stayed laser focused on the mission of gathering the requirements. And when needed, we escalated the matter to the executive sponsor, to help facilitate the conversation. All the while, we kept our cool (think of Morpheus in The Matrix, Amélie Poulain in Amélie, or Ferris Bueller in Ferris Bueller’s Day Off), always remembering that our goal was to document the process, rather than to engage in argumentation with colleagues. (There was a case where the defiance was so fierce that we could almost hear the bones of their hands crackling reluctantly, as their grip unlocked to share the information with us.) 

As the requirements poured in, we started writing a body of documentation (including diagrams, figures, etc.) describing the entire process. We divided the work into sections, each of which contained the specifics from each of the approvers, then we published everything in the company’s knowledge base. Having all the information in a single place not only brought understanding and clarity, but also bubbled up inefficiencies, and gave us the chance to suggest optimizations. 

There was a vital role played by the approval committee that could not be addressed by sharing requirements alone. If a product was non-compliant, it could not be released; the consequences could be severe. Gatekeepers were undesired (because of the inefficiencies), however stakeholders shouldn’t be toothless, either. The solution was to establish a channel for communication with all stakeholders (e.g., group instant message, group email) and a minimum period (typically two weeks) for review, evaluation, and reply. 

Toyota is known for using an Andon Cord (a.k.a. Jidoka principle) in its assembly lines. In summary, it means that any worker can stop production if they perceive a problem that would compromise the quality of their products. 

The comparable Andon Cord for us was to assume automatic approval if no response was given after the minimum assessment period. However, any participant could, at any moment, raise a concern and stop the release until the issues were addressed. Stakeholders were no longer a chokepoint–having to explicitly approve a release, yet they had authoritative power to stop or veto the product release and tell the team what needed to be done to meet compliance. 

With all the pieces in place, the inevitable question in everyone’s head was: would the new process work? There was only one way of finding out, we had to run a pilot. The first product released using these new procedures was going to be the litmus test to validate or refute the work we had done. Not only that, but it would also show us wrinkles and creases that are only visible once you put theory into practice. 

We chose a team, explained the entire process, and what we were trying to accomplish. They agreed to be a “guinea pig,” and together with stakeholders, we all worked in close collaboration in this pilot. 

The team’s attitude is worth mentioning. Rather than trying to shield and protect our new process, we opened it to criticism. Final decisions were still ours (waiting for consensus or group deliberations are appalling alternatives). This meant that our intent was to get it right, rather than to be right. We listened, evaluated, and decided the merit of each suggestion, whether to apply it, and when (immediately or an adjustment for the next release). 

Overall, the release was a success, and we learned a great deal about a few things that could be better. We made the necessary changes and updated the documentation to reflect that. In fact, the release process is far from static. It is frequently evolving with feedback received from teams, stakeholders, and lessons learned. 

With a successful product released and a simplified and polished release process, we held a seminar to showcase what’s new, explain the changes, and demo the pilot to all. Teams were free to choose penitence (i.e., the old way), but by now stakeholders were nudging adoption of the new method. 

Taking the training wheels off

The new process was a success, the pilot was a success, nonetheless a question remained: would it scale? 

Airbnb’s Bryan Chesky said, “If you want your company to truly scale, you first have to do things that don’t scale.” In his case, he was referring to serving customers one by one, until you have a solution that does what they need. 

A variation of this lesson applied to us. For the next several weeks, we worked in close collaboration with teams that were releasing products. From walking them through the new process, to helping write the documents, communications with stakeholders, and monitoring progress. All parties appreciated this non-scalable, personalized semi-concierge service. And similarly to when a person learns how to ride a bicycle, the training wheels had to come off, so they did. 

I still remember the nail-biting moments when the first team went on to release their product on their own. Yet they required no nervousness, nor assistance. By now everyone was familiar with the process, and it was business as usual. Ownership was shared among us all.

Doing it yourself

The refactoring of this process worked for the case I described in this article, though a question remains unanswered: can it be replicated? Even if only partially, which sections could be of practical benefit to other situations, more specifically, your use case? 

Recipes rarely, if ever, fit all. Their simplicity gives a false sense of control of the situation. A person may naively grow tempted by the thought “I just have to follow these steps to be successful.” This is deceiving because it is an oversimplification of a complex system. That said, recipes do have value, as they communicate intent, provide a starting point, formalize thought into a structure, and are a guiding reference to milestones. A tool that is far from magical, but nevertheless a useful one. 

These are the basic principles for refactoring a bureaucratic process, distilled from my own experience:

They may work for you, too.