The Many Faces of Low Morale

And it's one, two, three,

What are we fighting for?

Don't ask me, I don't give a damn,

Next stop is Vietnam.

And it's five, six, seven,

Open up the pearly gates.

Well there ain't no time to wonder why.

Whoopee! We're all gonna die.

    -Country Joe and the Fish

I want to talk a bit about morale.

As game developers, we have good days and bad days. When it's good, it's pretty exhilarating. We're lucky in that our industry is one where many of us do what we love; what we believe in. Most of us approach each day energized, and ready to make something cool.

When that morale drops, however, even the passion we have for our work can be too weak to stir us. It becomes a chore to start or continue a task; to find inspiration; to be critical of our own work; even to approach others. In a way, much of what makes us good game developers comes and goes with our morale.

As someone who's worked continuously for the last 14 years, I've been through a few spells of low morale. And as I became more familiar with them, I started noticing certain signature behaviors in myself and others. During one particularly long bout, I decided to catalog my feelings and behaviors as I had them, with the intent of cleaning it up for presentation and review later.

That "later" has finally come, and I've put together the list below. My hope is that it does a few things:

1. Help managers recognize the tangible benefits of high morale by contrasting against what is lost to low morale.
2. Help employees to understand how low morale can cause a negative feedback loop, worsening the problem.
3. Help both managers and employees alike to recognize the symptoms when they suffer from them.

Low morale has a way of creeping in, so sometimes we're under its influence before we realize it. And in many cases, our natural tendencies are to bunker down and make it worse. Recognizing that it's a problem, and when it happens, are important first steps towards taking corrective actions. Because, as we will see, low morale can have some pretty devastating effects, to individuals, their teams, and projects alike.

Motivation to Work


Probably the most obvious (and expected) effect of low morale is the lack of motivation to actually do work. I would have difficulty starting new tasks, or getting out of idle slumps. The prospect of coming in to work in the morning, or back from lunch to a task, felt burdensome instead of inviting. 

The days quickly devolve into a series of attempts at avoiding work, whether it be checking email, "researching" something on the web, or even making a long, slow trip to get a cup of coffee. I found I'd actually relish the need to use the restroom at times, because it meant I could take a walk away from my desk, even for a few minutes.

Not surprisingly, this type of foot-dragging creates a downward spiral, as tasks get pushed back later and later, piling up and seeming even more insurmountable against the already low, and falling, motivation.

Reactive Posture

Another fairly obvious change in my work ethic involved my willingness to seek out work. When succumbed by low morale, it was tempting to just wait for tasks to come to me, rather than seek out what needed doing most. I just didn't have the energy nor motivation to make new work for myself. Instead, I would lay low and hope to be looked over when it came time to task someone with something.

Unfortunately, that tended to make things worse as well. Invariably, the tasks that did find their way to me were things that others didn't want to do, either. And since I was decidedly un-busy, I was ripe for nomination. Again, tasks would pile up almost as fast as my distaste.

Indecisiveness/Ambivalence

One change that was a bit more of a surprise to me was my lowered investment in decision-making. As someone normally pretty engaged in lively debates (and a confessed contrarian), I was surprised to realize I just didn't care one way or the other how things turned out.

For someone to be this far gone should be concerning. Possibly the only mechanism one has for making things better is to be involved in decisions as they are made. Furthermore, personal investment in a project or organization are only likely to get worse as one sits out important decisions.

Less Feedback

Related to indecisiveness, above, I found a significant drop in my willingness to volunteer feedback to decisions and announcements. Like above, this only serves to dissociate one from the work or environment to which those decisions and announcements pertain.

Defensive Scheduling

My time became a battleground when my morale was at its lowest. I found myself defending personal time against any intrusion. If meetings ran long into my lunchtime, or overtime was called for, I was way more likely to make a "thing" of it. 

Ironically, for all of the lack of motivation and decisiveness exhibited in all other aspects, this area seemed to be the exact opposite. I had fuel for endless battles when it came to defending my personal time, and it only grew stronger the more I was resisted.

Pigeonholing


As with defensive scheduling, above, I also felt a distinct lack of enthusiasm or energy to do things not directly related to my job description. "Not my job" sprung to mind whenever anyone approached me with something I could find an excuse not to do.

In practice, this rarely plays out as obvious as that. Most people would prefer not to be "that guy," who shirks duties and passes the buck. Whether out of politeness or self preservation, most will quietly, begrudgingly, accept the tasks. However, this attitude can be as damaging just by virtue of the stress and resentment it breeds.

