Build Systems, Not Process
As companies grow they worry more about failure (they have more to lose). The common reaction is to clamp down by instituting more process. It’s really harmful because it causes good, productive people to get frustrated and leave.
We want to guard against massive failures that could harm our customers or our team, but it's not worth jumping through hoops to make sure $5 doesn't get wasted.
Of course, you still need some semblance of order. So we have systems. As we define them, a system is something that’s automated and designed to make your life easier. It’s designed to speed along a workflow in the common case and ensures that people retain autonomy and get default approval for as much as possible.
In contrast, we think of process as something that makes you stop and get approval because its primary goal is to prevent mistakes. It basically assumes that your people are going to screw up, so it gets in your way, slows you down and tends to default to no. It reduces ownership, motivation and responsibility.
Put differently, systems optimize to eliminate false positives (unnecessary delays to getting things done), and processes optimize to reduce false negatives (things getting done that shouldn't).
Here are a couple of examples:
- Periodically, we try to blow up any processes that have creeped in and end up blocking people. We had a process where people could replace their laptops every 18 months, and less than that needed someones approval. It turns out that nine times in 10, the reasons people wanted to replace their laptops early made great business sense, so we're moving our default setting to "replace it whenever you need to." If someone is replacing his laptop every three months, after a few cycles an alarm goes off and we'll have a conversation about if that's the right decision for the business or not -- we might have a bigger problem. But by default you need to assume people can make good decisions, or why are you working with them?
- We give everyone on the engineering team the ability to push and deploy code by themselves. We do require a code review and we have a bunch of automated tests to ensure you don’t break stuff, but you can override a lot of it in an emergency (we call this "break-glass"). It gives you autonomy and ownership. If you do something out of the ordinary it’s allowed, but it's elevated (very loudly) to the entire team. Everyone gets these bright red Hipchat/email/SMS/etc notifications: so and so just changed something unusual. People chime in: “Why are you doing that? Do this instead, it's safer” or “Good fix.” It creates accountability without slowing you down too much.
We'll be posting more insights in the months ahead. Email us with feedback.