I spoke once with a highly skilled engineer who wanted to get into management. 

He saw the position as organizational in nature. Managers: 

  • Define what needs to get done
  • Delegate tasks
  • Review them
  • And that’s basically it 

But that’s far from reality. 

When you transition from engineer to engineering manager (EM), you shift from dealing with technical tasks to working with people. And, as you probably know by now, most problems EMs deal with ultimately come down to the second one. 

A big part of this is navigating the very different personalities on the team. 

1 - Personality is not the problem

Diversity is an important consideration for your team and results. However, I’ve found one kind of diversity the most important. It’s not race, gender, or country of origin, though – it’s the mix of personalities you’ll be working with.

But this is tricky to realize when you first step into the EM role. Because, as an engineer, you’re used to working with systems that don’t change.

An example

Take an API, for example. Every time you send a call, you get the same response, no matter how many times you do it or on how many separate servers. 

So, as an engineer, you get used to this consistency. Since that’s your primary framework, you expect the same when you’re an EM. For example, you may think working with two backend engineers proficient in Node.js will essentially be the same experience.

But these are two entirely different people, and people aren’t systems. 

One of them might be more independent and self-guided, for instance. So, they’ll want to solve problems with a minimum of interference. And the other might need more hand-holding and affirmation that they’re on the right track.

This is not to say one is worse than the other, though. In fact, I don’t believe there is such a thing as a bad personality. After all, the one in need of more assistance and attention could produce the better results of the two.

The point is that everyone has a different personality and approach to work, and that’s not a problem. The problem is when someone doesn’t understand this and fails to manage the different personalities on their team appropriately. 

This is a misstep that can have disastrous results, leading to:

I know because I’ve seen all of these myself.

So, as an EM, you have to take personality into account when working with your team. And this is no more imperative than when giving critical feedback.

2 - Your feedback has to match the personality

Some people are like flowers. They add an incredible amount of life and vibrancy to a room. But if you apply too much pressure, they collapse and cease to function anymore. 

This kind of personality naturally interprets critical – even if constructive – feedback as a personal judgment. So, you can’t give them the same kind of blunt criticism you might give others. Instead, you should cushion what you say with positive feedback or a reminder that the problem at hand isn’t the end of the world. 

Other team members are fiercely resilient. They get offended at the hint of any sugar-coating and perceive compliment sandwiches as an affront to their independence. They have tough skin and want to show it.

In short, the task here is twofold:

  • Knowing your team
  • And giving them feedback in a way that makes them receptive to the purpose of the feedback

The problem is many EMs think this weakens the feedback they’re giving, or it may be difficult for them to give certain types. So, the key is remembering that adjusting wording or tone doesn’t have to change the core message, and you will get more comfortable with difficult feedback through practice.

An example

As an example, say you need to tell an engineer they’re producing too many bugs in their work. First, schedule the conversation, then prepare ahead of time and practice what you’re going to say. See how it sounds out loud and consider how you’d receive it if you were in their place. Then, adjust as necessary.

Maybe you start off with something like, “You’re producing too many bugs, and this is causing many delays for the project.” But if you know this engineer doesn’t respond well to blunt feedback, you can change it to something like, “I’m noticing a lot of bugs in your work. Normally, I don’t, so has something changed recently?”

The core message remains the same, but you have an improved chance at a better outcome since you’ve changed the wording based on their needs.

3 - Not everyone wants to connect beyond what’s necessary

Some people are perfectly fine having an entirely professional relationship with you. They build and maintain a solid boundary between what happens at work and outside it. 

You’ll also work with some people who hate small talk or even to turn on their cameras during meetings. The best you might get is fifteen minutes’ worth of informal conversation a month – going for more can feel artificial, forced, and tense.

But there are also others where a lack of connection can produce the following conversation: 

  • Them: “Are you unhappy with me?”
  • You: “Not at all. You’re doing great.”
  • Them: “But you haven’t talked to me in a month!”
  • You: “Should I have? We didn’t have anything to talk about.”