Distraction

I also found it can be easy to become distracted by anxiety when one's future is uncertain. When one is worried about what comes next, their mind is not on the "now," and the work suffers. This is a slightly different facet of low morale, as it can infect even the most diligent employees. This sort of anxiety is often the result of leadership failing to communicate in ways that the employee responds to, failing to follow-through with promises, or not communicating at all.

To make matters worse, most game developers are able to call upon an extremely powerful imagination when trying to ascertain worst possible outcomes. And fear can be infectious between colleagues.

Introversion

Possibly one of the more self-destructive aspects of low morale is the tendency to withdraw into oneself. Some employees actually form stronger coworker bonds during times of low morale, finding unity in the shared suffering. 

However, many in the games industry, myself included, are introverts. And introverts often find it easy to abandon social ties when things get tough. Over a period of time, I found myself transitioning away from daily lunch and evenings out with coworkers towards lunches at my desk, and retreating home after work.

The key behavior to watch for isn't necessarily reclusiveness (which might be normal), but rather a sudden or gradual divestment in social ties.

Nothing to Lose

For all the negative side-effects of low morale, it turns out there was at least one benefit: courage. When things are bad, it can feel like there is little room left to fall. Sometimes this can manifest as a desire to champion change within the workplace. 

More often, however, this is the trigger point for employee turnover. Visions of greener grass are all it takes to start vetting other employers, or new careers altogether.

Psychological Impact of Low Morale

Many of the above symptoms are not unlike experiencing depression, and maybe that should be no surprise. For many in the game industry, passion is what defines their career, and having that relationship fail can be devastating.

What are some things we can do to improve morale? A satisfactory discussion of that topic is well beyond the scope of a concluding paragraph. I've heard it said that employee autonomy is a good place to start. Another area to examine is whether your workplace is fostering the right balance of intrinsic and extrinsic motivators, as having  purpose is an important motivator. Or maybe you just need to work on getting everyone on the same page.

Whatever the case, morale should be one of your organization's top concerns, right up there with finding top talent. Because if your current top talent is suffering any or all of the symptoms above, the aren't really top talent anymore. They're just unhappy warm bodies drawing top talent salaries until they can be inspired again.

A Note About Low Morale for Indies

Indies are by no means immune to the effects of low morale. It might sound as if many of the above are AAA organizational and leadership issues, but low morale can precipitate out of a one-man show as well. Faith in one's work, skill, or even platform of choice, can be shaken. Indecision can paralyze progress. Distractions become that much harder to combat with nobody nearby to keep you in check.

And the effects are just as damaging. Low motivation to work can halt progress. Energy for making decisions can come up short, causing a shift to busy work instead of meaningful analysis. And the tendency to withdraw socially can inhibit good customer relations and PR.

Indies have a fairly serious obligation to keep their personal health and morale in check. We may be blessed by a vast network of internet buddies pulling for us, but our remoteness from the network might mean we're "off the grid" for too long before someone notices.

Being sensitive to the symptoms of low morale can help alert us to things gone awry. We can recognize self-destructive behavior if we know what we're looking for. And armed with that knowledge, we can make incremental changes to help get ourselves back on track, or seek a friendly ear when it's too much to tackle alone.

If You Agree to Crunch, You're Part of the Problem

Recently, Ben Kuchera called to light a eulogy for LucasArts, drawing particular attention to the sacrifices made by employees in enduring crunch. In his words, crunch is a "monstrosity" not to be romanticized, and that's actually a pretty good way to put it. For not only is it a wholly destructive force unleashed on those who work in the industry, it also never seems to die, no matter how many times we try to kill it.

And as developers, it's our fault.

What is crunch?

Before I get into the hows and whys, though, let's quickly establish some definitions.

Overtime, which is a component of crunch, is defined as working more than 8 hours in a day, and more than 40 hours in a week. Some places vary in those numbers (e.g. Alberta, Canada uses 44 hours for their week), but it's roughly in that ballpark for most of the world.

Crunch is the "sustained" application of overtime. Definitions of what "sustained" means here vary, but I think all will agree "months" qualifies without hesitation. "Weeks" has a pretty good shot of qualifying as well. "Days" is probably arguable, and starts to depend on how often within a month it happens.

Crunch is, basically, leaning on overtime too heavily to solve problems. And as it turns out, there are some more concrete definitions of how much overtime is "too much."

