When you think of a startup, processes are not exactly the first thing that comes to mind. Instead, you envision an environment where people are trusted to always do the right thing, where checklists are scoffed at in favor of a natural feeling for what needs to be done, where failure is viewed as something that happens every day because that’s how things work.
On the other end of the spectrum are enterprises, where process is king and employees have instructions for doing everything, and each change must be approved by an excruciatingly slow bureaucratic apparatus.
Most startups are terrified at the idea of becoming an enterprise. You know the kind of environment I’m talking about: it’s the office where people talk with contempt about those working at Google, or Apple, or Microsoft. It’s the office whose residents think they are saving the world (they’re probably not).
It also happens to be the office that will not be around anymore a couple of years from now.
Don’t get me wrong: I love startups. I work in a startup. I think there is something very powerful about being lean and being able to bend and change at a whim’s notice. With that said, I also think that sometimes we are so scared of becoming too rigid that we fail to see the advantages of structure. If we could tap into this pool of knowledge, we’d be able to achieve much more as individual companies and as an ecosystem.
After all, there must be a reason if Google is Google.
As I mentioned in one of my latest articles — In Defense of Human Testing — there are things that humans are naturally good at, like thinking and creating, and there are things that are better confined to a checklist.
You might think that startups can afford to fail more than large companies, but in fact the opposite is true: as a startup, you have to fail, but you should set up your people for success. Trusting their brains to work like computers is not a successful strategy, not to mention a waste of their brainpower.
If you create processes around the most common and repetitive tasks in your company, you will free up your people’s time to work on what really matters: when your development team doesn’t have to worry about forgetting a step of the release process, they can focus on solving the next big challenge instead. When your QA team is not trying to remember what a regression test was like, they can use that spare time to come up with new tests.
Another important advantage of processes is that they simplify and speed up the on-boarding of new team members, as they will be able to perform the mundane tasks right away and will be free to focus on the most complex aspects of the job — hopefully, the ones you hired them to take care of.
Finally, you should never forget that process naturally leads to automation. When you are creating a checklist for people to follow, you are also laying the foundation for letting a machine take care of that same process at some point in the future. which will save your team even more time down the road.
There is a very simple rule that you can follow to determine when exactly to implement a process around an existing task: only do it when it hurts. While not a terribly objective suggestion, I can assure you this is a pretty good one.
If you try to implement a process before it’s needed, you will most likely fail.
First of all, you won’t know exactly which parts are causing the greatest friction in the team and why that’s happening, so your solution might address the wrong problem.
Secondly, it will be much more difficult to get buy-in from the rest of your team: people are reluctant to change. If something’s working well, why should they start doing it in a new way? Wile short-sighted (things can always work better), there’s wisdom in this view of the world: one should always focus on the most pressing issues and disregard everything else.
By waiting for problems to manifest themselves, it will be much easier to come up with the right solution and ensure people actually like the solution.
The second aspect to pay attention to is the kind of problem that you are trying to solve. With time, I have come to differentiate problems in two categories:
If you try to apply a People solution to a Process Problem, you will fail to fix the problem, because you’ll be asking people to do things they’re not good at, like remembering stuff.
If you try to apply a Process solution to a People Problem, you are laying the ground for disaster to strike. If two team members don’t get along, and you try to force them to get along without understanding the underlying issues, you will not only fail to address the problem, but very likely exasperate it by creating resentment towards the company and the management level.
This is the one mistake you cannot afford to make: never treat your people like their issues are trivial, because they’re not. Find People Solutions for People Problems. It takes much more time and effort, but ultimately it’s the only way to create happiness and enable growth.
This is a method I picked up when researching better ways to structure retrospectives. It turned out it can be applied whenever you want to ask for ideas and keep track of their implementation over time.
The underlying concept is simple: the bigger the change you are making is, the heavier the resistance to that change will be. If you sweep people off their feet, they will do whatever they can to maintain their balance.
However, if you only change one or two things at a time, gaining feedback at every step and adjusting course as needed, eventually you will make a huge differences with people barely noticing that you are disrupting the status quo.
A practical way to do it is to start the definition of your process by asking yourself these three questions:
For instance, suppose you are trying to improve how you handle urgent bugfixes. You might come up with the following answers:
There are multiple benefits to this approach: first of all, each change is small and can be implemented without excessive effort from the team, which avoids process fatigue.
Secondly, it is much easier to gain feedback at intermediate steps in the implementation, which virtually eliminates the of risk coming up with an incomplete or useless solution.
Lastly, it doesn’t feel like an attack: you are not bashing people for what they’re doing wrong, but identifying both the things they are doing well and the things they could do to improve the current state of things.
I can assure you everyone will respond to your proposals dramatically better if you make them both innocent and easy to implement. On the other hand, if you try to force people to do things your way, you’ll just make the wall harder to breach next time.
There’s one last consideration: you should always respect momentum. For a deeper explanation of what that means, I invite you to read my article The Hype Cycle: What It Is and How to Game It.
Basically, you should never try to enforce a process that no one likes or that is obviously not working. It’s simple to get fascinated by the the prospect of changing things and forget what problems and solutions led to the current situation — by doing so, you are bound to fail.
Instead, you should consult your team before, during and after the change to ensure that you are helping them, not creating new obstacles. Understand their why and how, wait for the time to feel right and get buy-in from at least a few team members before you start.
Learn the rules, then start breaking them.