The System Design Relay Game

A game boosting tech skills and teamwork for software engineers.

Introduction

I’ve always enjoyed devising team activities and achieving goals through the design and implementation of these events. When thinking about how to lead the growth of backend team members, I hope that activities can improve engineers’ technical skills and communication abilities. One day, I had an inspiration for this activity and decided to implement it with our engineering team.

We call it: The System Design Relay Game!

How to play

TL;DR

Just like a general system design interview, except that it becomes a group of people taking turns to complete it!

game process

Pre-game preparation

1. A host is needed (could be a senior engineer from the team) to act as both the host and the PM proposing requirements
2. 4–10 participants to complete the requirements.
3. The host selects a system design topic and lists the requirements.
4. The topic can be released in advance to allow team members some time to prepare.
5. Prepare a whiteboard, whiteboard markers, erasers, and a cheerful mood 😎.
6. Maybe prepare some snacks so everyone can eat and drink during the game.

Game flow (1 ~ 1.5 hr)

1. Determine the participants’ order of action.
2. The participants take turns asking the host questions to clarify requirements.
3. Start the game 🎮
   Each person takes turns contributing an action until all requirements are met, and actions can include the following:
   > Drawing a component and explaining its role in the given requirement, and how it can interact with existing components on the board.
   > Can help converge the requirements of a function to complete.
   > Expanding the use of an existing component or removing unnecessary ones.
   > More detailed clarifications of the component’s data flow, data model, or operation mode can be made.
4. Once all requirements are met, it’s a success. If requirements aren’t met after two rounds or within an hour, it’s considered a failure.

Notice: During the game, you can keep asking about the components’ functionalities. However, guiding or interfering with the person currently drawing is strictly prohibited.

Post-game discussion (1 hr)

• After the game, the host examines the system, reviews how the functionality was achieved, and ensures all designs meet all requirements.
• Dive into questions and discussions, addressing aspects like scalability for larger traffic, monitoring, testing, and delving into the trade-offs of certain use case solutions.
• Participants of senior software engineers can share more of their own experiences, perspectives on the system, and how to solve problems at this time.

post-game discussion

What things need to be considered in the game.

Regarding system design topic selection:

• Topics can be derived from simplifying existing company systems, building future systems, or even refactoring. This helps improve team cohesion and familiarity.
• However, avoid copying internal company requirements exactly to prevent the team from falling into old design patterns.
• The difficulty can be adjusted based on participants, including the complexity of requirements and data volume.
• Requirements can involve multiple components, helping participants understand more elements.
• Or, it can involve fewer components with a large data volume, requiring in-depth discussion of a specific scenario mechanism to explore deeper technical knowledge.

About releasing topics in advance:

• If team members are unfamiliar with the topic, giving engineers some preparation time can be helpful. Otherwise, those with no ideas may be too passive during the game and unable to contribute.

Regarding taking turns:

• The main purpose is to break engineers’ perfectionism and, under the influence of different team members’ ideas, cooperate to iterate the system to achieve the goal. This is what makes the game most interesting.
• Since each person can only draw one component at a time and lacks the authority to make decisions for the entire system, collaboration and explanation of the purpose of adding their component are essential, promoting extensive communication and consensus.
• It allows team members to express their ideas during the game and learn from others, promoting knowledge sharing and exchange.
• It reduces the mental burden on less experienced engineers, allowing them to contribute their ideas during the relay process rather than needing to complete the entire system at once.
• Senior and junior engineer members taking turns may be a good way👍.

About the actions:

• Each person’s actions can be diverse, with the goal of advancing the solution to the problem. There are no strict rules about what must be drawn.

Experience sharing

Our game topics are inspired by the current company systems and future requirements. We choose requirements that require at least 5–7 components to be drawn, with the goal of familiarizing team members with the use of various technical components. The host discusses the topic’s difficulty, including data volume and complexity, with architects and adjusts it to ensure the team can complete it within an hour. However, we also ensure it’s challenging enough to provide a sense of achievement.

In our game, we initially arranged the order randomly. The process of clarifying requirements is not only clarifying the requirements but also includes the consensus of the participants on the requirements. During the game, everyone needs to keep thinking about how to complete the requirements, how these components will interact with each other, and what components are still missing, since it is forbidden to tell the painter what to draw, everyone will continuously ask the painter what goal they want to achieve. While brainstorming and discussing, we also have a lot of fun trash-talking LOL.

For example, someone drew a component in the first round, but after that, the system did not go as expected. In the second round, they had to sadly erase the component they drew 😢. Someone drew a component but no one adopted it, so he became a technology vendor to encourage everyone to use his components 🤣. During the discussion, we will start discussing more edge cases or system limitations with the host due to the design of the architecture, etc. The whole process requires cooperation, communication, and consensus among each other. We can discover the blind spots in our junior members' technical understanding or everyone's different views on how to solve requirements, which can be further discussed in the post-game discussion.

From team feedback, this activity is not only enjoyable but also highly beneficial for broadening and deepening team knowledge. It promotes communication, technical skills, and team building. We highly recommend every engineering team give it a try!

Conclusion

Originally, I wanted to play this game a few more times with the team before sharing it. However, I realized that it’s an open-ended game format, and there’s no need to rigidly adhere to strict game rules. So, I’m sharing it now. If anyone wants to play, you can refer to these rules, but feel free to modify them to make the game even more enjoyable.

I wish all your teams can grow and improve together in joy!

This article is simultaneously published on dev.to