Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 26, 2014
arrowPress Releases
October 26, 2014
PR Newswire
View All
View All     Submit Event

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

You Won't be a Good Manager if Can't Let Someone Go
by Greg Holsclaw on 10/18/12 05:04:00 pm   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


You are FiredPaging Donald Trump!!! Do indie devs and indie studios stay mediocre or bad because they won't part ways with someone not pulling their weight?

"You Won't be a Good Manager if Can't Let Someone Go" were the words a close friend utter to me in the midst of my latest project. But is it true?

Must you go through the pain of letting someone go before you can really be good at managing a project/studio?

Let's discuss in the comments, because I haven't decided yet, but I will give one main thought on why it happened for me. NOTE: Is related to our upcoming game, Lab Bunnies.

I am sure there are plenty of MBA courses that have tread this ground well, but I want to share my experiences over the last few months. I will keep the details to a minimum since the project did get back on its feet, but after a replacement was made. The first person wasn't bad, might contract out to them again if the timing and projects align, but they just didn't in this case and so a change needed to be made.

I came from the start-up world, where one mantra is 'Hire fast, fire faster'. But as a team leader, I was never directly in the chain of command that made personnel changes (I advised/interviewed candidates for hiring and was consulted on a few potential layoffs). But I never had to pull that trigger and have that tough talk.

The weight of first trying to fix the issues (second chances, re-rolled deadlines, ….) while knowing that if things didn't improve was a great motivator to try and get it right without having to go the distance and lay someone off. Since I had never let someone go before, I was avoiding it like the plaque. Give another chance. Find a workaround for the issues. Try to find new motivations to keep them engaged.

Nope, none of it was working. That is when a close friend who was watching me struggle uttered that opening refrain. From the outside they could see the project was going to fail because I couldn't move to replace a team member. And if the project fails, in indie studios at least, the chance of the whole studio failing goes through the roof. So I made the change, made a bunch a waves, hurt some feelings, but not as bad as I thought it would shake out, and we finished the project.

But can a studio do great things without going through this process? I sure hope so.

At Least I Learned Something - It was my fault!

Taking responsibility as the manager of a studio or project is the first step to doing it better next time. If you have to let a contractor or employee go, then the person who brought them onto the team is in responsible. On reflection, the first person (only person) to blame was myself.

Was their skill level matched to the task? Was their compensation set properly to motivate them? Was the project novel enough to keep their interest? Did they fit into the project's culture?

These, and more, are the questions you should have nailed down before adding that team member. If later you find out they aren't a fit, or aren't motivated, it is your fault for not digging deeper at the beginning.

For me, I rushed past all these questions. The other main team member recommended an individual for certain tasks. As a friend-of-a-friend, I moved forward with the person.

Later, as deadlines were missed and quality declined, I found out:
- Skills for some of the project tasks were lacking (wanted to learn new stuff)
- Availability was much more spotty than originally communicated
- Compensation mix was off (rev-share mix didn't motivate, as it does some people with a desire to 'own' a project)

Solution: We hired a hourly paid contractor whose compensation and skill set matched exactly the tasks we needed to accomplish, and whose availability was there to rush the project along. We took 2 weeks, numerous paid samples and trials until finding the right person.

Main Takeaway - A short-cut in hiring produces many more delays than taking weeks or a month on the front end to find the right people.

So back to my original question, primed for discussion:

Must you go through the pain of letting someone go before you can really be good at managing a project/studio?


PS: Check out our new iPhone 5 ready game, Lab Bunnies. Coming Thursday, Oct 25.

Related Jobs

Digital Extremes
Digital Extremes — London, Ontario, Canada

Character Artist
Digital Extremes
Digital Extremes — London, Ontario, Canada

Sound Designer
Disruptor Beam, Inc.
Disruptor Beam, Inc. — Framingham, Massachusetts, United States

Lead 3D Artist
Red 5 Studios
Red 5 Studios — Orange County, California, United States

Graphics Programmer


Benjamin Quintero
profile image
Letting people go is just one bullet on a long list of responsibilities for a manager, but it is not some kind of mutual relationship to being a "good" manager. What is important is knowing WHEN to let someone go more than building up the courage to pass them their pink slip. Some people are strong assets when you use them the right way and others are just anchors for your team who offer little help. Some guys will complain endlessly but they may also be your top content producers (ie: most and best quality of work). It's important to recognize where the strengths are and where the weak links are, beyond what you perceive of each person. Look at the concrete facts and ask your staff who they think the top 5-10 employees are and why (not the weakest); you may be surprised at who trickles to the bottom or who bubbles to the top.

That line about "good managers" sounds like something your boss tells you right before he asks YOU to fire his secretary =). I wouldn't take that statement about good managers too literal, just use it as a guideline to know that you can't drag anchor forever. Eventually you are going to catch a reef and sink your project...

