Sometimes there's something you want so much, or that's necessary for the next six months of work, that we need to take that risk even if the patch or the deliverable slips a week or two in order to get it in. How is figuring that out? Is that just the decision of one person? Is that the work of a committee? Is there a formula to it?

Usually when we identify potential risk for a deliverable, like a feature or something, I think we had a recent example that we've talked about, the ship trespass feature, for instance. So we had a full-blown schedule for the feature on a task level. We knew when it would be ready, but there was always this risk looming that there could be more edge cases that we have to address before we can release the feature in a good enough state, right? So that was one of those risks that we tried to mitigate but couldn't, and then we didn't feel comfortable with just releasing it anyway because these edge cases needed to be dealt with, and so we had to pull it out of that release. But in other instances, it's usually a discussion between production, the team leadership and a director like Todd. We will sit down, we'll go over the risk, and then we'll give him a few options and discuss it with him. And then if he's happy to go down the road of, okay, let's shoot for it, right? Let's put a few more people on it so we can get it out on time, then we'll do that. And if he would prefer we keep it, we make it good, we get it in a better state, then we'll do that instead. It's always a coordination effort between leads.

And to that I'd add, sort of how this process starts is you look at your release, just the release that you're planning for, and you try to identify what are our tentpole deliverables, right? What are the things that are really going to prop up this release and be the big selling points for this release, the things that are going to excite people, right? So you identify what those things are. And you then discuss what your level of risk appetite is. And basically risk appetite is what's our tolerance for risk with these specific features. And generally speaking, your tolerance for risk, basically allowing the potential to go down different paths that might impact a schedule negatively, your risk appetite might be higher for tentpole deliverables because that's going to be a make-or-break sort of feature. Whereas something that may not have as big of an impact, we don't mind delaying slightly to give it the time it needs. Or it could be even a bigger thing, but we're like, you know what, this needs a little bit more time in the oven, right? The risk appetite is low on this. So let's go ahead and do that. The trick with this is that everybody has to be in alignment. Everybody has to have the same risk appetite.