In high tech and startup circles recently, process has become a dirty world.  Conventional wisdom has it that process is an unnecessary impediment to the famous Facebook motto of: “move fast and break things.”  It prevents experimentation, slows progress, adds bureaucracy, and makes the famous lean startup motto of “launch and iterate” much more difficult.

Complaints against process, particularly recently, can be summarized as: process slows things down, and is therefore bad.  One hears this complaint quite frequently in startup world where each hour represents a finite supply of cash and a day closer to business death.  Even larger companies have embraced agile methodologies, and are spending massive funds trying to be more nimble and fostering startup culture in their walls.

So does process make things slower?  If designed poorly, unequivocally yes.  Surely those who have worked in large companies or in government can sympathize with decision-making structures involving committees who are ill-informed about the decision in question, or procurement mechanisms that slow decisions while adding little value.

Yet good process often makes things move faster.  Indeed, even the lean mantra of “launch and iterate” works better (and faster) with well-designed process.  For instance, when considering a technical or product change, in the form of an A/B test, you have to know what you are measuring.  Simply launching such a test without clearly defining your hypothesis beforehand – what you are hoping to learn from the test – means such a test may not measure the right things.  So a team burns time and money and effort experimenting, but learns little from that experiment.  Much better to spend the time up-front discussing what the hypothesis of the experiment is, thinking about what the team wants to measure, ensuring that those metrics are part of the test, and then ensuring that the test results in learning/progress towards a Minimum Viable Product (MVP).

In short, much of the case against process is right but is fundamentally only an objection to poorly-designed processes.  Our next blog will give examples of how well-designed processes can enable organizational speed and execution, not act as an impediment to it.