A Difficult Software Developer so convinced of their irreplaceability that they adopt an attitude of arrogance that makes them impossible to manage.
- Can mutate into: “The Hostage Taker” or “Technology Enamored” Difficult Developer
- Dangerous when coupled with: “The Cheerleader” Difficult Project Manager
- Likelihood of fixing: High
- Danger to project: Low
Relevant Podcast
Problem
At some level, to manage someone, they have to do what you say. The Diva Developer cannot be managed because at their core, they do not believe they work for you, and instead that you have the privilege of working with them. They believe themselves to be utterly irreplaceable, and therefore believe that they hold all the cards in any discussion.
Contrary to their own belief, The Diva Developer is not necessarily a skilled developer (see “The Rockstar” Developer). Their arrogance is based on their view of themselves in the organization, not their actual technical skill. As a result, it is all too common for The Diva developer to rate their skill level much higher than that of their peers, when in truth it is not. This generally leads The Diva Developer to be disliked by their fellow developers.
To determine if you have The Diva Developer on your hands, you can look out for these common catch phrases:
- “That’s stupid – I’m not doing it like that.”
- “We should be doing it this way.”
- “If you don’t like it then you can talk to my manager.”
- “Well, we’ll see about that.”
- “I’ll go talk to your boss about it and see what they say.”
The Diva will not take direction. They consider any attempt to be managed as an insult, as they are above having to be accountable for their actions. The Diva problem personality is commonly found among long-time developers who were deeply involved in the companies early success. Now, years later, thanks to their long standing relationships with company founders, believe they are beyond reproach by a mere middle-manager.
The Diva does not represent a material danger to the project, as they typically do nothing but blow hot air. They are disruptive, however, and tend to have a negative effect on moral – especially among newer, more productive Developers. They must therefore be brought back in line in order for the project to flow smoothly.
Solution
The solution to The Diva Developer is to disprove their core belief: That they are irreplaceable and therefore can do whatever they want. The most direct way to disprove this belief is to hire their replacement to work closely with them. To adequately convey to the (most likely in denial) Diva that this is indeed their replacement, two conditions must be satisfied:
- The replacement must be better qualified than The Diva
- It must be made clear to The Diva that their replacement has no other job than to shadow and be trained by The Diva as their replacement.
The quicker the replacement is at picking up any legacy knowledge The Diva may possess (see “The Legacy Maintainer” and “The Hostage Taker” Developers) , the faster The Diva will fall into line. The effect can be dramatic, such that you may see a turnaround in attitude in only a few days. Ultimately, they are no longer irreplaceable, and therefore are no longer a diva – they are simply a bad employee.
The only hope The Diva then has of retaining their self-perception of status is to get promoted into a managerial position (see “The Aspiring Manager” developer). The more savvy The Diva, the earlier in the training of their replacement they will attempt to do this. Promoting them is ill-advised, however, as you will most likely see resignations from developers The Diva is put in charge of. Therefore, upon rejection of their request for promotion, they are left with only two choices: Fall in line with the other developers, or leave. In either case, your problem is solved.
I see these 2 sentences to be in complete contradiction (though juxtaposed):
“The Diva does not represent a material danger to the project, as they typically do nothing but blow hot air. They are disruptive, however, and tend to have a negative effect on moral – especially among newer, more productive Developers.”
A negative impact on team morale / atmosphere, preventing progress… this is a HUGE negative impact on the project. Projects with a robust culture are far more capable of overcoming other obstacles (such as technical); when people are demotivated (due to The Diva and a PM tolerating that), even relatively straight forward tasks become problems.
I’ve never regretted removing The Diva type from a team. Despite losing knowledge and talent, the results have always been better overall. Always talk first, but if that fails…
The key word in the first sentence is “material”, by which I mean what while they are annoying, and might negatively impact productivity due to their negative impact on morale, they usually can’t ruin the entire project unless there are other factors involved such as weak management. There is a general assumption I make in the “solution” sections whereby I assume there is management capable of applying the fix, but I accept that this is not always the case. A capable management team can nip The Diva in the bud, and prevent them from continuing to damage morale. If they choose not to do so, and allow to let The Diva to continue to degrade the morale of the project for months on end, then they *will* eventually present a material danger to the project.
I don’t normally post things without my name but hey…I’m a diva.
I’m a diva and I’m trying to learn not to be. Ok, maybe I’m not the platonic ideal Diva. I think I’m good but not god. I get a buzz out of being proved wrong in a good debate.
But at this point I have developed a dangerous contempt for some of my coworkers’ abilities and I hate that, particularly when we go for a beer and I remember that I like them as people. I think I’m the best at software architecture in the little startup where I work but I’ve learned from many better ones in other companies. I’m not irreplaceable, just a bit tricky to replace quickly.
So I hate being at this point where I’m having tension with people all the time. I’ve always been happiest where I felt like my boss was smarter than me and I didn’t have the fate of the whole project on my shoulders. Where debate was regular, balanced and produced good solutions. I hate this constantly recurring belief I get that “if you won’t debate me properly on this objection I have which feels super important then this company has given up on reason and what the hell am I doing here!?”. I know it’s so often disproportionate and even when it is really important, it’s not like there’s any clever strategy or realising when to stop digging.
I feel like the causes behind this mental tic are complex so maybe this article is more funny than nailing it. (See. Did it again. Focussing on flaws is always the way I begin analysis.)
So my problem begins with the fact that the whole point is about *impact*. I’m only happy to work for companies whose product vision I believe in. I like beautiful code but it’s a means to an end, and just a vanity if it turns out to be over-engineered. If I write a piece of code that looked smart and hard to write I worry about maintenance and try to rewrite to make it look like it was easy. All this “think like an owner” stuff and I should be a company’s dream developer.
But thinking like an owner when you’re not the owner is a real problem. Sure, there’s the honeymoon period where product team are like “it’s so nice to have a dev that really just gets what we’re aiming for, spots domain misunderstandings, pre-empts bugs and doesn’t need every detail spelled out.”
Some time passes, I find my feet, see a few strategic mistakes happen, spent a lot of bed and shower time developing and internally pen-testing a set of opinions about what needs changing. So now the CTO is getting tired of hearing the same architectural opinions again and again and product think “why does this guy need to have a list of concerns and caveats on so many damn user stories?”.
And probably they’re not just right that this is interpersonally tin-eared but is often objectively inefficient too. As a manager, you need some space to try things out, risk being wrong without every coder Joe with an opinion holding up progress to debate everything.
I get this intellectually but it’s so damn hard to stay a good person to work with when I’ve hit that oh so common disillusionment and belief that the management aren’t perfect enough. The sense of “I don’t think I could do your job better but I’ve spotted these n things I think I can prove I’m right about and you MUST agree.”
At this point genuinely wondering if anyone has any advice to give. Any mental tricks they managed for being more mature while keeping the passion alive and still managing to have maximum positive impact?
Perhaps you need something like “The Zealot”
“A Diva”, I don’t think you fall cleanly into this archetype – and I’ve worked with people who I think had similar habits as you. I’d agree that “The Zealot” would be a good term. They were incredibly smart people who were frustrating to work with.
You use the word “Debate” a lot. How many of those debates are productive? Some of the time, debate is healthy. There are some decisions (including technical, managerial, and product decisions) that are very difficult to undo later. However, if we’re being honest those are the minority. Software is easy to change. Many times when working with “The Zealot”, I try to avoid debate by asking them the consequences of being wrong. If the cost of change down the road is less than the amount of time we spend debating it now, then it’s not worth debating. Just pick a road and go down it.
I’d challenge you to work on picking your battles. At any point before or during a debate, you can pause and ask a few questions. “What’s the cost of change if we are wrong? What’s the cost to our stakeholders if we are wrong?” If the answer to both of these questions is “not that big a deal”, then this shouldn’t be a debate. It should be a decision that is made quickly, implemented, and then re-visited only after it becomes a problem.