Greg Holsclaw
profile image
Benjamin, in this case it was less about weak link, and more about timing and motivation. This project just couldn't offer the right mix to keep them going. Hopefully in the future that won't be an issue, but as a fledgling studio, we have fewer options to keep things going.

Adam Rebika
profile image
In such a small team, I understand you had problems firing the guy, as relations can grow much more personnal than in a bigger company.
Now I think the important word in this industry is *team*. More than the abilities or availability, you should look at what the worker is actually bringing to the team. Some skilled worker that will, to attain personnal advancement, backstab other teammates or more generally bring in a bad atmosphere in the workplace should be disposed of, while someone who may not have all the skills someone else might have - as long as, of course, he's qualified with his job - or have a lower availability than normal, but makes the team more productive by improving the atmosphere, passing data around should be kept. It's all about finding out what exactly are the personnal skills that this guy will add in addition to his professional ones (this applies less in smallest companies, where everybody has to give as much as they can to the project).

Greg Holsclaw
profile image
Adam, I once had a former Deloitte Consulting project manager tell me they had done a research survey which concluded that it is better for a high performing team to have up to 20% down in-between projects (while keeping the team intact) than to break up the team. More or less, that means there is at least a 20% productivity boost from in a well function team, as apposed to an ad-hoc team that is brought together for a few months, and then disbanded after the project is complete.

I think this hits the point you are making, that assembling a team (not just a group of individuals) is highly important for success.

TC Weidner
profile image
anyone can fire someone, that doesnt make for a good manager.

Jonathan Jennings
profile image
The Key is knowing when and if to fire someone i think. the fact of the matter is that we are developers and not only developers, game developers. we probably have one of the most consistently experimental carrer paths possible and if you expect to surpass others who have developed something similar you have to go above and beyond what they hav already done. the issue however is game development is in my experience NEVER a smooth rie their is always going to be a bump in the road or a stall somewhere. You gain knowledge as you continue to develop games across the board and if you approach development with the attitude that when a project stalls it is time to continue the process with someone else I think you rob the individual in question of growth and you lose any knowledge they have used on the project as well as all the knowledge they gained and could have gained.

i won't say there is never a time to fire someone nor will i say that you should exhaust every option because if a person just isn't doing their job i think you have every right to replace them with someone who will. It's a complicated issue. personally i think it all hinges on the health of the team and the project without the person. At my job we had a lead programmer who was extremely crucial to the project but consistently failed the team and often times didn't do his job .

It was tough call that hurt the project in several ways because we lost essentially the information hub behind our game BUT a new lead programmer who had the previous's skill set , gained his knowledge , and optimized the projects in ways the previous thought was impossible or just didn't know how to.

it's definitely a case by case situation because rarely is just letting a person go not going to cause some sort of ripple effect.

Diana Hsu
profile image
Being able to fire/ lay off someone (not "letting them go," as presumably they were free to leave at anytime) is just a task that needs to be done as part of a manager's responsibilities. Not being able to do it is a weakness in a manager, but being able to do it certainly doesn't make someone a good manager.

What makes a good manager in this area is knowing when you need to fire someone, how to do it, and how to deal with the potential fallout.

profile image
"At Least I Learned Something - It was my fault!"

This is an absolutely true phrase. As a developer if you messed up some code/tests/design you should own your mistakes and deal with them. The same applies to the case of hiring and firing. Luckily it sounds like this relationship was informal, but it's such a headache to remove someone when there are legal points involved. You don't have to be Trump-ish and act like you enjoy it, but it has to be done, and like all these nasty things the earlier you move the better for everyone. This is assuming you've been a good boss to that point and clearly communicated things like deliverables and consequences for failure etc.

Michael Wenk
profile image
Honestly sounds to me like you're beating yourself up on this question.

"At Least I Learned Something - It was my fault!"

So? Your point? If you expect everything to work perfectly, you will fail because you're not setting your expectations properly. If you're setting blame, then I really have to wonder why. Does it matter? Of course if you do the same thing several more times, then I might well question your ability, but you will fail. The important thing is to fail fast and in a way that minimizes impact.

Vetting employees is one thing you should do, but in this day and age, you don't always have the time to do so. So if you come away from your mistake thinking that you always should vet an employee, then you're likely setting yourself up for another failure.

In my opinion your only mistake was letting it go on before nixing it.

"Later, as deadlines were missed and quality declined, "

You should have set your own deadlines before milestones and then when they weren't met then have a heart to heart, and if the heart to heart doesn't get what you need, then you need to take corrective action.

Does that mean firing? In this case yes. Does that suck? Yep. So in a sense I agree with your friend. But I would go further. If you can't and are not willing to recognize failure, and act fast to mitigate it, then you might as well not try. And that doesn't always mean firing. It could mean any number of things, cuz like you said, the person that failed this time may well succeed in something else.

Greg Holsclaw
profile image
Michael, you definitely seem to be echoing the term, 'Hire fast, fire fast'.