Plato Elevate Winter Summit has been announced (Dec 7th-8th)

🔥

Back to resources

Handling Strong Personalities on the Team

Managing Expectations
Company Culture
Legitimacy

12 August, 2020

Melby Mathew
Melby Mathew

Engineering manager at LinkedIn

Melby Mathew, Engineering Manager at LinkedIn, shares how he handled a dominant and vocal senior engineer by asking him to support his proposals with quantifiable data.

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Why Overloading Product Teams Never Work

23 November

Adi Purwanto Sujarwadi, VP of Product at Evermos, shares how he identified the symptoms of his overworked product team and worked towards defining conflicting priorities.

Managing Expectations
Product Team
Deadlines
Stakeholders
Adi Purwanto Sujarwadi

Adi Purwanto Sujarwadi

VP of Product at Evermos

How to Build Rapport With an Introverted Manager

17 November

Piyush Dubey, Senior Software Engineer at Microsoft, shares his journey of climbing up the career ladder through awkward times dealing with an introverted manager.

Managing Expectations
Internal Communication
Collaboration
Coaching / Training / Mentorship
Juniors
Piyush Dubey

Piyush Dubey

Senior Software Engineer at Microsoft

Managing Team Collaboration After an Acquisition

10 November

Han Wang, Director of Engineering at Sonder Inc., shares the ins and outs of working successfully with the other half of the team after a merger.

Acquisition / Integration
Large Number Of Reports
Company Culture
Performance
Han Wang

Han Wang

Director of Engineering at Sonder Inc

Creating a Cultural Shift for Effective Meetings: Building a Writing Culture

10 November

Han Wang, Director of Engineering at Sonder Inc., talks about adopting a writing culture for making team meetings more effective.

Remote
Company Culture
Meetings
Internal Communication
Collaboration
Han Wang

Han Wang

Director of Engineering at Sonder Inc

How Technical is Your Conversation?

3 November

Sambit Kumar Dash, Founding Director at Lenatics, shares an analogy-based technical conversation.

Managing Expectations
Product
Convincing
Users
Sambit Kumar Dash

Sambit Kumar Dash

Founding Director at Lenatics

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.