Alongside the well-known “Move fast and break things” sign at Facebook was another sign: “Done is better than perfect.” The fact that this phrase needed posting is a reminder of the ubiquity of most engineers’ tendency towards perfectionism over timelines.
I tend towards perfectionism myself, but I recognize that perfectionism can work against me and my team. People across my company, and outside my company, depend on me to hit my commitment dates. Trade show dates don’t move, so presentations and product introductions need to be ready. Clinical trial sites make a huge effort to arrange trial dates – coordinating a variety of hospital staff, and postponing normal activities – so clinical product needs to be ready on time. You get the picture.
So, what can you do about it?
Perfectionism is costly. Each incremental unit of effort results in diminishing amounts of improvement, reducing average productivity. That same effort applied to another set of tasks could create significantly more value. So perfectionism has both a real cost (diminished productivity) and an opportunity cost (other unfinished tasks).
In engineering school, we were all on the same fixed timeline with the same assignments, so we were graded only on the quality of our work. In the real world, both quality and productivity are important. No one ever trained us for this. No wonder we tend towards perfectionism.
In real world engineering, the opposite of perfection is not sloppiness, but risk. If you don’t fully optimize a design, then some low severity, low occurrence risks will likely remain. Perfectionists reduce engineering risk to a lower level than necessary, at the expense of timelines. Notice that your smartphone apps are constantly being updated. App developers get the app out the door, even though they know that some bugs remain. They can make it better in a later release.
If your company has competitors, both quality and speed are necessary to win the market. If you’re the first in your market, quality and speed help you dig the deepest moat*.
Done is better than perfect. Managing your own productivity is an ongoing process, not an easy fix. Here are a few techniques you can use to tame your perfectionism and hit your commitments more often.
1. Recognize perfectionism in yourself and make a commitment to explicitly manage it. Do you have trouble meeting commitments and hitting dates? How is this affecting your professional reputation, and your manager’s perception of you? If you aren’t sure, ask your colleagues or your manager.
2. Set interim milestones. Plan out your projects in more detail. If you don’t hit your earliest milestone, you’ll never get your project done on time. Arrange meetings to present your interim work. Make public commitments to milestones, and you are more likely to get them done.
3. Work with a partner and coach each other. Athletes train with partners. Why not engineers? Your manager might be your default partner, but consider partnering with another engineer with the same tendency. Ask your partner to push you to hit your timelines, and coach you when you are going off track. Do the same for her.
4. Get started with GTD. http://gettingthingsdone.com/get-started/ ’nuff said.
5. Each time you execute a project perfectly, realize that you very likely went too far. Your colleagues commend your results, but they also know it took you forever. They wonder why you put in so much effort, when they needed you to work on something else. They know this, they feel you let them down, but they are too nice to tell you. So, I’m telling you.
6. Teach yourself to explicitly manage design risk. Ask yourself if the extra effort to reduce risk is really worth delaying a project. Test the top two concepts, not the top five. Rather than proving the root cause beyond the shadow of anyone’s doubt, recognize when you’ve found the most likely root cause, and accept that there is a small risk that you are wrong. Stop spending time analyzing low-severity failure modes.
This blog post is far from perfect. But it’s done.
*Moat: see https://youtu.be/r7m7ifUz7r0 2:39
More in my series on Star Medical Device Engineers: