21

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.
  • 4
    At first I didn't really understand the problem, until I saw the mention to the "other project". Was his workload supposed to increase, by taking on the new project? – lvella Apr 22 '20 at 14:14
  • 25
    There's a mismatch in your question against something in your quote from what your direct said. You question says he doesn't want "new" challenges. Your quote says he doesn't want "more" challenges. These are very different things. – Joel Etherton Apr 22 '20 at 16:24
  • 2
    Seconded Joe in reopening. Just because the poster's position may be considered more in the wrong than the poster realizes (based on the answers already given) doesn't mean that the question isn't valid. It's clearly worded and contains plenty of information for people to meaningfully answer it. A frame challenge is a valid answer, and a question requiring a frame challenge (again, based on the given answers) is a valid question. – Flater Apr 22 '20 at 23:18
  • 2
    "His current project is on the maintenance stage and we feel he'd be of more value in a different project." Was your plan to transition the maintenance stage project to other devs? – AffableAmbler Apr 23 '20 at 2:45
  • 2
    @JoeStrazzere What is the goal? The question explains the situation, but doesn't explain the end result the asker is trying to achieve. If we provide an answer that says "put another developer on it" or "give him time to do hand-over", it wouldn't help if those aren't actually possibilities for the asker (or if they are strictly worse options when you take into account everything we don't know) or they actually want to know what the employee is thinking (which we can only speculate about), how to discuss it with them or something else. – Bernhard Barker Apr 23 '20 at 11:07

12 Answers 12