Why do we crunch?

What is good about crunch? Why do we do it?

Ostensibly, crunch is meant to increase productivity of a given set of developers within a given time frame. Evan Robinson actually addresses this question in his Why Crunch Mode Doesn't Work: Six Lessons:

Management wants to achieve maximal output from employees — they want to produce a (good) product as cheaply as possible. They also want to avoid hiring extra resources that increase the cost of the finished goods unless absolutely necessary. On the surface of it, Crunch Mode looks like the most obvious and logical way to reconcile these two desires.

He also points out that this is often related to a looming project deadline. He then expresses that assumption as a simple, linear function:

O = R * t

Where O is the team's total output, R is the team's rate of output per hour, and t is the number of hours worked.

However, as Evan's extensive research illustrates, R is not constant over time. R actually varies over the course of a normal work day, peaking in the first 4-6 hours. In fact, R approaches and even drops below zero after enough hours, resulting in negative output for workers.

Effectively, an employee starts damaging the product they work on (bugs, quality issues) if left to work for too long continuously. (For reference, Evan cites 21 as the number of continuous hours of work one needs to reach a mental state equivalent to being legally drunk.)  Conversely, working 8-hour days was shown to produce a 16-20% productivity boost over working 9-hour days.

What's more, prolonged periods of long work days start to produce a cumulative fatigue, reducing the average daily rate R by more each subsequent day. In The Revay Report, experimenters found that 60-hour weeks boost productivity for a few days, but productivity noticeably dropped after a week, cancelling out the boost at 2 months, and continuing to worsen over time after that. (see figs. 2, 3a, 3b, page 2)

Evan goes on to point out that every single other industry has spent the past 100 years optimizing this formula, and has arrived at the 8-hour day, 40-hour week. In Evan's words:

Any way you look at it, Crunch Mode used as a long-term strategy is economically indefensible. Longer hours do not increase output except in the short term. Crunch does not make the product ship sooner — it makes the product ready later . Crunch does not make the product better — it makes the product worse.

I don't think I could put it any clearer than that, except to point out that this is only how crunch negatively impacts the product. For the other drawbacks, I certainly can't put it any better than those who already have. In short, crunch ruins lives, products, and sometimes companies, with no up-side.

How is this our fault?

So how is crunch our fault? I mean, developers are the victims, aren't they?

It's true that developers bear the brunt of the pain in crunch. And it might be comforting to imagine that someone "up the pay scale" is responsible for botching things enough to warrant crunch. It's that last phrase, though, that's the problem: "enough to warrant crunch."

How can a project ever warrant crunch? We've already shown that crunch has a purely negative impact except in the shortest of intervals. So how can we agree to do it? Whether for selfish reasons or love for our product, how can we say it's "ok" to begin working in such a way that damages the product, ourselves, and our coworkers?

Nothing warrants crunch. As we've just seen, industry has been wrestling with the pros and cons of crunch for a century now, and crunch has been shown to be ineffective. Crunch is not a rational option. And our guilt is enabling crunch to happen in the first place.

If you agree to crunch, you are incrementally making the whole industry worse for everyone, yourself included.

Take a moment to let that sink in. Everyone is worse off for your agreeing to crunch. You have to work more, and deal with mounting stress and diminishing rest. Your coworkers have to agree or appear unreasonable in the face of your compliance. The lives of those around you and your coworkers are affected. And your company is forced to absorb the drop in product quality, along with a workforce that's losing competence, morale, and loyalty by the day.

Crunch isn't helping anyone. And by agreeing to it, you're making it easier for crunch to exist.

What if your manager asks you to crunch?

In short, tell them "no." Be polite about it, of course, but don't let politeness give way to bad business.

Look at it this way. By asking you to crunch, your manager has simultaneously just done two things:

1. Indicated that they have failed to manage the project appropriately thus far.
2. Indicated that they have no clue how to continue going forward.

Now, if you like this manager, it might be a good time to pull them aside and direct them to this post, or Evan's piece, or any of the research sources Evan used. If they didn't know, fair enough. Now they do.

If they still insist on crunch after learning about its negative effects, you might want to say "I'll think about it" and speak to their manager. Again, arming yourself with polite concern, and some established research on the topic, hopefully you can impress your point on someone with more experience and reverence for historical data.

If you find yourself talking to more than 2-3 managers in this way without progress (or run out of managers), you might want to consider another option: finding a new employer. Because any company willing to impose crunch on their employees at that many levels of management has a deep-seated philosophical problem, and it may take more than common sense to fix it.

