To Contractor or not to contractor? Pros and cons of putting off full time hiring.

Problem

In 2011, when we founded Rogue Rocket, our goal was always to stay as lean as possible because we were small and undercapitalized. We hired staff based primarily on a project-needs basis, erring towards working with contract developers first to minimize cashflow risk. Deciding when to hire full-time staff, versus when to rely on contractors is a difficulty companies must grapple with and the answer will be driven by many factors that will be different between companies. There's no one-size-fits-all solution, and you have to decide on how it fits into your overall strategy, and how it affects your cash flow and risk profile.

Actions taken

Rogue Rocket only wanted growth driven by success, rather than to grow for the sake of growing. Because Rogue Rocket was trying to stay lean, when we had an idea for a product, we would pitch a budget for it to a publishing partner, and would agree on a general timeline. We would then work backwards from there, using the product concept to plan out what resources we would need. When we started out we consciously chose to staff with contractors, as they were useful for filling positions when we had a very specific need and did not risk cash flow when the project concluded. We used our personal networks to quickly find and hire contractors for all types of disciplines including level design, engineering, and QA. Because at the time, my business partner and I had a lot of experience in game development, but less in server technology and cloud-based services, it was clear we would need to a contractor skilled in those areas. We didn't have somebody in our network that fit this profile but were lucky to find somebody who had applicable experience and wanted to work on a contract basis. Roughly a year after first founding the company, we made our first few full- time hires, with some being conversions of contractors who had worked for us and had proven really valuable. However, our company did not rapidly expand, as we had decided to focus on only growing as our cash flow did.

Lessons learned

Our strategy was about keeping things lean and attempting to generate value from high quality game products that if successful would generate a huge multiplier of value over investment. However, unless you have a product that's valuable and incredibly difficult to replicate and/or enjoying a significant amount of traction and growth, technology companies are more commonly valued based on their permanent staff. If you are trying to build a company based on enterprise value, then this strategy may not work, as contractors don't usually add that value. Our goal was to create great products while maximising quality and creativity. We believed that if we were successful at that we'd then be able to create more long-term personnel positions. While the business environment for digital games in 2011 made this strategy difficult but plausible, it may not be a wise choice for companies in our current business environment depending on your locale and goals. In California, for example, skilled technical personnel is in incredibly short supply, with large successful companies sucking up all the talent, making the contractor pool small, mercenary, and expensive. It would be much harder to today to find valuable contractor resources who you could convert to full time without losing them along the way. There's no one size fits all strategy for building a team. The strategy has to be crafted based on what your priorities, challenges and needs are.