Before we get into the changes this year, how were we approaching production before? What were its strengths and weaknesses, and why was that the way we were doing things then?

I think we should clarify, it's not a reorg or a restructure. Those generally have negative connotations, so I want to make sure that's clear. That's not at all what happened. It was more of a look at the strengths of what we've been doing for the last couple of years. As we scaled up in certain departments and as we brought in certain talent, it was now about going, what could we divide this into that makes sense to make this go to the next stage? And Crow could talk even more to this, Dennis Crowe. I tend to call him Crow. We have a couple of Dennises, so Crow. What needs to be based around the features to allow for faster iteration, and what needs to be based around pipelines? And I think Dennis can even speak more to that. But this was building on last year. We had already done some of this at the same time last year, of going, let's get people into strike teams or into goal teams. There's always various production-y words to use for this same idea. Get people together, let them work together, work quicker. And as the team has shifted and the responsibilities kind of ebb and flow as we bring in talent in certain areas or in certain teams, we have to constantly evaluate this stuff to make sure it works well. There's a human element that I was mentioning at the beginning of this: these are humans making this stuff. And the more we work together, the more we work alongside each other, the more we know each other's strengths and weaknesses. I've mentioned this multiple times when you're forming any kind of team, we're in this phase now, performing. We know what people can do. We don't question where that information should go or what part of the team should work on it. Now it's about doing it, getting it done, iterating quickly on it. We do it often, but I'm sure next year we'll go through that again based on what we learned this year. And as the product evolves, and as we get more out and we're working really closely with the community and they got more content with 3.0, it was a big one for us to go, look at all this content and how it all came together, what's the next step for us. A lot of the R&D we've been doing, which is really what a lot of that stuff is that people are playing, is R&D. If this was any other game, people wouldn't be playing that stuff. That would be just us going, oh cool, this looks really fun, okay, but don't tell anybody yet, but look how fun this is, okay, there's a lot of broken stuff. And so we get to R&D alongside the community. It's really unique. It's a live game, but we're learning alongside them, for sure.

Just to echo that, I would agree. I think one of the things that we would probably want to say, though, is it's not necessarily a production change. It's a development change, really. And again, it was not necessarily a reorg. What it is, is understanding where we're at in development and fitting how we work to the work we need to do. So it's not about, we have these ideas of how we want to make our game. It's, here's right now where the game is at. This is what's working really well. This is all the research that we did and the experimentation that we did and all the things that we have made and shipped. We've learned a lot. The project's in a different stage. And so when the project's in a different stage, you should say, okay, are there things that we can do now that more match what we're ready to do? We know how to make a ship. We know how to make these characters. We know how to make cinematics. We know how to make these features. So now that we know that, we don't have to be in the experimental phase that was required. To make something new, there's no roadmap. There's no manual for how to make this game, right? So we had to figure that out. We had to research that, come up with all these ideas, try out things. Try things, and then you get a result, and that's not what you expected. So try something else, okay, that's a little bit closer. So now that we've tried a bunch of things and we kind of know what works and what doesn't, and now we have a base of knowledge and we have a great tool set, we have a great engine and all these types of things, the project's just in a different phase where it's, okay, now we know the features we need, so we need to reorganize how we develop. We need to have people work more closely together. On this half of the room, you guys can huddle up and go do features. Let's organize into some groups so you guys can kind of work together and just go hit these features up. The guys over here, you guys need to be producing a ton of exceptional quality content. And you need to be doing it in a very streamlined way where everybody knows what's going on. Everybody can see what's going on. And then the guys over here: we know what features we want. We know what content we want. We have a tremendous amount of it already made. So now what we need to do is evolve our tools to support all that. So you couldn't have done all this in those three groups, in terms of what each person needs to do, until you had done the research. Because if you just come up with that piece of paper and you say, we're going to execute this piece of paper, so let's just all go do it, well, now we're following a plan. And the idea of Star Citizen or any great game is not how closely can you follow the plan. The plan is the start. It's about making a good game and learning and adapting as you go. This is an adaptation as we go.