3 Types of Developers and How to Manage Them

A colleague once said to me that I’m very lucky I haven’t had to fire as many people as he had. I definitely agree with the fact that my management tenure has not involved many terminations, but I don’t consider myself lucky. I put in work, just like you’re doing, to understand how to manage different types of developers.

As a dev manager, it’s your responsibility to understand your team. Each one is different: they have different likes, fears, motivations, and measurements of success. The problems come when you start to bundle all of your developers into a single style or group. Or, even worse, if you expect that they’re all little versions of you. Far from it - and you should be happy! This diversity is what makes your team successful.

In order to manage and work with your team, it’s important to understand each individual character. There are many types of developers, but let me focus on just three today.

The Hero

The last time I fixed an issue that was affecting the entire company, I can barely describe the scene! There was a cake, music, a dance party. Did someone just release a bunch of doves? Wow!

Ok, well maybe that didn’t happen. But there’s something addicting about being the hero. The hero is the developer who can always come in and fix something at the last minute. They know everything about the systems. Without them, how would we have survived the panic of 2012!? Everyone loves the hero, including themselves.

But, are they an egotistical bottleneck?

First thing’s first, let’s talk about risk. The hero programmer introduces an extreme risk into your team and process. You most likely have noticed that you rely on them above all else. Other programmers will shy away because they know Mrs. Hero will be able to solve all of the problems. You might have also noticed that you change your leadership style or demands in fear that this person might quit.

The only cure for this is to pretend like they’ve quit effective immediately. How would you do projects without them? Get the hero out of the doing, and on to documentation and teaching. Others will step up, things will get solved anyway, and the botttlenecks will start to go away. Once you both realize that you should be moving some of this work to the rest of the team, things will progress much faster.

The second, and even more important thing to deal with, is the built up ego of the programmer. Remember, Mrs. Hero has been solving the businesses problems - maybe even before you joined the company. They’ve likely built up meaning in this trait, how it relates to the job, and self worth. So, you can’t come in, rampaging away, and completely extract them from this role and responsibilities. It will destroy them, make them resent you, and they may irrationally decide to abandon the company.

What makes the hero so magical is the way they’ve learned to digest information, reformulate it, and use it to solve problems at a speed that seems inhuman. What’s great about this is that those skills transition to other areas of the process, not just emergency triage. The hero needs to continue to have an impact. They’ve been in an important role, they need to continue to feel important.

Hero programmers can be transitioned to proof-of-concept developers, researchers, and people who stretch boundaries. Put them on the bleeding edge. Use their ability to digest immense amounts of information and formulate solutions before anyone else to fuel your innovations.

The Martyr

“Everything is the worst.” I received this message from Shelly* one Monday morning. She was convinced that we’d never finish the project on time. I can’t say I was surprised by her attitude. She normally seems pretty negative about our projects. I’ve noticed that lately that most of my team seems to be agreeing with her.

That’s when I figured out she was The Martyr team member. The Debbie Downer, the Negative Nancy, the Sad Sally, the Morose Molly, the… ok I could go on, but you get my drift. She really thinks everything is the worst.

The more I thought about my interactions with her, I realized she not only felt negative, but seemed to think that we were all doomed to failure. This was not good.

The Martyr is a hard personality to manage. I’d say you have a 50/50 chance of turning this around (most people I believe can be worked with - but the martyr, the negative mindset, is a cancer to the team).

The key to working with this developer requires two steps. First, you have to be very direct, very calm, almost emotionless. Explain that the attitude is negative and that it’s contagious. It’s clear something is bothering he or she. The next step is to ask what we can do to make a difference. The answer to this question is the key to whether this developer stays with your team.

If The Martyr gives you some reasons or steps that will make things better, you have room to work. It doesn’t matter if the reasons are ‘real’ or they’re something you can control. The fact that they gave you reasons means there’s hope. You can work with them to address, manage and change things.

If they can’t put into words why everything sucks, they probably aren’t a good fit for your team anymore. Sometimes depression manifests itself into the martyr attitude, though, so I also suggest you recommend they work with your HR department to get assistance. But, you should make it very clear that their negative attitude is not building up the team or adding to the team’s success.

The Insubordinate

“Man, this guy is pissing me off!” I thought to myself. Every time I asked Jordan* to do a ticket in Jira, he ended up doing something really different. He wasn’t listening to me! I’d ask him to do write a new feature, and then he’d upgrade our whole infrastructure. I’d tell him to fix a bug, and before you knew it, he added a new feature!

How could I justify our progress to upper management. “Your other features are behind. But, we did add this new feature you never asked for. By the way, it’s going to generate more customer service requests. Ok, thanks!”

I was reaching my breaking point. Maybe it was time to fire Jordan. He was being insubordinate.

The problem was, though, he’s just so damn smart. If I got rid of him, my team would have a huge technical hole. I couldn’t fire him, but I can’t have some programmer doing other things against my will.

I decided it’s time to have a talk with him. I brought up the Jira board to look at his open tasks. Clearly, he had to have a ton of them if he was being disobedient and doing other things.

Not a single one open. All complete and deployed.

It was in that moment that everything clicked for me. Jordan wasn’t being insubordinate.

He was bored.

I wasn’t challenging him enough. He was one of the most technically proficient on my team. I’d assign him tasks that I thought should take up his day, but he finished the tasks in a fraction of the time I’d expected.

I expected he’d ask me if he finished early for more work. But, I just assumed that. Turns out, he’d finish his work, then go exploring on new features or handle tasks that he thought was best for the team.

He was bored because I had left a vacuum.

Is your insubordinate developer actually being disobedient? If so, what measures and metrics are you using to prove this? Have you set your expectations properly? Are you challenging them?

Jordan became one of my most prized colleagues then (and still is now) because I learned to challenge him. He was smarter than me, so I needed to give him (what I thought to be) overwhelming work. He sped along and did all the things I told him to do. Now, he was motivated.

Before you jump to a conclusion that your developer is a bad seed, you need to reflect a little bit more on the situation. Are they causing you a problem based on malice or based on your vacuum?

Attend to your different programmers

“Always remember you’re unique, just like everyone else.”*

~ Red Green (or Jim Wright - why am I so bad at picking quotes?)

You are unique, intelligent and learning to do your job better. A step above the rest (that’s why you’re reading this newsletter, right?) You’re certainly different than other managers who don’t care. But remember, each one of your developers is unique and different, too. It’s your job to understand that and apply this knowledge to your leadership.