Our top dev doesn't want new challenges

Question

TLDR: One of the top developers is busy up to the brim, and doesn't want extra responsibility. How can I best manage the situation?

This dev, let's call him John, has been involved in a specific project for more than a year now and, due to managerial mistakes and bad project management, ended up as the sole programmer for that project and a lot of the knowledge lies with him. We have several multidisciplinary teams working on different projects and they all have rotating people to cover emergencies and other things. John's team, on the other hand, does not, because only he knows how to solve most issues that could arise.

I had a video chat with him a few days ago where he expressed anger and fatigue towards the project and management, and I, being the (relatively new) manager, admitted that he was right and apologised for past mistakes. I assured him that we'd try our best to remedy the situation and, with time, get him a replacement so he could transfer to another project.

Meanwhile, and with COVID-19 at our doorstep, priorities changed, and a (until then) dormant project of the company became strategic and top priority. The other managers agreed that John's technical knowledge would be key to the success of this project so I scheduled a follow-up call with him.

Thinking he'd see this as a breath of fresh air, I told him about this opportunity, highlighted its urgency for the company and then he immediately stopped me in my tracks and said, and I quote "I'm sorry, I'm not interested in more challenges at this point."

I told him I'd look into it but to be frank, I don't know what to do about him. I understand where he's coming from but if anything, I think his response was inappropriate and a bit unprofessional.

What can I do?

Edit: Wow... so many answers. I want to stress the following after reading some of your answers:

• He had been informed that he wouldn't be taking sole ownership of the project and would be accompanied by another senior engineer.
• There would be new challenges in terms of technologies and frameworks used that could enrich his knowledge further.
• His current project is on the maintenance stage and we feel he'd be of more value in a different project.

Answer 1

I told him I'd look into it but to be frank, I don't know what to do about him. I understand where he's coming from but if anything, I think his response was inappropriate and a bit unprofessional.

"We loaded our pack mule with as much as it would carry until it groaned in agony. Then we piled some more on top of it and it groaned even louder. I don't understand why it keeps groaning when we pile more on top." - That's basically how I'm seeing the situation you've described.

He's had sole responsibility for the specific project because of a lack of good management. Now you've presented him with more responsibility couched as some kind of "breath of fresh air". He sees it as an additional workload and frankly he sounds burnt out. None of this is, from my perspective, his fault or his responsibility. Is it your plan to remove him from the other project or do you plan to keep "piling on" to his list of responsibilities and workload? If I were him, I would have given you the same response.

You need to provide appropriate depth so as to alleviate his workload and you need to make him understand that this new project isn't simply adding more work to his already overburdened load.

EDIT:

I read your edit to the question, but frankly I'm still seeing this as "We know we've done a bad job of managing these projects and managing your workload but we really need you to pitch in on this recent and very urgent project." - And he's still reading the situation as more work and more responsibility.

I'm not blaming you for this situation but convince us that we're wrong with our assumptions.

Answer 2

they all have rotating people to cover emergencies and other things. John's team, on the other hand, does not, because only he knows how to solve most issues that could arise.

So his experience with the company is one of extra work, higher than normal levels of stress, being the single person pestered about the status of the project, and being the one who has to solve every problem alone.

highlighted its urgency for the company

Unless the project is high profile and there is some nice promotion available after it, "urgent" is usually code for extra work and managers asking "are you done yet?" every day. Urgent projects require heroes. Heroism can be valued at many companies and can be thankless at others.

Challenging

Most developers define challenging as a project containing lots of stuff they do not know how to do with many things they need to learn, not a project with a close deadline.

I would put another developer who has had a less problematic experience with the company on the project if for no other reason than you could easily end up with no knowledge about it when this dev gets fed up and leaves.

Answer 3

I can understand John's concerns here. He is the only person who can deal with emergencies in his current project. Even if you would tell him that he no longer has to work on his other project, he knows (and he's right) that the moment there's a problem with his current project, he's going to be the one that will be called on to look into it.

Bcause this new project is "critical", he also knows that all this time that he'll lose on the other project's emergencies, will add to the stress that he's having with the new project. And this new project will have its own share emergencies, so however much overtime he's having because of lack of a team, will double (at least) with this new project.

And worst of all, it sounds like the company is again trying to make him the only person who knows about an important project, so it doesn't sound like the "double the emergencies" is going to go away anytime soon. It just means that at the end of the project, your company has to do twice as much work they've proven unwilling to do to give John a break and they've now proven that they're willing to keep piling on more copies of the exact same problem on John whenever the chance appears.

