Done Is Better Than Perfect

done_is_better_than_perfect

In school we are taught to target the right answer. I envision the math problem sets that encouraged us to show our work and neatly box the correct answer at the bottom – and we were ultimately judged on the basis of that answer. But in the fast-paced world of tech, that approach doesn’t exactly work. Beyond the question of “what is the right answer?”, we have an adage on my team that done is better than perfect.

“Move fast and break things” is the motto that enabled Facebook to grow so rapidly. In the context of moving quickly, getting something done in a timely manner and on paper can actually be more valuable than being 100% accurate. Usually, getting to that level of accuracy requires modeling or precision that isn’t necessary to make an informed business decision.

This is predicated on the idea that there is a right or “perfect” answer, which there usually is not. In the tech world, you’re usually trying to solve problems that haven’t been solved, or answer questions that have never been answered. Cranking away until you get the right answer when the solution can usually be discerned at 80% of the way there means you’re wasting time when you could be working on something else.

Of course, there are instances in which you precision is imperative: you might need to propose 1 exact number or finish the demo of a product. For the most part, having an MVP – a minimum viable product, is enough to propel you to the next step of whatever you’re working on. If you’re going to move quickly and keep up with the market, done has to be better than 100% right.

Advertisement
Done Is Better Than Perfect

Making A Mistake

giphy

Nobody’s perfect, as the adage goes (I beg to differ, but that’s another story). We all make mistakes both personal and professional, and hopefully we are not remembered or defined by most of those mistakes.  But making professional mistakes happen , as my friend @marktemple says, “you learn more from your mistakes than what you do correctly.”

Artfully handling mistakes in a professional setting, however, is a different set of challenges. For starters, there are two ways to come across a mistake.

  1. Discover it yourself
  2. Have someone call you out

1. If we dive into the first: discovering a mistake yourself, you might think this is the more favorable of the two outcomes. You’re clearly a keen observer who made a simple error. The moment you notice it, that feeling sinks to the bottom of your stomach and your mind starts racing.

In my experience, the best way to approach the situation is to tell someone right away. While your natural inclination might be to try to mask the mistake, you are likely to dig yourself into a bigger hole. Avoid this route at all costs: even if you might be able to make it out alive, it’s dishonest and almost always comes back to haunt you. The best person to notify is a supervisor, or someone more senior to you who is directly related to the project.

No matter how big or small the mistake, the ability to fall on your sword and admit fault will show not only humility, but also professional maturity. A manager will be happier to be alerted to the mistake so that he or she is fully aware of all of the possible outcomes. In addition, your manager will probably be able to help you navigate correcting that mistake. You’ll learn a lot from it, and will get professional credibility in the process.

2. Getting called out is slightly different, since you have less time to prepare. I’ve been in situations that involve public chastisement for mistakes, and others that have been subtle pings or emails nudging me in the right direction. It stings either way; but you have to brace for the fall.

The best way to handle a situation like this is first to listen, then to probe and make sure you understand the right answer, and finally make the appropriate or suggested changes. In most circumstances, apologizing is not necessary. We all make mistakes – and handling the feedback gracefully will make you stand out among your peers. Treat being called out as receiving feedback (more to come on this topic soon), and seek to understand what you did wrong and learn from it.

What not to do:

Under no circumstance should you ever get defensive or try to defend your point. If you’re wrong, it’s better to admit fault than to argue something fruitlessly. If indeed you feel you were correct, then it’s fine to stand up for your beliefs. But if it’s a matter of subjectivity, take the high road. The argument is never worth it.

Worst of all? No one catches the mistake until after the final version of the project, or never at all! You never learn from that error, and you run the risk of making it again.

What do you think? Let me know @ellenjdasilva or email me ellenjdasilva at gmail dot com

Making A Mistake