Do you optimize for consistency or flexibility?
Many of us are drawn to patterns and processes. When something goes well, we try to figure out how to repeat the success. “That project went great. Let's do the same thing next time.”
When things go poorly, we look for which inputs led to the wrong output. Then, we introduce checkpoints to provide a sense of safety. Those three words we've all heard at some point — "From now on..." From now on, every deployment needs to be signed off on by a senior programmer, we can't ship until QA gives approval, each team will do a daily standup so details aren't missed, etc...
Learning from experience is how we improve, but new processes won't ensure the result we're looking for. We want security and assurance, but work is messy and always will be.
Heavy process also has a cost. It limits your options and slows things down.
The best processes are things you do often, but not always. Leave room to do things differently.
At 37signals, sometimes we spend days on QA because the risk is high or the surface area of the work is large. But a team can also ship without it if they're confident and the downside of missing something is minor.
There are features we ship internally for a week first to try them out and plenty that we don't.
Shaping a new product idea sometimes takes a week or two, with a bunch of customer research, technical feedback, discussions, and revisions. Other times, a pitch comes together in a few hours—the problem is obvious and the solution straightforward.
Another example is how we use Basecamp to run projects. At a high level, the work for every project is tracked and discussed in a single project that anyone can join. The 2-person team shares their progress regularly.
How that plays out in practice, though, varies widely! Some teams make heavy use of hill charts that are updated daily. Others post a weekly heartbeat message and some just share a running commentary in the chat.
Forcing every project to do things the same way and jump through the same hoops leads to process theater—people going through the motions and doing things that aren't the right fit for the situation. Moving slower and having less ownership isn't a recipe for the best work.
The temptation to rethink processes is highest when something doesn't go according to plan, like when a project turns out to be more substantial than first thought. You wonder, how can we make sure that doesn't happen again?
Maybe we should spend more time up front digging into what the work entails and estimating how long it will take. Or we could make sure every pitch is reviewed by multiple programmers.
But before jumping to new processes and checklists, it's worth asking, is this one-time or all-the-time? Don't overcorrect for what may have been a unique set of circumstances. File it away and dig in more when you start to see a pattern.
Next, look at how the system as a whole works and what it's optimized for. Each piece affects the other pieces. If every pitch needs a lengthy vetting process, that means there's little room for promising ideas late in the process. Is it worth making it a bit less likely that projects have surprises if you lose the ability to be opportunistic?
Maybe it is. It comes down to priorities and trade-offs. Just be aware that changing one thing inevitably changes other things.
The sweet spot is when process is treated as best practices, then mixed with a strong dose of trust and flexibility. Be clear about what you're trying to achieve and give the people closest to the work the freedom to decide how.
Many of us are drawn to patterns and processes. When something goes well, we try to figure out how to repeat the success. “That project went great. Let's do the same thing next time.”
When things go poorly, we look for which inputs led to the wrong output. Then, we introduce checkpoints to provide a sense of safety. Those three words we've all heard at some point — "From now on..." From now on, every deployment needs to be signed off on by a senior programmer, we can't ship until QA gives approval, each team will do a daily standup so details aren't missed, etc...
Learning from experience is how we improve, but new processes won't ensure the result we're looking for. We want security and assurance, but work is messy and always will be.
Heavy process also has a cost. It limits your options and slows things down.
The best processes are things you do often, but not always. Leave room to do things differently.
At 37signals, sometimes we spend days on QA because the risk is high or the surface area of the work is large. But a team can also ship without it if they're confident and the downside of missing something is minor.
There are features we ship internally for a week first to try them out and plenty that we don't.
Shaping a new product idea sometimes takes a week or two, with a bunch of customer research, technical feedback, discussions, and revisions. Other times, a pitch comes together in a few hours—the problem is obvious and the solution straightforward.
Another example is how we use Basecamp to run projects. At a high level, the work for every project is tracked and discussed in a single project that anyone can join. The 2-person team shares their progress regularly.
How that plays out in practice, though, varies widely! Some teams make heavy use of hill charts that are updated daily. Others post a weekly heartbeat message and some just share a running commentary in the chat.
Forcing every project to do things the same way and jump through the same hoops leads to process theater—people going through the motions and doing things that aren't the right fit for the situation. Moving slower and having less ownership isn't a recipe for the best work.
The temptation to rethink processes is highest when something doesn't go according to plan, like when a project turns out to be more substantial than first thought. You wonder, how can we make sure that doesn't happen again?
Maybe we should spend more time up front digging into what the work entails and estimating how long it will take. Or we could make sure every pitch is reviewed by multiple programmers.
But before jumping to new processes and checklists, it's worth asking, is this one-time or all-the-time? Don't overcorrect for what may have been a unique set of circumstances. File it away and dig in more when you start to see a pattern.
Next, look at how the system as a whole works and what it's optimized for. Each piece affects the other pieces. If every pitch needs a lengthy vetting process, that means there's little room for promising ideas late in the process. Is it worth making it a bit less likely that projects have surprises if you lose the ability to be opportunistic?
Maybe it is. It comes down to priorities and trade-offs. Just be aware that changing one thing inevitably changes other things.
The sweet spot is when process is treated as best practices, then mixed with a strong dose of trust and flexibility. Be clear about what you're trying to achieve and give the people closest to the work the freedom to decide how.