You should be happy he said he's not interested. If he were to accept this, there's a pretty good chance he'd quit halfway through due to burnout or disillusionment. He seems smart enough to know what'll happen if he says yes to this in the current situation.

If you want him to take on any new projects, you need to first give him the time to hand over all responsibilities for his current project to a new team and then put him to work on this new project with a team. Anything else just makes the problem (and the way he feels) worse.

Answer 4

the title is about >new< challenges. the body is about >more< challenges.

you first mentioned getting him a replacement, but instead it seems there is just a new project without any replacement. So this seems to be a case of more.

So your top dev doesn't want more. If you want him to work on the new project, make sure that this critical project is new, instead of more. After you are sure that this is really just new, then it should be easy to convince your dev of it being so.

But if it is more: Your top dev will smell it. So be honest with yourself.

Answer 5

His response fits the bill, heavy with satire too. I do not see how a 'Challenging' project would lie dormant for that long, only to be re-packaged as an 'opportunity' amid a depression. Sounds to me like an 'emergency'. Challenging projects are the stuff developers live for, first off the shelf.

Answer 6

Suppose you were competing in a track meet. You've just finished running a marathon. You've given it your best effort, and you finished very high in the standings, but at this point you are exhausted and bent over double trying to get your wind back. Your coach comes up to you and says "Hey nice job! Look, one of our runners in the 500 meter sprint came up lame. Can you jog over to the starting line and substitute for them? I know you are a distance runner, but I bet this is just the sort of challenge you distance runners love." Odds are high that you'd quit the team on the spot, maybe after slugging the coach.

You say this is one of your top developers, but your company has apparently been running them ragged for some time. As far as I can tell, even after your edit, you haven't yet addressed their primary concern that they're the sole resource for the older project. You may be planning on getting someone to replace them on the maintenance for that project, but that just means they'll be responsible for on-boarding their replacement just as they're becoming critical path for the new project.

Your company has burned out one of its top developers. You need to follow through and get the replacement in place and trained on the old project. You also need to give the top dev some breathing room to recover from a stressful period, maybe a couple of months where their only responsibility is light maintenance and training their replacement. As other have suggested, ask the developer what they'd like to do going forward. You don't have to give them everything they ask for, but you have to listen and begin a negotiation.

Finally, nowhere do you mention monetary rewards or incentives for someone who apparently has been doing an excellent job, and is a key player. Has the developer had appropriate monetary rewards for their good work? Bonus? Stock options? A raise?

Answer 7

The other questions answer the current problem very well (as a developer myself I agree with them), but not how to fix this in the future.

I strongly recommend that you do the following things:

• Make sure some of the knowledge only he has is given to someone else. If he gets hit by a bus, you have an even bigger problem. It's in your best interest to spread the knowledge to minimize risks. It is in his best interest to spread it so that he doesn't have to fix every damn thing and after a while it also creates an equal to discuss certain issues with.

  • I suggest you do this by asking him if [new found bug] could be solved by someone else, possibly with a little guidance from him, so that the next time it occurs that other person might fix it.
  • I also suggest that he creates some kind of presentation and let the others attend to spread it further and also making the others aware that it is no longer just Johns problem only. (You could optionally add a 'John has a lot of knowledge, in case of doubt, John can decide' bit, acknowledging him/his work).

• Talk to him how to improve his situation. Let the other answers sink in, realize that he has a different perspective and tell him that you performed some research and "might understand his response a better". Then have a meeting/discussion with him where you can discuss some ideas to improve the situation. Most programmers like creating new code over fixing bugs, so the fact that he declines is a big red flag.

Be sure you're sincere (judging from your post, I don't think that's a problem). If you 'trick' him, (apart from that being a d*ckmove,) he might quit. What he needs right now is someone who has his back, who means well with John the human instead of John the programmer.

Answer 8

How is he going to be rewarded?

He's already pulled a load of extra work, got one project to market, and is now critical to the maintenance of that one project. This is comparison to every other team, where it's taking multiple people to do what he's had to do on his own. What have you given him for this? Did he get a 10% pay rise last year? Extra holiday? Stock options? An opportunity to choose his next project which he'd find most technically interesting?

If all he got was "here's your salary, and here's another deathmarch project", don't be surprised if he's not enthusiastic.