What if your manager doesn't ask you directly?

What if you're in a place where crunch is the elephant in the room? I.e. nobody explicitly asks you to crunch, but it's implied that overtime is expected? Perhaps that's just "the way it's always been," and sticking to normal working hours seems like an invitation to be fired.

Again, this is a topic to be broached with managers. Give them the benefit of the doubt. Bring it up, and see where things go. As above, if you can't make any progress after 2-3 rungs on the company ladder, that may be a sign you're in a place that's unhealthy.

What if they fire me?

What if they do?

Ask yourself that, seriously. If the company you work for sees your concern about unhealthy work-life balance as cause for termination, I think you can safely write them off as an employer you want a relationship with any longer.

You may have heard (or even been told at some creepier companies) that there are 100 others waiting to take your job if you leave, so it's no skin off the company's teeth if you go. That's not true, though.

Good companies recognize the true cost of finding and training good workers. It takes time and resources to find a good worker, and more to train them in your company's workflow. If your company doesn't recognize this, it's probably not a good company. They'd be doing you a favor by firing you.

What if I'm compensated for crunch?

In light of the aforementioned effects of crunch, this should be irrelevant. The focus should be on removing crunch entirely, not putting a band-aid on it.

If employees were compensated for crunch, we might see a change in crunch habits in the industry, but that's just conjecture. As it is, employees are rarely compensated fairly for their crunch, either in dollars or days off.

California may be the one place where this is addressed by law, promising anyone under $83k annual salary ($39.90/hr) time-and-a-half pay for any and all overtime (Labor Code Section 515.5(a)(3)). They also define several exceptions and exemptions, which mandate overtime for entry-level or in-training software fields, film and television artists, and writers. How this impacts software development in California remains to be seen, though.

However, whether you're compensated for extra work or not doesn't address the bigger issue of whether your management knows what they're doing or not.

The bottom line

The point to remember here is that a century of industrial research and work hours testing has resulted in the nominal working hours of 8 per day, and 40-44 per week. This combination produces the highest sustainable productivity possible.

In short bursts, overtime can produce a slight boost in productivity. But the boost wanes after only a few days, and actually cumulatively grows worse each day after that.

If your employer is suggesting (or fostering) an environment where overtime is sustained longer than a few days, start considering whether they're causing more harm than good. See if you can open a dialogue with managers or HR to address the problem in other ways. And be prepared to say "no."

If you like your employer, reward them accordingly. Give them diligence, timeliness, hard work, honesty, creativity, accountability, loyalty, and all the other things you're paid for. In exchange, expect them to provide a healthy working environment, tools and support, intelligent planning, and monetary compensation for your efforts.

NEO Scavenger's Humble Beginnings

I was cleaning up some old files on my laptop this weekend, and I came across some of NEO Scavenger's earliest prototypes and documentation. And let me tell you, they were pretty eye-opening. Even for me. NEO Scavenger has come a long way.

Since this blog is meant to help newcomers to the indie world, I thought maybe I'd share some of what I found. Not only is it interesting to see how an idea evolves over time, it also might encourage those who are daunted by the finished products they play.

Few games, if any, spring forth whole like Athena from Zeus. More often, they're ugly, slimy, helpless little buggers, just like you and I were when we were born :)

A Little History

In April, 2011, I left my job at BioWare to try my hand at making games of my own design. NEO Scavenger was a foggy idea I had kicking around my brain, and was actually quite a different beast back then.

In fact, NEO Scavenger even had a different name: Post Apocalyptic Oregon Trail (PAOT). Here's a look at it's original design doc (pre-dating the design doc published in June 2011):


Title
Post Apocalyptic Oregon Trail (PAOT)

Category
Survival/Strategy

What Is The One Sentence Story Line?
Exiled from MegaCity, the player must survive the wild wastes as he travels west in search of paradise.

What Is The Game About?

Salvage food, shelter, and tools from the wastes to meet daily survival needs, as you travel west to paradise beyond the mountains.

Game Overview

• Man against nature
• Plot your course west, one day at a time.
• Search for food in the wilds and wastes, to stave off hunger.
• Find shelter from the elements to stay healthy.
• Find and improvise tools to help in your journey.
• Balance the provisions you carry against the fatigue of carrying them.
• Manage inventory by arranging your belongings in pockets, compartments, and other containers like puzzle pieces.
• Find transportation to help you travel faster, at the cost of fuel and maintenance.

