As a producer you maintain an overview of the project progress and coordinate the disciplines (Art, Design, etc) to bring together a final product in the game (ship, location, etc), however to maintain the overview you need to be in the detail of each discipline. How do you draw the line between maintaining an overview and going too far down the detail rabbit hole? Give us an example.asked by Graxas

I think this is a question we've both been looking for, at least we've waiting for this question to be able to answer it.

It's very tough. We're going to get to later, I think there's a question on ownership but when we talk about what our backgrounds are, what we're experienced in and what we know we'll tend to spend a little bit more time in those. So you hire different production with different skillsets to provide you different perspectives. So if you have a producer that's very technical they may know a little bit more about the detail so they may answer those questions better. As you said in that post, "know enough to be dangerous", right?

Yes. I actually got that from Senior Producer Jason Hutchins.

It's great, it's exactly right. So I think the question's "how do you draw the line?" You just got to figure out what you need to dig into. For me, it's good to have an overview of the schedule; to plan it; to work with your leads and your team; but then sometimes you have to get into the weeds, you have to dig in even further. So it's not necessarily you shouldn't do one or the other: it's more you do each at different times.

That and when I first started here, I'm not a coder, I'm not a programmer, I'm not an engineer, so there was a little bit of a feeling of displacement when I first started because I wasn't really sure if I would be able to talk at the level that's necessary for the engineers and designers. But just through sheer saturation I feel I can at least carry on a semi-decent, intelligent conversation that doesn't rely on just grunts and pointing.

So being able to have a conversation about the Item system or the Entity Token system with developers, like on a phone call this morning, I think we should know enough just to be able to ask questions on how progress is going and know when someone is bluffing us. So we have to be able to read, what's the word I'm looking for, anticipate what the needs of that particular discipline are. We don't need to be experts in it, we just need to know enough to be able to converse with the developers and be able to manage those tasks.

Sure. So give us an example. I think you already started talking about one: the Entity Token. Right?

Yes!

So how did you manage that how did you draw the line between; how far did you go versus "I just need to stay back and help you guys get it done"?

For reference, this is what we were talking about on a Skype call we had this morning with our UK office, with one of our programmers Stephen Humphreys, and he's in charge of our Entity Token which is the sequel to GOST. So I am not fluent in FlowGraph in CryEngine but with the way the Entity Token system's working I know enough about what they are trying to accomplish with it to at least know what the end goal is; what they are trying to do to get there; what the voids are; and if a certain person leaves an aspect of this project what more resources do we need to allocate to that.

And knowing who has what skillset is absolutely necessary knowledge to have in order to be able to fulfill that void. So in talking to Mr Humphreys we knew that he was making progress on certain aspects, certain concepts; I need to be able to ask how far is he; where's he going with it; and i had to be able to converse with him at a level where it showed I understood what he was trying to do.

I would say lastly I was just re-reading this about "how you maintain that overview?" That's kind of the point of production: we are the third party perspective; we are the outsider; we aren't in the weeds per se so we are able to get a large overview. So I think, intrinsically, by being Production and being required to not know everything down to its base level that allows us to keep that overview. Right? So then we chose, as producers, where we should learn more information to help understand that better.

That becomes a double edged sword because the more technical detail you have, where does it stop where the producer starts getting more involved with the actual technical, for example, if the producer can read code or write code it doesn't mean that he's going to start jumping in and changing people's code when he sees a mistake or he feels something should be changed. That should be up to the designers and the programmers, and the producer should just be there to guide them towards the specific objective and not interfere with what the designer and programmer is doing.

Absolutely, great question.