Read Time: 5 Minutes

Complexity is a constant challenge for us in game development. Interestingly enough, even as previously complex problems are now more straightforward, new complex problems come in as we become evermore ambitious in our goals.

A great example is that technology, tools, and 3rd party solutions that give developers access to incredibly high graphical fidelity and game engine power are more common than ever. Yet, game companies are running into more issues with game-breaking bugs, release management, and technical risk than I’ve seen in my career.

My takeaway is that dealing with ever-increasing complexity is part of what it means to be a leader in our industry.

As we covered in last week's newsletter, we often deal with complexity by denying the risk and attempting to plan our way around it. If we can get the tickets all organized and broken down so everyone knows exactly what to work on, that complexity goes away…..right?

You should approach this differently.  If you do and master the necessary skills, you’ll be among the top-most capable leaders in our industry.

The first concept I want to leave you with is understanding the level of complexity/uncertainty in each problem you encounter (or perhaps all of the relevant problems you see for your project).  It’s important to understand that different levels of complexity require different responses from you.

A loose framework is:

• Known knowns: the problem is simple; everything is predictable.

• Known unknowns: the problem is complicated but still measurable and analyzable. We know what we don’t know. We can't say precisely how things will work.

• Unknown unknowns: the problem is chaotic; things are constantly changing. We don’t know what we don’t know.

You can also use Dave Snowden’s model below to get a general idea of how to think (and hopefully breathe) at different levels of complexity.  I have no idea why his model goes counter-clockwise.

Hopefully, this got the juices going. I want to provide you with four essential tools you can use to deal with complexity yourself as a leader and build a team/org that’s resilient to complexity, ultimately taking some of that burden off of you.

Remove it Aggressively

If something is incredibly complex and risky, eliminating it is the easiest way to solve it. I’m shocked that people don’t talk about this more often.

I understand that this requires some “gusto” and risk-taking for you as a leader.  It also requires a decisive approach to management and a willingness to get others on board.  However, removing a very complex and unknown component of your project is one of the easiest ways to reduce the risk of failure. If that’s not worth spending some of your influence on, I don’t know what is.

Most leaders I see swim in complexity because they want all the cool features, all the new tech, all the latest tools, and the most brag-worthy data points to talk about externally. Most of these companies also end up digging their graves. The studios I see actively managing this complexity by aggressively removing anything that isn’t imperative to the goal are killing it out there, delivering great products at record speeds.

I did this on my projects regularly. Every complex backlog item, tech investment, or feature idea that I could “dismiss” from the backlog was a massive win regarding focus and project risk for my team. A day spent digging into this is a day well spent.

Action:

1. Look over your project's most significant investment areas (use your roadmap if you need to). Rate the items in terms of complexity (use the frameworks above if you have trouble). Ask your fellow leaders if they can get on board with removing even “one” very complex item in the spirit of risk management. If you can accomplish that, you’ve done an excellent service to your team.

2. Sit down with your team and ask them about the following three major roadmap items. Understand how they’re thinking about the problem and the critical components of each roadmap item.  If a roadmap item is four pieces, is 80% of the risk in one of those pieces?  Is that peace critical to the goal?  If not, remove that piece; again, you’ve done a great service to your team. If that piece cannot be removed, focus the team's effort on it FIRST if they’re not already.

Focus Yourself on Clarifying Objectives

We talk about this idea a lot, but I want to cover it specifically regarding complexity.

The cleaer your goals are, the easier it will be for your team to handle complexity without you.

When the work is incredibly complex, you need maximum clarity on the goals and direction. This is why we constantly hammer on goals. In game development, the world is one of ever-escalating complexity. Identifying and clarifying goals for our teams is one of the best ways to add value to the bottom line.

On the largest projects I ever worked on (hundreds of developers), we had space to discuss and clarify the goals daily. As the project grew larger and more complex, I spent more of a percentage of my interface time with the team discussing goals (and less discussing the work). 

Action:

1. Ensure the goals are clear. Spend time weekly with your teammates, identifying them or clarifying the ones you already have.

2. Ensure goals are discussed amongst the team regularly.  The larger the project, the more precise and understood the goals need to be.

Compartmentalize

A key tool in battling complexity during development is sectioning things off, removing dependencies as much as possible, and creating clean interfaces between groups.

API-centered development is one of the most significant technical leaps in the last 20 years. For those of you who aren’t engineers (don’t worry, I’m not either), it’s an essential concept for you to understand. In the same way, the engineering community has brilliantly used this solution to manage “n-squared” complexity in the technical space; you can use these principles also to manage project or creative complexity.

APIs allow engineers to get access to other technical components & data through a clean and knowable interface.  So if my component calls your component, we just need to make a “handshake” that we’ll follow the same rules and communicate in an agreed-upon way. Then, and most importantly, I do not need to understand how your component works as long as I adhere to the communication rules we’ve agreed on and you provide me with what I need.

Not needing to know how your component works and being able to “trust” your system allows me to call it when I need it and reduces my complexity.

This is what I mean when I say “compartmentalization.” It is a fantastic way to manage complexity.  It doesn’t just work with technology - it works with teams, too! Remember that this approach to development requires you to ensure each group is as functionally independent as it can be (cross-functional teams, for example). The fewer dependencies, the fewer “API calls” you must make between groups.

On the huge project I was referring to earlier for League of Legends, I created interface rules for teams to interact with each other. This included clear roles, expectations, and rules of engagement. This didn’t just make their interactions and requests knowable; it gave them the luxury of not needing to know all the details of the other teams' other work. The more I could compartmentalize them, the more they could focus. Because the teams had a common and knowable interface, they could trust the other compartments and focus their efforts internally!

I mentioned earlier that I focus my effort in these situations more on goals, clarity, and systems. These compartments functioning in a trusted and knowable way also allowed me to focus my efforts on higher-level things. Because my team leads knew how to operate, run their compartments, and interact with other compartments - I could take my hands off.

Action:

1. Inventory how many dependencies (operational and work-related) your teams have on each other. See if you can identify 30% of them to cut out by creating “rules” that they can lean on amongst each other.

2. Do your teams have a defined interface? Are roles and responsibilities clear? Does each group have a leader? If not, define these things and get your teams on board.

3. If this isn’t how your team is organized, and it feels daunting, try creating a diagram of what your team could look like if it were organized optimally. Draw it out on a miro board or whiteboard.

Emergence is your secret weapon

Human creativity and ingenuity are the best ways to “digest” complexity. Every day, your team will develop new ways to do things, new ideas for scope to remove, or suggestions on improving the process.

Your job as a leader is to leverage this energy to improve your system, remove distractions, and encourage your team to do more. This is your secret weapon to dealing with complexity: Let your teams help you.

When building projects, I was stymied by how much my team responded positively to being given bigger responsibility, more ownership, and more precise focus.  When they had those things, they’d come up with ideas constantly. I’d encourage them to vocalize them to the team and implement their suggested changes.  Now, this team that might, in another scenario, be a gigantic thing I need to manage has become a living, breathing, evolving entity.

Closing

Consider the models above when you inevitably run into complexity in your projects.  Remember the four key areas to focus on when driving your teams through the dark woods.

1. Get rid of complexity.

2. Clarify objectives

3. Compartmentalize

4. Use Emergence as a tool

Whenever you’re ready, there are 3 ways we can help you…

—>Courses built by game devs for game devs - check out “Succeeding in Game Production” HERE.

—>Regular deep dives on critical game development topics on the BBG podcast

—>We’ve helped many high-profile game studios save a ton of money & time through building clear vision and leveling up leadership. If you’d like to work with us, please reach out at [email protected].