How do you fire a developer?

Question

In an agile team, who's responsible for firing those that consistently fail to contribute? Should the individual recognize he might need to move elsewhere? Should the team bring up the matter, or should the manager take care of it?

Any advice on how to do this as humanely as possible? Also, how do you protect yourself from attacks? Developers have a lot of knowledge that could be used inappropriately.

Edit: Someone asked if this was in a corporate environment or an open source project. We're small corporation in which IT plays a big role. However, I'd also be interested in hearing how the environment affects the way you fire people.

Answer 1

A little bit of clarification is needed first - is this is a corporate project or an open source project?

Edit - If this is a corporate project then the best route to take is to address the issues that the team is having with the project manager and have project manager directly address the manager of the individual in question. If all goes well then the manager might just have to "crack the whip" and the individual should become more productive now that they know they are being watched closely. If they don't become more productive then it is the responsibility of the project manager and the manager to have that person removed from the project. Ultimately the responsibility of removing the person falls on their manager, and maybe the project manager, so any issues related to the removal should be handled by them.

Open source project are likely much different though as you are slightly abstracted from some of the other individuals working on the project if you never actually meet them in person.

Answer 2

The responsibility to fire someone in a company is always the person that manages the department that the employee works in.

You always need someone with personnel responsibilities in a company, and its these peoples responsibility.

Answer 3

The obvious answer is that its management that finally has to pull the trigger. If the dev is clearly not pulling their weight, the developer will already know this (whether they want to admit it or not). As far as humane goes, you can't really do it a humane way unless they quit themselves.

It's my opinion that if they are wasting time/resources, cut the cord, tell them specific reasons, and if they probably won't take it too harshly.

Answer 4

First try to figure out why the person is not contributing. If you are talking about contributing with ideas to solutions, could it be that he or she is to afraid to speak up due to overpowering co-workers or that he or she is just plain shy?

If it's actual code contribution you are referring to, it might be that the specific job does not suit the person and that he or she is bored and feels unchallenged. Moving them onto another piece of work might spark some enthusiasm.

Obviously if the person is just downright lazy or is just not suitable for the job then just let the person go.

Answer 5

If have found that most under-performers usually think they are doing a good job unless they are getting feedback to the contrary from their supervisor. And sometimes that feedback falls on deaf ears. So I would not be waiting for this person to bench themselves.

I think the only professional way to handle the situation is to bring up the matter with your supervisor. You have to get your facts straight and not get personal or overly emotional. Measures of performance need to be very transparent and applied equally to the team. Your supervisor might already be acting on the performance issue.

On the other hand if you are close to your colleague you might consider asking if they need help. This person could be stuck and afraid to ask for help. Or maybe they have some problems outside of work.

Answer 6

It may be possible that management doesn't know there's a problem. Unless you specifically tell them that said employee hasn't been doing any work, they may be completely oblivious to the problem. If all the work is getting done, because others are picking up the slack, they may have no reason to think anything is going wrong. I think, although it's hard to be the "tattle-tale", that you have to make it clear to management that there is a problem with the work said employee is (or isn't) doing. Having somebody who doesn't pull their weight, can create a lot of problems with the work moral of the rest of the team.

Answer 7

Here is how to do it to make sure the company and the code is protected. Schedule a meeting first thing in the morning the day of the firing, and the night before lock out his account so he doesn't have access to grab the source code or cause any problems if sees the writing on the wall.

The manager of the team is definitly responsible. And in many cases if everybody in the team sees this person as unproductive contributor than firing him will actually increase moral, because it means that their work is being recognized as valuable to the team. If you keep an unproductive person on the team it is demoralizing to the people contributing because it means their hardwork isn't worth anything.

Answer 8

If you have the time (meaning the project isn't so behind and broken that the changes needed to happen a month ago), the best path is to sit down with the person and tell them your displeasure -- and be specific. If you can't be specific, then you haven't really thought about the problem hard enough.

Then, together, come up with really high, definitive, measureable goals that need to be reached in a short timeframe. You can even ask the person to come up with the goals themselves - but keep pushing, so its really hard to hit them. Also tell them the consequences if they miss them (they'll be fired). If the person does hit the goals, well... then you may have just turned them around. If they do not, then they will likely understand what is happening and why it is happening.

I've found that if you set up a situation where you express your unhappiness with a person's performance, and then tell them EXACTLY what they need to do to fix it - when they don't get it done, they know what's coming and even accept it.

My old boss used to say, "I don't fire people, people fire themselves." I always knew if I was under performing and exactly how I was under performing.

Also, I think Joel talked about much this same subject in one of the podcasts.

Answer 9

The Manager has to take responsibility. Agile team or not, no-one is going to want to take that kind of talking to from one of their peers.

If the individual has been under-performing for a while then presumably they've had a verbal and possible a written warning? If so, they know what could happen and it ain't gonna be so much of a shock.

Whatever happens, the manager has to do it. Saying that, I've worked for a fair few spineless managers who would rather crawl naked over broken glass than fire someone. If seen many teams carrying no-marks because no-one has the nuts to get rid of them.

Answer 10

Assuming that you potentially want to keep the person around:

1. Tell the person they aren't performing at an acceptable level.
2. Tell the person what they need to do to improve. Set a clear timeline for how long they have to make the necessary improvements.
3. If they can turn themselves around (and most people can't), great.
4. If they can't, let them go.

That's pretty much all you do. This gives them a chance and gives you a paper trail to keep them from suing for wrongful termination down the road.

The rest is on them.

Edit I went back and re-read the question a bit and it seems like you're more interested in who actually has to do the unpleasant job of firing the person.

In my mind, that's the project manager's (or team lead, if you don't have actual project managers) responsibility. I think it's completely inappropriate for individual team members to have to deal with that sort of thing.

Answer 11

Any advice on how to do this as humanely as possible? Also, how do protect yourself from attacks? Developers have a lot of knowledge that could be used inappropriately.

Well, humane isn't really part of the equation. If someone is a really bad fit, then it's in everyone's interests for them to go - including theirs. Best thing is not to hire anyone you're not 100% sure of; what I found is that people always turned out to be how they seemed in the interview, and that the deficiencies we found in our interview tests were real ones and affected their work just like they affected their test scores; nobody ever gets better!

Depending what country you're in, you probably have a legal duty to give them a verbal and then written warning. It's only fair to make sure they understand what they are failing at and what they need to do to improve. Once the formalities are out of the way, give them notice.

If you are concerned about security, you're in pretty poor shape unless your development process is such that EVERY edit they make can be tracked through good version control and code review. Make sure you monitor what they do closely. And if there are signs of malicious intent, remove them from the building. Once they are given notice, I would say they should work out their notice at home without remote access.

Answer 12

In agile, doesn't the team manage / report to the team? In my experience (in an agile environment) the one time this has come up the team member realized they weren't fitting in and resigned. Now that might be a rare case (I have a feeling it might be). But again, in my experience it's been pretty easy to identify people that aren't contributing as much through the agile process.

Answer 13

a) "We find it's always better to fire people on a Friday. Studies have statistically shown that there's less chance of an incident if you do it at the end of the week." - Bob Slydell

b) while it's unfortunate, it's also almost inevitable that you have to fire someone. be up front with them regarding the reasons, take some of the blame yourself (really, you could have done better getting jobs in, or training them or whatever). and be civil about it.