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?”
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Vadim Antonov, Engineering Manager at Meta, dictates how he brought a brand new team into the remote learning process by ramping up onboarding and creating a mentor system.
Engineering Manager at Facebook
Vadim Antonov, Engineering Manager at Meta, details his journey to improve his personal hiring process and team pitch.
Engineering Manager at Facebook
Vadim Antonov, Engineering Manager at Meta, details his process of implementing an organized execution system for his cross-functional team.
Engineering Manager at Facebook
Anurag Jain, a leader at Fortinet, discusses his strategy to promote growth within his teams, using servant leadership concepts.
Leadership Role at Fortinet
Andrew Tsui, a Product Leader, works to build great teams that are independent, demonstrate mastery of their domain, and fully commit to their purpose.
Director of Product at Startup
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.