Managing a Perfectionist: A Lesson Learned the Hard Way

Problem

A few years ago I was working at the same company with a senior engineer who was considered technically very skillful but hard to work with. He was a perfectionist when it came to technical details of the job and according to his own words, someone who wanted to follow the best practices regarding software development. He would always choose the best technical solution over any business outcome and had struggled to deliver tangible business value on his previous teams. Nobody felt that it would be a good idea to fire him due to his technical talent but he kept being reassigned from one team to another. My team remained the final resort.

At that time I was working on a brand new product with a small team of only seven or eight people on a tight deadline and when my manager asked me if I was willing to take him on my team I agreed to give him a try.

Actions taken

Before anything else, I met with him to discuss his past performance and his reputation and to set clear expectations for the future. I stated that my key expectation for him was to deliver business value. Indeed, our working environment was not ideal -- requirements were vague and there was a lot of pressure -- but it was a befitting opportunity for him to prove himself. I believe I was absolutely clear regarding my expectations and he seemed to have complied with that. I also wanted to get my team on board with the idea, especially that they were familiar with his reputation so I anticipated some potential tension. I used one-on-ones with my direct reports to discuss this opportunity. They were initially skeptical but eventually accepted the idea.

The perfectionist engineer was assigned to work on a new product and it was of utmost importance to be pragmatic and cut corners in order to meet tight deadlines. The team understood the situation very well; they were ready to sacrifice perfect solutions for meeting deadlines. After a few weeks, I noticed that things got stuck on code reviews and the team members were expressing their concerns that their perfectionist colleague was causing it. He was very picky about code reviews and testing of the product and was questioning many technical decisions. If we’d had more time we would have agreed with his proposal, but that was not the case. In addition, he was constantly focused on secondary items, not the product itself.

I realized things were not going well, but I hoped to correct some of the misunderstandings during our one-on-ones by providing him feedback and instructions for improvements. I recall referring to our initial discussion when providing business value was established as the main objective. At the same time, his team members were getting more and more worried. In general, I dislike micromanaging and the team was doing great self-managing themselves applying Agile methodology and deciding which tasks to prioritize. However, considering the gravity of the situation I switched to micromanagement mode since we were approaching the critical phase of integrating two pieces of product. Nevertheless, a conflict between him and another, more pragmatic engineer escalated and I had to become involved in mediation. At that time, I was repeatedly getting signals from my team that they were tired and frustrated with this individual.

I had no other option but to remove him from the team. I got HR involved and we organized a meeting with him to recap the last few months and compare the initial commitments with the current setup. We had three weekly meetings that ended up in a mix of denial, surprise, and accusations for mobbing on my part. I felt exhausted trying to fix something that was beyond repair. I was glad that I had gotten HR involved at the right stage because I got support from them and they made sure that everything was documented and they made the entire process objective as it was possible. Eventually, HR and I found a way to manage him out in a way that both sides were fine.HR found a way to manage him out.

Lessons learned

• Don’t be overly ambitious. I was aware of his reputation and I should have been more careful with taking on this opportunity. I was already under the enormous pressure of a deadline and having to build a brand new product with my team -- a demanding, perfectionist on my team was a distraction I was not able to afford. Know when to say no and pass the opportunity!
• I should have talked to his past managers and learned if he was given adequate feedback in the past. He claimed he had never been told that his insistence on ideal practices made him a person undesirable to work with.
• Certain types of personalities can’t thrive in fast-paced environments. Startups are not a suitable environment for perfectionists. Becoming cognizant of that impacted my future hiring and I adjusted my interview questions accordingly.
• Fire fast! Even if someone is a skilled engineer but not the right culture fit and has a negative impact on his/her peers, s/he shouldn’t be on your team. Especially, don’t assign him/her to critical projects, it could be detrimental on many levels.
• Involve HR to keep the process formal and transparent. I’m glad that I reached out to HR instead of trying to sort things out by myself. In general, I trust people and my main mistake was not to keep the paper trail of our one-on-ones and other internal communication. While it is time-consuming, keeping the paper trail will save you from future discomfort.