Running a Studio: A Game of Hats

When you start an indie studio, or tell people that you’re thinking of starting one, you’ll be told that you ‘need to wear multiple hats’ so often that it becomes more of a cliché than words that are supposed to mean something. The idea is that you can’t just focus on your main discipline, but need to manage your business and bridge any gaps you have in your development team, too, but how do you do that? Well, this week, I take the hat metaphor too far to answer that question.

How to Wear Multiple Hats

I love my producer hat. I wear it very happily day in and day out. I feel comfortable with it, and I feel like I know what I’m doing when I wear it. Most of my days require my programmer beanie more than my producer hat, so I’ve grown used to hanging up my preferred hat, and getting to work. Throughout the day, there are occasions where I’m compelled to change hats, though. The team might have questions about the schedule, or want to know when they can work on a specific mechanic. Other times, I can see that a programming task is much more complicated than I anticipated, and will take more time, so I have to awkwardly put my producer hat on top of my coding beanie and try to make that seem normal. Still other times, I may get an email that requires my director cap, which disrupts my coding beanie time, which in turn, requires my producer hat to make an appearance, and before I know it, my day has turned into an unfashionable disaster. So what has one to do when they wear too many hats, and they don’t know when to wear which, or how they should influence each other? To me, that sounds like an overview and planning issue, and one we can get out of.

MVGIE Studios consists of just Alex, Allie, and me, Phillip. The three of us make games, as well as manage the business, so we’re quite used to wearing multiple hats, though we don’t always love it. We’ve noticed that if we let ourselves be dragged into whichever problem seems more urgent, and switch hats whenever something happens, we have less of an overview of our time, and find it harder to change hats back to our most used. It can be difficult to get back to the mindset of a programmer and get reacquainted with code you wrote hours ago, if you had an unexpected intermission of market analysis for the latest version of the pitch deck, for instance. What we’ve taken to doing is schedule our outfits and change out hats at pre-determined days, parts of the day, or conditions. For instance, we’ve decided that Mondays are great for wearing our director caps. This is when we get to manage everything related to external communication, applications, pitch decks, business development, etc. The rest of the week, we’re generally trying to abide by our default development-related hats. For me, that means that I am wearing my coding beanie Tuesday-Friday for the most part. However, since I also have that beloved producer hat, I’ve scheduled our morning stand ups, and our end-of-cycle reviews to wear that hat. Sometimes it needs to come out a little more often, but I trust the team to respect the boundary between my producer hat and coding beanie, and so we usually schedule in spontaneous hat-switches if needed, and keep those meetings brief. Alex has been known in the past to like switching his focus halfway through the day, so that he has something fresh to dig into. This works well for his situation, since he has both the top hat of writing, and the designer trilby, and they’ll often require equal attention.

These schedules won’t always work out for your development or company management, as things will come up suddenly and need to be dealt with then and there, and you’ll have periods of time where some tasks require much more attention than others. The idea here is to plan your hats in advance as much as you can, so that you get control over your time, and can adjust as needed. This makes it easier to make up for sudden calls to change your hat, too.

Has Anyone Seen This Hat?

When you imagine your perfect company wardrobe (hatstand?), you probably have an idea of all of the hats that need to be within it. You can see all of the hats that you can wear yourself, all of the hats that your co-workers wear, and you may have an idea of which hats you need to wear in the future, but you haven’t figured out how to pull it off yet. What if you notice there’s a missing hat, though?

MVGIE has this exact problem. While we’re very well-rounded in general, and can manage almost all aspects of development and business, one hat eludes us, which is the artist’s beret. None of us really know how to wear a beret, or at least, how to pull it off while wearing our other hats. We’ve been getting by so far by using ready-made assets, and it’s worked fine. There’s no problem in using asset packs if it fits your game direction, but for us, we’re looking for something just a little more special, and perhaps, assets that don’t already exist out there for us to get. So, what are our options?

Just Wear It

This is an obvious solution, and it’s equally obvious why it won’t work for many teams. You could just start wearing the hat yourself, and learn to be comfortable in it. If you don’t know how to perform the skill you need, consider whether you could learn to do it, how much time it would take for you to learn to the level your project/team needs, and how it detracts from the other hats you’re wearing. If you’re in need of a foley fedora, might it be possible for someone to learn how to record and edit foley to a level that you can use it for your game? How about to a level where they can get basic versions in the game, and know where they need a contractor later on to replace the sounds? It can be tricky to have someone just pick up another hat, but you can always start small. Start by just learning about the hat you’re looking for, what might be required to pull it off. If you find out it doesn’t make sense for you to wear it, at least, you’ve probably learned what you need to look for in other people, when looking at how they wear their hats.

