Your Project Team Sucks: When Grotesque Inefficiency Isn’t a Strong Enough Descriptor

A while back I had someone pose the following question: If indie developers/studios can put out near AAA game quality on a super tight budget, why then are AAA games so damn expensive to make?  Is it the voice actors; the marketing; corporate expenses?

It was an interesting question.  It’s true that indie studios in recent years have cranked out beautiful, story rich, immersive games for a fraction of the cost of the big studios.  And, recent advances in technology has made the entire process of making games accessible, and by extension, cheaper to make.  So why has the cost the big studios throw out there so fucking high?

I’ve heard many times that the project costs are on the rise.  The need for more specialized roles needed in projects is indicative of a project with a higher price tag, and what needs more specialized talent than a video game… right?  RIGHT?

Finding Someone Who Knows Something

I reached out to an old friend of mine.  Someone I knew back when he worked for Sierra Games, who has gone on to work for other studios, both big and small, and asked him the question that was posed to me.

What came out was a pretty scathing discussion on why working for major studios is the worst, as well as a running count of how many times he thought of quitting the industry entirely.

For I Have Seen God Face-to-Face, and Yet I am Still a Game Dev

“When I worked at Sierra, you always knew who was in charge.  It didn’t matter where in the development chain you were at.  {even if you were} building an engine for an as of yet unknown game, Roberta (Williams) was the voice of god, and we were just servants in her court.  There was never a question.  A guy I worked with had worked on Final Fantasy XI under Koichi Ishii, I believe.  Same thing.  There was never any question who you needed to answer to.”

I tend to shit on product/project owners.  Mostly because they tend to be untrustworthy in the work you need them to do and overly controlling of the work you need them to back off on.  But they are useful for one thing, they tend to know everything that needs to be known.

I’ve seen POs go both ways.  Ones who have a vision, and they communicate that vision to anyone who will listen, and I’ve worked with ones who sort of know what they want but only when you tell them what they want.

We’re talking about the former.

Ultimately, you need someone you can go to if there is any sort of conflict in direction, the voice of god. 

“The first time I worked for EA, I answered to, like six or seven “managers.”  None of them agreed on anything, and everyone kind of… hated each other.”

Look, I know that matrix organizational structures are all the hotness.  I know that for many companies, it makes for a much more efficient work environment.  The problem isn’t the matrix structure, it’s that companies don’t want to define barriers of responsibility.

Here are these five people, they are all your manager.  Ok, what are they managing?  Are these specialized managers?  Who do I go to if I have a problem? 

You have to define that shit.  And ultimately, you need to know who overrules everyone else.

“I’m a Strong Independent Developer, I Don’t Need No Man(ager)”

“One of the biggest issues I’ve seen is a lack of a coordinating force.  A person who is responsible for making sure everything is in sync and copacetic.  So many devs think they don’t need anyone telling them what to do, and so the industry culture is to let devs do their own thing.  Problem is, no one wants to do the boring stuff, so it never gets done until it absolutely has to.  By then we’ve created a ton of rework.”

I recently at a conference for PM professionals, where a guy gave a talk, he titled “the slow death of Agile.”  Well, I know I don’t have to tell you, this piqued my interest, since, you know, fuck Agile.

What I expected: Agile is an aging methodology with a lot of flaws, and we can do better.

What I got: Project managers and executives are trying to inject structure into Agile, and Agile only works if there is no managerial oversight.  I wish I was exaggerating.

The problem of devs not wanting to do the boring stuff, and only work on the novel, exciting things isn’t unique to the gaming industry.  I remember a while back hearing about Spotify struggling with the same problem, although at the time of writing this, I’m unable to find a reliable source to back this up.

My interviewee said something that stuck with me and was the reason I decided to write this.  The “coordinating force.”

A coordinating force could be a project manager, but it could also be a creative director, a stage manager, a site supervisor, an intern, anyone, really.  It seems silly, but you need someone who knows what needs to happen and in what order and is able to quickly respond to issues that might come up if things fall out of sync. 

Mostly, it requires someone who can tell the developers, no, you have to build out the logic behind the random number generator, before you start building the battle logic.  You need to have player statistics in place, before you can focus on matchmaking for online gameplay. 

You need an asshole to say, no, you have to eat your goddamn peas before you can have some fucking pie. 

It’s easy to say that this person is managing the project, or say, a project manager, but I feel that this aspect of project work is a specialized set.  Coordinating.  If we’re going to say being a great facilitator is a PM skill, then by fuck, we should also consider coordinating efforts and being a coordinating force to be just as important of a skill.

