I'm not perfect, but I'm worth it
Adopting a "Done is better than perfect" motto in the workplace
I joined Facebook in May of 2011, marking my entry into the tech industry and setting the stage for a transformative journey. During my time at Facebook, the company's core values made a lasting impact on my career as an operator. While values can often feel hollow, at Facebook they were ingrained into the fabric of the company, displayed prominently throughout the offices as daily reminders of our expectations. One particular value that continues to shape my professional approach is "Done is better than perfect." In this piece, I will explore why embracing this mindset is essential for success as an operator in a rapidly evolving tech company.
Change is the constant
Change and chaos are constant companions in startup environments. A week's vacation can bring a whirlwind of new developments upon return. This is precisely why I advocate for a "done is better than perfect" attitude when embarking on any project. As an effective operator, it is important to have a solid understanding of the landscape, but also to possess a bias for action. In the fast-paced startup world, it is impossible to have a complete picture. However, by prioritizing swift execution, we can drive improvements within our teams and gather valuable feedback to iterate and refine our work accordingly.
This feedback is precious as it helps in validating your work and measuring its impact. It could reveal that your work is not benefiting the team, allowing you to adjust course. Consider the predicament of spending months on a project without adequate feedback, only to release it and discover it has no value. I've observed at startups that people who strive for a perfect solution often end up launching a change that is irrelevant due to significant shifts in the business during the time they spent crafting this solution.
I feel like I’m not having an impact
Adopting the “Done is better than perfect” mindset allows you to feel a consistent sense of progress rather than being stuck in an endless cycle. Battling the urge to attain perfection is a common challenge among operators. I've seen team members grapple with this – although they generate fantastic ideas, their slow pace of implementation prevents them from making an impact. This can lead to a sense of discouragement as they feel they are not moving fast enough and, consequently, not making a significant impact. This detrimental cycle can be disrupted by emphasizing completion over perfection.
How do I change my approach?
To implement this mindset, I prefer to segment projects into individual tasks or phases, ensuring continuous progress and timely delivery of components that add immediate value to the team. This approach works even when the overall vision has not yet been fully realized. Whenever you tackle a new project, spend some time strategizing not only the problem but also how you can phase it to expedite the launch.
If you're grappling with perfectionism, try this method on a project you consider low-risk. Compare the results with a perfectionistic approach, and evaluate the pros and cons. You might surprise yourself, or at the very least, you may challenge yourself to broaden your problem-solving approach.
I think tactically speaking (in software) the following things need to be true for you to ship to production more often:
1) Infrastructure - reliable, repeatable way of deploying new development into production environments, including reasonable amount of testing to ensure you're not deploying a "grenade" into customer's orgs.
2) Requirement clarity - you generally don't want devs guessing about what is "good enough", your approach to iteration should start with a product minded business person who draws that line, and conveys their thoughts in a legible way so devs can deliver + test the MVP. I've found Gherkin ticket format to be helpful in this regard.
3) Tendency for horizontal communication - something about waiting for executives to tell you what to build guarantees you're going to spend a lot of time waiting, teams who are directly involved in CX (product, customer success, support) should have the ability to decide when to deploy/rollback new stuff