Ask HN: Should I fire half of my team because their performance is terrible?

"I've tried lots of things to motivate them and didn't succeed." "I have to nudge them to get things done,constantly."

Sounds like the managerial and systemic failure is all yours, dude.

If you've not introduced automated systems to track what's being done and /help/ them (e.g. redmine, tracking relatively highly decomposed tasks, etc) keep on top of the work and the deadlines (and know why each deadline's important; i.e. who they'll be screwing over if they don't deliver) then you've only got yourself to blame.

Why would you think it'll be different with new people - because you'll just "be better" at hiring this time around? Unlikely.

J

(FWIW, I have no management experience, so these are just some ideas and questions from the other side. Good luck whatever happens.) If 5 out of 8 people working for me were sometimes good and sometimes bad, I'd worry I am not leading them right. Also, with so many people performing badly, is poor performance now part of your company's culture? What contact do your employees have with each other?

Before you let them go, have you analysed what makes the difference between their performance being good and bad? What have you tried to motivate them? Have you asked them if there is anything that would motivate them and if there is anything that is demotivating them?

One suggestion though: Are they being given enough direction? No-one likes a micro-manager, but having a couple of clear goals for what to get out of a day does wonders for my productivity. The thing is though, I'm not great at setting that for myself. Working with someone to set that kind of daily target is great. You say you have to nudge them constantly, but I'd argue you are probably an exceptional person (e.g. starting your own company and employing 8 people.) Setting goals and direction is what you are good at. If your employees were good at it, they wouldn't be working for you, they'd be your competition!

As others have said, it does sound like a management issue. One thing that might be interesting is figuring out why the other 3 are doing better. Do they work on different parts of the project (or even a different project)? Do they communicate more amongst each other or with you, do they have a personal bond beyond the "colleague" level? Do they have equity or some other motivating factor? It could well be that they do just naturally have a lot of drive, but if that is the case you're doing pretty well at 37.5% self-motivated employees.

Perhaps, rather than firing all 5 of them, you should hire a really good manager who can work with them. Or, fire the worst of the lot, and use his salary to hire a manager.

Focus on what you're good at, and if you have the money, hire someone to fill in where you're weak.

I've asked very similar question. Check comments in it as well

Ask HN: Should you fire average devs and have only talented devs in a team? http://news.ycombinator.com/item?id=1634231

I am curious what kind of motivation did you try? Also it is hard to work remotely and many people just can't do that.

How often do you all sit in the same room?

How often to you pair, or simply work together physically?

First thing that struck me was the size of the team. Eight techs is a big team, especially for a start-up. I'm generalizing, obviously, as we have no idea what you are doing. It would help to know whether you are building product or service.

We need more info to offer good advice. Though it does sound like you need assistance.

I have been on the other side. I'd like to think of myself as an excellent programmer, but occasionally I'm hard to motivate myself.

The main reasons for that is that the job is boring, and the feeling of getting nowhere, being stuck. The thing that motivates me the most is the feeling of getting things done, fast.

In other words: it's a vicious circle. People are demotivated because they are in a rut, and people work fast because they get results, fast.

The best thing to do now, to get them out of the rut, is to stay on top of them. Deadlines are meaningful only if they are real deadlines, like "this feature must be done by next week", and not some artificial goal like "work on this for 30 hours". BTW 30 hours for a single task is much too long, it should be broken up in smaller tasks. Set real short term goals. And if they are getting nowhere because there is something that they cannot finish, you may switch tasks, so they get something new to do, instead of just continuing working on the same old. Let a few people work on one task together, I've noticed that often that is a motivation booster, myself. But always: small, meaningful goals.

And, yeah, I agree with the others: switching to new people will not help, though it might seem to do so temporarily, for as long as those new people are new to the tasks. Once they get in a rut, it's back to the old situation.

I am fascinated that in this economy, employees need motivation beyond the length of the unemployment line.

Nudging them to get things done is to be expected for many employees - it is considered good management practice by many. They are employees, not founders, and you should expect them to need some nudging - the solution is to develop processes to give them the nudging they need to make them worth what you pay them to you.

I'd suggest calling all 8 for 5-10 minutes a day (it's less than an hour of work - if you don't have time for that, appoint someone else with the skills as manager). Ask them for a brief verbal description of how they are going, what problems they are facing, and what worked. Make it mainly positive - praise them for what they have done, guide them on what needs to be done, and if needed, gently reprimand them if something isn't so good. Keep it short and focus on the needs of the business and give them autonomy when possible, unless they need more help.

If you find that, even when properly managed as above, performance means they are not worth what you pay them, schedule an in-person meeting or if that is impossible, a call. Tell them their continued employment is at risk, and let them bring a representative if they want. Make sure you observe all employment law and contract terms applicable to you. At the meeting, explain that their current performance is making them a drag on the business, and explain exactly why. Give them plenty of time to explain themselves. Then, ask them how they can improve their performance. Set achievable milestones at the meeting for them to step up their performance to a reasonable level that everyone is happy with. For coders, that could be a list of tasks to finish, with times they will finish them by. Ask them if there is anything you can do to help them improve - and if it is reasonable, do it.

If they don't meet the performance targets, and don't have a good enough reason, then you can think about dismissal (in accordance with their contract terms and applicable employment law).

Dismissing so many people is going to kill morale at your startup - if it looks like you have to, you might be better off trying to start a new one, sell assets to the new one, hire the good ones, and wind up the first startup making everyone redundant (to the extent that is legally possible). If the first startup is financially solvent, you can sell assets (e.g. your codebase, trademarks etc...) to the new one.

If you do hire people, the most important thing is to get someone who knows the field the potential hiree is in to assist with the interviewing. Ignore bits of paper like qualifications or resumes, except to screen out candidates who don't even claim skills you need. Don't believe anything in a CV or that any qualification means they know anything you need - ask them to solve a task that would take a good employee an hour for you, and rate their work. Also look for experience that is actually proven - working in a team for a big company doesn't prove much, even with references. Look for good quality Free / Open Source code (actually look through the revision history, and check the quality of their commits), or successful projects where they were obviously behind it (a history of consulting as sole programmer on different successful jobs for one business could be good evidence).

It's ok to work remotely but I don't know if I could have a case where it was all remote working and never meeting up, as a long term employee, not sure about the situation here. Even if it was only every 6 months or a year a meetup could put everyone on the same page and identify these problems far better than you can remotely.

Firing so many people is scary for the remaining employees. Just fire the worst offender and hire a replacement. That might be enough to turn the team around.

Motivating telecommuting programmers is a big issue for startups. If you manage to do it properly, please come back and tell us.

first, you will have to nudge nearly everyone you hire. this is part of managing people. get over it, and learn how to nudge effectively. Note, each person requires a different kind of nudge, but nearly everyone requires at least a little. Employees who don't need those nudges are very rare, and become expensive quickly. If you have lucked into one, keep them happy. (note, though, my experience has been that while these sorts make incredible individual contributors, they generally make poor managers.)

Next, though, you do sometimes have to fire people. this is the way it is. If you don't know how to nudge those 5 under performers into performing well, and you are unwilling or unable to figure out how to do so, you will have to fire them, even though they probably could have performed acceptably under different management. Let them go and hopefully they will find a place where they fit.

As others pointed out, this will kill morale at your startup. Do it quickly and respectfully, and maybe give your best people raises or bonuses at the same time. The big danger here is that your best people will leave at this time, so take extra care with the people you want to keep.

Me, when I fire people, I try to frame it as my fault. I mean, I hired the guy, right? and it's my job to manage them. If they didn't work out, I think it's best all around if I publicly and sincerely accept the fault. And really, it's best if I think it's my fault. I mean, I can change my behavior; if I can learn how to hire better or manage better in the future, that's a big win. Feeling ripped off by an employee, on the other hand, is almost never productive.

It's best to remember that in other situations, these people might be pretty good. I certainly know I'm not the best manager in the world. There is no reason to make this any more painful than it has to be, and really, there is no reason to publicly say anything bad about these people. You will meet these people later in your career, and your employees will maintain personal relationships with some of these people, so the better you can have them think of you, the better off you are.

If you can spare the cash, give them some severance. Even a week or two is a lot better than nothing (and in the startup world, a lot more than the employees probably expect.)

Now, when it comes to hiring; what I do is that I make it clear it's a contract assignment, at first, without any expectation of continued employment. If they don't work out, there's no more work. I pay them and we part friends. If they do, I can slowly work towards an expectation of longer term employment.

As for telecommute vs. office, well, it really takes a specific personality type to telecommute effectively. I recently got an office, and I note a marked improvement in productivity both from my PFY and from myself, on days when we both decide not to work from home.

  Employees who don't need those nudges are very rare, and become expensive quickly

I had a small telecommuting team once, and what helped us a lot were two pieces of technology around which our development process was built.

The first one was a simple issue tracker. The 'nudging' and 'motivating' bit became almost redundant. There always was a list of issues that needed to be addressed one by one, and the employees could work on the simplest ones, or on the complex ones, depending on their skill level and personal energy level at the time.

The second piece was the idea of short 'sprints' we borrowed from the Scrum process. Each week we aimed to deliver something that worked, so there was a set of issues that needed to be addressed as a matter of a priority. In this way the team stayed motivated and saw results of their work, i.e. there was an (almost) instant gratification.

Interestingly, one of my developers was a 'star', and another was a 'rookie', but they found a happy balance under this system. The experienced one tackled complex/architecture related issues and avoided the boring simple tasks which the less experienced employee was happy to do because that kept him feeling productive and contributing.

The management process consisted of a weekly skype conference call where we would agree on a issue set for the next 'sprint', and then we simply communicated through email to check on the progress during the week and to address problems. Obviously, I had to write up the requirements (in the form of issue tickets) as well.

Again, a simple issue tracker (we used Roundup) was the single most useful management tool for that project.

It is your job, as a leader to make sure the team performs well.

No one, themselves want to perform bad. If I am spending my time on something, or if I am committed to something, I might as well do very well in that time.

But sometimes, performance is bad. Not because one cant or one isn't interested but because there is some thing preventing one from doing it. It could be a personal problem, but more likely a communication gap or some cultural difference.

Most people do something because they feel like it and not necessarily because they have to do it. It is your job as an employer to ensure that they feel like it. This is exactly where the company culture, peer performance review and the like help a lot.

Or you might as well hire self motivating individuals, far too little, generally.

I think at 5 out 8 it's not a mere firing, it's a bloodbath. If you've built any kind of team cohesion, you'd be throwing it all away. Obviously, if they're all critically detrimental to your business, fire the lot and eat the hit. Have you considered firing maybe 1 or 2 and seeing if it improves the performance, overall?

All telecommuting? You mean they hardly ever see each other or you?

I'm surprised they're doing anything at all.

Are they from the same country as you?

1/ Install agile process:

issue tracker (fix bugs first),

CI,

weekly deliverable,

daily short conference call: what's up? what's next? any block?

3/

Loop Hire a new fellow, based on github track record Wait a while. Fire the most damaging.

Repeat until you'r happy

Somehow I see some red flags. If they are getting well paid, happy with business and are honest about their own negative performance evaluation, I doubt if the problem is on their side, unless they were technically not upto the mark to begin with.

Even if thats the case, where they are lacking in technical competency, if I can afford, I would love to have such a honest team and would rather work with them to help them reach higher levels of performance. It can result in an inspired and loyal team - please note, it is 'can' and not 'will'.

Even the best team will fail, if the system and expectations in which they work is not set up right. By 'system' I would also include, the goal setting, delegating of responsibilities, method of checking accountability, the method and tone of communications, etc.

I consider its the leader's personal responsibility that the 'system' is set up right and keeps getting fixed and mended when required.

Though I would prefer a non-telecommuting team as I think it has some strong inherent advantages, a successful telecommuting team is not impossible. I have been running a telecommuting team (programming team + testing/requirements team) for around 8 months and am very happy with the way they work. Now I don't even have to intervene, just tell them what feature to work on, and they coordinate with each other and get it done real fast. (Partly, luck is involved, was able to get some really good programming lead and testing lead)

But, there was this instance soon after the testing lead came in. There was this exchange of emails between him and the programming lead over some misunderstanding and they were going on back and forth on whom to blame between the two. I could foresee it screwing up rapport between them with long term ramifications for me, stepped in right away, took the blame for the misunderstanding ( I think I did have some responsibility for that), so that they can focus on fixing the problem and move forward. It worked.

A bit later, I wrote up and sent some philosophical crap to both, about all of us being imperfect and all the great things in the world getting built by imperfect people and systems. ( I do believe that crap though :) ). Its been more or less smooth sailing since.

