from Hacker News

Ask HN: As a dev manager, how do you deal with a prima donna?

by LordGrey on 7/28/22, 10:24 AM with 19 comments

I'm about to take over a small team of developers. Over the past few days I've been sitting in on their daily standups and attending various project meetings, getting a feel for the group and the status of ongoing work.

It's become apparent to me that one of the developers is a prima donna. He's been with the team for about a year, and during that time he's virtually rewritten every project he's worked on (because the old codebase was trash, of course), he resists learning anything about the other technologies in his projects' tech stacks, and his views on customer feature requests are utterly binary ("easy" or "stupid").

The developer really is talented, for those technologies in his wheelhouse. He is probably the best developer in that group and I can see why his current manager hired him. However, the friction is ... considerable.

I've read many articles and blogs about handling prima donnas on a dev team. Some of those were good, some less so.

HN, what is your experience? Have you had success turning a dev like this around? What did you do? I would love to hear from non-managers as well: How is it, working on a team with a prima donna? Was it a problem, and was it resolved well?

Thanks!

  • by john_the_writer on 7/28/22, 11:04 AM

    I don't believe he's a good dev.

    Sorry..

    If he's been re-writing large swaths of code he sucks, and he will cost you way more than you can afford.

    I worked with a dev who convinced the boss to let him and rewrite a large bit of our app. While he did this new features for the existing app were on hold and bugs were on hold. We pissed off clients and management. Eventually a few devs went behind the upper managements back and fixed bugs in the old system, and added minor features.

    6 months later he had finally finished.. It was loaded with bugs, and the best part he was the only one "smart enough" to maintain it.

    Then one Wednesday at 10:30 am he closed his laptop and walked out.

    None of the other devs who knew his chosen stack would touch his steaming pile of Not_made_here code. Not willingly at least.

    A year later the original app was once again "the app", and we had a party when we finally killed the project.

    He's a shite dev. A good dev makes the least amount of changes they can get away with. A good dev makes the customer happy because they pay his/her wages.

    My suggestion. Get rid of him, before you lose other devs.

  • by clintonwoo on 7/28/22, 1:41 PM

    Sounds like you have a talented developer on your hands without enough experience for the business sense. Maybe for the inter personal sense also.

    Sounds like a mid level developer since they have the code skills but lacking experience and inter personal skills. I myself have been in this phase once, although I achieved significant improvements in UX, performance and maintainability though changing structure.

    I would say just low key ask them what's the business case or engineering justification for the rewriting. Ask them to justify the justification, just probe their process. Over time hopefully you can converge an agreement.

    You mentioned his views are binary but this isn't very important. Maybe he's just being to the point or concise. A bigger issue could be if he's hurting other people's feelings with comments in which case that just needs to be brought to his attention if he doesn't realize.

    All the code there was likely written by existing members of the team so criticizing that code could be taken badly by other people, well intentioned or not. Ask him to think about other people hearing somebody criticize the projects they worked on.

  • by codegeek on 7/28/22, 3:01 PM

    I have hired developers for past 7+ years (full time, freelance and in between). I personally have experienced that no matter how great they technically are (debatable at times), they are of not much value if they cannot work with a team. If they are too much about "me me me. I know best", I don't care how much code you can write. They usually don't last that long anyway.

    I judge a good developer by what they focus on especially in early days in a team. If they come in and start shitting on everything current state, they either lack real experience or are too arrogant. I would rather have a developer say "Hey I was wondering why we do this process abc in xyz way. Was there a reason because it seems inefficient but I wanted to understand better".

    However, don't judge too quick. It may be possible that this developer is trying to tell you something which you as a manager must understand. If they truly care about the team and the customers, try and listen. If they don't, cut them loose.

  • by alexfromapex on 7/28/22, 2:15 PM

    Love this site, it explains how to deal with all of the developer archetypes: https://neilonsoftware.com/difficult-people-on-software-proj...
  • by dyingkneepad on 7/28/22, 10:45 PM

    I worked at this project where a very smart developer started working on a certain very important product. He fixed bugs, added features, etc, but he was kind of a pain to deal with, so over time the previous developers left him alone handling everything. Eventually other people joined to try to help the efforts, but they all always ended up being 'slaves' to this developer: they needed him in order to understand the code, anything they implemented had to follow this dev's desires, otherwise he block them on code review. That product became his baby, everything was bound to his will.

    Over time, the codebase started getting more and more bizarre (to his taste) and eventually people stopped trying to help him: he was too much of an asshole and the codebase was too impossible to understand. We got to a point where we needed very significant changes to that product do be done in 1-2 years, and as technically brilliant as this person was, he would never be able to do it alone. We tried to put people to help, but they had no chance: the new features were full of bugs and deadlocks. Our projects got super late and we delivered some very shitty products to our customers.

    Then a team of people started working on a replacement for this product behind this developer's (and his manager's) back. Everybody except he, his 'slaves' and his manager got super excited for it. We're still building it and recently announced it to him and his group. We're going to spend 10-20 man-years to replace this product. Management expects this developer to keep maintaining the legacy product, nobody wants him to join the replacement project.

    Yet, management still doesn't even consider the possibility of firing him!!

    PS: I hope nobody gets offended by the term 'slave' here.

  • by brudgers on 7/28/22, 1:25 PM

    A manager calls one of their reports a "prima donna."

    Now the team has two problems.

    Good luck.

  • by wruza on 7/28/22, 11:27 AM

    resists learning anything about the other technologies in his projects' tech stacks

    Sorry for quoting out of context, but I also do that. The reasoning goes: when I have to do something and it’s clear how to do it, there is no need for “the other way”. I perceive it as changing routes daily just for novelty, against boredom. Old tools have nuances, so do new ones. But the work is done by me + tools, so the best combination is me + what I know to the bone.

    Is this bad for a developer? Does that stress colleagues often? No catch, just asking.

    And I do learn ofc, after some “it sucks too much” threshold. But years of early development taught me to raise that bar much higher than my procrastination pikes, otherwise I end up in a loop of jumping tech and never get satisfied.

    Edit: to make it clear, other described “traits” I do not have.

  • by thiago_fm on 7/28/22, 3:03 PM

    Well, you have definitely a lot of leverage by being a Manager. For the better or worse, you have much more leeway and can push the developer out of the company if you want. But that would make you a terrible Manager, like others in many companies.

    One think that might help you to digest that situation better is that... while he has to write features and make things work in your company, all you need to do is mostly play politics and you have much more time than him to make yourself look good and him... that is actually in the trenches making the company work, bad.

    This is why you as a Manager, you should actually help him to work effectively. To me, he looks like the carries the company and you are just there to help him do it. You need people like this in a team and need to know how to keep them happy and motivate them to also move up the ladder. If you aren't able to do that, you aren't really meant to be a Manager.

    I've this episode many times. Manager joins and already starts gaslighting the person who is carrying the team. Eventually person leaves and Manager is left off with an average team with silly output. Things get reorg'd and Manager keeps having a silly performance all around the company, but as they paint always with good words, things work well for the Manager.

    As a Manager, you are expected to have the soft skills to handle people with different personalities and have more deeper social analysis of a situation. From what I've seen, you've already called him a "prima dona" and seem to need to work on those skills. You should also be able to call the developer when they say something not nice or toxic and learn how to build him and incentivise him to change.

    He also must be under a lot of stress and you can only gauge that by working on the team and knowing the Developer a bit more personally.

    Get his trust and develop him. I've said this before, but if you aren't able to influence people in that way, you can probably have even a considerable good management career in your view and of other peers, as managers get a lot of leeway with that. But you won't be a top manager.

    The fact that you've labeled him like this before even getting a good gist of the situation is a red flag and tell me that there's a bit of inexperience on this from your side. Try to get this "prima dona" out of your head and instead find a way that you can both profit from this situation, He'll be helped by your coaching skills and developing people, which is, BY THE WAY, the #1 skill for a Manager. You in exchange will get a person that can perform well and grow with you and the company.