Differentiation Within The Category

• Focus more on survival through resourcefulness rather than gunplay
• Opposition is mainly environmental rather than soldiers, monsters, etc.
• Play style is more laid back and pensive than Resident Evil type survival games.

Franchise Strategy

• Free Flash game, licensed to game hubs
• Possible ad revenue through MochiAds
• Story establishes IP for POST (Note: POST was a working title for a post-apocalyptic setting)

Similar Titles

• Oregon Trail (I, II, Yukon, Amazon, etc.)
• Survival Kids (1, 2)
• Lost in Blue (1, 2, 3, Shipwrecked)

The game described is actually not too far off from NEO Scavenger, at least in terms of theme and gameplay. The focus on traveling west is different, as is the origin of the character (MegaCity exile). And the transportation bit is admittedly optimistic.

The "Franchise Strategy" is a completely different story, though. NEO Scavenger as a free, ad-supported game was based on the assumption that I would work on it for a few months, then launch. Little did I know that I'd be working on the same game for years (starkly against my own advice).

Also, revel in how little I knew about the survival genre. Granted, many survival titles have cropped up in the past two years. But I'm pretty sure I was missing several important titles in that market assessment.

NEO Scavenger's First Prototype

Perhaps a more telling example of my lack of understanding is NEO Scavenger's first prototype:

Press the "I" key to see the map in the prototype.

Impressive, huh? You can move colored blocks around a grid, and switch to a map view to watch our protagonist travel west from "Elis." There's some random weather variables, tracking of time, hunger, sleep, and distance, and the ability to choose between traveling or sleeping for the next 4 hours.

The next prototype added a fancy map to the background:




Not much more to do, though. I eventually added a more representative item to the inventory screen, and made each location contain two of those items. The player could take the "soup" at a given stop, and the character would automatically eat when hungry:




It even featured an end-game! Patient players would be rewarded with green text proclaiming "You Made It!"

It wasn't very fun, though.

There were some interesting systems under the hood: weather simulation; tracking hunger and sleep; and item management in a grid. But I found myself clicking the "travel" button thoughtlessly until I needed to recharge "sleep." There wasn't much to the gameplay loop. No strategy. No risk. No fun.

I started wondering whether it might be more fun to navigate a map rather than a line. What if the player had to choose where to go, and there was no guarantee food or encounters would await them in the direction they chose? What if moving around was more or less costly depending on the terrain? What if visibility was limited by terrain?

Also, I was hooked on Civ V at the time.

So I decided to try changing the game to utilize a hex map. And this is how that looked, initially:

Still not much to look at. In fact, almost all of the systems of the above prototypes were stripped away, here, and it was just turn-based movement on an hex map, with date tracking per-turn.

Visibility, though, was a big difference. Not being able to see the rest of the map, and having to choose which way to go, felt like an improvement over having a linear, prescribed path to follow.

And within a few days, I had this:

Now I was actually starting to enjoy the prototype. Exploring the map kept my interest, as I wanted to see how the world looked, and what landscapes I could reveal. Movement was more strategic, as I weighed visibility vs. movement costs.

There wasn't any tension nor risk yet, of course, but it was starting to feel like a "toy" rather than a "tech demo."

A week later, and there was day, night, and weather!

Day

Night

Rain

Still no risk vs. reward, but I was starting to get more inspired with each iteration.

It was at this point that friends were starting to ask more frequently what the point of the game was. And they were right to ask. I needed to take a step back, and come up with a plan.

I drafted a new design doc. I started prioritizing features and tasks against that design. And from that blog post onward, you can see the iterations NEO Scavenger passed through to get to where we are today.

Rainy nights with stuff to do, and things to fear!

Baby Steps

Getting back to the original point, it's important to remember that making a game is a series of baby steps. Your game might not start out very good-looking, or even fun. And as you can see from PAOT/NEO Scavenger's history above, it might even involve a false start or two.

However, determination is key. As an amateur (programmer/artist/designer), I had to keep pushing forward, despite my own shortcomings. I made a ton of mistakes, too. Some more than once.

Over time, though, the baby steps add up. The thing you're working on gets better each time you add something that's necessary, or take away something unnecessary. Your own progress becomes a thing that motivates you, rather than just hope and optimism.

And eventually, you enter the phase where you wonder when you should call your project finished. I'll let you know once I discover the secret to learning that lesson!