I gave a talk at PAX Dev recently on the skill of staying with unpleasant emotion. My basic argument is, if you're not comfortable staying with fear and anger, then they control and influence your actions in bad ways and you make poor decisions.
Here's the video of the talk. It's just under an hour long:
I had more material for the talk than I could fit in an hour, so a bunch of stuff got cut. One of the big things was my thoughts on production - the discipline in game development responsible for schedules, coordination, and logistics - and how a skillful relationship to negative emotion is especially critical for producers.
Before I left Bungie, I had a conversation with a friend there, a producer with whom I had often disagreed. He spent a lot of time working with data to make predictions about the schedule. I was teasing him about how elaborate his spreadsheets were. I told him I didn't use them very much for my team.
"Right now we're just working to make things faster, and that means iterating - figuring out what the next low-hanging fruit is, knocking it off, and then moving on to the next one. Extrapolation isn't even meaningful right now."
"Well, sure," he said, "Obviously you can't predict how long it'll take to build something if you don't know what you're building."
And therein lies the fallacy. Creative work like games is chicken-and-egg by nature. You are always simultaneously building the thing and figuring out what it is you're building. They are both convergent processes. You start out having very little idea of what you're building, and very little of it built, and you must move both of those things together at the same time. This is true of all creative work. I read Change by Design, about IDEO's process, and it's immediately recognizable. Everyone in creative industries arrive at this rhythm. It's fundamental.
To use phrasing like "if you don't know what you're building" is deceptive because it suggests it's a black-and-white thing: you know, or you don't. In reality it's all shades of gray. It's about certainty. The only time you're 100% certain of what the thing will be is when it's done and you can look at it. Until then you're just getting closer.
To make matters worse, you can never really know how certain you are. Maybe you think you're almost there, and then you start pulling everything together and that's when you spot a hole in your design. You thought you were at 90%, but you were really at 60%. Whoops.
And that's the rhythm of the work. That doesn't mean you can't aim for dates and hit them: You do that with the final piece of the puzzle, scoping. The cadence looks something like this, in the end:
1. Refine your vision for the thing.
2. Estimate how long it's going to take.
3. Start building it and, simultaneously, learning more about it, building your certainty.
4. When you learn something surprising that invalidates your estimates, go back to step 1.
Every time you pass through step 1, you reform the vision around what you have to work with and how much time you have left. You trim things, you reenvision the thing as a new thing, coherent in itself, that fits in the time left.
Don't spend too much time on #2 for any given iteration. You just need to do it well enough to keep working and to have something reasonable to track against. But you don't ship great thing on time by estimating perfectly. You ship great things on time by estimating adequately, and iterating a lot, and constantly reenvisioning what fits.
OK, so generating ultra-precise estimates isn't really necessary. But it's worse than that: If your area is not terribly certain, generating ultra-precise estimates is extremely dangerous! And here's where it relates to my talk: I mention a few dangerous knee-jerk reactions to unpleasant emotion, and one of them is the Craving for Certainty. As a producer, you need to be very careful not to feed this craving when that certainty is a lie.
Ideally, when your area is uncertain, your job is to be a shepherd, driving your team to the areas of uncertainty and getting them to linger there, doing work to make decisions they can be sure of. But you can't always do that. Sometimes the path to certainty is blocked. And when that's the case, you have to fight to make sure everyone still knows things are up in the air. It's like old maps. You don't just leave an area blank. You write in big letters: "Here Be Dragons."
Here's a story of how things go wrong:
You're a producer. Your team was working on some new design features, and needed to see them working in-game to really be sure of them. But the game wasn't working, so that work had to wait. So they really weren't finished, and you knew they weren't finished. But then your boss asked you for a rough calendar of feature work for your team. You sent back a spreadsheet, broken up by person and by month, roughly penciling in what they'd be doing and when it'd be done. There was no way in the spreadsheet to represent uncertainty, though. You knew that more than two months out it was very rough. Probably wrong. You said so, in the email where you attached the spreadsheet. But once the spreadsheet had been forwarded three or four times, nobody read that part of the email anymore. The other producer on the other side of the building who was building the overall schedule just copied and pasted yours in, and all that uncertainty was lost. Then people started using his aggregate schedule in presentations. "We know how it'll all fit together," they'd say, and everyone breathed a sigh of relief.
You kept telling people that it wasn't really so certain, and they paid you lip service. "Oh, sure, everything can change." But their actions belied their words. They didn't really take it seriously. They kept marching ahead. They made plans around the data you gave them. And so when the time came, and your team revisited that work, and found that they were totally wrong and had to rework a bunch of stuff, the schedule implications sent shockwaves across the whole project.
This happens because people love certainty and hate uncertainty. When you generate an artifact like an Excel spreadsheet with a schedule in it, people will treat it as gospel, because they like feeling certain and don't like feeling uncertain. Nobody wants to stay with the discomfort of a wide-open scary future. Daniel Kahneman talked about this on stage with Nassim Taleb. He said, people have real problems keeping multiple possible futures in their heads at once. It's not something we're good at. It makes us feel bad, and we don't like it.
I'm suggesting something radical, something that I've never seen anyone actually do. If you're a producer, and someone asks you for a schedule that extends into areas where you're very uncertain, say no. Refuse to generate them a schedule. You know it's a lie, anyway. And if they get angry and say, well, just give me the thing that seems most likely right now, say no again. Refuse. Because you know that schedule will end up on someone else's desk, stripped of the uncertain context, and it'll get used to make other predictions. And people will seize on it because it looks like certainty. And bad things will happen.
In a perfect world, on a creative project, you resolve the biggest risks earliest, so that over time, your certainty converges smoothly towards 100%. It doesn't always work out perfectly, but a well-structured project should be able to get pretty close. And yet, on every game I've worked on, there's always one huge late-game surprise, a huge upheaval way too close to the finish line for comfort.
And this is always why it happens. Denial. Craving for certainty. Earlier in the project, when the risk should have been seen, should have been worked through so the team could have made a real, confident decision, they got short-changed. They were coerced into making a commitment without doing the work to believe in it. And through a series of miscommunications and games of telephone, everyone understood it to be a solved problem.
Don't feed the Craving for Certainty.