How to Scale Your Process Beyond One Team
Read Time: 5 Minutes
I’ve seen many leaders run a team and set up a small process relatively well, but very few can set up effective scaled work systems or team-of-teams level processes. As some point in your career this skill will become essential. You will either get promoted and need to create and improve scaled processes, or you’ll run into an organization that doesn’t have enough competent managers to serve each team.
Most leaders will try to use the processes they’re applying on one team, but bigger. This is a huge mistake. Bureaucracy doesn’t scale without a ton of additional management.
Leaders will also create rigid structures to make things ‘controllable’ and to reduce conflict or variance around what to do and when to do it. While meant to reduce complexity, this comes at the cost of autonomy, innovation, creativity, and team morale.
It’s the reason large companies lose their spark and become bureaucracies. We should avoid that at all costs in creative development. Team agency & creativity are often the primary factors in building a great game.
For setting up graceful team-of-team structures, use these principles:
New processes should be lightweight and focused on alignment rather than work
Build a strong leadership team that collaborates across the org
Create clear “rules” around endpoints (interactions between teams and layers) so everyone knows how to negotiate and resolve conflicts
Focus on outcomes and accountability, and trust that your people will figure out the rest
Let’s walk through some practical tips to help you set up a scaled process beyond a single team.
Keep New Processes Lightweight and Alignment Focused
The default thinking is that the difference between one team and several teams is the amount of work that needs to get done. That misses the plot.
The goal is to help this larger group stay focused on the most important things and align their work to a uniform set of global objectives. The bigger your team is, the more you need to focus on helping them hit the target instead of how to string the bow or notch an arrow. The thing that decays most rapidly at scale is alignment.
Rarely do I see a situation where a project has a ton of managers to handle every aspect of a super complex process. Scaling purely through management is usually not an option.
I worked on a large team of around 150 people on a huge project for League of Legends. We created a couple of “Project-Wide” processes that were incredibly valuable (and a bit unorthodox).
One was a vast standup that included everyone on the project. This might sound ridiculous, but we used it to make announcements, remind everyone of our top 3 global goals for the project, and open space up for anyone on the team to request help from anyone else (with breakout conversations immediately after). The Meeting never took more than 10 minutes and was cited as the most valuable meeting we had at all levels of the project. We used it to align the team and provide a pathway for anyone to get immediate support on whatever was blocking them in the last 24 hours. The public nature of the standup normalized helping your teammates (read: project-mates) as a top priority.
Another was the pre-sprint strategy meeting that we’d have between team-level product leads and the overall project leads, including myself. We’d quickly discuss the last sprint’s progress across all teams, how each team would contribute to the top 3 project-level goals (or negotiate those if need be), and leads would make commitments to each other regarding how they’d support and collaborate across teams to meet their objectives. This took less than 30 minutes and kept all the teams focused and supported by their peers. Commitments were made between teams toward the highest-level goals, then incorporated into each team's local planning session.
These are a couple of examples you can use on your teams, but the key thing to remember is minimize process as much as possible and focus large group processes you create on objectives, alignment, and support.
Build a Strong, Collaborative Team of Leaders
In any team, some leaders fulfill specific roles. This includes craft leadership, managing the priorities, making the process, or doing development work. In a team-of-teams scenario, a new responsibility set needs to be fulfilled: a cross-team, “strategic-level” role.
When you embark on a large project like this, you must rethink how leadership functions and how people’s priorities change. If leaders are focused only on their pocket of the org, you will get incongruent outcomes, conflict between teams, or poor focus on bigger goals. You will need to add these responsibilities to existing leaders, or create new roles to be filled by new people.
I solved this on the project I referred to earlier by creating a new leadership role (we happened to call it pod-lead but you can call it whatever you want). These roles’ functions were to collaborate with other pod-leads, ensure the team's priorities served the global project priorities, and escalate to project-level leadership if they needed support or were off track anywhere.
A vital function of a role like this is that the primary accountability is to the project first via the “team” of leaders. This incentivizes these leaders to support each other and honor the goals at the highest level instead of falling into the trap of, “Well, we got OUR work done!”
I created a document that outlined the pod leadership role, what its functions were, what authority it had, and what it was responsible for. All pod leads agreed, and I had my new project-wide leadership team.
It was beautiful to see the pod-leads coming together in their strategy meetings before every sprint. They consistently found novel and creative ways to support each other and the teams.
Create Clear Rules Around Endpoints
It’s important to create a list of specific ways a team is responsible to the bigger group/project and also a list of ways that teams should interact with each other.
I told each team (or pod) that they could run whatever process they wanted as long as they provided the following outputs to me at the project level:
A prioritized list of tasks/objectives that the team was working on that I could see
A method or process they used to learn from mistakes and improve their approach
Their pod lead’s attendance to the cross-planning session (see above)
A designated pod leader and someone to fill that role in their absence
Either using a pre-selected tool for tracking metrics OR doing the extra work of translating their data into a format I could use at the project level (2-3 key data points)
That was it. Through the clarity of a few rules, I could plug each team gracefully into the overall project AND give them maximum autonomy in approaching their work.
We also set up explicit rules around resolving conflicts between teams (i.e. try to negotiate twice, and if you’re at an impasse, escalate to project-level leadership). This helped teams resolve and raise issues on their own without external interference.
As a leader building such systems, it’s essential to think beyond the pipeline of work getting done and understand how the disparate pieces of your scaled project fit together, and how you’d like those distinct sections to interact in creating the outcomes you need.
Focus on Outcomes and Accountability;
Build Trust for Everything Else
Writing down clear roles and responsibilities, rules around endpoints, and etc., allowed me to get clear commitments from leaders signing up for specific roles, hold them accountable, and, most of all, built trust that because of that upfront work, they’d be able to handle it without being micro-managed.
The process we built was designed to focus everyone on clear project-level goals.
The roles we created were about ensuring that the project-wide leadership responsibilities were covered by effective people who knew what they should be doing.
Once those two things were in place, we could take our hands off everything tactical and focus on the big picture. This made our teams very happy because they could creatively solve problems and not be micro-managed. It made us happy because we had time to ensure the goals were correct, to steer the big ship in the right direction, and to avoid getting buried in the details of a 150-person group working on a massive amount of simultaneous work. We balanced autonomy and control by leveraging leadership, clear expectations, and focused alignment.
Because the large group was focused on high-level goals, we could ask, “Are we meeting our goals?” If the answer was no, we knew we needed to make changes. We had systems and leaders in place to figure out what those should be and then enact them. This allowed us to use actual results (working features) to assess how we were doing and then react. It also allowed us to avoid getting mired in the details like team velocity, faster and slower, or who did more JIRA tickets. We focused on results.
I hope these principles of approach and tips help you on your next scaled project. Going through this threshold and becoming more strategic as a leader was one of the most satisfying experiences I had in my career. Doing it without creating a giant draconian management structure was even more satisfying.
As I said before, we can’t afford to crush the team's agency and creativity with heavy process systems and management in creative development. Making games is incredibly complex, and we need to leverage the brainpower of our people. Maintaining that while building scaled teams is challenging but possible if you focus on the right things.
Whenever you’re ready, there are 2 ways we can help you…
—>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].
—>Regular deep dives on critical game development topics on the BBG podcast