 |
|
|
| |
Opinion: How To Tackle Work For Hire
by James Portnow [PC, Console/PC, Columns, Exclusive]
|
|
| |
|
June 26, 2009
|
| |
[Should your studio take on work for hire? Sometimes -- in this opinion column, Divide By Zero's James Portnow tackles the deceptively complex issue and breaks down the whens and hows.]
One of the toughest questions for any startup developer is whether or not they should do work for hire. It provides revenue, which can look awfully appealing at times, but it can be a big distraction from the reason you started the company in the first place.
A little backstory: Ever since we opened up our iPhone division, we’ve been flooded with requests to do work for hire. Not just iPhone games, but everything. Up until recently, I had dismissed offers of work for hire out of hand: I tended to consider contract work a pernicious trap.
Of course, something strange started happening when such work came in in volume.We got work for hire offers that I actually thought were neat -- by which I mean we got work for hire offers that were interesting and compelling, independent of what they paid... work I’d be doing in house if I had thought of it first.
Eventually, the temptation was too great and I caved and started taking some of these offers. Below I’ll detail what we’ve done to make contract work as positive as possible for the company, what we’ve done wrong, and what I feel is unavoidable.
The Problem
I’ve seen many studios begin doing work for hire because they needed capital and end up losing focus. They become work for hire houses that die out in a few years without ever accomplishing what they started their studio to do. When I began taking on work for hire I told myself I had to do the following things:
1. Distract as little as possible from the main endeavor.
2. Keep employees satisfied with their jobs (not have them feel like they’re being relegated to ‘lame’ work for hire work).
3. Have the work for hire more than pay for itself (this one sounds very basic, but I’ll explain below)
4. Add value to the company.
The Answers
Establish a New Division: After the first project, when we decided we were going to really start doing work for hire, we established a new division of the company for it, wholly separate from the core development team working on the main project.
This had the advantage of minimizing the distraction from the main project and allowed us to establish new standards and guidelines specific to the work for hire division.
It also allowed us to offer a different pay scale for the work for hire team (they get less salary but they get time allotted to work on personal project which Divide by Zero helps publish and which they get the lion’s share of the revenue from, on occasion they also get part of the rev share from the projects they work on).
When I say Divide by Zero is going to do something, I don’t believe in total subcontracting. I believe the quality of the work and the dynamics of the team are simply better built up over time in house.
This has the disadvantage of keeping people on salary. This means that the division has a fixed cost per month, which either has to be covered by work for hire or we have to take a loss: which means that it’s takes a lot of will to remember to...
Choose Work Carefully: Up until this point we’ve been an entirely equity financed company, this means that we aren’t relying on work for hire to survive.
I’ve seen many studios which will just haphazardly take absolutely everything that comes their way, sometimes because they need it to survive, sometimes because they don’t know when other work will become available (and sometimes because they just get caught up in the whole contract work thing and don’t take a step back and look at why they are doing it). This is fatal.
We’re very careful about what we choose to take: we probably reject work for hire offers on a 6:1 ratio. It was incredibly difficult to take a step back and say, “I’d rather take a loss on the work for hire division and give them more time to work on personal projects in any given month than take the wrong work.” But I believe it’s one of the best decisions we’ve made regarding this part of our business.
Ask Who Wants to do a Project: One of the core requirements for us to take on any particular work for hire venture is to make sure that we have people who are excited and passionate about doing that particular work.
Before I accept anything I go to the work for hire division and say, “We’ve got _____ coming up, who wants to work on it.” If I get back a positive response from a group of people with the required skill set and I believe they have the time in their schedule I greenlight the project, otherwise it’s a no-go, even if management is interested in doing it.
Not only does this increase the quality of work we turn out (in my opinion), this keeps morale very high in the work for hire division and actually makes it easier to get things done.
Anecdotally, people in our work for hire division psyche each other up and ask each other for favors. If a team is mostly formed but doesn’t have one of the people it needs, the people who want to do the project usually convince whomever they need to get on board. I rarely ever have to step in.
Also, this is the only case where I’ll contract out. If we’ve got 3 people raring to go and they need one more person to complete the project I’ve had teams come to me and say, “I know this guy, I’ll get him to work for almost nothing and I’ll totally manage him. If he fails I’ll take responsibility.” In that case I’ll give it a shot. It’s worked out well for us so far (we’ve even hired someone out of a situation like that).
Approach Companies: If you are going to do work for hire, biz dev is important. While a lot of work just comes our way, we’ll actively go seek work if we think it’s cool. Often we’ll be at lunch and someone will say "Wouldn’t working with X be awesome?"
If it gets a resounding "hell yeah," then we go out and approach those people. Part of our core work for hire business is reviving dead IP (you’ll see in a few months…) and helping companies expand their IP into the interactive space. This allows us to continually work on projects that we think are compelling, but would be impossible if we just sat back waiting for business.
Do The Math Right: Don’t try to overbid and don’t try to impress anybody by bidding low. Assume everyone’s acting in good faith and be okay when they walk. You’re not going to get every contract.
Remember, everything’s going to run long or need some extra hands on it, there’s always unexpected changes in this sort of work, so budget for it. So long as you’re giving an honest estimate of what you think your team will require no one will fault you.
A word of warning -- make sure to be very clear on what you’re being contracted to do. Many entities don’t understand what it takes to make games, and when dealing with contract work we find that often people change their minds or come to realize what they actually want only after the work begins.
Don’t be afraid to let your client know when they want you to do something that exceeds what you originally agreed upon and will cost them more money.
We usually recommend to clients that they commission us for a design spec first. This is less risk on both sides and is the cheapest way to attain clarity and make sure that everyone’s talking about the same project.
It also gives both sides a clean break point to work with other vendors if we discover the project is something that we can’t really handle in-house (and if they do choose to walk, at least we’ve provided them with a document that they can take to anyone else to determine if they’re the right vendor for the project).
Be Flexible: We’ve had some crazy stuff come across the desk when dealing with contract work... and crazy stuff is often the most fun (and profitable) to work with. We’ve specifically built the work for hire division around people with a broad set of skills who are willing to dive into anything and learn (who knew how handy a working knowledge of ancient Greek would be?).
Additionally, as a business, you have to be flexible: if someone has a big meeting with their funder and needs a document done in two days you’ve got to figure out a way to make it work (assuming of course they’re willing to take on the cost associated with doing so), if someone wants some crazy payment structure, consider it. You want the opportunity to say no, not the necessity.
Adding Value: We also look for work for hire that adds value to the company beyond what it pays. In some cases this means building out a tool that we can use in other projects, in some cases it means broadening our skill set, in others it’s establishing good relations with an interesting IP holder or even getting to experiment with mechanics we hope to have in our major release.
Downsides: Work for hire is a distraction. No matter how much we’ve tried to mitigate and how much we keep the teams separate it takes a lot of management overhead.
Preparing the contract, finding cool projects, making the deals, managing the relationships with clients, even doing strategic planning for two divisions instead of one requires a lot from the management team.
Don’t delude yourself going in (we did, a little bit) -- work for hire will change how your business functions. It may offset your costs but it won’t fund any major project, you’re still going to have to raise capital to put out your AAA title.
If you are going to do this, do it because it will allow you to employ a few people during a down economy. Understand that it will cost you something and hope that the benefits outweigh the costs.
That doesn’t mean do it stupid: you’re a business and you want to maximize every opportunity you have. Be keenly aware of what contract work is doing to you as a company and be ready to back away if it ever takes you too far off course from your original intent for the company.
Shoot me questions at Jportnow@gmail.com or bother me on twitter @JamesPortnow.
|
| |
|
|
Thank you for sharing.
We're doing a AAA project and several iPhone/emerging media projects (short dev cycle stuff) and this is the model we use.
Hope that helps (not sure if I fully followed the question)