Producers - Knowledge Sharing

I've recently started working in a Producer style role at RetroEpic. I basically have no idea what I'm doing though, so I am creating this thread in order to get in touch with people that fill similar roles or have some experience in the local community. According to the most recent MGSA survey there are apparently 17 around here somewhere. :)

I call it a Producer role since I don't really know what else to call it. So it would be good to talk to other people about their day to day tasks as well and what they actually do as a "Producer".

I don't want to limit the discussion to certain people though. What I'm actually hoping to gain from this thread is some knowledge sharing. Everybody faces workflow issues sometimes, or procrastinates a little more than they'd like to. I want to discuss those kinds of problems here and see what solutions we can come to as a community.

I also thought we could share information about tools like Trello and Slack and have some discussions about best practices for those.

In the end, I really want to connect to the local people that are facing the same issues I am, so if you think you fill a Producer role, please post here and get in touch. :)


  • I recently found this article very useful: Five things I've learned as a producer

    Writing everything down is especially useful. The time I've felt super pedantic about it have always paid off while the times I slacked off on writing down what we spoke about have come back to bite pretty hard. And yes, people > processes. You can have well thought out processes or run process experiments all you like, if the people using those processes aren't happy, no amount of process change will fix that.

    Can I ask you what it is you feel your job as a producer is? You seem to be worrying about other people procrastinating, but I'd caution against making that your primary concern - use it as a signal, but not a thing to be policed. From my perspective, production is about efficiency: Making sure everyone's on the same page on a project, managing bottlenecks well in advance so that people aren't waiting on a key thing to be done, taking the time to look far enough ahead that you're not stuck in the direct week-to-week cycle of work and can navigate around icebergs coming in a few months, etc.
  • I'm not a producer but this stuff interests me. I'm currently working with a small team and what I've found is vital is clear communication channels. We don't use slack because that was an extra thing we didn't want to manage. Thanks to it's not too much of shlep but the fact that we can't send gifs is kinda annoying.

    Stand ups are great. I like having them as early in the day as possible. Best time for us is 10:00. The way we do them is just for everyone to articulate what they're up to at the moment and give a "deadline". I feel that when I've articulated my goals to the team there's a sense of accountability. That helps me stay on track and not procrastinate because there's someone else who knows what I'm aiming for. That person can then ask at following stand ups how that task is going.

    Trello, love it. First came into contact with it when I was working at The AppFactory. I've kept using it in the same way we had been using it.
    Pretty basic and self explanatory. So, assign yourself to a card put in progress, finish it put it in the done list of the day it was done.

    What I always try to do with the cards is to make them as small a task as possible. So instead of having a "Player Movement" card. I'd split it into "Jump ability on player", "Horizontal movement on player", "dash mechanic on player". I've found that having smaller cards helps with morale as you can finish them quicker and feel like you're getting shit done. While chilling on a card for a week feels shitty. Sometimes we've got Done lists for a day that we can scroll through. It's just a nice feeling.

    Just my 2 cents.
  • @dislekcia, thanks for the article. It breaks things down nicely.
    It's difficult to answer the question to what I think my job as a producer is. Part of the reason is that I've never really known what a producer is, but also because I don't think that producers do the same thing in every team. I'm talking about specific tasks here.

    There are some overarching goals that I want to accomplish, like remove overhead, increase focus, identifying when snags can arise. Those are all general things that can be achieved in various ways. I'm not sure if this helps answer your question though.

    As far as the procrastinating goes, I don't really spend time worrying about that at all. I firmly believe that if someone knows what they are supposed to do they'll be doing it. That isn't meant in the sense that if they've been told what to do they'll do's meant in the same sense that you we're talking about of being on the same page. I think people procrastinate (for the most part) when they are not convinced that the next action they take will move a project forward. So I agree, it's more of a warning sign than something to "manage". I was more wondering about how people actually deal with it when they do procrastinate. I'm checking my assumptions so to speak. :)

    We also use Trello for our projects(among other things). I like the simplicity of Trello. It's super easy for anyone to edit and moving cards around is so much fun(for me at least :P). It's such a visceral way to handle tasks. If it were feasible I would love to use actual cards like that, but that is a bit too slow. :(

    I want to ask you some questions that might seem completely ridiculous, but humor me if you can please. :)

    1) What does Backlog mean to you?
    2) What goes into the Backlog?
    3) How do you use the labels?
    4) How do you decide when a card is small enough? (ie. when do you stop breaking it down)
    5) Why do you keep multiple done lists?
    6) Do you have any structure to naming your Trello cards?
    7) Do you use the comments in Trello cards to communicate with each other?

    I'll leave it there for now. SO many questions. Thanks for the responses so far. I'm excited to see where all this will go. :)
  • I'd be keen to hear experienced producers like @Jason, @Shazfaery and @Counterspell weighing in. :)
    Thanked by 1Rigormortis
  • 1/2) Backlog is anything and everything that needs to be done on the project even set up a FB page, or youtube trailer. We've actually started more "Backlog" lists for ideas that may not be put in the project but you don't want to forget. Recently we've added a Sprint list for the week to create urgency on certain cards.

    3) We then have labels to differentiate bugs, art assets, prototype feature, etc. Just to see at a glance what the mountains of cards are.

    4) That's really dependant on the task. Sometimes, I know the card is maybe one line of code but I still add the card. There's times I don't know what actually needs to be done on a specific system card for example "Dynamic mesh animation". Like I've never done that. What I do though as I get to know what needs to be done I just create a checklist within the list that I continuously add to. It really doesn't matter to me how broken down the card is but sometimes you get the weird scenario where they're tightly dependant cards and you end up assigning yourself to 3 cards at the same time which should probably be one card with a checklist.

    5) The multiple done list is just what I was taught by TheAppFactory. It was mainly for the project manager to see what people were getting done and see if you're slacking quickly at the daily standups. Since the cards are so small you should be having something done everyday.

    6) No. In one project we didn't use labels for bugs so a bug card would read "[BUG] Rotating arm on orc not 360". Don't know why that happened. It was dumb in my opinion. It just randomly started and we kept with it.

    7) YES!!! Sometimes I pick up a card and I'm not necessarily close to the person to quickly ask so I tag them and ask a question. It also helps keep it in the card and you can keep track of what details are changing. I think this comes done to like the article said "write everything down". The comments also could be brain storming ideas on how to solve a problem or links to articles with some information.

    We're a very small and young team and we just change stuff and refine it as we go. Plus weekly someone always goes through our long Backlog and reorders them in some "this is kinda more important than the other" order. Very dynamic. Recently I've been thinking of making individual Backlog lists for each member in the team since we're small enough that we know who kinda needs to do certain tasks or in a meeting we've said "you're handling this and that" but I've been hesitant about it because I don't want to create too much clutter on the board.

    Thanked by 2Rigormortis quintond
  • @Rigormortis thanks for starting this thread!

    I am really looking forward to connecting with other producers. I have been doing game production full time for 5 years now and mostly been making it up as I go :)

    Some random things I have picked up:

    I have come to think that the job of a producer is to make things happen . This includes a lot of things and differs wildly from day to day and between projects and jobs. The producer needs to know about all the aspects of all the projects that may affect his team (the bigger picture). This knowledge enables you to direct the effort of individual team members in the best possible way.

    The producer needs to make sure that people are happy. There is (at least in my role) a very big HR component to production. Training new people takes ages and if you can keep people around for longer you will be better off.

    The producer also needs to be the buffer between management and the development staff. Management will very often get wacky ideas into their heads that need to be executed yesterday. The producer needs to be able to say NO we can’t do it. Or at least not now, or not for that amount of money. Being the buffer means you also need to take the blame when things don’t work out and never point to your team or individuals.

    It's important for the producer to keep calm. I think it’s very unsettling for the team if the producer is stressed out and losing his nerve because of things going wrong. There is always a way out or around a problem and freaking out won’t help anyone.

    I do a lot of problem solving in my role. Management will have some project that it needs to realize and the producer is the person that needs to figure out how to pull it off. This will involve finding the right people, time, hardware, tools, process, plans, designs and schedules. I find it helpful to get involved in implementation level problem solving as well. Sometimes developers and artists can get stuck in a line of thinking that just needs a little kick to get out of.
  • edited
    @Rigormortis I am not a producer (firstly).

    I agree that procrastination comes from not expecting that a person's actions will move a project forward.

    What I think I've observed is that when a problem is too difficult, with too many ramifications, the person who has to solve the problem can be paralyzed. Usually this is a creative problem that affects the vision of the game or a technical problem that affects a lot of systems where the results are difficult to foresee. And as a result of this decision paralysis, the person procrastinates. I don't think this is exclusive to really big features, and some problems cause more procrastination than others.

    I think I've observed that other times procrastination comes from not expecting an intrinsic reward for the work you need to do (like the action doesn't move the project forward in the person's mind, or the work the person has to do cannot be executed adequately given the resources).

    And it makes sense that procrastination can come from the person expecting no extrinsic reward for the action the person is to make (most people being more motivated when their team is going to notice their work and be pleased).

    And it makes sense that procrastination can come from just not knowing what to do.

    And I imagine I might be leaving other causes out. Obviously there are some causes unrelated to the producer's job, like the person just having a lot of personal stuff they really want to do. But I think the causes I've outlined to relate to the actions of a producer.

    You and @Dislekcia say that procrastination is a signal, but not something to worry about in itself. If it's a signal, then what actions would you take as a producer when you spot it? (or what actions would you take to avoid this in the first place).

    And are there other problems that someone procrastinating might signal?

  • EvanGreenwood said:
    You and @Dislekcia say that procrastination is a signal, but not something to worry about in itself.
    @EvanGreenwood, I tend to think of procrastination as a symptom. So as with any symptom it can lead you to the cause. Trying to treat the symptom might bring some relief but without addressing the cause of the issue this will always be a temporary solution.

    To answer the follow up question is difficult. I think it will always depend on a myriad of things. A lot of times I think it's good to sit down with whoever is having trouble just so they can bounce ideas of you in a no pressure environment. I've found that it's helpful to have a sentient rubber ducky to talk to.

    I'm also fairly adept at breaking things down into tasks(things with a definite start and finish state). So helping people do that on an as needed basis has also been helpful in the past. A lot of people can do this, but when you are in this state of paralysis you mention it's often difficult to process/break down things on your own.

    I believe the key is being pro-active about it though. People that I've met who work in games usually work their asses off, and they do that because they want to. Procrastinating is probably more frustrating for them than anyone else on the team. Each person's reasons will be slightly different, but having some of the basics sorted out goes a long way. Clear end posts for sprints, individual tasks that can be completed, not trying to catch up on work by working more...those kinds of things prevent a lot of it happening in the first place. If you can pro-actively keep these things in check, then each individuals reasons can be handled retroactively.

    I'm also a huge fan of removing mental overhead. Say for instance there is a major feature that a coder just doesn't have any idea how to implement. It's not a critical feature atm, but needs some serious thought and discussion before coding can start. The coder that has to implement the feature might be thinking about this discussion that has to happen a lot more than they need to. This could slow down their current work. What I would do in that situation is schedule a specific time for a meeting about that feature. Create a short agenda of points that need to be covered(that can be added to until the meeting date). That allows the developer to "forget" about the feature until the meeting happens.

    I hope some of that made sense, sorry I'm typing as I think and don't have a lot of time now to review my own wall of text. :P

  • edited
    @Rigormortis That makes sense. And I think those are some good points. Though, with regards to creative paralysis, I'm not sure that your solutions would go far enough as to solve the problems I've seen in the past. I'm not sure what the solutions are to be honest. I feel like sprints and Trello, while great generally for improving motivation, do as much harm as good for this kind of problem where the timelines are unknowable and thumbsucked estimates just add unhelpful pressure.

    Creative paralysis is something that affected me, and a couple others, several times during Broforce. So I guess I'm fishing for perspectives. I hope this is something our team might be getting better with, but it won't be until the next big project that we know.
    Thanked by 1Bensonance
  • Creative paralysis is not something a producer can fix, imho. What the producer should be able to do is see that a person is struggling on something and realise that they're not going to get further by staring at it any longer. It's then important to get them onto something that would bolster their creative ego or energy and may boost their confidence or kickstart their creativity enough to go back to the original problem.

    "Sleep on it" (ie: give it a rest and come back to it later as well as literally giving your brain time to mull it over during sleep) is sound advice for this kind of problem.

    When I have been in a project management role, this is what I would do when I found a team member stuck. Tell them not to worry about that problem and refocus them on other work that also needs to be done. In the end they'd always come back and have everything done in time.
  • I agree that a creative paralysis is different than a solving a technical problem. My background is coding so I tend to focus more on those kinds of problems when I get stuck into helping to solve the problems themselves. There I at least have some sense of what is going on.

    With regards to the creative paralysis you are mentioning. It is difficult. For me though if someone asks my help on this, or the advice I would usually give is to pick something and get on with it. This is putting it glibly but that is what it comes down to for me.

    To explain a little better. Usually the paralysis isn't choosing among an infinite amount of things you want to do, but rather a few options that you won't know which is best until the very end of the project. So, if you've narrowed it down to some set of choices, then choose one(usually the one you like best). Once you choose one, try and figure out what the risks/problems and benefits are of doing this specific thing. If at this stage the risks outweigh the benefits(not compared to other options) then go back, scratch this option and choose another one. At some point you will have something with which you can progress on. For me it's then important to have certain criteria where you stop step back and see if the risks/problems are still worth it for the benefits you are getting. It really helps at this stage to have other people that can spot potential problems and/or benefits that you won't.

    That being said, I might be answering a wrong question since our definitions of creative paralysis might be different. What do you mean when you say creative paralysis?
    Thanked by 1EvanGreenwood
  • You and @Dislekcia say that procrastination is a signal, but not something to worry about in itself. If it's a signal, then what actions would you take as a producer when you spot it? (or what actions would you take to avoid this in the first place).
    So, I'm not a producer (but I play one on TV), I guess that I've had production roles because they needed doing and we were a small team, etc.

    I agree with @Rigormortis that procrastination isn't an indicator of a specific problem, just that there seems to be a problem of some sort. So step one is always figuring out what's wrong, or maybe what isn't wrong. I think it's important here to rely on personal knowledge and understanding of whoever you're interacting with, rather than having some system in place for how you're supposed to solve this (although I will say that having some systemic approaches to things definitely help on the other side of the producer-developer interaction, a formalised space can help to establish that this is a work situation, not a personal one, and as such there are different goals here).

    If the problem is a creative block, then try solutions to that based on what might have worked before. Sometimes refocusing on something to get "momentum" can help as @dammit pointed out. Sometimes a team exercise to spread the creative load helps. Sometimes just realising that this isn't procrastination, but someone's brain digesting something unconsciously is the way to go. I dunno, creativity (especially mandated creativity that has to happen NOW) is really hard.

    I will say that if sprints/task tracking are adding pressure, then they're not being employed well. Ideally, sprint goals should be a ratchet towards a thing becoming more and more finished, if a sprint goal leaves the game in an unplayable/broken state with less features than it started with, then that shouldn't have been a sprint in the first place. Sprints/scrums are a good way to deal with unknowable timelines because they're supposed to constantly add features/content to a thing that could be "complete" after each sprint, but isn't yet because you want to do more... If a task list/tracking system adds pressure then I'd hazard the tasks are too large or poorly defined. If reading a task makes people go "Er, how do we solve this?" then it's not properly decomposed. Having a team meeting to decompose tasks can be a great thing to do BTW: Everyone gets more in touch with the state of the project, working together to chew problems into manageable bites feels good and ups motivation, and because the discussion was a group thing you'll know who to talk to about a particular task or idea should you need support on it. If your team CAN'T decompose tasks well, then it probably means you're not sharing the same goals and you need to reaffirm all of those together first...

    At least, that's what I'd expect a professional to do.

    Thanked by 1EvanGreenwood
  • Adding to the questions in this thread: I'm curious as to how producers deal with deadlocks on issues within the team.

    As an example, say there are a few different ways to implement a specific system/feature for the game. Everyone agrees that it needs to be implemented, but the conversation about how to actually do that has stalled. What do you do?
  • If the implementation design of a feature is deadlocked (the developers cannot agree on a design) then it falls to the lead developer to make a call.

    If a lead developer is not available (indie/small team) a secondary goal needs to be added to the mix. Which of the designs favour a secondary outcome that was not previously considered? (fastest implementation, most robust in the long term, etc.)

    In general I think deadlocks need to be handled by the leads with guidance from the producer in terms of preferred outcomes.
  • It's a bit old (and the audio quality isn't the best) but a producer talk from the JHB meetups

    Thanked by 2dammit Rigormortis
  • wow, blast from the past.
  • If the implementation design of a feature is deadlocked (the developers cannot agree on a design) then it falls to the lead developer to make a call.

    If a lead developer is not available (indie/small team) a secondary goal needs to be added to the mix. Which of the designs favour a secondary outcome that was not previously considered? (fastest implementation, most robust in the long term, etc.)

    In general I think deadlocks need to be handled by the leads with guidance from the producer in terms of preferred outcomes.
    We now select team champions per project. Generally speaking there is a art champion and a programmer champion for each of the larger projects. For a smaller project, someone might be tasked with being the project champion. Being a champion doesn't mean making all the calls, obviously, but it does mean that when a decision needs to be made and there is disagreement in the team, then the champion makes the call. And that call may very well be to go with a particular suggestion from one of the team members, not necessarily their own personal idea or solution. The champion is expected to know quite a bit about what's going on on the project and sort of acts as a mini producer per project (for the smaller projects anyway).
  • Hi, nice discussion. There are two tools we use at Fuzzy Logic that might be of interest:
    - Hansoft for project planning. Trello is great for a small amount of tasks / very small team, but you might find it gets a bit unwieldy after a while. Hansoft is more formally defined: sprints, assigned to, priorities, time estimates etc. Using time estimates we can make sure we don't over assign tasks for a sprint, and by updating work remaining throughout the week, "management" constantly have a clear picture.
    - HipChat for team communication (the same as Slack). We found this works awesomely for our team. For example an artist might share on there several different mockups they've done, and then everyone can respond with their favourite and give feedback in their own time. This means everyone has the option to be involved, but saves us from having to formally call a meeting on everything.
Sign In or Register to comment.