If the problem is indeed with the people then firing may be a good solution. But if the system is the problem, you will be having the same problem again. So do check if the problem is with the system.

If you do have to resort to firing, try one at a time but for a definite and solid reason and communicate that reason to others. That single firing itself can bring about positive changes in thinking, actions and performance for the rest, provided the system was not the problem.

Mass or in-explained firings will bring down the morale and can also bring down your credibility with your remaining and new employees. I have seen it happen.

Sorry for the long post, just wanted to share my perspectives and experiences in case it helps.

Good luck.

Sometimes you do have to fire people. Have you fired someone before? If not, fire 1 person, the worst performer. Then have a talk with the others. But be careful.

Also, it looks like you hired badly. Hiring is hard, consider it a lesson and work really hard on doing better next time.

Is there an opportunity to get everybody in the same physical location for a day? Either way, maybe it would be good for you to have a clear the air session, communicate vision/direction/expectations, allow them to communicate their issues with you etc. In my experience as a manager, when I see team performance start dipping etc.. then I start to identify why and maybe introduce new ways of doing things, i.e. keep reinvigorating the team. Communication is vital in your team; have short audios on a daily basis if you can afford it. Keep track of issues. Inject some spirit into your team.

I couldn't offer advice on whether or not to fire without criteria more specific than 'performance'. Presumably, you aren't hiring people to perform you're hiring them to get a job done-- and what specifically about that job has not been done that you need done?

Unclear expectations and confusing priorities can make motivation very difficult. You use the term 'performance' 5 times and I still haven't the slightest idea what these guys are supposed to be producing except that they are "technical." I understand you don't want to be identified and that's fine, but if you use this kind of imprecise language with your employees, they'll just nod and vaguely agree to get through the conversation. Five minutes later they'll realize the conversation was completely pointless.

From the perspective of someone who's been telecommuting for the past year-ish: if they admit that their performance problems are personal, and it's just a lack of discipline on their part, maybe they're not cut out for it.

You've got to be able to ignore sunny days and log some productive hours, and if you can't you're not cut out for telecommuting. And if you've got this culture of being lazy and not taking deadlines / goals seriously, the 3 competent guys are going to realize at some point that they have no real motivation for being competent.

I'd make an example of one of the peons, give the 3 a token raise/reward, and have a chat about what's acceptable and professional.

And if you're looking for a contract guy who can deliver, shoot me an email ;)

Firing 5 out of 8 people is an indicator that you are not good at hiring or not good at managing them.

Try these podcasts, they talk about both topics. http://www.manager-tools.com/