Rent It

Realistically, if you’re trying to make an indie game and you want to release it in a tangible near-future, you’ll be planning out which parts of your game gets done at which point. You might have a waterfall-like overview, that tells you which things needs to be done at which time, or you might have an agile flow, and you know generally which tasks are needed to constitute a release. In either case, you have the tools to break down which hats need to be worn, for roughly how long, and in which periods. So, if you’ve got your diary of hats, have a look at what the cost (for money and time) would be to just rent the hat you’re missing. Core parts of your team probably can’t be contracted out, but if you need a specific role to perform a job in a defined scope, consider hiring a contractor to help with just those parts. A beret-wearing artist may be a multi-generalist, but realistically, most have specialties. If you have an artist and their style of beret is more of a 2D workflow, but you really want to make a 2.5D game, and there’s just a few 3D assets that you need to make the game pop, then you could bring in a contractor who wears that style of beret to do just those parts. When weighing up the resource commitment, you may find that it’s cheaper than having your artist learn to wear a different style of beret. If your artist is spending months learning how to make those 3D assets, and extends the development timeline, that’s also costing you salaries, so even if contractor hours are more expensive, they may be able to keep you on schedule, and make it cheaper in the end.

Find Someone Who Wears The Hat

Why force yourself to wear a beret when you know you feel your best when you’re wearing a trilby? And more importantly, why settle for your idea of a well-styled beret, when you know there are people out there who pull it off effortlessly, and have done for years? Finding a collaborator who wears the hat you need, and loves it, is perhaps the ideal way to fill the missing spot in your wardrobe. However, you might face problems being able to bring people on to your team. Early-stage indie developers without funding will have a hard time trying to recruit or hire staff to work for them, for free, and while revenue-share can sound enticing to some, most indie games fail to ever generate meaningful revenue, and so a share of not a lot loses its allure. If you know someone with the hat you need and they’re interested in being part of a pre-funding start-up, then maybe you can fill out the role that way, but you’re likely committing to a more serious co-director relationship, which has its own implications. Either of these options might be a great fit, but it comes down to the people. Of course, if you have the money to hire someone, this is a much easier choice.

Did You Find Your Hat?

Well, no, not yet. We haven’t found our elusive beret, but we have a good idea of how to manage that. For us, we really like the idea of working with an artist who styles their beret just the way we think will work for our game, and sharing that creative process. For now, though, we don’t have the funds to allocate to hiring someone, and we already feel comfortable with our management staff. Should an artist come along at some point before we open up a position, then we’ll see what happens. In the mean time, we’ve got good leads on how to continue with assets for now, and make them look the best they can, while making the technical art direction go towards the art style we want. We’ve gotten some good advice on how we can hire contractors with intention, for just the things we really need to have assets made for. At the same time, I’ve started to look at what sort of art skills we need, and which direction we want to head in. Not enough to be the team’s artist, but enough to make our game look just a bit more polished right now, and to know how we want to collaborate with other artists in the future, whether they are hired, or contracted.

Like us, you might find that a mix of options makes for the best overall solution. While running a studio really does require wearing multiple hats, it’s just as important to figure out how that hat needs to be worn, and when. A different team with the same problem may look into creating an art style that doesn’t require a lot of asset development at all, relying on shaders to create a unique look, or nailing a programmer-art or stick figure aesthetic. Whatever your situation, some ingenuity and resilience will get you all the hats you need in the end, and if you don’t know where to start, I suggest you get out your overview hard hat, and accompanying planning visor. It may not be a stylish combination, but the point is that everyone can put it on, feel safe in working things out, and then change hats again.

Thank you for reading along. I’m not the type of person that usually wears hats, so it took some pointed web-searching to find types of hats to use in this post. Most of the time I like to wear headphones. You get noise cancelling, music, and usually, it blocks out the sound of creatives swearing at themselves when they’re in the zone. I highly recommend it. Should you have any hat-related topics you want to discuss with me, I mean, maybe don’t ask me, but if you have comments or questions about anything I wrote about, or about game development in general, you can find me at: phillip@mvgiestudios.com

Phillip