137

TL;DR: A hyper-productive, stellar employee doesn't have enough tasks to do and is getting worried that this might mean he is about to be fired. He wants to work more, but we simply don't have enough work to keep him busy all the time.


We have a team of a dozen software developers.

Most of them are of the overall skill/productivity level, except by one—let's call him Bob.

Bob is very fast. He can clear his task queue far faster than other developers, to the point we end up without any tasks to assign to him. He isn't cutting corners or doing tasks half-assed, even - most of his code reviews have only minor adjusts, if any at all, and usually any issues we point at him are solved within the minute.

He is so blazingly fast at killing his tasks that his productivity is becoming an issue, as we simply can't separate tasks quickly enough to keep his queue going - to the point he ends up with nothing to do midway through the week, until our manager has some free time to sit down and allocate more tasks to him. This creates a situation where Bob is becoming somewhat anxious, as he feels guilty for not having enough tasks and is getting increasingly worried that our manager might be holding tasks from him in so he can fired without much hassle at some point in the near future.

That's not the case, as far as I'm aware - our manager is just too busy and can't stop everything he is doing every couple of days to refill Bob's task queue.

So far, we tried a few things, but none of those solved the issue at hand:

  • We gave Bob tasks on a programming language he wasn't used to. He picked it up and became fluent on it within the week.
  • We tried giving him tasks on an environment he wasn't used to - he's a desktop developer, so we put him to develop for Android instead. Tasks were dead before Friday hit.
  • We put him on charge of finding out how to package stuff for publishing using a new installer tool. He got it done in two days - the previous developer was stuck on it for a month and couldn't get it done.
  • We gave him a task to implement a major feature for the new system we're developing, and he ended up finishing it in two weeks. However, the amount of work he did was so large that part of our team got stuck for three weeks doing code reviews and couldn't finish half of it yet.

Mind you, it isn't that the rest of the team is incompetent. Everyone is pretty skilled and very good developers themselves, but Bob is such an out-of-the-curve developer that we're having a very hard time managing his productivity in a manner that makes him happy, too:

  • Bob loves his work. He codes for fun. He loves fixing bugs and seeing the system growing and getting new features. Leaving him "taskless" is almost akin to punishment to him, as he legitimately has a lot of fun doing his job.
  • Giving him time off has a bunch of issues on its own - mostly because he is paid by the worked hour, and corporate has a strict limit of how much paid time off we as team leaders/managers can give out to our employees. Sending him home would shaft his payments, and he adamantly refuses to pad out his time so we can do this "under the sheets".
  • He doesn't want a promotion to a managerial role. It's pretty clear he's a developer, wants to stay as a developer, and has no interest in anything but being a developer. He gets a bunch of tasks, gets them done, and move on to the next ones. That's it.
  • We can't downsize the team so more tasks would be left over to Bob. Our team has a 3-headed-dog policy - every type of job should be able to be dispatched to at least three different people. This is done partly because it is incredibly hard to recruit software developers nowadays, but also because we want to be able to keep working smoothly when someone goes on vacation or gets sick. Firing one employee so Bob can have more tasks would absolutely cripple our productivity if Bob ever gets sick or decides do leave.

So, that's the situation. And hence, the question:

How does one handle an employee that's too productive? We want to make him happy and make him stay, but we simply can't keep up with his work pace currently.


Is there a reason Bob can't fill his own queue?

Tasks are strictly controlled. Each version of our software needs auditing and approval from an external, client side. Part of of the process of publishing a new version includes detailing what, why, how and by whom of each task, filling up formularies and other misc bureaucratic work. Getting a task on the backlog to be done is a whole process that, so far, our manager seems to like keeping close to his heart. I've scheduled a meeting with him to find out if the dev team has a way of helping him out speeding that up.

Can he pair up with other devs?

He can, and he often does when he doesn't have anything to do on his backlog. It helps, but it doesn't quench his thirst for "getting things done" - he often aks for something to do by himself.

Why you don't promote Bob?

Bob doesn't want to lead or be a manager, and we don't have anything above his current position that he could fill on a strict-development sense. I'm going to push the idea of getting him an architect spot to our manager.

What about free time?

Bob doesn't seem to enjoy being let "free" without tasks on his board, but I'm starting to think that's more of a lack of direction than anything else. After reading some of the answers here, I'm going to bring up to our manager the possibility of filling up Bob's time by offering him courses and new things to learn instead of busywork.


Update: I've scheduled a meeting with my manager next Monday to discuss this situation. Thanks everyone for their input so far!

Update 2: After the meeting, we decided that it would be best not to make a meeting with everyone and giving them a clearer idea of what is expected, and what they could do when they have free time. We gave them a thumbs up to work on ideas of their own during this downtime, and said it was OK to take a break and have a rest/some fun if all tasks are done.

Afterwards, we had a second meeting - this time with Bob only - and gave him extra reassurance, and a staggered raise plan starting January (the sooner Corporate would allow us). We also swapped his work notebook for a way better one, saying that "we hoped this new machine would be able to keep it up with him". He seemed really happy to have better hardware. We also talked to him about courses and other study he would want to do on his free time, and he seemed interested in picking up a new language (as in, a speaking language), so we're setting things up with HR for that to happen.