It's often said that engineers are more motivated by job satisfaction than by money, and to some extent that's true. But money is the only way to judge how the company genuinely values you. Everything else is basically free for the company and the management. So money is how you keep score of whether management feels your contributions to the company have been significant or not. It doesn't really matter how many "employee of the month" posters you get, or whether your manager says "nice job". If you've generated extra income for the company, over and above the day-to-day expectations, it's totally reasonable to expect extra income yourself. And conversely, it's totally reasonable to refuse to put in additional effort if there is no reward for it.

Answer 9

Have you labeled the response "inappropriate/unprofessional" due to him declining, or due to the way that he pushed back? I think it is reasonably professional to set limits and manage expectations for his availability and workload.

It may be fair for him to say "I don't think I could meet expectations on this new project given my current obligations". That strikes me as a more-professional response than saying "sure thing" to unlimited work and then failing at an arbitrary subset of it. Those are different words than he used, but that may be the message he is trying to convey, particularly since we couldn't see the exact quote and context for the way that you pitched him this project.

If you think it would be valuable for him to be on that new project, ask him what things he would need to give up to make that new project successful (potentially multiple options at varying levels of staffing—leadership only, team lead, sole contributor) and how much time ahead of that he would need to hand off his previous work. You may not like the answers he gives, or you may decide that you would have to offload enough work that it is no longer a viable option, but you would have at least turned a "yes or no" answer into a "how much would it cost" answer, and that alone may result in a better understanding and more fruitful conversation.

Answer 10

YOUR BUS NUMBER IS ONE.

He's the only guy who knows the important stuff about an application. He should be documenting that application so that anyone familiar with the elements of the application's technology stack can replace him with a minimum of lead time.

This should be a formal project in his project list, with a priority second only to making necessary changes to the application itself.

Answer 11

Sounds to me like he has probably given up on your company and is looking around for something else. So not interested in doing anything new there. In which case your only hope of keeping him would be to give him an offer that matches or exceeds what he would likely get on the free market.

Also consider that he might well think your company is worse than average for keeping promises, or work environment, or whatever, depending on what he has experienced there. So you might have to offer him considerably more than others in order to just keep him.

It doesn't matter if it is true or not, it is all about his perceptions at this point, which might be very hard to change. Some relationships are irreparable.

As to what you should do:

• Let upper level management know there is a high risk that he will leave and there will be an impact. The longer you leave this, the more it will be seen as yor fault in the end.
• Prepare yourself and the rest of the team for his sudden departure. You, or possibly someone else you trust, should be gathering as much information on what he does as possible without alienating him. This is easier in a world where the managers can actually do what their directs do, but not a world most IT people live in.
• Obviously the other suggestions here, that are mostly focused on motivating him, are worth trying. But if he has decided to leave already, you may not be able to sway him anymore, and it will be wasted effort. So prepare for the worst.

I didn't see that answer here, so I am posting it - rather late.

Answer 12

Your description of the situation contains a clue which looks like it might be important.

John has a team, and yet he is the only one who has sufficient knowledge of his project to solve its particular problems.

At the root is the question "why isn't his team also knowledgeable and able to be rotated in, or even provide coverage on his project, especially if other teams in the company follow this practice?".

You mention a history of mismanagement on the project. This can lead to team members avoiding the damaged project rather than sharing responsibility. It is also pretty natural for overloaded devs to divide up sections of a project or a team portfolio into private niches where the cost of knowledge sharing is optimized (you don't have bandwidth to know more than what is on your plate).

It is also possible that John has some comfort issues around moving into a new project, vs staying in one where he is invaluable and knows the system. These can be ramping up time, new skills, but also concerns of being put out on a branch that could be sawn off in difficult times.

In any case, there are things you may be able to do to unstick John and his team from the project being just on him.

Talk to the whole team, not just to John, with the intention of improving the company's ability to share support on any project across multiple people, by making it possible for them to work this way.

This leads to discussion of the workload of the team, time allowed for documentation, production support sharing, the need perhaps for DevOps or other support staff or best practices which may be absent in order to share responsibilities, etc. The list goes on.

If you really want to get the most value from your dev staff, it is important to recognize that if John is overloaded, others probably are too. They have experienced admitted mismanagement. Don't see it as just John's issue. You probably have to hire someone to augment his team and/or support it better.

Edit: assure John through whatever appropriate means that the company values him and is viewing the new project as a career advancement step that will be recognized in title and responsibility and compensation... he is your top dev, after all.