As individuals, we tend to each have our own way of looking at things and our own judgment of what matters. We can be very critical of our work and may only want to bring forward our very best. Well, isn’t that great?! What could ever be bad about being a perfectionist?! Shouldn’t I only present my best work?! Shouldn’t I always strive to make things better?! The answers to these questions are never simple, and will always differ based on the situation. A great leader should always be ready to guide others on how to answer these questions. Where we land on the scale of perfection could vary as we deal with different scenarios. Sometimes “good enough” is just perfect and sometimes “perfect” is not good enough! The art of leadership plays a big role in adding the right amount of strokes to create that perfectly imperfect picture.
As an individual contributor (IC), I struggled a lot as I was always concerned about making things better, whatever that was! I couldn’t easily see that “good enough” line and a lot of my effort went towards perfecting what was meant to always be imperfect. I created software solutions that lasted years and others that were simply thrown away. At the time, all I could think about was how to deliver the best possible solution even if it took twice the time of the second best solution. I was always so close to the picture that it looked visibly flawed most of the time. I couldn’t understand why some leaders didn’t see the same imperfections as I did. It was simple, the devil was in the details and they couldn’t see the details from where they were standing. Here’s the thing, I was right and they were right! Seeing the flaws and making an effort to fix them is what made me a good IC, but also having my lead guide me on when the picture was good enough is what made them a good leader.
As a leader, I started seeing the picture from a different angle, an angle that allowed me to appreciate the value that ICs delivered and made me want so much more of it. I realized that some solutions required perfection, such as updating an authentication flow for a public facing application, and some solutions just needed to work, such as early prototyping of a new feature. Based on each situation, I would evaluate and communicate where we should be on that perfection scale. Recognizing when we’ve reached an acceptable solution to the problem is key towards creating a high-performing efficient team that’s always delivering the right amount of impact. Sometimes, we may need to actively call something done to tackle a much more important thing. I’ve had ICs say that we need to make things better by refactoring or redesigning, and that’s when I ask “what’s better about better?!”.
- Are we making things better to feel better about our work?
- Will ‘better’ save us time in the future?
- What are the consequences of not making it better now?
Answering such questions will prevent the team from falling into the trap of over-engineering or over-perfecting.
Now let’s do simple math! If a single IC happens to save about 5 hours a week by recognizing when solution acceptance is reached without over-engineering, then this would lead to a total of 6.5 weeks of saved time per IC year. Now imagine a team of 8 ICs that are all trained on how to efficiently and effectively deliver work, they would collectively save one whole year of IC time! It’s no wonder great leaders are known to be force multipliers. A leader that constantly helps the team stay focused on the bigger picture is a leader that is capable of multiplying the impact of the team and hence is a true driver of success. The faster you succeed, the faster you can build on that success. The faster you fail, the faster you re-try, and the faster you have a better chance of reaching success. With that in mind, now think “what’s better about better?”
While the fear of over-engineering or over-perfecting is a common trap that most people fall into, under-engineering is just as common. Under-engineering can often occur when there is lack of proper planning and can result in subpar performance, limited functionality, and a higher risk of failure. In order to avoid that trap, leaders should always strive to make the most informed decisions based on the experience and expertise of their team. For example, under-engineering an API design can create costly consequences in the future as changing an API structure post-release is never smooth. It is important to strike a balance between cost-effectiveness and meeting the intended purpose and requirements to avoid under-engineering or over-engineering problems.
A “perfect” looking picture is what any successful leader is after. However, perfection is a gradient of colours, and a good leader is one that can see and accept imperfections in effort to focus on the bigger strokes that will make the imperfect picture seem perfect!