The Case of the Creative Visionary v. Games Publishers

“… it happens more than I think anyone would cop to, but these directors who see themselves an auteur, a creative visionary who doesn’t listen to the publisher… the people who are funding the damn game.  Then when it’s crunch time, instead of making the game playable, we’re desperately trying to make the game we were contracted to make.”

This one might take a bit of explaining.

Sometimes a publisher will contract with a studio to make a specific game.  Frequently, it’s very-very specific.  The publisher will give all of the requirements, visual style, game mechanics, design, etc.  The studio, then, is tasked with making the game the publisher wants.

But… yeah, it frequently doesn’t work that way.

Let’s say the publisher acquired the rights to a popular murder mystery IP, and they want to build a game around it.  They want it to be a driving game that is real time/real roads from Seattle, Washington, to Camp Pendelton, California.  During the drive, you have an opportunity to ask questions of your passenger, call people and ask them questions, and in the end, you try and solve this mystery of your brother who vanished.  They want the ability to stop for gas and food, stay in hotels, or in the car on the beach, and an ability to integrate with Google Maps traffic, so that you would be driving in real time traffic.

The studio who will be building the game hires a director who sees himself as the best of Marty Scorsese, Yoko Taro, and Fumito Ueda.  He doesn’t like the real time drive portion, nor does he like the drive down the west coast of America.  Instead, he wants to set it in the German countryside but not call it Germany.  Instead, he wants to integrate more fantasy elements.  Also, the murder mystery angle is tired, he says.  We’ll take the characters from the IP, and have them solve a mysterious heist, where a multimillion-dollar gemstone was stollen from the royal family, that totally exists in the fantasy Germany.

This auteur is the voice of god, he’s the coordinating force, his vision is translated into bytes and nibbles, and when it starts to get close to delivery, he sends a proof over to the publisher, who responds with, “what the fuck is this?  This isn’t what we asked for!  Why the fuck is the main character a fucking half dragon, half yeti.  Are you suggesting that the fucking Abominable Snowman is out there knocking up dragons?”  

The auteur is a problem that has plagued Hollywood for years, and now it seems that it has found its way into gaming.

I guess it’s to be expected.  Now that games are peppered with such words as story rich, prestige gaming, fully immersive experience, etc. it becomes destined to attract assholes who want to make a name for themselves, even if it means making a game that isn’t being asked for.

We see the same shit in projects.  How many times have you had to tell someone to stop gold plating their fucking work, and just stick to the requirements?   I had a developer that would cosplay as a UX designer in his free time, and in his not free time, and in his work time… basically, he really wanted to be a UX designer but instead was a shitty JS front end developer.

The number of times I’ve had to beg him to just follow the mock-up that the UX team threw together is too damn high.  But you see, he had a vision, and by the gods he was going to see that vision get implemented, one fucking way or another.

Goldilocks Don’t Live Here Bitch

“… I almost quit the industry all together; at least a half of a dozen times.  One thing that will absolutely crush your soul is crunch culture.  It isn’t just because of the long hours, I mean, that does suck, but more than that, it’s that it frequently happens at a time when they’ve pared down the team, so you’re already overwhelmed.  Early on we have too many people involved, and we’re just wasting time, at the end we have too few people involved, and now we’re in crunch time.  It’s a nightmare.  It feels like we’re never properly staffed.  That is probably the biggest frustration.      

How many times have you heard about a game that is rushed out to meet some deadline?  Maybe it’s because you have a deal with McDonalds (looking at you Sonic), your game is part of a new console release (FFVII), or because the studio has a tight release schedule and doesn’t want to overlap with other releases.

The sin is that of “end date driven delivery,” and “run lean at all costs.”

I get it, with anything that is consumable media (games, movies, music, etc.), you have obligations and partnerships that lock dates down to very tight delivery windows.  In reality, though, this isn’t about those tight delivery windows, it’s about shitty planning.  There is never a reason why a team should have a panicked frenzy to get things out the window, especially when the staffing is so imbalanced throughout the lifecycle that you’re only ever overstaffed or understaffed. 

It’s this cycle.  Leadership says we’re going to get so much shit done in the early days of the project.  Oh, shit, we’re overstaffed, and it’s slowing down work of other teams, let’s pare down the teams.  Oh, shit, we’re behind schedule and have no free resources to help crash the schedule.  Oh, shit, we’re running out of time, better force everyone to work 16–20-hour days, seven days a week to make delivery.

