Why do we do everything we do, like creating new products, attending planning meetings, creating new processes, or writing articles? Because someone (we hope!) Thinks that each of these things is objectively good. And if everything is good, then collectively they are all… perfect? Unfortunately, the calculations don’t work that way.
Perfection does not exist. There is just one set of compromises that, for a particular purpose or observer, allows you to ignore the bad and focus on the good. As you try to achieve perfection by doing more things – all in an effort to avoid compromise – you end up causing harm. The overlap in costs outweighs the benefits, and the interactions between the solutions start to be strange and painful.
In other words, beauty is in the eye of the beholder… because trying to do something beautiful for everyone guarantees that it will get ugly.
It’s not a very original thought, okay, but it’s something I’ve been thinking about a lot lately. I work in software engineering at Zapier, something I’ll quote a few times below, but I think the lessons here are universal.
How the pursuit of perfection can create a monster
It all starts innocently enough. We are doing good things.
But we realize that there are all these other things that we should do too, so we try to do all the things. Finally, we create a monster.
We find ourselves in a trap from which we cannot escape.
Every meeting is good, so you have to attend. Every process is good, so all should be followed. Every tool is good, so we have to use them all. All features are good, so none can be removed from our products.
These trends mean, overall, that we may end up with very little time to build anything. Our products can get more complicated and we don’t have time to simplify things.
The result? The thin slices of productivity are further subdivided by the complexity tax. The fun parts of the product are obscured by the awkward parts.
[Read: How do you build a pet-friendly gadget? We asked experts and animal owners]
I do not have perfect respond to situations like this. It is easy for a team member to say you should be doing less, but it’s a lot harder for a team to agree on what you should stop doing. The “correct” subset, after all, is subjective.
And while you might agree, it takes time to simplify things. It’s ironic, but it usually takes a while to Stop do something. In software engineering, for example, removing a feature takes time because you have to remove the code, update your documents, etc.
That said, there are a few things you can try.
Try to be neutral in terms of complexity or better
If you’re asking someone to do something, think about how you can make their life easier, not just harder. It means asking potentially counterintuitive questions.
Is there a process you can delete to make room for a new process? Is there another task that you can at least put off to give time to build a new habit? If you ask someone to use a new tool, can you give time for training? If you’re already adding another new tool, can you just complete this transition first? When you hire someone, can you think of what they might remove and not just what they will add?
These are not obvious questions, but they are necessary. Make sure you ask them.
Recognize the math
It is not possible to do everything. The more you try to do everything, the more shortcuts you will take. You’re just going to check a box, and as a result, you’re going to create these weird overlapping circles that I showed you above. Or you’ll start doing things you shouldn’t even be doing.
Some tasks require waiting for other people to complete their Tasks. This is called the waiting time. There is some basic math involved here, which this graph shows well.
If you don’t trust math, there is a great video which illustrates this “resource use trap”.
If you don’t have downtime, the wait times are indeed endless. If you feel like nothing is happening but you’re really busy, it’s probably because everyone is busy waiting for each other. There are two solutions to this:
Have more idle time
Eliminate the need to wait
Both are important. You can never remove all dependencies, so you need to have some downtime to help each other out. But you want to remove as many addictions as possible, so that people can help themselves.
At Zapier, this reality has motivated some key changes: we are working to make different parts of our product less interdependent. This means that each team that has a service can make decisions on their own, so that they don’t have to wait for other teams.
But when you remove dependencies in this way, you really must remove them. If you break up parts of your product but the teams still consult with each other for every decision, you’ve just made the problem worse. You pay for more people to do the same job, but more slowly.
Sometimes you won’t have a choice. There will always be things that will require the cooperation of the teams. In other cases, the cost of inconsistency is too high. Therefore, you should reserve idle time for these cases.
Make explicit compromises
If you accept that perfection cannot be achieved and that everything you add will make things worse, then you can start to compromise.
It’s easy, if you have a problem, to think of the solution in isolation – to work as if you have endless time and energy for that solution. But you exist in the physical world, where there are constraints.
The desire for consistency has trade-offs. Teams can be free to ship what they want and how they want, or they can be forced to use a shared solution and follow a shared process. Sometimes you have to choose the latter, but you have to be aware of the impact it has. To ignore this means to accept an ad hoc mixture of chaos and deadlock.
Our product at Zapier is a good example. Our desire to have a unique product that fits every use case and every customer has tradeoffs. The product is a blank canvas, which can make the value proposition difficult to achieve. We continually balance ease of use with power.
One option for us might be to create specialized products that are easier to understand. The problem, of course, is that it would mean more complexity in our documentation, our support tools, our integration, our organization – the list goes on. These products also may not always fit together well and customers may be confused.
This compromise is fine, as long as we are explicit about it and everyone understands it. If we want to avoid this confusion, we should invest more in a consistent experience for our users, which is another trade-off because this is the time we can’t use to create more products.
I could go on. The desire for planning, visibility, and metrics also comes with tradeoffs. We do these things to make better decisions, that is, to perfect compromise. But there are no perfect decisions. Sometimes we just need to recognize the math, promise to be complexity neutral, and plan for a potential rollback if things go wrong.
Published March 10, 2021 – 08:06 UTC