This’ll probably be a multi-part post, written over a few days, just becuase I realized that one of the things I deeply wished I’d done while Self Aware Games was in its heyday was evangelize how we did what we did.
And what we did was that we beat one of Zynga’s big cash cows (Zynga Poker) with a team about a tenth their size with a minuscule fraction of their budget. They had the hype, they had the resources, and we ate their lunch.
Not only that, we did it with almost no one ever working more than a 40 hour week. The sole exception was having a handful of the artists stay for an extra few hours to get some critical stuff done one night, and when that was done, we post-mortemed that as a failure of leadership.
Our game (Card Ace: Casino) went on to become #1 on the App Store in its most competitive category, our company ended up getting acquired, and then later, that game was the basis for multiple $1B+ acquisitions.
Again, with almost zero crunch.
So there are two questions I hope to answer:
1.) How?
2.) Why?
And I’ll get to those. They’ll be the next two posts. But first, the thing I want to address is that there is a huge difference between what you do as a founder for yourself, and what you do for the team.
But they’re also very intermingled, and it takes a lot of thought to make sure that your actions match your words, and even more, that your values match your actions.
The first thing to know as a founder is that no one will feel the same way you do about the team/product/company. And unless you are giving everyone a really unusual amount of equity in the company and they have the same decision making power as you, that disparity in commitment is correct. Being salty that people aren’t giving it their all the way you do is profoundly un-self-aware.
They aren’t compensated like you. They don’t have as much of an ownership stake in the company as you. They don’t set the direction like you. Their risk/reward profile is usually totally different than yours, and if you expect people to behave like you behave, when all those variables are different… you’re making a huge mistake.
This is why when I see founders talking about “leading from the front” like it’s some deep thing… fuck you – of course you should be leading the charge. You know what’s harder than living the 24/7 grindcore life?
Leaving the office at the end of an 8-hour day.
I was never the last person in the office. And yeah, what kind of example does that set? It sets the example that I’m leaving because I’m gonna go pick up my kids, have dinner with the family, and you should do that with your family or friends, too.
And then I’d answer customer support e-mails and deal with other stuff until 1 in the morning. Did I tell folks that was what I was doing? No. Did I spam them with e-mail at midnight? No.
My job wasn’t to make people sprint to the point of failure. My job was creating an environment where my team could run at speed forever.
There are a lot of reasons I despise crunch. But the big ones are a.) burnout and b.) (I should have used B for Burnout) single-mindedness.
Burnout’s downsides are obvious, and I’d be surprised if anyone reading this hasn’t experienced it in some form. I give young folks some conflicting advice at the start of their careers. Never work for a company that crunches intentionally, if you can avoid it. But also, work your ass off and put in as many hours as you can. The difference is the company expecting it as a baseline from you – to devote your whole life to it – don’t do that – and choosing to crush every task you’re given and show you can deliver above and beyond what’s expected. That’s you choosing to spend your time to build a reputation.
But the single-mindness part of it is important, too.
The problem with obsessively working is that all you get to experience is your obsessive work. When I was at EA, working on the Sims, I’d get in at 10, and go home at 10-midnight most working days. There was a stretch where I did that 54 days in a row. During that time, I did absolutely nothing else but work. I didn’t have any hobbies, any interests. I didn’t spend any time with friends. I didn’t learn anything, except stuff I explicitly needed to learn for work.
There was a period in 2008-9, where every game’s main character was a white, bald space marine. The baldness was probably because hair rendering wasn’t very good yet, but everyone was a space marine of some kind because every person leading a major game at the time consumed the same media as kids (Aliens, Warhammer, etc.), and spent every other waking moment making and playing games. So they all had the same influences, and they all made the same game. Minor differences, sure – but basically everything converged on this one kind of expression of their interests.
On the Sims, I ended up doing my first real “game design” work revamping the food system for Sims 2 Console from the ground up. I built a huge spreadsheet of ingredients and methods of cooking, and spent weeks coming up with plausible results for every combination under the sun, and a whole matrix of stats for various ingredients and ways they could be prepped. It all was based in real food, and how real food would be prepped, because I loved to cook.
That whole thing came from having the time and mental bandwidth to devote to developing an interest. And bringing that interest to work made the game better.
So much of what we’d call “innovation” is the merging of unexpected and disparate interests. Seeing something in one field you can apply to another – where no one else could come to that realization because you didn’t have the interests you had.
That’s the opportunity cost of crunch. It’s why every game had bald space marines. It’s why sometimes every AAA game under the sun feels the same. It’s because when all your love is games, and all you do is games, you can only make games that are like other games. You need to have a team that has a diverse set of interests and worldviews, and time to cultivate those interests.
End day 1
—–
Turns out, there’s a lot to talk about “how” when I think about how we developed games at Self Aware & my later teams. But let me try to break it down into some bigger chunks:
1.) Continuous Deployment, de-risking releases, how we communicated with users
2.) Clear direction & distributed decision-making
3.) Scrambling the status quo with focused chaos sprints
My favorites are 2 & 3, but by far the most important was #1. When I think “crunch”, it always comes down to deadlines and scope. With games, a lot of times the project ends up talking about launch dates long before the project is done. This used to be a necessity because of long lead times for manufacturing, the importance of holiday releases, and coordinating shelf space and marketing budget in retail stores. Most of that isn’t relevant anymore, and even when it is, it’s probably not all that relevant to *your* project these days.
I wish I could say this was some sort of stroke of bold personal genius, but as with most things, we happened upon this concept a.) as an accident of circumstance, and b.) out of necessity.
The circumstantial bit was simple – in 2009, you couldn’t count on a release date because you couldn’t figure out when Apple would approve your app and release it. Yes, if you were “big and important”, you could figure these things out in advance because Apple would talk to you. But if you were us, you got absolutely nothing from them most of the time. You could “hold back” an app for a release date, but if you tried to predict when your app would get through approval, you’d almost always be wrong. So you either predicted a very conservative date, or you just had to roll with the punches. We chose the latter.
Again, in 2009, getting your app through approval took a [shakes Magic 8 ball] amount of time. Maybe a day, maybe a month. Totally unpredictable, but usually for smaller devs, weeks. At one point, we ran a bunch of calls to third party things when the game launched. An iOS update borked one of those things, and black-screened the game on launch. So the only thing that was making us any money now died on startup 100% of the time. And because we are now also in the future, we learned to feature flag all those things. But at the time, this was absolutely fatal. The only option was to update the app, and hope that Apple would approve it quickly.
We happened to have a very, very big gun we could fire at the problem. Someone very high up at Apple who we had a unique relationship with, but we could only fire that bullet once in our entire existence. This was that time.
The app was approved and updated in two hours. But we knew we’d never, ever be able to use that option again (I can tell you the story IRL, but not here, sorry!) – so we realized as long as we were beholden to the App Store approval process, we were never safe.
This led to a radical restructuring of our game, and one that was extremely high risk at the time. We completely revamped the app so that any iOS native stuff was in the client, but then literally everything else got yoinked out of the app, and reimplemented as HTML5, which at the time, was getting to a point where it could do what we needed for the games we were building (both Fleck and Card Ace Casino).
This meant that everything in the game, from the UI to the tuning to the gameplay, could be updated with a server push. Since Self Aware’s core mission was multiplayer social gaming (at a time when “social” for us meant *actually something you wanted to play with your friends*, and not just spammy dark pattern manipulation thanks Zynga), everything was always online anyway.
Which meant, aside from maybe a twice-a-year client update to keep up with Apple’s updates & added functionality, we no longer had to go through the app approval process. We could launch anything, change anything, whenever we wanted.
It’s hard to overstate how scary this was at the time. We were sure that if Apple found out what we were doing, we’d be ejected from the App Store, and the business would be doomed.
But we had to do it, because we’d seen the unacceptable alternative. And as we began to experiment with what was possible, we realized that this structure was an unbelievable advantage.
The key was that rolling out an update was easy. The super-key was that rolling back an update was also (relatively) easy.
Think about every release that you’ve ever done, and how risky it is. The risk is “how much person-time worth of work is going into this release, and how much can go wrong?” The riskier your releases are, the more stuff that can go wrong, the more you have to play defense. The more conservative you have to be with your experiments.
When you get to a point where you can release any time you want, and you can roll back any time you want… you can do anything.
We did entire top-to-bottom revamps of the UI. We added new games. We changed how the mission-critical purchase flow worked. We’d hotfix problems. We’d roll back features. We’d launch something, find a problem with it, roll it back, and then re-launch it in a single day.
We made all kinds of mistakes, but we learned so much, so fast, that it was unlike any other kind of development I’ve ever experienced.
Compare and contrast:
1.) After we were acquired, we had a change to make to the purchase flow for Casino. At a time when it was making about $500K/day. The acquiring company wanted to make sure it’d be safe! So throughout the feature’s development, they had reviews with PM’s, the lead PM, the lead engineer, designer, team lead (no longer me). Weekly meetings for months. When it was ready for release, it was tested to the ends of the Earth. Finally, months and months later, it was released. Made no difference. No negatives, so in that sense, “success”. But also, no positives.
2.) When we were operating the way I operated, we’d design and implement the feature – probably would take a week or two. When it was done, it’d go through normal testing, and then release on a Tuesday. We’d watch the data, and if it dipped, we’d roll back. If we screwed up anyone’s experience or caused any downtime, we’d reward players who raised any issues, sometimes literally giving out free stuff or trigger sales for everyone. Usually this would cause an increase in revenue. But we’d know in an hour or two if it was working.
The thing you may not be thinking about is that option 1 did have a cost.
Five to ten people in a room for an hour every week for months adds up. Particularly when the people in that meeting are expensive. It costs in money, at that point to the tune of tens of thousands of dollars, and it costs in opportunity. Both for the people, and for the company.
Most of those people didn’t need to be in most of those meetings. The four to six months it took to roll out that feature was four to six months of not learning.
Before the acquisition, we could have iterated on that feature 20-30 times, each time learning something significant. After the acquisition, we learned once.
De-risking releases builds speed. It builds confidence in experimentation. It builds an environment where the question isn’t, “How safe is this?” It’s “How cool would this be?”
In the time between 2009 and 2010, Zynga released two major updates to Zynga Poker. By the end of that time, they went from #1 to #2. We release every week, often multiple times a week. We made massive changes to every part of the game, building not just poker, but the first unified casino app, many world’s first features, entirely new types of slot machines that no one had ever made before, and we went from #100+ to #1.
Being able to release continuously has two other things worth talking about, but this post is getting super long.
1.) No crunch. If a feature misses its expected date, there’s another potential release date next week. Something is gonna release this week regardless, so if you need more time, take more time. No pressure to finish if it’s not ready.
This isn’t the same as “no pressure slack off whatever.” If you were late because you were lazy, you’d know about it. But games are inherently unpredictable, and building something new cannot be scheduled definitively. Acknowledging that, and acting appropriately, created respect for the process. We didn’t ask for bullshit dates and we never held you to them if you were working diligently, which everyone did.
2.) You have to communicate carefully to your players. You cannot promise things. Early on, in my enthusiasm for what was coming, I’d often tease features that were in the works. This would invariably backfire, as things slid their schedules. I think one thing that was interesting was that because I was the one who teased stuff to the audience, and I was the one in charge, and I was the one who caught all the shit from the users when stuff didn’t go out…
..no one was more aware of how stupid this was than me.
Which meant that I learned quickly not to do it, and was able to push back any time someone asked/demanded foresight into what was being released. Causing the negative consequences, and having them land squarely in your lap? That’s the best kind of feedback. Very impactful.
So I learned quickly, we don’t tease features. We talk about them when they’re done. Not even hours before. There were so many times when something was set to go out, a total sure thing, and then it’d be pulled at the last second because something went wrong.
And every time someone got pissed about it, it was my fault because I was a blabbermouth. So I’d have to apologize. But I did my best to be the wall that stopped the pressure from the players from getting to the team. Me feeling bad was my fault, because of my actions. It wasn’t because the feature was pulled, because pulling the feature was the right call.
Continuous deployment’s benefits are huge. So huge I cannot imagine developing in any other way anymore. Honestly, even if I was making a boxed product, this is how I’d develop it regardless. Maybe will talk about this more in the future.
End Day 2
—–
Gonna jump around a little to write about one of my absolute favorite “tools” as a team lead – the chaos sprint.
I started doing chaos sprints when I was running the team at Self Aware. The goal of these sprints was to drop everything we were working on, and as a complete team, focus in an absolutely ludicrous way on a single problem for a very short, very intense period of time.
Sometimes it was an internal problem – that we were missing some tool, or that some particularly set of problems had backed up and gone unaddressed for too long. Sometimes it was that a specific metric was weak and we needed to fix it. But the point was that it was one simple, measurable problem that everyone could understand. Let’s say “D1 retention needs to be doubled for this game to survive.”
We’d completely halt the roadmap, and everyone would stop what they were doing. We’d get together, I’d talk through the specific issue, things we’d maybe tried in the past, why we needed to address this, what it meant to players, etc.
Then we’d reorganize into as many small, cross-disciplinary teams as possible, with a bias to grouping people who had never had the chance to work together before. You’d have the entire morning to brainstorm with the team, and figure out what you were going to work on, and we’d get together after lunch to share ideas.
After lunch, you’d just get to it. Some teams needed more thinking time, some teams would get straight to prototyping and building.
The goal was to have something playable by actual users by the deadline. Initially, we gave teams a week. So by the following content release, you’d have to have something you could ship to players.
This forced a really dramatic focus on scope. What can you do in a few days + QA that will move the number in a positive way? Working with different folks gave you more exposure to ideas you hadn’t heard before. Andrew Klose, for instance, would always have ideas that were shockingly evil, which was hilarious because was normally such a thoughtful, player-considerate person. But these sprints brought out a wild mercenary side of him that was delightfully strange. Seeing new groups of people get rattled by him was always hilarious.
So, super tight scope, new teammates, harsh deadline. The week would end with everyone sharing with the whole company what their team had done. (PS: cross-disciplinary didn’t just mean devs. It meant marketing, social media, etc. The works. Ideas from everywhere.)
And then at the end, we’d ship it, test the ideas, and see how it worked. Every single time something surprising happened. Usually something surprisingly effective, sometimes surprisingly educational, sometimes delightfully idiosyncratic that we’d never otherwise have done. Always excellent. Not everything worked, that’s fine.
“Failures” were never failures. That phrase, “You never lose – you win or you learn” was really applicable here. Everything was public, everything was supportive, because no one knew what would stick.
Stuff that didn’t move the needle usually got pulled, and sometimes reworked.
Over time, we’d shorten the sprint length. What started as a week eventually hit my favorite duration – one working day. This is such a bonkers time requirement to ship something to players that the ideas get really weird, which usually means something very interesting happens. The one-day sprints usually aren’t complete things – but they often became the starting point for incredibly creative things.
Needing to work with new people under ludicrous time constraints was both a bonding exercise and a way to break everyone’s habits. People who were new to the process often hated it – it was scary and unnerving – extremely uncomfortable. But that’s the point.
After going through the process a couple times, I think people generally came to really enjoy it. The positive benefits become obvious pretty quickly, and the new relationships and practice focusing on what’s important carried over into day-to-day work.
The general cadence for this became roughly twice a year – that meant the main roadmap didn’t get shaken up too often, it was a change – if everything is chaos all the time, injecting chaos sucks, and there were usually enough new people that exposing those folks to more people usually happened at the right time.
This was one of my favorite tools as a team lead. The combination of positives was huge, the results were delightful, and it was a way to break up problems that everyone knew existed but would never make it on the roadmap, which was also super satisfying to the team.
At my last job, where one of the things we did was create a lot of small experiences, these sprints led to a lot of the best things we ever made.
Super fun. If you want to try this, you have to start with a small problem everyone can understand. You have to not dictate solutions at all. You have to have a very clear and short deadline. You will have to help teams get through the brainstorming part, unless they’ve done it before. You will have to correct direction, and initially, help them manage scope, because this is usually shorter & more intense than anyone is used to.
So it’s a work, for sure. But well worth it.









































