We also brought up to our higher ups that we had to give out more benefits to our employees, since retention on the industry is becoming somewhat of a problem and we have a team that we really don't want to lose. They are checking out what they can do in terms of benefits to improve morale. Those things are a bit on the slower side, but the gears seem to be moving, at least.

Thanks everyone for the great input!


Update 3:

In addition to extra recognition, a raise, and a few bonuses specifically for Bob, we're going to try out a 4-day week moving forward, for the entire dev team. Our boss thinks that by doing this we'll be able to redistribute tasks in such a way that it will allow better usage of Bob's increased productivity, keep the team well-rested, with improved morale, and hopefully keep them for quite a long while. I personally think it is worth a shot, since a 4-day week is already reality for a bunch of other dev shops around the world. Let's see how it goes!

5
  • 2
    Comments are not for extended discussion; this conversation has been moved to chat.
    – DarkCygnus
    Sep 9 at 22:20
  • 2
    I think you might mean "off the sheets" or "under the table" :)
    – hert
    Sep 10 at 11:12
  • 3
    Thanks for you update, you seem to be an excellent manager in a great environment to work for :). Hope you are able to continue keep everyone happy.
    – ILoveKebab
    Sep 19 at 19:56
  • 1
    @ILoveKebab Thank you! And I hope so, too!
    – T. Sar
    Sep 29 at 11:25
  • 3
    @T.Sar Excellent update. I'm so glad this looks like a pretty good direction to go. Yes, 4 day workdays will help a lot, and it's great to hear that upper managers are listening. Are you guys hiring? :D
    – Nelson
    2 days ago

18 Answers 18

150

Congratulations, you seem to have won the "great employee" lottery.

Bob is becoming somewhat anxious, as he feels guilty for not having enough tasks and is getting increasingly worried that our manager might be holding tasks from him in so he can fired

This is a simple communication problem. Your manager (and maybe you, depending what your role is) need to tell him repeatedly that he is great and that there is zero intention to fire him. Actions are good too: A raise or public recognition go a long way in adding credibility.

as we simply can't separate tasks quickly enough to keep his queue going -

That's where your problem is: Poor planning. It's actually quite rare that a dev team has an empty backlog. A few things you can do

  1. Spend a little more time grooming and filling the backlog. If you are doing scrum, make sure that your backlog has 2-3 sprints of work in it.
  2. Do some strategic planning. Are there any high level projects or architectures that Bob could work on? What things may you need in 3 years from now that are not on the daily task list?
  3. It's a good idea for everyone (including Bob) to have a well defined side or pet project. Something that's useful for the business, fun to do, but doesn't have a hard deadline or deliverable yet. Could be technical or scientific research, tools, process improvement, experimental features, documentation, user research, competitive analysis, etc. This is "stuff to work on" if your hair isn't on fire and your tasks are mostly done. These can be defined in collaboration between the employees and the business stakeholders.
  4. Ask Bob what he wants to work on. What ideas does he have that are fun for him and also good for the business?

Honestly, it shouldn't be too hard to keep Bob's plate full. Most managers would give their left kidney for that type of employee. If your manager is "too busy" they are not prioritizing correctly.

11
  • 20
    About 1 - We had 3 sprints of work ahead until Bob joined. Nowadays our boards are extremely boring by how empty they are. 2 is a bit dependent on what our manager wants for the future, but 3... That can work. I'll talk with my manager and push the idea of pet projects forward. About 4 - Bob usually gives non-descript answers, in the vibe of "anything that could help". That's what's more hear-breaking of it - Bob really wants to help, we just... have a hard time finding how. I'll bring your option 3 to my manager - that might work.
    – T. Sar
    Sep 8 at 19:50
  • 6
    @T.Sar There is always more work to do. Bob will probably realize that sooner or later and leave if your manager doesn't wise up to it. Your manager not being able to find enough work sounds like the pretty obvious issue here
    – Mdev
    Sep 9 at 8:18
  • 92
    With regard to tasks to do: add reducing technical debt to the list. There's always technical debt lurking somewhere. If you're not sure where to find it: ask the other developers. Whatever is getting in their way when developing, check if Bob could crack down on it => make Bob an enabler, and let him improve the productivity of his peers. Sep 9 at 9:59
  • 22
    How is the testing situation?Automating and adding tests and/or improving coverage is extremely beneficial to the stability of the software and it is usually a long, neglected task.
    – bracco23
    Sep 9 at 15:00
  • 5
    @T.Sar a raise should definitely be in the works; if he can pick up languages as quickly as described, readily helps others with their work when his queue is clear, and is always chomping at the bit for more, you have a unicorn employee. Keep him, he's worth it! Seconding that reducing technical debt is a good backlog task for him, as are R&D/pet project sorts of things. Just have him check with management for approval on a given project, then let him burn off excess energy on it when his queue is clear.
    – Doktor J
    Sep 9 at 21:00
104

As a software developer who is also quite fast, I strongly recommend against doing some of the ideas that are presented here. First of all, do not give him too many more tasks. I am assuming he is young or young hearted. Going fast shouldn't mean doing much more work. If you do that, he would burn out much faster. Encourage him to take more breaks. Tell him, this is the amount of work you are going to do this week/month, you are free after you have completed your assignments. Let him work 4 days a week.

