We've just launched plato for individuals

🔥

login


Google Sign inLinkedIn Sign in

Don't have an account? 

Finding matching engineering personalities

Underperformance
Company Culture
Productivity
Coaching / Training / Mentorship
Career Path
Health / Stress / Burn-Out
Feedback

6 December, 2017

An engineer in Matthew’s team didn’t understand why he was receiving bad reviews, as he worked hard and was used to receiving positive reviews. Matthew studies the engineer’s personality to understand the reason for the negative reviews.

Problem

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.

Actions taken

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.

Lessons learned

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.


Related stories

How to Help Your Reports Grow and Pursue Their Goals
27 September

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.

Coaching / Training / Mentorship
Career Path
Himanshu Gahlot

Himanshu Gahlot

Director of Engineering at Lambda School

What Will Make You a Great Engineering Leader
27 September

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.

Leadership
Personal growth
Coaching / Training / Mentorship
Pete Murray

Pete Murray

Principal Software Engineer at Electronic Arts

Getting From What to Why
27 September

Pete Murray, Principal Software Engineer at Electronic Arts, explains how he successfully solved a long-troubling problem by applying a root cause analysis.

Dev Processes
Productivity
Impact
Pete Murray

Pete Murray

Principal Software Engineer at Electronic Arts

Setting Guardrails and Containing an Increase in Cloud Costs
21 September

Michael Mac-Vicar, CTO at Wildlife Studios, dissects how to set guardrails that would contain the exponential increase in cloud costs.

Dev Processes
Productivity
Michael Mac-Vicar

Michael Mac-Vicar

CTO at Wildlife Studios

Changing Responsibilities In an Organization Undergoing Change
14 September

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.

Career Path
Mason Mclead

Mason Mclead

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.