Creating a Process for Process
"If you can't describe what you are doing as a process, you don't know what you're doing."
- W. Edwards Deming
I've found myself thinking a lot about process recently.
Creating and documenting processes in startups is hard, for several reasons. First, it feels like time unwisely spent. A startup has to move so fast that it doesn't have time to think about process. Secondly, things change in startups so quickly that a process is going to quickly become obsolete, so why bother? And lastly, sticking to process takes discipline. When that discipline isn't there (especially from the leaders of the organization) then any process becomes unused and wasted.
On the flipside, having too much rigid adherence to an inflexible process can definitely hamper creativity and innovation.
So what's the right amount of process, and how is it kept relevant?
The conclusion I'm coming to is that it's important to create a process for process.
What I mean is that everyone in a startup agrees that:
- Creating and documenting processes is important for creating repeatability, speed, scale and efficiency of decision making. A process is a map; a blueprint that defines how members of an organization spend their time working to achieve a common goal.
- To keep from overdoing it, create processes using an agile approach, with a "Minimum Viable Process" that can be clunky to start.
- Every process is a living thing and is subject to improvement by anyone in the organization.
- That improvement happens in a structured way that's defined ahead of time (that's the process for the process)
If you disagree with point #1, then you might as well stop reading right now, because it's way outside the scope of this blog to debate whether the existence of process is valuable to an organization. But the 'right amount' of process is way trickier. I believe it is "the minimum is that gets the job done in a repeatable way." Note that I didn't say efficiently repeatable. It just has to be repeatable -- inefficient is OK to start.
Where I find that things usually break down in an organization is in between steps 2-4.
For example, with a clunky, inefficient initial process: When the Minimum Viable Process is clunky, it will feel broken. It's really easy to throw the whole thing away at that point, and just have every person fend for themselves. So recognizing that it's better to create a quick but clunky process than none at all is a big step. Training ourselves to change our initial reaction is important: If a process doesn't feel right, it does not mean the process should be abandoned. In fact, just the opposite: it means more thought has to be put into making it better.
That gets to point #3. It has to be possible for anyone in the organization to suggest improvements to the process. I think of it as an A/B test: Process "A" is the agreed upon way of doing things. Anyone can announce a challenge to that as an experiment. The challenger -- process "B" -- has to work better than A when it's tested for it to unseat the status quo of Process A.
For this to work, everyone in the organization has to understand and agree that there will be challenges to the status quo process. Those challenges have to be actively encouraged to come from anyone in the organization. It's important to communicate that Process B experiments are only a test so people don't freak out that their agreed-upon process has suddenly changed.
And one last, really important point: This workflow assumes there's already an initial process in place. I've found that the most chaos comes from having no agreed upon defined process for something at all, where each stakeholder is just doing his or her own thing in their own way, and everything feels like an experiment. In that scenario, the best way to get into this workflow is to make a strawman of an initial Minimum Viable Process, iterate on it quickly with the stakeholders until they agree it's good enough to try as a starting point, and then make that Process A, ready & waiting for a challenger that's better to unseat it.