Short-term options to mitigate burnout and demotivation while working with painful colleague

Question

In summary, I've been a tech lead on a project for over a year now, and during that time I've worked almost exclusively with one developer, who is probably one of the worst I've ever worked with (writing really low-quality and often incorrect code, and a lack of understanding/care as to how and why), and doesn't seem capable of improving despite receiving lots of feedback and training.

The developer says that he's clear on his responsibilities, but that's not how I see it, because he continually doesn't fulfil them. I've fed this back to the project manager, my manager, and the developer's manager, explaining that it's significantly impacting the quality of the project (e.g., by creating loads of bugs and technical debt). Their response is non-committal and implies that it's my problem. But the way I see it is, I'm a technical lead on a project, I'm not this person's manager, and I feel like this person needs a managerial level of support.

I'm now very tired and demotivated and have stopped caring as much, and have even started accepting code that I don't feel is suitable because I don't want to go through the same process of pointing out the same mistakes and bad practice as I was pointing out over a year ago. Of course I realise that 'logically' this is counter-productive, but I just don't have the energy to push back anymore. The endless cycle of pushing back just frustrates both of us and eventually one of us gives in.

I think the long-term solution here is to find a new job, but until that happens, what are some options to mitigate this burnout? A few things I've tried:

• Ask for myself to be taken off the project: No, because we're short-staffed.
• Ask for a different developer: No, see above.
• Train and feed back to the developer: Has no effect, and believe me, I really have tried, I've put a lot of effort into this which is partly why it's so demotivating to still be in this position.
• Enhance our automated policies to highlight (and auto-fix where possible) some of the most common, easily-fixable mistakes, which has been good, but for things like code smells and general incorrectness, this isn't really automatable.

Answer 1

I might catch some flack for this. But I am speaking from experience and have your best interests in mind, so I will just say it:

You've already done too much, and none worked. So the only thing left to do is: stop wasting your time doing all those things. You've been too engaged and you've done your best, and it didn't work. If the person is not pulling their weight and not performing, but cannot be let go, then all you can do is cut your losses: disengage.

Stop worrying, coaching, training, providing constructive feedback, feeling concerned about their performance.

Assign them tasks where the damage from their 'efforts' would be minimal as far as not being part of anything mission-critical, high-visibility, deadline-driven.

It's not harsh, it's fair.

Employees who refuse or are unable to improve in spite of all efforts effectively sabotage the work of their teams and their employer in the broad sense. They become a business risk, and risks must be contained. Simple, effective, easy to remember. Good luck!

Answer 2

It sounds like you own the code base and your managers accept your role as lead which means you have control over the situation. And I'll take your word that this employee is incapable of improvement.

You need to reduce the amount of effort it takes to manage this employee. Couple ways to achieve that:

• Assign them low priority, low effort tasks. The easier the task, the simpler the code will be to review/reject/etc. This also ensures that delivery is not affected.
• No interruptions. Schedule 15 minutes check-ins at the start of the day and 15 minutes in the middle for questions/explanations/code reviews. Because your interaction is now tightly controlled, they can't go back and forth with you at a rate that will tire you out. If they're the drop in type be firm and make them wait until the next check-in meeting.
• Instead of repeating yourself during code reviews or conversations, write down the explanation once and then forevermore link to that response. Copy paste from prior code reviews. If there are valid follow up questions, update the text. This database of knowledge will also be helpful if your team expands.
• Don't over review. For example, if there are 20 mistakes you spot, don't catalogue them all. Timebox yourself to 10 minutes and write up as much as you can (hopefully its just quickly linking to code standards and prior conversations). Wait for the next round to bring up the others.
  • To be clear, don't do this by default. My rule of thumb is that I provide feedback commensurate with their response to the feedback. Fix all the problems I identify in one round, get all the problems in one round. Fix problems one at a time, get problems one at a time.
• Ask your managers to put the employee on a performance improvement plan. This is more proactive than simply saying they need to go. And it's standard process at many companies if you want to fire them anyway. Google what goes into these, ask your HR if they have an existing process. Afaik, you shouldn't have to do any more than those check-in meetings, so don't worry about this somehow eating up even more of your time than before.
• Tell your manager to fire them but frame the argument from how it affects the business, their product and their clients, not how it affects you or your mental state. Here's how I'd start approaching that conversation:
  • They're not improving. It's normal for new devs to take time to adjust. During that time it is a given that they will slow things down, not speed things up by asking questions, etc. The payoff comes later when they learn enough to improve. No improvement means the new dev is constantly slowing you down; negatively affecting your teams' ability to deliver.
  • If you were able to go through a performance improvement plan, presuming the outcome was negative, you'd mention that as well.
  • Firing them clears up budget for finding another staff member. However, its costly to replace an employee, so know that there will be resistance to this point.
  • If they demonstrably messed up and cost the company money or reputation, I'd mention it.
  • Have good data to prove that the team functions better without this employee. Log the time you spend helping them. Save code reviews or chat conversations where you have to repeat yourself. You can pull these from chat history, old PRs, etc.

