Managing Different Personality Types: No “Golden Rule”!
30 May, 2020
Like many engineering managers, I first got into the role because somebody in the group had to do it, and there I was -- so I wound up doing a lot of learning by experience and managing by common sense. Naturally, I often followed the Golden Rule of treating others as you want to be treated as it embodies respect and good intentions. This worked great as a lead in a team of essentially peer developers; I could easily anticipate what others needed (for example to not interrupt coding “flow” with meetings) simply by putting myself in their shoes and drawing on my own experiences on the front line.
However later in my career, as I began to be in charge of more diverse teams, this became more challenging, and I had to develop less subjectively-based management approaches.
A key learning experience occurred when I was hired to direct a portfolio of teams working on advanced projects intended to push the boundaries on multiple technologies (eg VR, web authoring tools, cryptography-enabled applications, AI, etc). These teams were assembled from different groups of contributors across the company, and included a broad cross-section of skills and experiences; some were researchers, some had a product focus. If there was any core trait they shared it was simply a passion for innovation, and so I resolved to adopt a “low touch” management style for our group that underscored respect for their individuality as “wild talents”.
Following the golden rule, I then gave them all lots of space to create and develop great new stuff. I emphasized my trust in them as professionals and to show my commitment provided only the minimum of process and direction, just checking in, avoiding micromanagement, optimizing interactions, and eschewing generic meetings -- in short what I assumed from my own experience would be the engineering ideal.
However, I noticed that one particular individual began to seem insecure. While other engineers headed off in their own directions, readily getting into the state of flow, he actually seemed to be troubled with my less-directive approach and increasingly sought reassurance and facetime. Rather than becoming more empowered to take initiative to innovate, as I had assumed everyone would, he initiated more conversations. I was concerned and puzzled: it seemed the more I demonstrated that I trusted him the more anxious he became!
Trying to “debug” the situation, it began to dawn on me that this individual, unlike the many senior programmers on the team, originally came from a technical support background. I began to wonder whether this was somehow related and began to look for root causes.
Serendipitously, a mentor introduced me to the Myers-Briggs Type Indicator (MBTI), a framework that attempts to categorize differing psychological preferences in how different people perceive the world and make life decisions. Like a kind of psychological “zodiac”, MBTI posits a vocabulary of 16 personality types. For example, most engineers and technical people -- including myself -- tend to fall into their so-called “intuiting-thinking” core pattern. But others exist, such as “sensing-feeling” and so on. The hypothesis is that, in order to interact well with each other, we can discover and adapt to the differing needs and styles of each person’s type.
As I read more about the Myers-Briggs system a light dawned. For example, the typical technical personality (like me) was described as tending to prefer just enough feedback to be sure that s/he is on the right track, but, paradoxically, too much praise makes him/her feel uncomfortable. If you go overboard, (as for example extroverted businesspeople sometimes do -- check out your next all-hands!) it actually creates a negative vibe for many engineers.
So it began to dawn on me that this person fundamentally was not motivated by the prospect of slaying technical dragons, but by a love of doing things for other people. For example, he’d brought in his espresso machine and liked to make custom coffees for everyone in the morning. Unlike us geekier creative technical types that want to be left undisturbed to labor until at last, they can “bring fire down the mountain”, he thrived on daily human interactions.
I realized then that I was applying the golden rule too simplistically: treating him as most engineers (and I) typically wanted to be treated, was not right for him. By striving to minimize interaction by applying a “fair” one-size-fits-all management style I was actually starving him of what he needed most to grow and prosper as a human being.
This insight enabled us to refactor his role, to customize it to his actual profile -- structuring it around more incremental deliverables with more opportunity for social interaction. This reduced his anxiety and allowed him to contribute more effectively.
When managing people, try to determine the value proposition for each individual. Be aware that there is a variety of things that motivate people and influence how they understand and interact with the world. Some individuals fall near different ends of the various spectrums. You should take care of the outliers and ask yourself what is unique about them. For example, some technical people can be remarkably critical and you should strive to appreciate that perfectionism so that you can use it in the best possible way by channeling those insights constructively. On the other hand, someone who seems lackadaisical can be a resource for thinking outside the box.
Wield the Myers-Briggs personality types and other methodologies as you see fit, but if you do remember they are only tools in your management process, there to help you better understand each and every person, to help you optimize outcomes. Individuals are not categories. Regardless of what “type” a person “tests out as”, be mindful that s/he deserves to be respected and valued for the characteristics that make them uniquely themselves.
As a manager, regularly reach out to other folks (both on the team and outsiders) for feedback on people. We all perceive each other in terms of our own reference points and conceptual frameworks. People with different personalities will perceive things from diverse vantages. Pieced together, their different perspectives will deliver a more complete and vital picture of the individuals you manage than you ever can by yourself in isolation. One natural way to solicit this advice is to ask, “What do you think I can do to help X be more successful?”
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.
Head of Product Engineering at Redgate
Pierre Bergamin, VP of Engineering at Assignar, recalls his own transition to a leadership role in a new company and how he made everything smoother by embracing trust, delegating work and encouraging collaboration.
VP of Engineering at Assignar
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.
Director of Engineering at CurrencyCloud
Jose Pettoruti, Director of Engineering at CurrencyCloud, describes how to handle multiple inputs from a number of people in an asynchronous mode.
Director of Engineering at CurrencyCloud
Murali Bala, Director, Software Engineering at Capital One, discusses the importance of psychological safety emphasizing its unparalleled significance during the Covid-19 pandemic.
Director, Software Engineering at Capital One
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.