There are conflicting beliefs that many businesses and project owners subscribe to, that create fucking chaos.

1. Hiring more people early on will get the project off to a “fast-start” and will speed things up throughout the process.

2. If resources aren’t being utilized every hour of every day you have too many resources.

The first is total bullshit and is something that we are dedicating an entire article to.  The one thing to know is that the “fast-start” argument is never true.  Just because things start off positively, doesn’t mean that it will be true throughout the entire project.

The second one is a misunderstanding of how many hours of productive work a person can handle in a day. 

I was working with a third-party service provider a few years ago, and the PM told me a story.  When they are setting up new service, there are 10 tasks that need to be done for the first level of integration.  They can be done concurrently if resources are available.  As a result, each implementation team is made of five people.  Their project plan tracks hours for tasks.  Management noticed that the IA team was only achieving an average of about five hours per day.  They felt that this was because there were too many resources per team and cut each IA team from five down to three.

What formally took two cycles, was now taking four cycles, and the output was still only averaging about five hours a day.  Removing 40% of the team doubled the delivery time.

Notice the contradiction.  Adding people will accelerate the project timeline.  Removing people will have no effect on project timeline.

What’s the solution?  Project managers need to be diligent; they need to build out comprehensive plans, with an understanding of how work interacts with other tasks, and they need to have a firm idea of how certain factors will positively or negatively affect task durations.

The problem is this doesn’t align with how a lot of Agile houses practice.  I’m reminded of what a former boss who was an Agile evangelist once said: “Agile is 80% vibes, 19% procedure, and 1% intuition.

The problem is that efficient utilization of resources requires you to have an in-depth understanding of how things play out.  You need to understand who goes where and does what.  Vibes won’t help.

For that, we look at dynamic path methods, which will be covered in another article.

A Hackathon Makes for Laughter, and Cheap Beer Makes One Merry, But Money Answers All Things

I hate that I keep returning to my time at Sierra, but there’s one thing in all my years of experience that I wish we would return to.  In those early days of my career, if you ran into a problem, you had to get creative.  There were limitations on what software could do, there were hardware limitations, there were i/o limitations.  If something came up the mantra was to figure it out.  Now, if there is an issue, the mantra is “just throw money at it until it goes away.”

In my opinion, very few things can wreck efficiency more than having a team that is creatively stunted (whether on purpose or as a consequence of other factors).  Creativity can catch problems before they start, it can find better methods of getting to the same endpoint, it can improve the output, it can have so many benefits to your project that it’s crazy to me that anyone would argue that it has no place in projects.

I once had someone tell me, without a hint of irony, that it was more cost effective to throw money at a problem that it is to pay someone to come up with a solution.

Seriously.

If you don’t see the irony in this, then you need to have a sit and think about your life.

What this philosophy is saying is “I’d rather pay someone else to come up with a solution to my problem, than pay someone I’m already paying to come up with a solution.” 

Now I hear you all grumbling, “but, if you’re paying someone else, then it means you already have a solution, therefore it would be cheaper.”  To that I say, fuck you, it doesn’t mean that at all.  It means you found something that you think will solve your problem, but there isn’t any guarantee that it will.  In order to be certain that it will solve the problem you need to pay someone to research the problem and figure out a way to fix it, which is what they are arguing is cost inefficient.

It's insanity.  Pure and simple insanity.

I know that this article is going to be pretty controversial.  A search of gaming subreddits will uncover a whole country worth of people salivating to wank off these AAA game publishers and studios.  They’ll say things like “they’re paying thousands of salaried employees for 10 years to work on a single game, of course it’s going to cost hundreds of millions of dollars;” “games are more complex, you can’t make something with a few developers and expect to make a profit, so you need to hire thousands of developers to achieve the same quality in the games from the 80s and 90s.”

It's bullshit, and the very real truth is that there is a ton of overspending for really dumb fucking reasons, and I can say that, because the observations of my friend are easily translated to other types of project work.  Project costs are out of hand, because of overspending for really dumb fucking shit.

I would estimate, based solely on my conversations, that games could save at least 25% if they just did their due diligence at the start of the project, and focused their efforts on working more efficiently.  Business projects are the same. 

Things won’t change, though, because too many decision makers are convinced that money equals success in all things, and grotesque inefficiency is the same thing as cost effectiveness.  The process just costs money, so fuck that process.

At the core, my takeaway is that the problem with projects of all types are those who argue that there is no other way and gleefully glom on to a shitty methodology, because they can't imagine a better way.