One of the things that keeps poking at me in the back of my head is the idea of "growth". Venture Capitalists want you to grow as fast as possible, because that's how they get their money back. You grow huge, do something that either results in a billion dollars, or you die quickly and move on. And it seems like that works okay for them, at least sort of. But it's not what we're doing, and in game development, I'm honestly not sure why anyone would go that route at all.
We have a team of four people. You can see all our smiling mugs up there in that photo. I'm a Game Designer, I do most of what we'd consider "production" to the extent that we need it, and I also do most of the businessly stuff, like deal with paperwork, pay bills, talk to lawyers & tax people, etc. We've got two engineers who write the code. One focuses on front-end stuff, one focuses on server-related stuff. And last, we have an artist.
That's exactly as much as we need.
We're not going to add any people before we launch the game, because
- There's nothing for them to do
- Most people = more money = more risk = shorter runway
It's a little different when your methodology is to release a finely tuned, highly-polished game - then maybe you need a team of many artists and many engineers, but I'd argue that that's a bad methodology for releasing games these days, because the hardest thing to do is not to make a good game, but to make a game that people want to play.
Yeah, there's some crossover between those two, but there's a lot less crossover than most people expect. Besides, if you've ever been resource-constrained, you know what I'm about to say:
Making something with fewer resources forces you to focus on finding elegant, efficient solutions. This leads to a better result than throwing lots of people and money at a problem.
Figuring out how to push against boundaries forces you to do things you wouldn't normally do. This forces you to look at problems in new ways, and it forces you to move past the obvious (and often simplistic) ideas.
So being resource-constrained is good. But it's also only good if you can solve problems. And being small lets us solve problems much, much better than being big. Yes, we have fewer available brains. But every person on the team knows almost everything that's going on in-game. Every person has (at this point) played the game with beta testers and talked to the testers about their feedback. So when we have a clear idea about what a problem is, we can move incredibly fast to fix it. We don't need to have meetings and form consensus to move forward, because one of the best things about working on a small team is that you don't need consensus. You have something much better - you have trust.
Trust is a hard thing to have with a team so big you don't even know everyone's name. When you lack trust, you need some form of consensus (or tyranny) to take its place. Or you have micromanagers. Or any number of other, much worse solutions. I don't need to know everything that's going on with the current UI update. I know the folks who are working on it know the problem. I know what their strengths are. I know that when there's something that needs my input, they'll get it. I know that they know what problems the players are having. I know they'll run the revision by me when it's ready.
As a result, I don't need to dictate what the UI is. I don't need to give them a plan. I don't need to manage their interactions. I don't need to dictate anything about this process other than if it were critical, to do a little bit of scheduling. And it's not critical, because part of the way we work is to basically eschew release dates. Because we all know what our available resources are, what our high-level goals are, and when we want to have something releasable. Sometimes things get carried away. They get nudged, gently. Sometimes folks go down a rabbit hole because they're following their passions. A simple reminder of the process is enough to pull them out of the rabbit hole. Then if they think the right thing to do is go down the rabbit hole, then I trust their judgment.
These things aren't possible on a large team. They aren't possible in a siloed environment. You can quadruple the team size, and productivity doesn't just not quadruple - it doesn't even double. If you do it wrong, you can quadruple the team size and significantly reduce productivity as a whole indefinitely. In my experience, doubling the team size in a year led to maybe a 10% increase in productivity. Oh, sure - more stuff got done. But less of the right stuff, due to communications errors, improper prioritization, etc. etc. etc.
I can understand that if you're fighting at the top of the ranking charts, and everything is hugely competitive and expensive, that extra 5% may warrant a 2x in the team size and all the negative garbage that entails. But there's a big reason that big companies can't move as fast as a startup, and in the modern mobile development environment, I think it's very difficult to argue that nothing is as important as speed. And a small organization is a fast, nimble one. The advantage we have is that we can respond faster. We can create new things faster. Other companies may have five engineers working on a feature where we have one - but we're still going to beat them to the punch.
Smallness is a strength. In many respects, it is a superpower that companies trade away in favor of "growth", which at least in mobile games gets you almost nothing in return. We're small. It's absolutely fantastic, and I wouldn't have it any other way.