I would suggest to let him work on a side project 20% style but that will also tire him out. Be careful, burnout is very sinister. It doesn't start gradually. It happens even when you are happy, productive and love what you are doing. Keep him healthy.

9
  • 24
    Many of the answers here are from the managerial point of view. Reading your answer should make clear why average employees are unhappy, and why above the average employees are above the average unhappy (depression&burnout being just symptoms of an underlying problem) in the long term. How would you feel by having 20% of the time not doing side project, but being allowed to get in touch with start-ups and technical schools... something like being in "listening" mode, rather than active?
    – EarlGrey
    Sep 9 at 7:16
  • 11
    It seems that this company pays Bob by the hour, so working 4 days a week is a paycut. Sep 9 at 15:21
  • 20
    Totally agree, I used to be Bob until I totally burned out because I kept being given random tasks that weren't even ready to be worked on or defined just so I was doing something. I've basically throttled myself so my work ethic doesn't get abused, and I now take lots of breaks during the day to do other stuff that is measurably more useful to my wellbeing.
    – 0x777C
    Sep 9 at 15:39
  • 12
    One of our out-of-college hires wasn't Bob-level skill, but was doing a good amount of work. We later found out he was working nights and weekends without being told to, because he had no clue how to pace himself.
    – Izkata
    Sep 9 at 18:11
  • 3
    Not everyone who works more than the usual employee will burn out. It is easy to be taken advantage of, but I work 10h/day at my job and I usually spend 3-4h a day of my own time coding or learning, and around 10h/day during the weekend. I'm 12 years in, and I just love building stuff. It gives me energy and purpose. I'd get bored otherwise.
    – Moox
    Sep 9 at 20:32
52

File this under "problems you want to have".

Tell your management that Bob should get a raise. And make it a big event for Bob. "Bob, you are our best achiever and we are proud to have you here". Maybe give him two smaller raises in a year so you can make him happy twice.

Are there trade shows, developer conferences etc.? Send him there.

Does he like writing tests or documentation? Let him add tests and useful documentation.

I assume the other developers understand how Bob works and that he is exceptionally good.

12
  • 6
    While I don't disagree with any of this it doesn't answer the question. Sep 8 at 19:16
  • 46
    @DJClayworth I disagree. It answers how to address Bob’s anxiety, which is arguably the biggest problem here.
    – Jim Clay
    Sep 8 at 19:36
  • 4
    How does giving Bob a raise make them feel LESS guilty about doing nothing? Sep 9 at 7:13
  • 21
    @GregoryCurrie the question's premise seems to be that Bob is anxious that the low workload (as he perceives it) is a precursor to him getting fired, not just that he feels bad about being idle. Giving him a fat raise would hopefully clue him in that management is actually very happy with his performance, and so remove that source of anxiety; obviously that still leaves the idleness problem, but if he's not worried about his perceived performance anymore he'd probably be more open to finding other things to do instead rather than begging for more tasks to prove his value.
    – Carcer
    Sep 9 at 8:14
  • 17
    @Mdev: I believe the raise is to show him he's valued. It's not about the money.
    – Julia
    Sep 9 at 11:14
49

we simply can't separate tasks quickly enough to keep his queue going

Fix that. Find or hire more task-separators if necessary.

If you want more productivity, you have to remove the bottlenecks.

our manager is just too busy and can't stop everything he is doing every couple of days to refill Bob's task queue.

Seems like someone other than just your manager needs to become able to do this. Or, your manager needs to offload other tasks to free up more task separation time.

5
  • 4
    I'll give some consideration to it. Our manager seems to hold very close to his heart the task-separation duties, but we might have to change that...
    – T. Sar
    Sep 8 at 19:54
  • 8
    I don't understand how identifying the bottleneck hasn't happened already during retros. Are there no retros? Sep 9 at 14:34
  • 6
    If you had to choose between keeping Bob or the manager, who would you choose? If the manager is holding Bob back then that's where to look for solutions Sep 9 at 15:45
  • 2
    @DewiMorgan There are retros, but it's hard to say this is a bottleneck when everything that needed to be done in the sprint got done. If we scheduled 40 features and delivered 40 features, with time to spare, there isn't much in terms of "where did we go wrong", just "we can get more done", but this also means that other, external teams - the audit teams - should get up to speed. It's... hard to increase our workload-per-sprint.
    – T. Sar
    Sep 12 at 15:52
  • Retros shouldn't be just about throughput. You should also be talking about how the team is doing. This would identify to the team the problems Bob is having.
    – Burhan Ali
    Sep 19 at 8:16
40

I do see side-projects being suggested, but did you consider allowing the developer to contribute to any open source libraries that are being used?

Many open source libraries have a backlog of issues that are waiting to be solved.

Suggest the developer that when there are no tasks, the task is as follow:

  • Improve the used open source libraries by fixing any reported issues so that the chance of negative impact on our production environments and/or company products will be reduced (possibly significantly)

Maybe allow the developer to work on personal/hobby projects for one day of the week. As a business reason the reason is that you support the gaining of (unusual) knowledge through private hobby projects, so that the knowledge may be used in the future for company projects. I personally carry a lot of hobby knowledge into the products I develop. The reverse is true too - valuable knowledge gained on company time I (am allowed to) use in my hobby projects.

