Handling Strong Personalities on the Team

Problem

We had a strong personality engineer on our team who was very dominant and vocal and thus influencing other people on the team. He was the longest-serving person on the team and he knew the system in and out.

Whenever there was a problem, he had ideas about what an ideal engineering system should look like; he was never happy with the code and was always proposing a number of changes. If the management would ask for a new feature, this person would refuse to move forward explaining that he should fix first all the problems in the code before starting working on something new. He was overly concerned with tech debt and always aspiring towards the ideal code. But due to his domineering personality, everyone else on the team was taking his opinion for granted and avoided confronting him.

Since our project was dealing with taxes and filings any type of mistake could have detrimental implications on our customers who would end up paying penalties, additional fees, etc. However, what I noticed was that his obsession with tech debt and never-ending work on the code resulted in him inadvertently adding bugs into the code during the cleanup because we didn’t have enough test coverage. We would have to then do remediation and discuss how to solve those problems while also paying off fines and doing re-filing for our customers. Part of his personality was also to take grave mistakes very lightly and as a new lead, I still lacked the complete picture on how his behavior was impacting our work.

Actions taken

It took me a while to understand the problem in its complexity. I initially allowed tech debt to be addressed as he proposed, but then after a while I had to confront him because of all the fines we had to pay and all the additional engineering effort we had to put to rectify the problem caused by his fixing of tech debt. Moreover, I had to repeatedly address the problem of his overbearing personality and its effect on the business. Therefore, I asked him to come up with a foolproof strategy for a tech debt before we would move forward fixing tech debt and the clearly showcased value his actions had for our customers. Not all tech debt is of the same value to customers -- did it save their time or their money and how that influenced our business is what matters.

At the same time, I had to repeatedly talk to other people on the team and encourage them to voice their opinions. I was trying to explain to them that, though addressing tech debt was important, if we couldn’t attribute a value to it in terms of time, dollar, or effort amount, we wouldn’t be able to go forward with it.

His personality continued to cause the ongoing tension and I had to engage in the same type of conversation over and over again. He would come up with new ideas about how to fix the code and I would have to again ask him to calculate the amount of effort, make a foolproof strategy, and come back with a request for proposal. I would instruct him to come up with the exact data and to deliver a brief proof of concept before I would approve any action on his part. By adding those due diligence steps I laterally introduced roadblocks for him to carefully dissect problems he wanted to fix and prioritize them. This approach served a twofold purpose: it slowed him down and made him pay more attention to some areas he neglected in the past. As a consequence, we were able to make progress on a feature side of things while safely making progress on tech debt.

Lessons learned

• I am certain that every manager will encounter in their lifetime a similar situation of a domineering engineer who would have strong opinions and influence other people on the team. While I don’t have a silver bullet solution to offer and every person needs to be approached differently, I strongly believe that they had to be confronted and made accountable for their doings.
• Always do due diligence in the form of impact analysis. When I joined the team, as a newly arrived manager I trusted people on the team to inform me of the impact. I didn’t delve into all details inquiring about our test coverage, for example. You should do due diligence, but so should your engineers. Ask for data and estimates rather than taking their words at face value.
• As a new manager, I was careful not to annoy anyone on the team and would often take their word for granted. I would ask them if something was safe instead of asking them to provide proof that something is safe. Oftentimes they would overlook some impacts, and I didn’t go deeper to double-check it. If you are new to the team, sit down with your engineers, and carefully analyze impact without fear that you will be disliked for pushing accountability standards.
• We have to demonstrate the exact value before we move forward with any project. That would save us a lot of time, is not a valid argument; a valid argument would include quantifiable data extracted from a ticketing system. For example, last quarter we had 34 bugs each taking around two hours, altogether that would save us 68 hours. This also helps engineers grow and be able to advocate for their proposals, but it helps you as a manager to make your case before leadership.