With the above steps, at most you're dealing with this employee ~30 minutes of the day. That's manageable.

Answer 3

The response I get when I ask others for help is that it's my problem and I need to find a way to deal with it. But the way I see it is, I'm a technical lead, I'm not this person's manager

It honestly doesn't matter how you see it, your management expect you to deal with it.

You need to have a conversation with your manager about what your role entails, because there's clearly a fairly large mismatch.

Answer 4

Ask for no developer at all

It's only a benefit having a subordinate if they produce more work than it takes to manage them. If it takes more effort to manage them than you get back, they are actively stalling your progress.

Of course management may not believe this. So ...

Put a cost on his mistakes

On your timesheet, add a line item for "Training Joe". If you need to, also add a second line item for "Fixing Joe's mistakes which he can't figure out how to do himself". If your timesheet system doesn't directly allow this, at least set up something like Clockify for yourself so that you have this tracked.

At the end of the month, you have evidence to take to management of how much he's adversely affecting your productivity. At that point you can directly say that he's cost the company $X in effort.

Track his mistakes

You do have something like Bugzilla, don't you? Looking through his list of issues and pointing out "CRx is the same issue as CRy last year" is evidence of a failure to learn.

Formal complaint to HR

I know, HR are not your friend. But HR are the company's friend. If someone is costing the company money, HR will very likely be in the corner of anyone who wants that to stop.

Answer 5

Management clearly feel that code quality and correctness is your job as technical manager.

Make sure you have a clear "definition of done" for each work package. Must be under version control, must build, must pass all tests (and must have tests to pass), and so on.

Then if you're fed up trying to teach this employee, take a hard line that every work package must be done before you will accept it as complete. But at the same time, ease off the "I wouldn't have done it like that" attitude to quality.

If it works, then it works. That's not ideal, but it gives you a chance to move onwards.

Answer 6

You've realistically got three options:

Option 1: Kick it "upstairs"

You say you've tried highlighting the problems to the project manager and your own manager. However what you've described is largely things that they are able to defer - partly because you've been handling the worst issues and partly because problems like technical debt can easily be kicked down the road to be a problem for the future. What you can do is kick this up a notch by flat out refusing to accept poor quality work - and treat it as essentially "not done" until it meets expectations. Keep your manager and project manager in the loop - but keep it simple, it's not "there's quality issues" it's "Problem employee" hasn't completed his tasks. That should encourage them to take a more active role.

This is risky - it can backfire on you if they somehow end up with seeing you as being the real hold up to the deadlines. But sometimes you have to go big or go home.

Option 2: Take the same approach as your manager / PM

The quality problems and the technical debt can become a problem for the Future. Unfortunately this is quite likely to actually mean it's a problem for future you. The potential upside is that you might have a better dev available to help you dig out of that hole once the debt comes due.

Option 3: Start being this person's "full" manager rather than just technical manager

Not always an appealing option - particularly if people management is something that you have no real interest in, and managing someone who is already proven to be challenging is, frankly, never a particularly appealing prospect. But it can get results - either because you succeed in managing them into something resembling productive competence or because they get tired of the unpleasant experience that is being your manager's sole focus when you're just trying to coast on a steady but crap level of performance and end up leaving. You'll have to get a replacement - but at least you get another roll of the dice and might get someone better.

The risk here is that the person just refuses to accept you managing them at all - if you aren't "officially" their manager then your authority is largely based on perception than any real backing.

Bonus Option: Leave

Not my favoured option - and I'd be reluctant to suggest this as a first action, but if it gets desperate you can always make this guy someone else's problem permanently by jumping ship.

Which option would I recommend? If I felt on reasonably solid ground with the organisation and was intending to stay there for at least the medium-term I'd go for a combination of Option 1 followed up by a bit of Option 3. If you're thinking you might be looking to move on before that technical debt comes due - well I'm not proud of it but given what you've already put in to trying to make this work then Option 2 with half an eye on the job market isn't the worst call in the world. No job or organisation is worth running yourself ragged or burning out over, you have to put yourself first!