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.
Q: Were there some hard career decisions regarding my career direction and what did I do?
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.
Q: How would you describe your management style?
- 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.
Q: you mentioned believing part of BioWare’s success was not understanding how many things could go wrong with a project. It seems common to run into problems that no one else has solved. What is your process for going about finding and developing a solution?
Is there a point in R&D where you say it just isn’t possible to get a feature done, or rather the path solution to a problem your working on isn’t the right one? How do you determine it?
- 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.