Read on Twitter
Seeing how 2020 happened and I didn’t get a chance to do my GDC talk, I thought I’d do a high-level thread here abut how I worked with a purely technical team when I’m not a technical person myself - complete with jazzy GDC title. Settle in, children...
First up, a little background! For 3 years, I was the producer for the tools & technology team, basically the team who make our inhouse engine and editor. The team was made up of 10-15 programmers and some tech artists.
I’d never worked with a purely technical team before, which lead to a fair amount of imposter syndrome – I didn’t feel I was technical enough to work with such a technical team. I was wrong - so I want to show people it may not be that different to working with a game team.
Why is this important? It’s likely we’ll work with lots of different types of team over our careers – and being able to work with a technical team is a huge asset. Increasing your knowledge base around tech means you can make more well informed decisions.
Working with a tech team opens your mind to different ways of working and thinking, and having a strong relationship with your team leads to better work output. Steep learning curves can be beneficial to getting better at your job. So…
Look at this as technical project management for seemingly non technical people. Here are a few small tips for how I learnt to work with my team more efficiently 
https://abs.twimg.com/emoji/v2/... draggable="false" alt="🎉" title="Partyknaller" aria-label="Emoji: Partyknaller">https://abs.twimg.com/emoji/v2/... draggable="false" alt="🥳" title="Partying face" aria-label="Emoji: Partying face">
First up: You need to get your team to trust you. Maybe they’ve worked with producers in the past who didn’t understand how they work; or who felt the most important aspect of being a producer was chastising them for taking too long on tasks or going off piste.
Having that kind of expectation makes it difficult for a team to trust you – so you need to build credibility. Show that you’re there to facilitate. For me that meant giving context to why we may not have delivered & understanding where we were with all the work on our plate.
One way I facilitated was asking my team to show me how to read certain things in a crash callstack, so I could assign bugs to the right devs. Previously we had one dev who looked after assigning out crash bugs – this was a bad use of his time.
Another was asking the right questions of the team to have an understanding of what was the most important thing – and why? I wont have all the answers to what priority things should be worked on, I need to be able to rely on my team to give me that information.
Making the team realise I wasn’t there just to task track or berate when stuff wasn’t completed, I was there to catch things before they got too far and help reevaluate if needed was a huge help. Asking the right questions made that process easier.
We implemented a system for build stability! We worked in a separate branch & would give ‘super users’ early access to test features & get feedback before a release to the mainbranch. We also implemented a process for testing changes before check in, leading to less broken builds
Convincing the team of the value of new process – Some people are apprehensive to change. Always demonstrate why this is making their lives easier and make sure to share the benefits of process changes with the people who resist change.
Dig into the reason current processes are failing – this helps to form new process by attempting to solve previous issues, I did this by trying to understand their current process by asking detailed questions and showing interest.
Suggest light improvements at first - when these prove fruitful, move to more impactful changes. Seeing the benefit of process change makes future change much easier.
Lean on your teams strengths. I knew which team members are able to explain complex code & features to me, and I leant on those individuals to understand the work on our plate. I always make sure to ask if I don’t understand something, - This is probably my most important point!
Never be afraid to ask someone to explain something to you or to get more information on something you don’t know about. 9 times out of 10 people are happy to share their subject matter with you or to make sure you understand something in more detail.
Technical teams are often methodical, logical and precise, so leaning on that when it comes to roadmaps and planning is imperative, too.
Communicating effectively! My team were super analytical and often want to just get their head down and write code. Being such a different communicator meant I was able to champion the team upwards and downwards – leaving them to get on with what they do best.
Lastly – Are you adding value by embedding yourself in the way they work? Constantly consider if the approach you take is a help or a hindrance to the team – never implement process for process’s sake. Sometimes this means doing things outside of your dayjob to support the team.
So, key takeaways - Being a tech producer is not that different to being a producer for another discipline. There are huge benefits to learning more about tech & working with people of different styles/strengths makes you a better producer.
Thanks for coming to my twitter GDC talk I hope this is useful thank you goodbyeeeeeeeeee