Maybe limit the time to one day or 4 hours per week on personal hobby projects, and a maximum of 12 hours per week on open source contributions which would improve the company product(s).

When the contributions are of high quality and value, not only will the company profit by having a less buggy and better product built on open source libraries, but the developer and company will have positive recognition in the communities they support.

I personally do not think that it's sustainable to keep adding more and more tasks when the average amount of tasks (in terms of value / work load across the team) is being assigned. This also comes with the burden of more reviews being required by other members (in turn, burdening them more). By allowing to work on open source projects the review work can be offloaded to the open source community - win, win and win.

There's also another benefit - when the developer gets assigned a task (it's not if, it's when) that the developer will struggle on, there are additional hours that can be taken from hobby time/open source time to help the project out - and that's okay.

-- A fellow developer

6
  • 4
    ByTheWay I would recommend to give anything promised, in writing to the developer (maybe an addition to the contract, ie developer is allowed to work a maximum of 4 hours per week on personal project on company time if there are no tasks available), as to make that person not feel anxious (i.e. setting up for firing due to alleged bad performance).
    – Raf
    Sep 9 at 12:28
  • 2
    You're absolutely right about burnout. This employee is at high risk for a life crisis in the next few years. Working on other self directed projects will teach him pacing and contentment.
    – 134121
    Sep 9 at 12:44
  • 7
    Regarding open source contributions, this can also help Bob on a personal level, knowing how contributions reach far and wide, and can help the company gain goodwill, where they can publish that their own employees are directed to use company time for the open source projects.
    – 134121
    Sep 9 at 12:45
  • 1
    Came to mention this specifically. I'm sure somewhere in your org you depend on some F/OSS licensed code. Ask Bob to take a look at their buglist and wishlist and allow him to spend either some time per week (better) or just to spend a few weeks going thru their hit list, which should give you enough time to find more tickets for bob to work on
    – ivanivan
    Sep 9 at 14:42
  • 1
    @T.Sar A real Linus, that one.
    – 134121
    Sep 9 at 16:50
13

Rockstar employees deserve rockstar treatment as they are very valuable in the long term.

There are a few things you can probably try:

1. Redistribute the workload to make Bob happy:

Re-arrange the amount of work, or the backlog such that Bob gets more workload than other developers. For example, if he wish, he can get 30% of the total workload, and the rest of the team can share 70% of the total workload.

But make sure that he is happy with the workload, and does not feel like he is unfairly overloaded with too many tasks. In other words, ask him exactly what amount of workload would make him happy. The key point is to keep him occupied and happy.

2. Make him the team lead (Give him additional responsibilities while still let him write code):

I know you wrote that he is not interested in the management path. But, you can make him the team lead so that he can spend more time to mentor new developers and even experienced developers. He would be the go-to guy or the problem solver for tough technical problems for the whole team. Of course, his main job is still to write code as it makes him happy.

3. Give him additional technical roles (Software Architect) :

Make him a software architect. Ask him to design and teach some courses to the whole team or even to the whole engineering department on various technical topics such as: how to write efficient code, how to improve OOD (Object Oriented Design), Design Patterns, Data Structures and Algorithms, SOLID principles, etc... Of course, his main job is still to write code as it makes him happy.

4. Rewards and Recognitions - (Give him assurances that the company always appreciates him):

The manager should nicely reassures Bob that they value him as the best employee in the team, and never plan to let him go. Give him many small rewards such as $100 gift cards, gift certificates, tickets to movies or to sport events or music concerts, etc... every few weeks for being the best developer of the sprint. In addition, every 6 months and/or at the end of the year, reward him a big and expensive item such as a new Samsung phone, iPhone, iPad, Apple MacBook Pro, XBox, PlayStation, or any technology valuable items for his significant contributions to the company. These will be periodic and continuous reminders to Bob that the company loves his talent and truly wants to keep him. Rockstar employees deserve rockstar treatment if you want to keep them. :-)

8
  • 3
    Also ask Bob if he can share his knowledge and experience with his teammates. If one Bob is this good, then imagine if you have 10 more. Teaching is also a good learning experience for Bob himself.
    – KC Wong
    Sep 9 at 2:20
  • 10
    Number three sounds risky. Some people just want to write code and not deal with people. Don't push him away by moving him into a role he is not happy with.
    – David
    Sep 9 at 3:00
  • 9
    I'm not sure doing point 4 often is a good idea: it might severely demotivate the rest of the team. Which could result in either the rest of the team leaving, or creating such a tense/hostile work environment that your rockstar leaves. Sep 9 at 6:24
  • 4
    @David I agree with you. Even number two might be considered as too much of a role he might not be comfortable with
    – Ivo
    Sep 9 at 7:02
  • 5
    As someone who left a company because of #3 I can assure you that's a bad approach. #2 might be doable, but depends a lot on Bob. Sep 9 at 10:17
13

You could create an all-purpose, open-ended task that would soak up down time. Whenever Bob has no tasks, he can work on that open-ended task. Letting him decide how much or how little to work on it will help limit the risk of burning him out.