159

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.

  • 35
    This is probably the first parable about a mule where the sympathetic character is the mule. – Matthew Gaiser Apr 22 '20 at 2:30
  • 4
    This. If they aren't taking existing workload off him to make room for this new work that's now the priority all they're doing is asking him to take on more when he's already made it clear that he's at breaking point. – motosubatsu Apr 22 '20 at 9:47
  • 45
    he's already made it clear that he's at breaking point with sarcastic overtones, which OP says is "unprofessional". OP, is it really unprofessional for John to respond in this way when management (i.e. you) are not listening? And if you continue to not listen, what do you think his next response will be? (I'll be surprised if it doesn't end in "off" or a resignation). – Justin Apr 22 '20 at 10:11
  • 12
    Manager screws up negatively affecting employees = "acceptable". Manager having to hear from employee about how manager is screwing them over = "unprofessional". Got it. Observe me as I play the world's saddest tune in the world's smallest violin... – code_dredd Apr 22 '20 at 18:06
  • 10
    Feel free to incorporate or not, but a few signs that I'd say indicate to any developer that likely a stress ride awaits them: 1) an "urgent" project 2) that suddenly (so no planning ahead) 3) has strategic importance (so top-level people demanding it was done yesterday the way they wanted, not how it's "right") and 4) requires new frameworks and technologies (so be fast with shit you don't know); that plus 5) a series of mismanagement, so promises are worth nothing, 6) a management that doesn't listen (he asked for calmer waters, OP sells a rafting ride instead) – Frank Hopkins Apr 22 '20 at 22:13
79

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.

  • 5
    Contribution appreciated for its attempt to burst the jargon and pin down its ambiguity (whereas you would expect that jargon creates unanimity) – XavierStuvw Apr 22 '20 at 12:29
  • 6
    @XavierStuvw cynical me suspects that management used all that jargon deliberately. – Matthew Gaiser Apr 22 '20 at 14:51
  • 4
    Perhaps even more cynically, one may suspect that management uses one neutrally-sounding jargon for anything that happens, whether good or bad, and defers discrimination of good and bad to those who face the music. Responsibility of the former for accurate reporting is swept under the carpet. The sense of smell and common sense of the latter is portrayed as an attitude to work or a trait of personality, possibly a maladaptive one. Dilbert, the strip, draws a lot from these situations (and puts a smile on our faces). Let's not rule out good faith though, it can just be an obnoxious habit. – XavierStuvw Apr 22 '20 at 15:00
57

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.

  • 2
    Exactly! It will be at least a few months of knowledge transfer before he is ready to take on more. – called2voyage Apr 22 '20 at 14:50
  • Yep, and this dev plus 1 other dev doesn't make a "team", it just makes 2 people share the burden of knowing everything about a project. A team to work on an urgent project, depending on size, should be at least 4 people. A large project might need 8 or more. And adding more people isn't to speed up completion, it's to prevent burn-out, stress, constant status requests, load balancing, and more, but not speed. It may end up speeding up the project, but that shouldn't be the first priority of adding people. – computercarguy Apr 22 '20 at 16:12
  • I guess if offered, in writing and with real monetary consequences, a guarantee that he would not have to work on his previous project any more, he would jump at the new one. But management will never do that. – Martin Epsz Apr 22 '20 at 17:42
29

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.

15

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.

14

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?

  • 2
    If it was my coach I'd either look at him like he was an idiot, tell him "No", and go back to getting some oxygen into my lungs, or if I was feeling particularly nasty, hated the coach, and didn't give a crap about the consequences I'd walk over to the start line, get into the blocks, and when the gun sounded I'd stand up and walk off the track. And as to monetary rewards: never in 30+ years as a developer have I seen someone paid more for doing a good job. Not.One.Time. Apparently, money is too valuable to waste on developers. The usual "reward" is what John's getting... – Bob Jarvis - Reinstate Monica Apr 22 '20 at 16:38
  • @BobJarvis-ReinstateMonica you are probably right. In fact it sounds like the developer in question adopted your first scenario. – Charles E. Grant Apr 22 '20 at 16:43
  • 1
    @BobJarvis-ReinstateMonica: Once - 20 years ago when I was still an apprentice - a client of ours had gotten a virus in his network and my boss asked me to go there asap and spend the weekend cleaning the network. When I came back on Sunday he gave me the next two days off and ~1500€. Hell yes would I be up for special assignments from him again! – Daniel Apr 22 '20 at 22:22
11

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.

9

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.

  • While I agree with most answers already given, this takes the cake. That professional went above and beyond and got nothing meaningful as a reward. – OnoSendai Apr 22 '20 at 15:17
  • 4
    HR professionals are happy to tell you, "Money is not a motivator" when discussing your compensation. However, they don't like it much when someone points out that a LACK of money is a big DE-motivator! And I have noticed that the folks in the executive suite are annually disenmotivated to the tune of millions of dollars a year, profits or no profits. – Bob Jarvis - Reinstate Monica Apr 22 '20 at 22:57
  • @BobJarvis True enough. It might not make a difference day to day, but on a wider level it's the only way of keeping score. And if works for the board level, it should work for everyone. – Graham Apr 23 '20 at 7:17
  • @BobJarvis Money doesn’t motivate many developers to work for the company. It very much motivates them to work for this company and not for another one. And sincere appreciation motivates them. Nothing is more sincere appreciation than a raise or bonus from a tight arse boss. – gnasher729 Apr 23 '20 at 12:29
5

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.

3

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.

  • This is a horrible idea. 1) It will accelerate this dev trying to leave. 2) It will give an illusion that the project can be picked up by anyone in an emergency... Planes are well documented, but there's a reason why the manuals aren't in your seat back pocket in case of emergency. (Assuming that the exact part that's needed actually made it into the documentation...thoroughly enough to help with fixing it...and the document is still up to date...) – user3067860 Apr 22 '20 at 18:03
  • 1
    @user3067860 No, this is called "competent risk management". Whether he leaves to find a better role, or gets run down by a bus tomorrow (the reason succession planning is also known as "the bus factor"), someone will have to pick up that project. And in fact it may be a good thing for this guy to know that they're planning to bring in someone for maintenance, so that he knows he isn't expected to run the new project and maintain the old project. – Graham Apr 23 '20 at 12:52
  • @Graham No, putting more people on the project to actually learn it would be risk management. Making the already burnt out dev take up a new, crummy task on top of not being happy just makes it more likely that the problem of that dev leaving happens before you've had time to manage it. As well as not actually being useful. (I have inherited a project "with documentation"...they might as well have skipped it, it didn't help at all, had to learn it from source code anyway.) – user3067860 Apr 23 '20 at 14:49
  • We don't know it's a crummy task until we ask the person who's getting tasked. I would like nothing better than to spend time documenting the ins and outs of the applications I've worked on. Knowing that in the long run it will save time makes it a much less unpleasant task, in my book. – EvilSnack Apr 23 '20 at 15:22
3

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.

1

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.

You must log in to answer this question.