As with giving feedback, everyone has different connection needs based on their personality. Learning who they are and how they feel about and respond to connecting with you determines your actions. 

For instance, you’ll be able to plan how often (or how rarely) you need to schedule one-on-ones and what and how much you discuss within them. And don’t be upset if engineers don’t want to connect with you beyond what’s necessary. You’ll have enough responsibilities to manage, so use shortened meetings to save time for other work.

4 - The work also has to match the personality

One team member might love going deep into their tasks – this makes them an amazing engineer, and they can do really complex things. But this also means they likely find it hard to pay attention to deadlines and regularly finish their tasks late.

On the other end of the spectrum, you might have someone who’s naturally punctual, so they’re great at deadlines. But they may be less motivated to go the extra mile with a task. As a result, their work could require refactoring later.

Treating these personality traits as correctable mistakes will drive you crazy. You need to accept them as part of the people you’re working with and not take it personally. Instead, treat them as strengths and get tasks assigned that play to those strengths.

Another way to think about this is by pretending your team members are tools in a toolbox. You wouldn’t use a hammer like a drill, for example.

Of course, you’ll need to coordinate with your project manager (PM) on this. They’re probably not aware of the personalities involved and likely need your advice. And don’t think you’re intruding – they’ll be grateful for the help to keep the work smooth and efficient.

5 - Clashes will happen, so be prepared to step in

Unfortunately, diverse personalities can lead to misunderstandings among team members. 

People have their own:

  • Ways of doing things
  • Values and ethics
  • And communication styles

An example

So, imagine you have someone on your team who wants to quit because of a personality clash. You have a senior engineer with a lot of experience and very high standards. She demands a lot from herself and others. 

Now, imagine you have a mid-level engineer with a different personality and values. For example, his standards are less perfectionistic but still within the norm. 

Because the senior engineer has a very direct personality, she calls out the other engineer for “dumb” mistakes. The mid-level engineer views the senior one’s behavior as toxic – it makes him want to quit. 

When intervening in a situation like this, you can’t just think about the mistake that was made, though. Instead, you have to consider the situation as a whole and the personalities contributing to it. 

This means speaking to each side in a “language” they’ll understand, such as with giving feedback. For example, the senior engineer may need to hear about the practical consequences of their actions and learn to balance perfectionism with pragmatism. And you may need to translate their feedback into a less “toxic” tone for the mid-level engineer.

Don’t worry if you don’t get this right at first, though – managing different kinds of people well takes time. But don’t neglect this task, either. Failing to make it a priority means spending even more time, energy, and resources hiring and training replacements.

The short version: adapt to them, not to you

As an EM, you’ll not only oversee technical tasks. You'll also need to manage your team, paying attention to how they interact with each other and approach their work. This means being aware of their personalities and how they impact team dynamics. 

Doing this means keeping the following points in mind:

  • Personalities aren’t the problem: Different personalities happen, and there are good and bad parts to each. The problem is not adapting to those personalities to get the most out of them.
  • Feedback has to match the personality: People receive negative (and positive) feedback differently depending on their personality. So, learn who you’re giving the feedback to and adjust accordingly.
  • Not everyone wants a stronger connection: Some people just want to get their work done and go home – others want to talk about elements from their personal lives. Know who is who and, as with feedback, adjust accordingly.
  • Work also has to match the personality: Some people produce higher quality work but miss deadlines – others do the opposite. Work with project managers to match the right person to the right task.
  • Clashes will happen, so prepare to step in: Different personalities rub against each other – you can prevent some of this, but not all of it. So, accept that it’ll occur and intervene when needed.

Knowing how people’s personalities work doesn’t only help you resolve problems as they emerge. It helps you get to know your team better and build better, healthier relationships with them. It also helps you resist the tendency to approach your team with a one-size-fits-all approach.

Want more tips on leading effective software engineering teams?

Join my newsletter if you’ve found this content useful

Originally published on Medium.com

Content in this blog post by Alex Ponomarev is licensed under CC BY 4.0.