Call it "Identify Refactoring Opportunities" or "Speculative System Analysis" or something like that. Let Bob figure out and propose ways to improve the product line that emerge from his own informed study of the code, and the business purposes served by the code. You can then have the three-member team that right now is pushing work at the developers decide if any of Bob's proposed improvements make any sense.

The entire problem with an SDLC like the one you describe - where sales and management create tickets, and developers work those tickets and nothing else - is that the developers often see opportunities for improvement that product owners don't, but don't champion them because they don't simply don't have the time. Now you have a developer who does have the time.

5
  • 2
    Also, sometimes they just don't see the possible improvements because they've never thought about it. Or at worst, they stop caring because they've been trained to implicitly follow the directions. A "work order" based operations is, imo, not very good for development.
    – 134121
    Sep 9 at 13:03
  • @134121 That's a good point as well. Developers who become used to the idea that they aren't supposed to look at the big picture...don't look at the big picture. Bob sounds like he has the ability required to take on big picture tasks; OP just has to find a way to allow him to do it.
    – tbrookside
    Sep 9 at 13:40
  • 1
    "You could create an all-purpose, open-ended task that would soak up down time" This will just bore Bob and waste his time.
    – 0x777C
    Sep 9 at 15:46
  • 2
    @0x777C If I gave a developer a task that essentially boils down to "Work on absolutely anything that interests you as long as we can relate it to one of our products somehow" and their response to me is "That's boring!" then I guess I wouldn't really know how to give them interesting work.
    – tbrookside
    Sep 9 at 17:37
  • @tbrookside An interesting task has 4 things: risk, relevance, oddity and difficulty. Obviously not all tasks have them in the same amount, but if you have all four equally you get a good task.
    – 0x777C
    Sep 10 at 20:19
9

You seem to have had difficulty formulating the exact problem into words.

The immediate problem, it seems to me, is that your star developer Bob thinks that you're withholding work from him.

You say:

our manager is just too busy and can't stop everything he is doing every couple of days to refill Bob's task queue.

To me, that is not a very convincing response. Expecting your manager to stop what he's doing, to work on ensuring that his staff have something to, is actually a very reasonable expectation.

If your manager is genuinely in crisis himself and unable to delegate his own responsibilities - these are the only circumstances in which it is reasonable for him to let his own staff go underworked - then the first step to solving your problem with Bob might be to ask the manager to declare that such an emergency is currently underway.

Alternatively, if there is no emergency, then this might cause the manager himself to take stock and realise that he either needs to spend more time allocating work (or allocate more work at once), or to delegate his responsibilities more thoroughly.

A third possibility, which will not be reassuring to Bob, is that your manager is, in fact, intentionally drip-feeding work.

The manager might be doing this precisely because Bob is more productive than the norm, but the manager sees it as desirable only to allocate an ordinary quota of work - probably because the manager's own superiors might not accept that there can be such variability in productivity.

Also if the manager employs Bob to the full, then he is not only going to lose the "three-headed-dog" resilience of his team, but he may have considerable difficulty replacing Bob in future. As you say, you're already backlogged just sifting through Bob's code to review it.

The manager has no reason to be overly concerned about under-using Bob's working time, because he's still getting at least a full quota of productivity for the money he pays Bob. Bob is just rendering that work quicker than the norm.

As I say, none of this will be reassuring for Bob, and it probably undermines his work pride. It would be like a gym-owner forcing the members to pump only so much iron as the weakest amongst them can bear. Guys who turn up strong already, will complain that they are not even pumping enough to maintain themselves, let alone to develop further.

Your manager might also be worried about the effects on morale and discipline of making any overt exception for Bob - such as more time off. He might already be worried about what effect Bob is having on you and your other colleagues, as the sudden appearance of a strongman might affect a gym full of weaklings.

The manager can hardly justify firing someone for being too good, in the same way that he can hardly ban someone from the gym merely for having too much strength - to do so would undermine the facade that he is there to promote strength, rather than to simply farm membership fees - but at the same Bob knows his mere presence poses a threat to the existing order.

