This seems to me to be a great selection of tips on how to effectively run a distributed studio or workgroup. This is interesting to me because I travel a lot and I like to work with people who are often on the other side of the world. I think with some of these practices, many great things can happen and perhaps, practices of this kind can offer a much stronger future for people engaged in small specialty firms.
On aspect mentioned by the author, Christopher Natsuume, which brings some interesting ideas is that of scalable teams which need not deal with many expenses of keeping people involved. However the really interesting opportunity here is to create specialisations which can be offered more easily to a wider selection of companies etc. This is a little related to the term coopetition which people have been talking about a bit recently and is a quite interesting model for new businesses.
Introduction
Boomzap is a completely virtual studio. We have no physical office, and everyone works from home on a flexible schedule. Our team includes about a dozen full-time, exclusive contractors in America, Japan, Malaysia, Singapore, Russia, and the Philippines. Some of our core team members have never met in person, and most of them see each other about once a year. Even more confusing, many of our staff members live very mobile lives: For instance, I split my time between Seattle, Singapore, and Yokohama. We have been doing this successfully since 2005. I get a lot of questions about how we make all of this work, and I would like to share that with you. Although this article will likely be of most use to other small, outsource-heavy studios like ours, managers in larger traditional studios may find some useful information here as well. But first, I’d like to explain why we do business the way we do, and what the benefits of a work-from-home, distributed business model are:
- Access to the Best Developers in the World: We can hire anyone anywhere, and not worry about relocation, visas, etc. And our employees don’t have to uproot and leave their communities to work with us. In fact, we have people happily working for us hundreds of miles from the nearest game studio, in places other game developers would not think of living.
Lower Labor Costs + Cost of Living Adjustments = Happy Developers: While wages in Asia are not as low as many North American developers would hope, our staff costs are certainly competitive. But for us, instead of seeing this as a chance to get dirt cheap labor, we see it as a chance to create a competitive advantage in our development environment. Rather than adjusting our salary rates down in those countries where we could get away with it, we peg all of our company compensation to Singapore wages, regardless of location. While this policy may not be best for developers in the US or UK, it makes our staff in places like Russia, Malaysia, and the Philippines some of the best paid developers in their local communities. This allows us to hire the absolute best in those regions—and keep them very happy.
Lower Support/Overhead Costs: We don’t pay for office space, computers, electricity, coffee machines—or even paper clips. We do pay a little more to our developers to make sure they can afford the equipment they need, but come on—they are game developers; they are going to have the best machines they can afford at home whether we pay for it or not. We just avoid unnecessarily duplicating that cost at the office, and let them put that savings in their pockets as compensation.
Freedom to Efficiently Mix Personal and Professional Time: Our model allows everyone in the company to adjust their work schedules to mix with their personal schedules in the most efficient manner for them. This not only saves time that might otherwise be wasted on commuting (for example), it also allows our staff to do things that they couldn’t easily do in a more traditional office—like go to school part time, teach a class, or whatever. The value of that freedom—and the happiness it creates—cannot be overstated. It points out that the benefits of working for an organization like ours extend far beyond time and money.
Work/Life Balance + $$$ = Loyal and Dedicated Staff
To be clear, the end effect of this is that our staff loves working for Boomzap. Any manager knows that retaining good staff is one of the keys to growth, and our structure not only allows us to pick the best staff from around the world, it helps us retain them. In fact, since 2005 we have not had a single staff member leave voluntarily. Sounds like a pretty good deal, right? Well, it is. But the trick is that you can’t run a virtually-distributed studio like this in the same way you run a more traditional studio. While there isn’t enough space to explain all of our management strategies in detail, let me share with you our Top 10 strategies for running a virtual development studio. To be clear, this is what works for us, and depending on your team, pipeline, and structure, these suggestions may or may not work for you. So judge and use accordingly. Ten Commandments
#1: We Don’t Track Hours—Ever
The #1 question I get about managing Boomzap is: “How do you know if they are working or not?” That’s simple: I don’t care. I know how much work a professional developer should get done in about 40 hours a week. I assign that work every Monday, and I expect it to be done by the end of the week. If it is, I don’t care how long it took them to do. If it’s not, they work through the weekend to make it happen. In point of fact, I hope they are doing it in less than 40 hours, and using the rest to do . . . whatever else makes them happy. The economics of this are simple: If you want to reward the staff for working quickly, you can’t make “hours worked” a constant, because then only quality and quantity remain variable. In a traditional situation where “hours worked” is a constant, the reward for working quickly and efficiently is just getting more work. Worse yet, in that traditional model you end up offloading work from crappy workers to top workers since the top workers are going to be chewing through more tasks in the same time. Thus, you inadvertently create a “do less work” reward for crappy workers while punishing the good ones in direct proportion to their efficiency. That really sucks.
Instead, at Boomzap we hold quantity and quality as a constant, and allow the staff to use time as an adjustable variable: They have a set task list and a minimum standard bar, and they set their own schedules for completing their work. If they can get good work done faster, their reward is that they get the rest of the time off, and if they can’t, they will quickly find that they are working a lot of weekends. In this model, inefficient workers self-select for removal from the team, as they will end up working a lot of overtime (and probably leave). At the same time, efficient workers find themselves with more free time—in direct proportion to their efficiency—and free time is a form of additional compensation. Having your best workers compensated daily results in good juju.
#2: We Do Daily Builds
In a studio where you can’t just walk the halls, go see what people are working on, and give them input, it is critical that you have a mechanism for checking what people are doing that gets them the feedback they need on a daily basis. To solve this, we have a super strict policy on daily builds. At the end of every day, there is a new build of the game with all new art and design assets included. We judge the staff by this, and nothing else. At least 90% of my communication to the staff is based on direct feedback on the daily build. I make sure the staff gets this feedback every day so that they know if they are going in the right direction. This process of daily builds and reviews is the lifeblood of our company. When it breaks down, the projects break down. #3: We Mix Full-time Contractors with Project-based Contracted Specialists
There is no point in tying up your best resources with work that could be done perfectly well by more junior staff, or work that could be done faster or better by specialists. The trouble is that keeping junior staff or specialists on permanent salary is expensive. So what we do is keep senior generalists on staff to create the structure and core design of the game, and then we outsource the bulk asset production to specialists and managed studios that we hire on task-based contracts. Since more than half of the people working on Boomzap projects at any time are these one-off specialist contractors, we can interchange about half of our total game development force at any time depending on our needs—or scale back to less than half our team without laying anyone off. This is hugely powerful in controlling cash flow. The key is that we’re not outsourcing so that we can pay our outsource partners less. In fact, some of our contractors are much more expensive than our core staff. We’re outsourcing to move the risk of idle time out of our studio. For instance, we outsource all web work, all sound, and all bulk production of hand-painted backgrounds and portraits. This is all work that specialists can do quickly to a high level of quality, and work that we only need for certain stages of production. We pay more for them when we use them, but we make that back in savings by “firing them” when we don’t need them.
#4: We Hire Full-time Staff Primarily Based on Character
Our model is great for mature, motivated staff capable of high levels of self-discipline. Sadly, there are a lot of great programmers, artists, and designers out there who don’t have the personality to work from home on their own schedule effectively. You have to be very careful to test for this, and not hire those people. We do this by having a full-month test followed by a three-month probation period before anyone enters the studio—even developers we know well. The month test is skill-based and answers the core questions about whether one is capable of doing the work or not. The three-month probation is personality-based, and answers questions about self-management abilities. In the few cases where we shortened that three-month period, we regretted it. We have even started lengthening that period for people who we don’t actually know personally.
The bottom line here is that if you are going to have people working within this model, recognize up front that some people—including some great people—just won’t work out. But for those who are independent and self-motivated, our model works very, very well.
A side note on this: some people have interpreted this issue as “virtual studios cannot hire young or inexperienced developers” – which we categorically disagree with. Some of our best workers are young, highly motivated interns, and some of the people that didn’t work out were highly trained professionals who had long since gotten used to the old way of doing things in a game studio, and were unable to adapt. The issue here is less about experience and more about motivation and personality.
#5: We Delegate Authority to a Project-based “Confederation” Structure
Another question I get often about the Boomzap structure is: “How do you manage all of those people when you can’t meet with them or talk to them?” Which is just another way for a producer to ask: “How do you get everyone on the staff to do exactly what you want?” The answer to that is simple. We don’t. Everyone in the company is assigned to a specific project. They know what project they are working on, and within that project they have enormous freedom and power. Our designs are very high-level by design, as are our tasks. We don’t micromanage our staff—not just because we hate micromanagement, but because doing that by email is prohibitively time-consuming. Instead, we create small groups of three-to-four people that are empowered to go make these games on their own. We manage them very loosely and give them the freedom to make their own decisions. This functions much more like a confederation of independent projects than the more centralized structure of many other studios. Each team has the independence and authority to make large changes to the design and product without having to check with the “central powers” and as a result, the central overhead becomes much smaller. To be clear, in a system with strong project teams, this works great. In a system with weak teams that need more oversight, this system would likely fail. So knowing your staff capabilities is key.
That being said, it is important to note that key to doing this well is being able to accept good work you didn’t expect. All too often studios spend a lot of time chasing a single vision-holder’s dream for a project, and they end up in an endless cycle of revisions trying to perfect that vision. The trick to delegation and empowerment is being able to look at work that is not completely what you expected and/or wanted and objectively judge whether it is good work. Doing so has two great effects: 1) Your staff will really feel empowered when they see that the work they are doing gets put in the game without constantly being retooled to fit someone else’s vision; and 2) Sometimes you’ll get stuff that is actually better than what you had in mind.
Remember, delegation is not just the delegation of work, it is the delegation of responsibility. If you want a team to truly start taking some responsibility for their work, you cannot constantly undermine their efforts by forcing them to revise work just because it’s not what you would have done. “Is this what I wanted?” is not the question. You’re better off asking: “Is this something the customer would enjoy?”
#6: We Hire Managers Who Can Actually Do Things
One of the great benefits of our model is that it’s impossible to hide workers who aren’t contributing. Middle managers who lurk in the corners of larger studios “optimizing procedures” and “facilitating meetings” don’t actually have anything to do in a virtual business model. And we haven’t missed them a bit. Everyone on the team, the founders included, do real live production tasks like scripting, testing, and level design. Because the only way we can judge the staff is by assets produced and placed in the build, the incentive to actually produce things is pretty overpowering. Better yet, because our managers are actually forced to work intimately with the technology, they are more in tune with what the rest of the staff is doing, and can better judge the time required for tasks, etc. This is all to the good. #7: We Depend on the Three P’s: PowerPoint, Prototypes, Photoshop
I hope I am not the first person to tell you this, but nobody reads design documents. In fact, when working at larger studios, I made a habit of inserting the line “I will pay $5 to anyone who reads this sentence” into the center of any document over 50 pages. In 10 years of development nobody ever asked for their money. That’s a true story. Problematically, the industry has solved this problem by holding meetings. Lots of meetings. Since we can’t do that, we have to find a different path. For starters, we do the initial design for a game by using short PowerPoint presentations full of diagrams, scanned-in drawings, references from other games, and Google images. (That’s right: Not a Word document.) The PowerPoint is generally a mockup of every major screen in the game—with minimal text callouts—describing what the game will look like and how it will play. Next, we let the programmers build a rough prototype version of the design using a bunch of grey boxes and placeholder art cut from the PowerPoint slides. When this is playable, we have something to reference in our notes and MSN discussions. The prototype and a daily sheet of notes referencing it and suggesting changes becomes the “design document.” When we finally have the prototype really fun and playable, the artists take screenshots of the demo and attack them in Photoshop, creating mockups of the final screens as they will look to the player.
When we have all of that, we go into full production. Usually someone will sit down with the PowerPoint and the prototype and create a series of simple lists that defines the tasks to be done to complete the production of the game—which is as close to a design document as most of our games ever get. Most of our games have shipped with less than 20 pages of documentation, and we still wonder if that’s too much.
#8: We Use “Producer-Programmers”
Another powerful secret to our development is that every project is run by a “producer programmer”—a highly skilled programmer who not only writes the core game code for the game, but who oversees the actual production of all assets for the game. We build our teams like this for a couple of reasons, the most important of which is that the producer working with the artists and sound designers on the project is the actual person adding those assets to the game. This removes many steps of conversation in the team and solves a lot of unnecessary communication issues. Additionally, it allows the producer to directly test and prototype new ideas—without the communication cycle of a producer explaining and a programmer interpreting that explanation. #9: We Create An “Idiot-proof” Pipeline
Development studios often spend a lot of “communication time” trying to help artists, designers, and musicians get their work into a game. Because we can’t have two or three people sitting at a desk sorting out these problems, and because expecting our programmers to document labor intensive pipeline processes is both wasteful and naïve (as anyone who has ever asked indie programmers to write documentation knows!), we go to great lengths to make the tools for driving the assets into the game as simple as possible. Our biggest tool for this is Excel, which we use to generate any script in the game including sprite lists, sound files, level design variables, object variables, localization strings, etc. The Excel sheets have a big EXPORT button that spits out a script, and nobody has the ability to break anything in script. Remember, automization means that all errors are systematic errors, and those are easier to both find and fix. And because anyone can read an Excel sheet and fill in variables, most people can figure out how to get their assets into the game without ever talking to a programmer.
Our level design tools are similarly simple. They are all WYSIWYG mouse-driven editors that are directly accessible from within the game engine—which allows our designers to get in and effectively build and test levels within a few minutes. Because the producer who defines what datasets are going to be manipulated in the game is also the one making the export sheets and editor, this process ensures a high level of idiot-proofing.
#10: We Hire Only Technical Artists
Finally, we don’t actually have very many artists on full-time staff. We outsource most of the bulk art creation, especially the creation of assets like decals, backgrounds, portraits, and story art. All of this can be done quickly and efficiently by outsourced teams and returned to us in simple files that can be dropped into place with minimal integration work. The artists on staff are technical artists who handle things that require a deeper knowledge of our tools and technology—things like fonts, animated objects, particles, and user interface. This saves us the cost of keeping specialized concept artists on staff, but also protects us from the lost efficiency that would come from training contract workers to create assets according to a complex technical specification. Nine Essential Tools for a Virtual Studio
These are some actual tools we use in our studio to help support our virtual development environment. This is not a sales pitch for any of these products, but they are working well for us as we operate a studio in which anyone, including the founders, can be anywhere in the world for essentially any length of time. You may have better ideas, but this is what works for us: - CVS: If you aren’t using some kind of online source control and backup system, it’s just a matter of time before you will deal with some HD-crash-induced or file-swapping nightmare scenario that will cost weeks or months of manpower. While this is true for any studio, the odds of file management disasters are much higher in a virtual model. Which software you use is unimportant, but you really should be using something. We use CVS, but that’s just a personal preference from our technical director. Whichever one works for you is fine.
Basecamp: A nifty online team collaboration tool that we use for our projects. A cheap $25-a-month subscription gives us the ability to create as many project groups as we need, giving our publishing partners direct access to our daily project management and creating a single record of all design/production conversations. For things like posting the daily builds/notes, this is simply invaluable. The best part of it is that it can be configured to send email out when messages are posted, and you can reply directly to messages in your mail client and have them posted to Basecamp without opening a browser. Very cool.
MSN Messenger: Our studio lives and breathes on MSN. We require all staff to be online and on MSN when they are working. In addition, they must set it to “auto-select away” when they are AFK so we know when they are available during the day to talk. We also ask them to set the “personal note” to let us know what they are up to. So if they go to the doctor, they add “at doctor until 3:00,” or if they are working on a particular part of a project they might add something like “drawing backgrounds.” Now everyone knows what everyone is doing without anyone needing to bother anyone. Also, if people want to be left alone, they set their MSN to busy. We have a strict “don’t bug busy workers unless it’s an emergency” rule, so people who want to really concentrate on their coding without constant interruption can keep focused, but they are still available if we have some kind of serious issue that’s stopping other workers.
SkypeIn and SkypeOut: Aside from the free Skype-to-Skype calls we do between staff regularly, SkypeOut will let you call a real phone anywhere in the world from any internet connected computer. With a decent headset the connection is usually better than a cell phone, and at two cents a minute, its darn near free. Better yet, you can set up a SkypeIn number that lets people call your Skype account as though they were making a local call. We have ours set up in Seattle, since most of the distributors we work with are there, and dialing a 206 number makes them feel warm and fuzzy. Better yet, you can have your SkypeIn calls forwarded to any phone anywhere, including your cell phone. And it has voice mail! The end effect? People in the states can call you for free at the same number, regardless of where you are in the world, and you can call anywhere for two cents a minute. There—your telecommunication problems are over.
Earth Class Mail: How do you keep publishers from sending checks and contracts to the wrong address? First of all, push them to do everything electronically. Automated Clearing House (ACH) is free, and pretty much any contract can be scanned and PDF-converted. As for the few Luddites who feel the need to write checks and send snail mail, set up a mailbox at Earth Class Mail. They’ll scan the envelope of any incoming mail, and send you an email about it. You can then forward it, shred it, or have them open and scan it for you – all from a web browser. It’s not free, but for the few mails you have to get, it’s pretty cheap. They have sites around the states (ours is in Seattle, perpetuating the pleasant illusion that we have a Seattle office). Be careful, though: When you set this up, choose the non-PO-box option, because sometimes you’ll deal with people or services that won’t deliver to a PO Box.
MyFax: If you have a scanner there is no reason on earth to have a fax machine. Set up an account at MyFax, and have all of your faxes delivered to your email. It’s simple, clean, and dirt cheap. And more importantly, you end up with a permanent, US-based, toll-free fax number that never changes, regardless of where you go.
PayPal: I don’t need to tell you that if you need to pay people internationally, PayPal is the only way to go. We use this for all of our contractors in the US and Europe, and not only does it get them paid immediately, it creates a great record of all payments out. Also, since you can use a number of different solutions for paying into your PayPal account, you can play with this to create short-term credit for cash-crunch situations at relatively low cost. NOTE: The author has dropped usage of PayPal since the service added a "rather onerous" international payment fee to a lot of countries, including those in which BoomZap operates. They are currently looking for an alternate solution, however until now PayPal has served them well and could still be considered for your individual needs
Your Mailing List Provider: if you are running a casual game studio, you’re going to be sending a lot of emails. There are a lot of solutions, but cost for value, we’ve had pretty good luck with YMLP.com. It has good tools for importing addresses from various sources and collecting addresses from our website. Most importantly, you can get to your entire mailing list from anywhere, without even needing access to your laptop. It’s also useful when you are sharing mailing responsibilities, so you can have different people working with your mailing list without anyone swapping files, and with everyone being able to see a clear record of what was sent when.
Portable Equipment: Last but not least, make sure when you are buying equipment, that you consider portability. My home work station is an Acer laptop with internal camera and a small second flat-screen monitor with a folding base. I also have a portable USB-powered flatbed scanner, a mini-printer, and a headset for Skyping. The whole lot of it fits in a single carry-on suitcase (though I am not a popular guy at the security stations at airports!). I can pack my entire “development studio” in about 3 minutes and take it anywhere. My office is anywhere there is an Internet connection and a table. A note: Try to buy only peripherals that power off the USB. This is super useful when traveling overseas, allowing you to essentially use your laptop as a power converter for everything else. Conclusion
I don’t pretend that our approach to development would work for everybody, but I can tell you this: It works very well for us. I hope this is useful to you, and hope even more that you’ll contact me with your thoughts and suggestions of how you have tackled similar problems in your own studio.
2
comments
Labels:
google,
purpose,
writing
Jonah Lehrer's 
Posts
