Thoughts On Process August 23 2012 Tweet
Process is a funny thing. Most of us have some sort of process we go through every day. Even if unintentional. We wake up at roughly the same time, we go to work, maybe we get some exercise a few times a week, we come home, eat dinner, go to bed, and do it again. When we start deviating too much from our day-to-day regimen, we start to feel unfocused and disorganized.
Yet, we view process at work through a much different lens.
Startups, by and large, seem confused about what process should mean for them. In many of us, the idea of "process" evokes fearful notions of bureaucracy and inefficiency. Many of us have worked in jobs where the processes in place were the manifestation of someone who was seeking control more than they're interested in helping the team get actual work done.
The gut reaction many of us have to process is a good thing -- no one wants to work at a company crippled by inefficient bureaucracy, or have pointless obligations that get in the way of our actual work. More importantly, a startup's very existence and sustenance rely on it's ability to move quickly and make decisions so it can accomplish it's one goal: finding a customer. For a startup to be riddled with bureaucratic process would almost certainly be a company killer.
Unfortunately, the result of this fear of inefficient bureaucracy is often a mis-directed desire for un-process. Often, young companies with a decentralized decision-making process end up with an overall lack of process and in-decision throughout the company.
We look at companies like Amazon, Github and Facebook and sometimes assume that their decentralized decision-making processes mean that they have very little process guiding their day-to-day work. The reality, however, is that these companies are deeply dedicated to efficiency and getting actual work done. They know that this is crucial for a software company to build high-quality products that their users will love. They throw out the bad processes and ways of building software, and strengthen the good.
So on one extreme, there can be way too much process -- bureaucracy. The other extreme, un-process, however, is just as destructive and inefficient. Un-process quickly leads to indecision, internal political battles and infighting, lack of cohesion and communication, and overall chaos. People stop sharing what they're working on, stop collaborating with each other to improve the quality of their work, and eventually, they'll stop caring altogether. The quality of the product suffers, and the speed with which things things get shipped slows measurably.
The company won't last long in this state.
So, neither extreme, un-process or bureaucracy, are places you want to be. On one extreme, we have pure freedom, a process of un-process. On the other extreme, we have the type of inefficient bureaucracy typically associated with large corporations, universities and governments. A startup's process needs to be somewhere in the middle, probably left-of-center, leaning towards the pure creative extreme.
I believe developing the right process is one of the most important things a young and growing company can do. So here's a simple definition of process:
Process is a
structured andrepeatable way by which you get work done.
That's a simple enough concept, yet executing on it is so much harder than it reads.
Enough with the Platitudes, Concrete Please
Early-stage startups are typically made up of bright, open, creative people, looking to have an impact and do something big. The idea of "process", even with such a simple definition, sounds constricting and anti-creative. However, the right process that evolves from real problems we have make us better at our jobs, not worse.
In most types of creative work, we already have forms of process. On the Zaarly engineering team, we judiciously use pull requests in our day-to-day development workflow. We write code for a feature, we create a pull request, solicit feedback from other team members, iterate on the feedback we receive, and when another team member gives a "+1" to the feature, we land it.
Build, gather feedback, iterate, ship. We repeat this process day-in and day-out. Simple enough, yet, this process is both highly intentional, and efficient. It serves our goals as an engineering team of shipping high quality code, quickly. The code review aspect of the process serves as a collaborative sanity check for the person doing the work, and a learning experience for the rest of the team. At some point, as a team we decided that all non-trivial code changes should go through this workflow, and it's the best way I know of to build software.
So, we have a process in place, and it makes us more efficient, not less. It's makes our jobs more enjoyable, not less. The benefits of peer review help us grow and progress as engineers. In short, this process helps us do our jobs better.
As with most things, the devil is in the
cliché catch phrases details. Waxing poetic about platitudes on process in a blog post is pretty damn convenient. Here are some general guiding principles I use when thinking about process.
Things to promote:
- Process should evolve naturally out of real problems your team has.
- The aspects of your process should be easily justified, and explainable in one or two sentences.
- Process should make those participating in it happier.
- The goal of any process should be to help people do their jobs better.
- Your process should be flexible, and open for modification.
- Things that facilitate communication and creativity amongst the members of your team (examples: Basecamp, Github).
- Process should promote things that provide feedback amongst the team (pull requests, design critiques, retrospectives, etc) and help individual members grow in their craft.
- Always favor lightweight and asynchronous over hard requirements.
Things to avoid:
- Process for the purpose of performance evaluation of employees.
- Process so someone can stay clued into "how things are going".
- Process motivated by anything other than helping people do great work.
- Meetings to solve problems (and meetings in general).
At the end of the day, there is one thing that matters at a startup: finding your customer. Your job is to build a product that customers will enjoy, and for which they will hopefully pay. Any process must support this singular goal above all other things.
Build, get feedback, iterate, ship. Rinse, repeat. Everything else is just noise.