Trending
Opinion: How will Project 2025 impact game developers?
The Heritage Foundation's manifesto for the possible next administration could do great harm to many, including large portions of the game development community.
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 share three lessons and guiding principals from world class leaders for ensuring that my projects are successful.
This blog post is reposted from http://blog.syncbuildrun.com/?p=118.
I often wonder if I’m repeating myself with some of the stories I share, since I share them so regularly with different groups of people. However, a former CEO reminded me that it can take up to six times of repeating something for the message to really sink in, so I don’t lose sleep over it as long as I’m not boring my audience.
That said, there are a few key lessons that I learned from various leaders that I would like to share.
Shotgun Your Success Strategies
The first strategy is from a CEO who spoke at the World Business Forum in NYC. Her advice was, when approaching any goal, don’t just try one approach at a time. While it’s the scientific method to alter a single variable through multiple iterative approaches, time is too critical to waste running linearly thorough strategies. Instead, do many many approaches at once, like ten. Shotgun a bunch of methods, so that if seven of the ten fail, at least three will drive you towards success.
Big companies do this all the time with interviewing. When they post a job, they don’t just talk to one person at a time, make a decision, then move on to interview the next person. Often, they’ll interview several people in the same week, perhaps even in the same day, for the same position. Some will inevitably have other offers, will bow out, or won’t make the grade. But of the many people interviewed, one or two will at least be qualified and a good fit, assuming the prescreening process at the company is decent.
At SyncBuildRun, we realized we couldn’t just work on code all the time, we needed to also think about title videos, concept art, music, marketing, financing, etc. About half my time every day is spend writing code, but the other half is spent talking with my contractors, reviewing their work and providing feedback, handling legal and financial issues, speaking with advisors, interviewing potential partners, and doing forward planning. Even if one of these areas falls behind, I know I’m making progress on the rest of them, so overall, we’re okay.
Aim Higher Than Everyone Else
This one is from film director James Cameron, also at the World Business Forum. Jokes about his supposedly enormous ego aside, Cameron had it right when he was talking about how he approached making truly groundbreaking films. “I aim high, really high, way higher than anyone else. Then, even when I fail at a few things that knock me back, I’m still succeeding at a level well above where everyone else was even aiming.”
Amazing for both it’s hubris and it’s brilliance, this strategy has also served us well. While other game companies are eager to make the next Match-3 or Angry Birds clone, we’re aiming much higher with a long-term customer engagement strategy of multi-episode games that last for months, with content at a continuous weekly cadence. Sure, a one-off game would be easy, but we want to aim big. If we fail, we release a one off game. Going the other way would be nigh impossible. Our goals are actually a lot bigger than that (a lot), but I don’t want to spoil everything here.
Which leads me to my one bit of cautionary advice about this strategy: Aim high internally, but meter your external communication with your customers so that you don’t disappoint them. It’s far better to under-promise and over-deliver than the other way around, and if you’re aiming high internally but being conservative with your promises outside the company, you’ll be set up for success when you ship.
Cross Coverage is Critical
It’s great to have subject matter experts on staff, but it’s better to have folks around who know a bit about each others job, so that they can contribute constructively. Lane was one of the most fun, and most talented guys I ever worked with, and he had the role of “Technical Artist”, which meant that he made content and wrote code, basically did whatever needed to be done, to get some weird cool effect on screen. When we were trying to relaunch the Space Quest franchise at Escape Factory, Lane was tasked with Roger Wilco’s vacuum cleaner “weapon”, which needed an animated cone in front of it to display the area of effect. The cone didn’t track the player correctly, and was animating oddly. Sure, an artist and developer together could have worked this out, but Lane jumped in, fixed the content, and wrote the code to make it work the way the designers wanted.
This isn’t a call to hire people who are jack-of-all-trades. Rather, it’s a statement that your team should know enough about each others job that 1) they can contribute constructively about various topics that come up and not just the easy to discuss topics, and 2) they can cover for tasks outside of their direct area of expertise when someone is inevitably out sick or away on vacation. At AMZN, we had a rotating on-call system, where every dev would be on-call for a week and would have to handle whatever external or customer crisis came up. It always sucked, especially for the new hires who rarely knew what to do. I solved this by starting an on-call wiki for our group, where every time a problem came up that was new, the on-call person was required to document what the problem was and how they fixed it. Then, we would review the documentation as a team, and ensure everyone was on the same page. Stress around on-call immediately dropped, because instead of being a source of tension about the unknown, it was now a learning opportunity and a chance for cross pollination. Junior devs learned from senior devs, and senior devs got to watch junior devs automate away their ten step process with a 20 line Perl script. Everyone learned something.
The final bit about Cross Coverage is that it shouldn’t just apply on your production team. Ensure that you have this on your board, across your advisors, and on your executives. Have multiple people who know finance, not just your CFO and directs. Hire musicians, so that lots of people can discuss the feel, mood, and tempo of your soundtrack in actual musical vernacular, instead of just telling your contract musician “I don’t know, it needs to sound more purple.” Having groups of people who speak the same language is critical for successful and productive communication.
Read more about:
Featured BlogsYou May Also Like