6
  • These are good ancillary considerations, if the obvious possibilities are not the main issues. Good management/holistic minded perspective.
    – 134121
    Sep 9 at 13:09
  • 1
    These.. are actually very good points. I'll need to think over this. I have not considered this angle before.
    – T. Sar
    Sep 9 at 14:41
  • 1
    I think this answer is pretty smart in the assumptions what might be the reasons behind the behaviour of the manager. But, it falls a bit short on what to do about it.
    – kedavle
    Sep 11 at 21:03
  • @kedavle, within the logic I've articulated, I'm not sure there would be any easy remedy for the OP to follow. Perhaps he could explain to the manager both Bob's talent and his worries, and suggest allocating more work, and then see what the manager has to say about it.
    – Steve
    Sep 11 at 21:56
  • "he may have considerable difficulty replacing Bob in future" - this sounds like a reason to indeed go ahead and "promote" Bob, both in title and in salary (not in role, if Bob doesn't like that!). It may be easier for the manager to argue "Advanced Senior Specialist Developer Bob is going to leave, we need to hire three new Regular Developers to replace Bob." than if Bob is still counted as a "Regular Developer" himself. Sep 11 at 23:03
7

Your problem is "that we simply can't separate tasks quickly enough"... might I suggest giving him a promotion (with a pay increase), and the additional responsibility of separating tasks?

It sounds like you have a lot of developers that could benefit from a bit of mentoring by Bob. And that Bob needs to be placed into a leadership role for personnel growth. Therefore he should become a senior engineer which is a leadership role but doesn't make him a 'manager'.

4
  • 2
    What makes you think "additional responsibility", "a leadership role" and "resposible for personnel growth" equates to "not a manager"?
    – Brondahl
    Sep 10 at 3:56
  • yeah, usually you have someone stream tasks to you. But in his rare case, he could be empowered to communicate directly with the client and work on a sepearte epics or sections that would not encroach on the team. The team leader/BA/Product manager is usually a good middle man to have, but in this case it should be streamlined by allowing direct communication.
    – Issel
    Sep 10 at 4:35
  • 2
    A lot of developers are not good managers.
    – seg
    Sep 10 at 13:47
  • Because being a senior engineer is not about managing people (At least at the company I work for). It is taking ownership for the technical sides of a product. Which I guess includes some project management... But no people management which is the thing (in my experience) that most people who don't want to be managers, don't want to do. As well as mentoring technical expertise on the side. Which is teaching, not managing.
    – Questor
    Sep 12 at 15:42
5

TL, DR:

  1. Bob must raise the delivery ability of the entire team.
  2. Bob must raise team members ability by sharing Bob's techniques
  3. Bob will at some point no longer be employed in this position - will there have been any positive long lasting benefits realized by the company?

Point 1: Building tools to fix problems at a meta level

Bob needs to no longer work on the actual code being delivered. Bob needs to be focused on improving / creating the tool suite that does the delivery. For example, automated security testing, tools that generate standard code required by every new feature, whatever annoyances that other developers have in the delivery process: have bob fix them. Maybe tests are a pain to write and maintain: can Bob write a tool that generates the tests more easily?

Whatever the problems are: have BOB WRITES TOOLS that fix a category of present problems AND make it so that this category of problems does not show up in the future.


Point 2: Creating MENTAL tools for the other team members

Have bob explore why he is so good. He has techniques or ways of viewing issues that others can learn from. Its more than just "bob is smart". He has mental checklists that he keeps in his head. Others will need to work from a written checklist that Bob creates.

This exploration will help bob become a mentor/teacher.

Right now, everyone knows that Bob is a superstar. The other members might even be getting lazy: turning to Bob rather than struggling through the learning themselves.

They should be learning new ways of working from Bob.


Point 3: Prepare for the inevitable.

Will the team/company have sustained long term benefit if Bob is not there.

Bob will:

  1. move to a different team
  2. get promoted
  3. die/retire
  4. goes on 1 month vacation (wants to go on a long honeymoon/ paternity leave)
  5. medical leave ( crashes his motorcycle )
  6. leave the company

Note how shitty it would be if Bob was told that he couldn't do an internal transfer/go on vacation because "no one else can do your job".

Bob needs to move back from the day to day delivery. The team needs to discover how to still have a high delivery rate even if Bob is not there.

Unless this is figured out: everyone of the above possibilities is devolved to "bob leaves the company".

5
  • 1
    "Bob must raise team members ability by sharing Bob's techniques" - the problem is that this may require an extreme commitment of time and effort from other members, when only Bob has free time to spare.
    – Steve
    Sep 10 at 12:10
  • @Steve Not necessarily. A workshop here, and new documentation here is hardly "an extreme commitment of time". If developers are unable to complete their tasks due to all the training, that should lead to more tasks in the Backlog Bob could pick up when he feels like coding.
    – Llewellyn
    Sep 10 at 18:00
  • @Llewellyn, most developers are not a one-hour workshop or a written memorandum away from higher productivity as developers. Even if Bob can describe what makes him so productive and desires to be engaged in the role of educator, it is probably thinking and cognitive skills which don't just require a written description but also considerable practice and brain-training. If you asked Schwarzenegger what method made him so strong, it could be said quickly but not so quickly applied: "tens of thousands of hours of pumping iron".
    – Steve
    Sep 10 at 20:35
  • "Sorry, we can't afford to lose you right now." --- "So, let me get this straight. I'm not getting the promotion because I'm good at my job?" It's funny, but it really does happen. Selfish and insecure management habits.
    – 134121
    Sep 11 at 12:36
  • @Steve Please read the backing paragraphs : "This exploration will help bob become a mentor/teacher" This exercise is intended to help Bob understand and make consciously aware to himself why he is good so that Bob can be a mentor.
    – Pat
    Sep 12 at 6:18
4

Not to look a gift horse in the mouth, but some of these things tend to be issues when dealing with situations similar to what you've described. Bob's performance may be a symptom of one or more of these things:

  1. Your development staff is incompetent. It's very uncommon to have a code review with few or no comments for any task of nontrivial importance. If you're saying that Bob is writing and rewriting major features and his code is so perfect that he has no comments on his PRs, that's a symptom that the people who are reviewing Bob's code might suck at reviewing code. You may want to give someone (Bob?) the task of going through the codebase and reviewing it and seeing how bad code quality you have to see if maybe you should allocate resources to paying tech debt you didn't know you had.

  2. Bob is working too many hours. Sure, maybe Bob is a rockstar developer, and that's great, but even a rockstar developer's hands can only type so fast; there are physical limitations to how fast Bob can write code, and if he seems to be writing code faster than these physical limitations would allow, perhaps he's spending more time than he should be. If you can, find some way to find out how many hours per day Bob is actually working, and make his workload more reasonable, by force if necessary (lock him out of his computer remotely if you can, refuse to review PRs published off work hours, etc). If Bob's hobby is coding in his off hours, that's fine, but doing additional work is going to cause burnout, and you'd rather Bob work for you as long as possible without getting burnt out.

  3. Your tasks are too small. Perhaps what you consider a "major feature" is actually just a small feature improvement. This correlates with the first possibility in that if you have people who are slow, then your tasks look bigger than they are, and you get used to thinking about tasks as larger than they should be. Bob is working at a reasonable pace, but everyone else is slow.

In any case, none of this is what you're asking about, you're asking about how to deal with Bob's anxiety over being fired. You've done all you can to reassure Bob he's not about to be fired, by telling him his manager doesn't have work to give him, you continue the stream of tasks to Bob as quickly as you can, and so on. There's nothing more than that you can do. Keep doing that, and don't fire Bob if you don't want to fire Bob. How he feels about not being fired is his own business; if he chooses to still believe he's at risk of being fired despite your reassurances, that's really up to him.

One thing you may want to do is ask him why he thinks, despite your reassurances, that he's on the road to being fired. Perhaps he's had some negative experiences in his past or knows people who have had bad experiences or something. If you ask Bob what the issue is, you can figure out the best way to reassure him that that's not you.

2
  • 1
    "there are physical limitations to how fast Bob can write code" - do you even know anything about writing code? My typing speed is thousands of times faster than the speed at which I can think what to code.
    – Steve
    Sep 10 at 12:23
  • 2
    Thank you for suggesting the frame challenge, which is that Bob is not an overachiever, but is typical, and there's a larger problem at the company. It's uncomfortable, because it takes us from "stellar employee" to "crappy team", but it should be considered, like, "Wait, are we the problem and Bob is fine?"
    – 134121
    Sep 11 at 12:53
3

This question really resonated with me, I feel for Bob.

I assume Bob must understand the current product very well to be so prolific and not wander down wrong paths too often. That also means he likely knows the product's existing shortcomings well; the ones that are too baked-in to refactor.

With this in mind, and if warranted, perhaps Bob could become architect for the next new version of your product. In my opinion, as a passionate software developer, there is nothing more exciting than a clean slate with which to take a fresh shot at doing things more correctly. It is a rare opportunity because there is rarely enough bandwidth for it. Sounds like Bob has enough bandwidth to continue his current work, and to also work on the next version as time permits.

This assumes your product is non-trivial, and has grown enough to warrant a rework. It also assumes your rather dictatorial manager will allow Bob this level of control. It would also depend on Bob's interest to take on that level of responsibility. It is a sea change to go from doing assigned tasks to choosing the next path. But it sounds like if anyone is groomed for the challenge, Bob is.

3

Allow Bob to change entire projects to fit coding standards and review/improve others' code. You'll find hundreds and thousands of files improving in a day's time.

Find out what makes Bob so fast. For example, does he use regular expression in Find/Replace to perform hundreds of changes at once? Does he use a scripting language to massage data? Does he customize his development environment in a unique way that improves his performance?

Then, tell Bob he's doing a great job, give him a raise, and ask Bob if he can train the other developers to be as fast as he is, or if he can create productivity tools or libraries that shorten the development time required for future projects. Give him a "lead developer" job title, and give him some say in the architecture/scoping decisions for projects.

Find out what open source tools you use in your projects, and give him some time to learn, support, and contribute to those projects. Do you use an open source OS, browser, or programming language? Send him to contribute to those as well.

Encourage him to read about programming-related security standards, such as OWASP, so that your code meets industry security standards and will have fewer vulnerabilities. Have him review projects to search for and fix security vulnerabilities.

You could also introduce him to codegolf.SE. That's what I did when I was in Bob's situation. He'll learn a bunch of random things and multiple new languages, and then he'll learn how to create his own programming languages and interpreters.

6
  • "Find out what makes Bob so fast" - I would say that he is just very good at organizing his ideas and expressing them in code. He's one of those devs that can think faster that they can type.
    – T. Sar
    Sep 9 at 14:47
  • Then perhaps he can still use that thinking to create productivity scripts that automate some of your development/testing process. For example, I've created a script that would look at HTML and corresponding JS files to find missing or unused imports. Then, I ran it on an entire project and fixed all the issues it found. Have him create tools that help the other developers make fewer mistakes. If you code doesn't have unit tests, have him write some and work on code coverage.
    – mbomb007
    Sep 9 at 14:49
  • We already have tools like that! (Resharper, on our case). We also do unit tests as usual, per part of our cycle.
    – T. Sar
    Sep 9 at 14:52
  • Awesome! I'd just say then that you should have Bob learn as much as he can the tools you use, how they're configured, and how he can contribute in each area. Have him learn security standards, or programming languages. If you use PHP, for example, he could learn C and contribute to the development of PHP 8 and 9. Whatever frameworks you use, he can learn and improve. If you use Visual Studio, then make sure he knows how to submit bug reports for the IDE and extensions you use, or maybe he can fix them in pull requests.
    – mbomb007
    Sep 9 at 15:21
  • If you don't find a way to fill his time, he will outgrow your company. It doesn't matter how much you pay him if you can't give him the work he loves to do. Money doesn't lead to fulfillment as much as doing what you love.
    – mbomb007
    Sep 9 at 15:23
2

Tell them they are doing a great job and you are very happy with their performance. Make them feel proud about what they are achieving.

Ask them:

  • what they enjoy doing most
  • what they don't enjoy
  • if there's anything they want to improve for the future
  • about their future career goals

Do everything you can to keep them happy and working efficiently while giving them the chance to develop their career. Make sure to pay them what you can, but focus on keeping them happy and comfortable.

Protect them from any jealous peers that make them feel uncomfortable. Do not allow them to get undermined.

Make sure they are stimulated, but don't push them into management or roles where they have to deal with people unless that is something they want to do.

A star employee like this can give a company a massive competitive advantage.

3
  • 1
    "about their future career goals" it doesn't sound like Bob has any interest in career goals other than 'make cool stuff'
    – 0x777C
    Sep 9 at 15:47
  • 1
    @0x777C That may well be the case. Make cool stuff is a pretty good career goal, in my opinion.
    – David
    Sep 9 at 20:05
  • Perhaps, but it's also a bit of a dead end once you've done it.
    – 0x777C
    Sep 10 at 20:20
2

Can you give him a small bonus? Actually, sounds like he deserves a huge bonus. It's really hard to think you are doing a bad job when you are receiving a bonus.

1
  • Without an explicit path that warrants a bonus, this is a bad idea for the company. Other employees will resent the action, because it's flippant in their mind. It's a bad precedent.
    – 134121
    Sep 11 at 12:56
1

As a developer myself, I can tip that one of the main things that skilled developers want is recognition.

How can we do that?

  1. rewards for the top developer each month (tech gadgets, etc.)

  2. soft rewards (use an internal "point system" on Stack Overflow)

  3. a fancy title, like "Principal Software Engineer" - same job, better title

Please don’t fall for the temptation to promote Bob into management. I get the feeling he doesn't want to do that (he likes to code) and I've seen moves into management demotivate developers before.

And of course, the simplest thing you can do is say "Thank you, Bob!" every time he finishes a task.

Sent him an IM "Thank you!" or walk up to his desk and tell him personally.

It costs nothing to be polite and show appreciation to a great employee - in fact you should be doing this already, but given Bob's special case you could really focus on this now! :) Good luck.

5
  • What do you mean by "use an internal "point system" on Stack Overflow"? Do you mean "use an internal "point system" like on Stack Overflow"? Or something else? Can you elaborate, preferably by changing the answer? (But without "Edit:", "Update:", or similar - the answer should appear as if it was written right now.) Sep 9 at 9:28
  • Some companies give internal "badges" and points in certain categories of learning. Of course there is effort to set up such a system, manage it, and make sure it's fair. Developers love swag and imaginary points ;) Sep 9 at 9:37
  • 5
    Developers love swag and imaginary points ;) => Honestly? No, I don't. I do appreciate having the esteem of my peers and as a result being involved in the decisions related to my area of expertise, however swag/points I could care less about. Sep 9 at 10:03
  • Yet you have 2853 points on a stackexchange site, and you dont care about imaginary points ;) Sep 12 at 8:12
  • I would say that a point system adds unnecessary stress and competitiveness to the work environment. Rewarding the top developer each month is just an insult to the rest of the team if everyone knows he's going to win every month without exception.
    – Kevin
    yesterday
