Finding matching engineering personalities
6 December, 2017
I inherited a team with an engineer (I'll call him Paul) that had previously received a lot of good feedback. However, he had found that his performance reviews were beginning to contain more negative feedback. The feedback said that Paul was slow and that he provided inconsistent results when he was pushed to deliver quickly. Paul was typically very methodical, and would research for a while before doing his work. He would always ensure that he understood a domain, and he delivered code that worked reliably. He didn't understand why he was receiving bad reviews, even though he was working as hard and as methodically as he could. He was very frustrated with his previous managers always rushing him and with the negative performance reviews. When asked about his strengths, Paul was adamant that he was better than at least half of the broader team, and that his leadership skills were vastly better than most of the others in the team.
I listened to Paul's concerns and got to know the broader team. It became clear to me that the work styles of Paul and the rest of the team were fairly different. To help Paul to understand why his hard work wasn't being respected, I used the Amazon Leadership Principles as a guide. I asked him to first rank his leadership style against the leadership principles. To prevent Paul from scoring himself strongly for all of the leadership principles, I gave him the option of placing three "A', three "B" and three "C" scores against the 14 leadership principles. This forced him to think about what he felt was most important, as well as where he felt he performed well. The leadership principles that he felt he was strongest at were "Dive Deep", "Are Right, A Lot", and "Learn and Be Curious". His self-scoring matched fairly well with his observed behaviors. However, this did not sufficiently explain his performance reviews. Once we finished discussing his leadership strengths, I asked him to look at the leadership principles that he felt the organization felt strongly about. As he worked through them, I provided my opinions as well. This allowed us to have a more balanced view of the organizational bias. The leading leadership principles for the organization were "Deliver Results", "Bias For Action", and "Have Backbone; Disagree and Commit". The Amazon leadership principles are designed so that there is tension between the different principles. This forces leaders to consciously find a balance between the different leadership principles and to modify their leadership behaviors in a situational way. In this case, it became very clear that Paul was not being sensitive to the leadership principles the organization valued. Instead, he was applying his personal style, while not paying attention to context. This mismatch resulted in ongoing frustration for both Paul and the organization's leadership team. Paul still struggles with modifying his working style to suit the organization's values. It's likely to continue to be an ongoing challenge for him to adapt. In a different organization, Paul's engineering personality might be more highly valued.
There are a few lessons that can be learned from this example. 1) "Cultural" Fit - Matching engineering personalities Most people cringe when there is a discussion about cultural fit. Cultural fit isn't so much about Gen X vs Millennials. It is more about the organizational norms that engineers are expected to follow. Using a broad set of leadership principles such as Amazon's, or the strengths found in Strengthsfinder, allows you to gain a deeper insight into how successful an engineer may be in an organization. If an engineer is a "Dive Deep" kind of person and requires two weeks of "thoughtful learning" before touching code, there will always be a conflict if an organization has a preference for "bias for action" and "learn through experience" behaviors. I feel strongly that both group and individual biases are critical for ensuring a good "fit" in a team. If the fit isn't there, performance reviews will suffer, and there will be a general sense of frustration. Getting an engineer to think about both their engineering personality, and that of the organization, is very important in helping them to determine their short and long-term fit within a team and how likely they are to be successful within the team. 2) Cognitive bias - illusory superiority The initial challenge with Paul was that he saw himself as one of the stronger engineers within the team. When asked about his strengths, he said he was stronger than average in terms of most of the leadership principles, and when asked to think about where he would rank himself amongst his peers, there was immediate pushback. Illusory superiority is a cognitive bias that makes someone feel like they are better than others. Usually, this is not a character flaw, but it can cloud someone's ability to objectively see what is occurring. To attack this bias, it's generally useful to force ranking by some mechanism. Forced individual ranking will usually meet resistance, but allowing clusters of ranks will generally allow the higher ranked behaviors come to the surface.
Himanshu Gahlot, Director of Engineering at Lambda School, shares how he used his own learnings to support his direct reports and help them grow in their careers.
Director of Engineering at Lambda School
Pete Murray, Principal Software Engineer at Electronic Arts, discusses what makes one a great engineering leader and singles out creating opportunities and motivating engineers as two key characteristics.
Principal Software Engineer at Electronic Arts
Pete Murray, Principal Software Engineer at Electronic Arts, explains how he successfully solved a long-troubling problem by applying a root cause analysis.
Principal Software Engineer at Electronic Arts
Michael Mac-Vicar, CTO at Wildlife Studios, dissects how to set guardrails that would contain the exponential increase in cloud costs.
CTO at Wildlife Studios
Mason Mclead, CTO at Software.com, explains how a primary job of an engineering leader changes as a company grows and how he felt that merely managing people is not the role that fits his aspirations.
CTO at Software.com
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.