Work Systems: How to Level up Your Process Game

Read Time: 6 Minutes

We struggle in this industry to value human systems or understand them. We’re reactive and often lean on outside expertise or vanilla systems (see SAFe and Scrum) to tell us how to operate to get things done. The problem is when something unexpected (like a global pandemic) comes up, and we all go remote, we’re now stuck asking ourselves what collaboration looks like or how to build it on our teams. Now that we don’t get it for free, we’re stumped.

Just as we believe it’s healthy for everyone on a team (not just the engineers) to understand how the game’s architecture works at a high level, game leaders should understand the basics of human systems, regardless of discipline.

If you’re comfortable implementing vanilla SCRUM, SaFE, waterfall, etc., and dealing with the consequences - come what may. These aren’t for you. But, if you want to understand why those systems often result in frustrated developers or sub-par results and develop better ones in the future, these newsletters are for you.

Today, we will discuss the work system, the two fundamental reasons they exist, and the importance of the architect’s mindset.

The Architect’s Mindset

You must embrace the architect's mindset to realize your effectiveness as a game development leader.

There are a lot of assumptions we make that are false in this space. For example:

• You can't understand engineering if you don’t have a CS degree.

• If you’re a producer, you should be “technical” to be competent (whatever that means).

• You don’t need to understand human systems (process) if you're an artist.

As leaders, we are responsible for influencing our developers toward the goal. And we can’t do everything, can we? So, we must adopt an architect’s mindset in a few key areas.

You may not know how three technical components are written in Java. Still, you should understand that if an engineer can’t change (critical component X that gets modified every patch) without changing (critical components Y & Z that rarely need to get changed for new features), the coupling represents a risk for your team and product.

Similarly, you may not understand the nuance of how SAFE works or how to run a sprint planning meeting effectively, but you need to understand what it looks like when a team is collaborating well.

That second example is what the following three newsletters are about: Work Systems.

Practical Application: Getting that understanding is much easier than you're probably thinking. Find the best team leadership expert near you (or process expert) and ask them questions about how they think critically and assess their teams. If you’re interested in the engineering example - do the same with the best engineer you can find - have them walk you through the overall structure of the tech stack/codebase. Think about the key components and why they’re arranged the way they are.

Why Do We Need Work Systems?

A work system is the sum of the groups and processes within an organization (be it a team, division, or studio). If you’ve heard of a ‘framework’ or ‘scaled framework,’ assume it’s a synonym for now.

OK, great. But why do we need them in the first place?

In a perfect working environment, everyone would know what to do and how to do it. This ideal place would have individuals in touch with the customer's needs, fully aware of the ramifications of any changes, and flawlessly and rapidly creating value. There is no need for managers, meetings, or process in this world. You just need the perfect people who know exactly what to do and when, who would work together without conflict or confusion.

Outside of the fact that I would be entirely out of a job, that sounds awesome. A customer has a need, and the team just KNOWS it, recognizes it, and works immediately to get it done without any confusion. Wouldn't it be wonderful?!

Unfortunately, the world doesn’t work this way. Human beings are imperfect communicators. The customer probably doesn’t know precisely what they need or how to communicate it. The team doing the work can interpret it in many different (and incorrect) ways.

Work Systems, when implemented well, solve these problems. Fundamentally, they help us create alignment. Since we’re thinking as architects, we must understand how they work.

What Even is a Work System?

A work system is composed of:

• Content (The thing you’re trying to build - what’s written on your JIRA tickets)

• Groups (i.e., teams)

• Interaction points (ie, meetings)

• Artifacts (The JIRA tickets themselves - or your JIRA dashboard)

A work system also has two key outputs:

Alignment

A work system consists of several components, creating alignment for all humans. We don’t live in a perfect world, so we must invest effort in building and maintaining alignment. We need to talk to the customer, we need to understand the outcomes desired, we need to know how to work together, we need to pick a solution, and we need to understand what each person needs to do. All of this is alignment. Our imperfect world requires alignment constantly.

Think about it - if you leave a group of people alone for long enough, eventually, they will argue, get confused, or go in different directions. Alignment is in constant entropy. The bigger the group, the faster it decays.

Most people think about the product when we say alignment, but this is only part of the story. How do we work? What roles do we have? What kind of work are we doing? What are our cultural and behavioral expectations? Who makes the decisions? These things tend to get left behind, even when aligned on the product.

This leads to a huge problem: in a world where there are tons of things to align around, and alignment is unstable and therefore constantly drifting, it would be easy to spend all your time aligning on everything and never getting any work done.

A deliberate work system addresses the entropy and focuses you on what matters.

Relationships

The secondary purpose of a work system is to develop relationships. People have different working styles, interacting, walking, eating, thinking, etc. A work system creates space for people to get to know each other, team member to team member, customer to stakeholder, and everything in between. These relationships form the foundation of trust and confidence needed to participate in the system.

Practical Application: 

1. Hit up a whiteboard, Miro board, etc., and map out your team’s processes (work system).

2. Bucket everything based on the four components (content, groups, interactions, and artifacts).

3. Try to use lines to connect boxes and write down your observations. What strikes you about how your teams work? Does your work system produce alignment and great relationships? Something else?

Closing

Thinking like an architect regarding the process is a complex and burdensome task. It is a lot less of a hindrance than being in situations where process is failing, teams are frustrated, and results aren’t happening and not knowing what to do, though!

We’ll leave you with two fundamental principles when it comes to work systems:

1. A work system should focus on building alignment around the most important things and building relationships between the right people to get results.

2. You cannot achieve perfect alignment. Instead, focus on having most of the people aligned most of the time. Do not attempt to attain perfect alignment; You won’t get anything done.

Next, we’ll cover who the work system is for and the common pitfalls organizations face when building them.

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].

This post is the first in a series about work systems. Originally posted by the same author.