0

Give it some time to what will happen with his productivity after a couple of years. If he is neglecting his basic needs, family, friends, his health, etc., he might be burned out in a couple of years.

Take care that his whole life is well balanced. Or better to say, encourage him to be aware of the importance of the other aspects in life, which assure that his productivity will be long lasting and will not result in a burnout.

-2

You did the right thing when you asked him to program in a language he didn't know yet. Keep that up.

Have Bob reprogram the microwave in the break room.

If your microwave is like ours, most of the buttons are probably useless and button combinations that a new user expects to work simply do not work. (Experienced users will have memorized some arcane sequences of button presses to achieve their desired cooking parameters.)

Bob is going to move on eventually. Your goal should be to keep him growing for as long as your can, and give him a plaque when you can't anymore.

Embedded programming (which is used for the keypads on microwaves) is extremely difficult and requires skill sets that Bob might not have yet. Assuming that is true, then Bob will have to grow to get the job done. And you'll get a better microwave.

Be sure to use your usual bureaucratic process to define the parameters of the project.

If Bob finishes the microwave project as quickly as the other projects, then it might be time to ask him to make a pair of network cards communicate faster than the fastest commercially available cards of their class.

If he does that successfully (and he hasn't yet figured out that he could work for anyone and left) then maybe you should ask him to take a close look at the fundamental limiting factors of your business. (You know, in the trucking industry, there are only so many gallons in the tank, and only so many hours in the day, etc. Those kinds of things are what I refer to as "fundamental limits".)

You see, I believe in Bob, as you do. I'd like to think that he'll go as far and as fast as his environment will allow.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .