login


Google Sign inLinkedIn Sign in

Don't have an account? 

Managing a Perfectionist: A Lesson Learned the Hard Way

Underperformance
Internal Communication
Feedback
Firing

27 June, 2020

Krzysztof Zmudzinski, Director of Engineering at Egnyte, recalls how he handled -- with much difficulties and frustration -- a perfectionist on his team.

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.

Related stories

Some Ideas for Breaking Down Silos In Your Organization
30 June

Jeff Foster, Head of Product Engineering, shares how he managed to break down silos in his organization by encouraging their employees to choose their own team.

Team reaction
Managing Expectations
Company Culture
Internal Communication
Collaboration
Productivity
Reorganization
Jeff Foster

Jeff Foster

Head of Product Engineering at Redgate

Prioritizing Tech Work vs. Product Work: The Incomplete Story
30 June

Jose Pettoruti, Director of Engineering at CurrencyCloud, shares some tips on how to prioritize and balance tech work with ever-emerging new features by working closely with the product team.

Collaboration
Internal Communication
Jose Pettoruti

Jose Pettoruti

Director of Engineering at CurrencyCloud

Asynchronous Written Communication: How to Make It Work
30 June

Jose Pettoruti, Director of Engineering at CurrencyCloud, describes how to handle multiple inputs from a number of people in an asynchronous mode.

Remote
Internal Communication
Jose Pettoruti

Jose Pettoruti

Director of Engineering at CurrencyCloud

Why Psychological Safety Is More Important Than Ever During the Covid-19 Pandemic?
30 June

Murali Bala, Director, Software Engineering at Capital One, discusses the importance of psychological safety emphasizing its unparalleled significance during the Covid-19 pandemic.

Remote
Feedback
Team reaction
Feelings aside
Company Culture
Internal Communication
Murali Bala

Murali Bala

Director, Software Engineering at Capital One

How to Lead your Leaders
30 June

No stranger to the meaning of team unity, Kowsheek Mahmood, Principal and CTO at Archetype, demonstrates the necessity of aligning goals and explicitly communicating needs.

Managing Up
Internal Communication
Leadership
Kowsheek Mahmood

Kowsheek Mahmood

Principal & CTO at ArchetypeTech

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.