As a manager, you want your staff to have a high bar for excellence; you of course don’t want people doing the bare minimum and hoping it’s good enough to satisfy. But not every project needs to be perfect, and if your team members are spending their time striving for perfection on things that aren’t especially important or high-profile, that’s time they’re not spending on items that have more impact. In other words, in some cases “good enough” really is good enough.
Here’s how you can get everyone be on the same page about when you do need to strive for perfection and when you shouldn’t.
1. Distinguish between what really must be perfect and what just needs to be good enough. For example, form letters that will be used with a broad audience or content that’s going up on your website should be polished – well-written, with your company’s voice, and no errors. But internal emails? As long as they’re easy to understand, they don’t need to be Shakespeare. A good rule of thumb: Things that will be seen by a large group of people outside your organization or by particularly important audiences or which will be reused again and again should get extra polishing time.
2. Be clear with your staff members that sometimes “good enough” is better than “perfect.” Conscientious employees tend to think that even if “good enough” is acceptable on a project, “perfect” would be better – but that’s not always true. Sometimes getting to perfect means that other work gets short shrift. And sometimes getting to perfect just doesn’t make sense, such as when you just need a rough outline to talk over before further work is done. It’s worth explicitly telling your staff that sometimes aiming for perfect isn’t just unnecessary, but even the wrong decision to make.
3. Encourage people to do deliberately rough experiments, with the goal of learning and refining from there. There’s real value in creating a culture where you test ideas quickly without putting in the time to get them 100% perfect, see what works and what doesn’t, draw lessons from your results, and then refine from there. Of course, that doesn’t mean launching an experiment to a massive audience; rather, you want to test it on smaller groups where the risk is lower. But doing that will give you far more freedom to road-test and then tweak, adopt, or jettison projects according real life results.