54

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.
12
  • 2
    " I don't want to go through the same repeated cycle of me pointing out the same mistakes and bad practice as I was pointing out over a year ago" How are these mistakes and bad practices being corrected each you point them out?
    – sf02
    Nov 29, 2022 at 15:07
  • 13
    @sf02: seems like they're not corrected, despiste being told and explained and expected to be improved, and that frustrates the OP
    – OldPadawan
    Nov 29, 2022 at 15:33
  • 2
    what kind of mistakes and bad practises? Setting up a process where some checks needs to be successful before the code gets to you might help. e.g. code has to compile/run without warnings and the project is set up to issue warning on the most common mistakes made.
    – bracco23
    Nov 29, 2022 at 15:46
  • 2
    We have automated checks that cover things like code building and tests passing, the problems mainly arise during code review when something has been implemented either incorrectly or the implementation is very low-quality and introduces bugs and technical debt. I normally point out things like this during code review (and I try and be nice about it, e.g., "have you considered" rather than "this is wrong").
    – Touchdown
    Nov 29, 2022 at 16:13
  • 9
    Sometimes caring too much about work you're doing for something else is counterproductive. If the company doesn't care enough about the code quality to support you, why are you driving yourself crazy over it? Take that focus and energy and invest it in something that has a better ROI for you or something you love. You can't force someone to care as much as you do. What could you be spending time on if you weren't getting your soul sucked out on this project?
    – ColleenV
    Nov 29, 2022 at 17:27

6 Answers 6

90

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!

10
  • 32
    Sometimes we have to accept other people's limitations, even when it seems like they could overcome those limitations if they just cared enough.
    – ColleenV
    Nov 29, 2022 at 17:20
  • 2
    Yes, I upvoted. I was just expressing my agreement.
    – ColleenV
    Nov 29, 2022 at 17:28
  • 2
    The thing that is missing in this answer is what's in the other answer: Make sure their manager and your manager know what's going on and ask them if they can help. Discipline is his manager's responsibility, and both should be interested in finding a way to overcome this (which may mean giving you someone else to work with). If they don't consider it a problem, you need to look hard at whether this is an environment you want to fix, tolerate, or leave.
    – keshlam
    Nov 29, 2022 at 17:56
  • 5
    I've been there too and couldn't agree more with this answer. Just make sure you are ready to explain to higher ups why your work, while keeping up with standards, is now slowing down. You can't accept lower quality and therefore have much to do by yourself to keep up the required level of quality. You're doing the best out of what you're given...
    – OldPadawan
    Nov 29, 2022 at 19:43
  • 3
    Thanks, I do get what you're saying. Ultimately this probably is the most sensible answer given my position. Part of me feels like "come on, I can fix this," and doesn't want to give up, but there has to be a limit because it's causing me stress and burnout, and I don't think this is something I can just fix on my own with my current skills and experience. I have already started giving them lower-priority tasks, but the problem is we're such a small team that this developer will inevitably have to do some of the more important tasks.
    – Touchdown
    Nov 30, 2022 at 16:57
37

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.

5
  • +1 I think this is the only answer (currently) that recognizes the OP just needs a stopgap until s/he leaves AND explains a good working set of principles to reduce the stress without just dropping an important part of the job. Nov 30, 2022 at 15:34
  • 1
    I think this is a good answer - I have actually been doing some of this, for example, I've created a team wiki where I document the problems we run into and their solutions/workarounds, and I encourage this developer to contribute to it as well. I think the best point for me to take away from this is "no interruptions" - reducing the frequency at which I have to interact with this developer and facepalm should help alleviate some of that stress.
    – Touchdown
    Dec 1, 2022 at 9:07
  • If personal engagement is tedious and frustrating you can always just leave short comments and decline pull-requests from this Dev until the code reaches adequate quality. Productivity will drop, but this will be clearly visible to management and not be soaked up by you and your health.
    – Falco
    Dec 1, 2022 at 12:25
  • Another bullet point for your final list: make a list of the types of repeated errors that you're having to catch, and explain to their boss how much it could cost the company (in terms of money, reputation, schedule, legal compliance, etc) if one of those errors was missed and made it into production. One of those bugs will eventually make it through, and their manager needs to know the level of risk that they're accepting by hanging onto a bug generator.
    – bta
    Dec 1, 2022 at 22:40
  • Enhancing documentation / adding to the test suite are good tasks in this situation. If he actually delivers value, good (and it shows he has learned something about the codebase meanwhile). If not, you can reject his changes in a loop until they are ready without holding up the rest of the project. Of course, it means he isn't delivering more useful value, but he isn't doing that anyway, and at least it avoids him being a constant drain on everyone else's time. Dec 5, 2022 at 9:05
13

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.

2
  • You could try involving the manager in code reviews, especially when there are many problems noticed. You could also ask the managers for "help" or ideas for how to get this employee to improve. Doing this could help them see that this person is taking up a significant amount of time. Just because they think it's his responsibility to lead doesn't mean that he has to go it alone.
    – Kevin H
    Dec 1, 2022 at 18:45
  • 1
    The managers job is to manage. Most likely they can’t do code reviews. I’ve had excellent managers who couldn’t do code reviews. What OPs managers do is refuse to manage.
    – gnasher729
    Dec 3, 2022 at 11:20
12

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.

8

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.

7

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!

2
  • OP has said s/he's basically leaving but needs a stopgap/workaround to reduce stress for the time being. I don't think your suggestions really help with that. Nov 30, 2022 at 15:31
  • @Chan-HoSuh I disagree: that the situation needs a "stopgap" solution doesn't really change the solutions available; it just changes what proportions of each solution you want to use, and how severely you might want to implement parts of each one. I actually find this to be the most useful answer, in particular because we don't know how long the stopgap is need for. (A month? Six months? A year?) Probably the OP isn't even sure how quickly he'll be able to change jobs.
    – cjs
    Dec 2, 2022 at 4:20

You must log in to answer this question.

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