Process Is The Hobgoblin Of Little Minds
By Bob Hueston on Dec 21, 2006
If we could clearly identify the steps that Hal followed informally, we could document (or formalize) a process for everyone to follow. It might look something like: write down all the requirements, brainstorm and list all possible solutions, then rate and rank each candidate on how well it meets the requirements and select the candidate with the highest rank. With a formalized process, everyone could make decisions as well as Hal; well, almost as well, since the transformation from instinctive process to formal process to execution is never 100% efficient. But we could raise everyone's proficiency. Everyone's, of course, except Hal's.
If we forced Hal to follow this process, he would waste time writing down all the requirements, identifying subject-matter experts, holding brainstorming sessions, writing all the options on pastel-colored 3x5 post-in notes and filling the walls of some conference room, drawing four- and five-dimensional diagrams relating all of the requirements to all of the options to all of the costs, and selecting the optimal solution based on a secret ballot of all stakeholders. What used to take Hal a few seconds or minutes of cogitating would now take him days just to get a conference room reservation. Hal's productivity would drop by orders of magnitudes.
The purpose of formal processes should be to compensate deficiencies while not hindering proficiencies too much. When applying a new process (or changing an existing process) there needs to be a net gain, a reason for the change, a "big payoff." A "good" process may not be good for everyone. And every process needs to be flexible so that it can be adapted and taylored to the organization, or the individual.
Formal processes and process change is not the panacea for all problems. To paraphrase an oft mis-iterated quote of Ralph Waldo Emerson:
A pointless process is the hobgoblin of little minds.
[Appologies to Mr. Emerson.]
The first step in improving processes is to understand the processes that are in place, formal or informal. If there are no formal processes, the first, critical, step is to formalize the existing processes, exactly as they exist, without embellishment. The last thing you want to do is formalize a process and change the process at the same time.
For example, I once worked at a small company with a team that performed very well with no formal processes. None were needed. As the team grew, new members needed to understand how things got done. So we set out to document the software change control process. The first attempt was a bit over-zealous, and resulted in a dozen-step process, with reviews, checklists, approvals, etc., which simply did not exist (and did not need to exist). That version was torn up and replaced with what was really happening:
- Author makes code changes.
- Author decides if other people should review the code. Based on feedback, author decides whether changes are necessary.
- Author tests code as applicable.
- When author is satisfied that that code is sufficiently reviewed and tested, author commits changes.
The process made clear what was expected of the developer, without creating artificial hurdles or pointless documentation. This process worked fine, and continued to work well for a long time, because the team members were very conscientious and could be trusted to do the "right thing". If you trust your team members, then your processes do not need to be onerous; they do not need to include checkpoints and approvals (and if you don't trust your team members, perhaps you need new team members).
Much later, when the team had grown and the rate of changes (and the rate of mistakes) increased, we did go back and change the process, evolve the process, in ways that improved overall efficiency at a modest cost. But we could not improve the process until first we had formalized the process.