Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
I recently was asked a few questions by a fellow who was early in his career and wanted some of my thoughts on topics he was facing. After I'd answered his questions I thought the answers were worth sharing.
I recently was asked a few questions by a fellow who was early in his career and wanted some of my thoughts on topics he was facing. After I'd answered his questions I thought the answers were worth sharing, so here goes and I hope you think they are worth sharing as well.
The only major decisions I made were early on I asked to move from pure management (3D department head) to product management (director) I made the same decision twice when I had been moved to more pure management roles. I realized I loved making things and just managing people didn't satisfy me at all.
My management style kind of grew out of a few core concepts, some of which came from the memoirs of Colin Powell (I'd used the basic concepts before I read about them it just helped to put them into words).
Ask first, talk later. - My best work was always when we encountered a problem and I'd sketch out the problem and then ask my core group for their thoughts. I already had an idea what I wanted to do, but sometimes they managed to change my mind before I spoke. It also allowed the person who suggested the concept to take ownership of it.
Know what you are building. - Early on my projects we always did a mockup of what we felt the game should look like at ship. This allowed everyone to have a common touchpoint of what the game would be and ended a lot of discussion before it even started ("let's look at the mockup")
Talk to everybody. - During NWN I spoke with everyone on the team at least once a week. I'd wander by, ask what they were up to and then casually dig into problems they were having. I'd list out the more serious issues and do something about them as soon as possible and ensure the person knew the issue was addressed.
Understand your role. - At the start if the project, the Director has to provide vision. In the middle it is support and editorial. At then end it is almost 100% support and enabling people to work. I really approached problems my team was having with an attitude that the people doing real work were more important than I was. Anything I could do to free them up to do more work was my top priority.
Presenting a positive outcome. - I screwed this up later in my career and it ended with a cancelled project. The director is going to know about funding issues or publisher issues. Some of this information the team needs to make the right decisions, some of it they don't need to know. You are a leader an as such you have to make the team feel like they can win, if they don't feel victory is possible, they'll go play for a different team. I support transparency, but until something is certain, you don't need to pass on uncertainty to your team.
How about now? - By this I mean a complete unwillingness to put off something which could slow down my team. If we were blocked by a decision, we'd grab the people who needed to be involved and solve it right then. I didn't schedule important meetings early in the project, I made them happen when they needed to. Later on I fell into the lazy trap and started scheduling weekly meetings to deal with issues and these wound up deflating the impact of right now.
Over time I became less rigid in my taking care of people, and resolving issues, mainly as a result of a loss of connection with the leadership. I had a really hard time feeling that our leadership was not listening and my diligence took a huge hit. I started deferring and handing off way too much and way too important tasks. As a startup founder, I'm getting a kick in the ass to rediscover my old behaviors.
The key with R&D is to figure out the problem you are trying to solve. Really dig into it, ask why it needs to be solved. Ask if there is any way to fake it or build another solution. R&D only makes sense when the user will notice. If someone will play your game and not notice the results of the R&D, don't do it. In the early days of Bioware, we didn't know much, so we did a great deal of R&D, solving huge problems which probably didn't need to be solved in hindsight.
I always leaned on my previous programming experience when we talked about R&D, and I could usually tell a rough order of magnitude around the problem. As a start-up, we avoid R&D like the plague. If we need a complex solution which doesn't currently exist, we dig into every possible way to solve it using know technology. I'm lucky in this respect because my business partner in IdeaSpark Labs / Beamdog is Cameron Tofer.
Cam was a former lead programmer at Bioware and a Tech lead at Namco. He's done a ton of R&D and as a result, he fights pretty hard to avoid it. If we need to solve the problem and it must be done, he'll get into it hardcore and answer the fundamental questions quickly, without getting fancy.
The big fear is that programmers love to feel smart and solving big, hairy problems makes them feel good. In some cases, people will pick a problem not because it needs to be solved, but because it will be a challenge and if they succeed, it makes them feel great.
So, with R&D:
Know the problem you are trying to solve
Come up with a few ideas for solutions to the problem
List out a few simple experiments you can perform to validate the potential solutions, ensure they have metrics for judging success
Build a quick and ugly prototype based on the experiments which solves the problem.
If everything works out, junk the prototype and build the real solution using the concepts proven in the prototype. If you built the prototype correctly, the code shouldn't be readable.
I had fun answering these questions and it helped me to try and articulate some of my thoughts around management and R&D. Thanks to M. for asking.
Cheers,
-Trent
You May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
