Last time, I touched on some of the crazy walls we put up between different groups in the organisation. I focussed in on the Community team because it happened to fit with the other stuff I had to say about our relationship with our gamers, but it would be unfair to give the impression that the problem was limited to their group.
From the moment we took the investment, our organisational structure developed in a number of unhealthy ways. These problems detracted from the quality of product and experience we were able to deliver, destroyed internal motivation and passion, and also caused us to burn through our cash much faster than necessary – all significant factors in our ultimate failure.
Spend it all!
Let’s start with our attitude to the investment we raised. We fell foul of some kind of modern version of Parkinson’s Law:
A Realtime Worlds project will spend the funding available to it.
When we received the initial $30m to develop MyWorld, management literally reverse-engineered a “hiring curve” (a graph of team size against time) from 3 parameters: the budget available, the desired launch date (set by the investors), and our internal figure for the maximum rate we were able to hire people at (this was the only good part of the plan – Dundee put the brakes on for us!). There are obviously far better ways to plan a project, and I could spend a whole post discussing just that, but for now I just want to focus in on the unquestioned assumption that we should set out to spend all the money.
This attitude infected our company culture at many levels. Almost everything we did, we sought to throw people at, and our hiring created inefficiencies all over the place.
More people in one team created knock-on effects elsewhere: more programmers needed to support more artists, more IT, QA and admin staff needed to support everyone else, more project managers needed to manage everything, and more recruiters to hire all these staff. We hired a whole “business development” group that did, well, nobody else in the company got told what they did, except they hassled development constantly for “executive” progress reports (of course, making reports takes time, so this probably contributed to further hiring). Then we hired a director of development, who while certainly helping us focus on on-time delivery, was sadly forced to spend much of his time fending this senior management layer off our backs. Then we added a “program manager”, reporting to business development, to fulfil a nebulous floating cross-company communication role. Someone above us came up with a “patent strategy” initiative; the engineers dragged along to the meetings managed to fend that off long enough for management to get distracted and forget the whole thing. We hired a “live production” team, whose entire job seemed to be to pass messages between operations (the folks who run the servers) and engineering, on the basis that these two groups were struggling to communicate. Unfortunately, they struggled to communicate with either group, and spent a lot of time creating Processes for how to pass these messages around.
All these layers, of course, generated extra meeting upon meeting. When I worked on APB, my Outlook calendar looked like a game of Tetris, the day stacked full of meetings, usually with a triple-booking somewhere and several double bookings. Hardly any of them held sufficient value for the time spent.
I don’t mean any of that to be a criticism of the specific people in those roles. Many of these folks were wonderful, talented people, and many of them realised the problems they were part of and fought hard against them. I was as much to blame as anyone. I built a technology team that was too big for its goals. I also spent a year in a nebulous “technical manager” role on APB, and didn’t do enough to fight the cultural problems, including the question of why I was there at all (and why I had so many meetings).
Good vs Evil
The layers and walls between groups all came from a smallish group of powerful people (who we’ll label ‘Red’ for the sake of argument), that wanted Realtime Worlds to become more “corporate”, lazily imitating big companies in a superficial way, at the expense of critical thinking and focussing on our true goals. Here’s a typical Red quote (I may not have the precise wording down but you get the idea – and I’m omitting the name of his previous employer because my point here is not personal):
Producers are how you drive accountability and make sure things get done. <Company X> [who they worked for previously] understood this. If we were adding a feature to the game, the first question would be “who’s producing this?” If the floor needed cleaning, the first question was “who’s producing that?”
Opposed to Red was a group that for the sake of argument we’ll call Blue, with diametrically opposed views. Quietly and subtly, perhaps without many in the organisation noticing, these two groups fought for the company’s culture. Ultimately the Blues were destroyed. While probably numerically greater, they held less org-chart power and were forced to work hard for even small concessions. And while the Red relished the meetings and political fighting, the Blue were passionate about getting on with real work, about making our product better, and for the most part gave up the fight to focus on that. The Red weren’t averse to dirty tricks either, such as paying a key Blue to leave (that’s org-chart power for you).
So a key piece of advice to any company receiving a large investment would be this: be very, very careful about who you hire to manage your fast growth. You need someone who “gets” lean startup culture and is not trying to turn you into an identikit corporation where everyone talks bullshit management-ese just for the sake of it. If you become big and successful, you might turn into that anyway, but if you try to be that way first, you won’t become big or successful.
Don’t get me wrong – I’m not against big corporate culture per se. It has its proper place, as the natural result of refining a successful business to reproduce and continue that success as efficiently as possible. But copying it cannot possibly be a driving force towards success in the first place.
Chalk and cheese
One of the most harmful organisational walls we built was between “business” and “development”. Once we took that investment, responsibility for anything with a £ sign in front fell to a small group of “business” people, most of them in our US office. We’d ask these people how much gameplay bandwidth cost us on APB, in case we needed to optimise our usage to make the game profitable. We’d ask how much patch bandwidth on our CDN cost, in case it was worth adding bittorrent support to our patching system. We’d ask how much running a server cost, in case it made business sense to spend more time on server code optimisation and reduce the number of servers we needed.
Every time, we’d be met with a condescending pat on the shoulders. “Don’t you worry about that, son, you just get on with making the game. Let us take care of the money.” We asked, and we asked, and we asked, and were eventually point-blank refused, and later just ignored, on these and other important questions.
It wasn’t just about the questions we were asking. The questions we didn’t ask were just as harmful and more. How much are we actually spending on this game per month? If we launch on this date, how much cash will be left in the bank? We got so fed up of the small battles that we gave up and stopped asking important questions. We wouldn’t question the financial prudence of an additional hire because we were tired of being shut out of that conversation. We just asked upwards for permission and washed our hands of financial responsibility. Of course, the people we were asking didn’t understand the importance of the hire, so we had to justify it to them. But we did so without any context of how important it might be to save money. It turns out, if your goal is simply to justify a hire to someone who doesn’t understand its importance, you easily find reasons to convince them.
We built a culture of treating development as completely divorced from the business we were running. It doesn’t help that game developers are not used to thinking about the money. Traditional publisher-developer relationships mean that the publisher worries about the money, and all a developer has to do is hire the number of people the publisher says they’ll pay for. Everything else is taken care of. We let ourselves sleepwalk into this attitude when we were spending our own money.
When we were asked to talk about money, the conversations were ridiculous. Our finance guys thought we should cut the free fruit. I had to wait 2 months for a pinboard because everything went for approval to the very top level for a while, apparently to help get a grip on our spending. We cut all conference visits for my last 18 months there – a paltry amount next to our salary bill. I spent 3 months arguing to upgrade some of the APB developers’ PCs in the name of working more efficiently; our wonderful build engineer, Phil, even put some hooks into the build system to automatically track how much time each developer spent compiling code in a day and collect all the data centrally. We could prove that the whole thing saved us money in a couple of months, but nobody was interested. They wanted to stick to a supposedly pre-agreed budget, which it then turned out they could change at will to suit their position. I wasted weeks arguing about this.
With hindsight, I guess we were about to run out of cash and any expenditure was a problem. But if this was the case, why on earth weren’t we trimming down our massive salary base at that point, or earlier? Why did we waste time debating pointlessly small amounts of money? Why did we force our talented development leads to spend their time on silly internal arguments instead of focussing on the product?
Developers might not be experts on money, but they’re incredibly smart people, and the parallel between spending in an organisation and optimising code is obvious. Measure where your resources are going and focus on the areas where you can achieve the most benefits. You don’t talk about cutting fruit bowls when you have 300 staff and are still hiring more. I also don’t see how you can spend intelligently unless you hold plenty of open, intelligent conversation between the two groups – or have someone who understands both development and finance run the show.
If wonder if the finance guys were equally hamstrung. Maybe they wanted to cut the staff size but were told to stay clear of that. I can’t think why else they appeared to be so interested in the petty savings (the only other logical explanation is personally unpleasant towards them, and I’m trying to stay clear of that, especially for people I hardly know).
I wonder what would have happened if we’d had a different relationship with finance. Or if we’d been given financial responsibility ourselves. I’m pretty sure we wouldn’t have come up with a plan that involved letting our cash reach almost zero at the point of APB’s release, with ongoing costs of 300ish salaries. I’m also pretty sure we would have trimmed our feature set differently, and structured our teams to be leaner.
What I’ve said so far sounds so unbelievably incompetent that you’d think we were all just a bunch of idiots. But I still contend that Realtime Worlds had an unbelievably smart, talented staff. I can’t prove that with words, but even if you accept it only hypothetically for a moment, it raises this question: why would a bunch of smart people put up with this crap?
Next time, I’ll try to answer just that.
(Part 3 now up).