7 min read

Magical Pairs In Game Development

Photo by ThisisEngineering RAEng on Unsplash

The concept of magical pairs

Recently Ilkka Paananen shared a blog post on the ten years of Supercell. From that post, I started thinking about this concept that has been in my mind for ages:

One very concrete thing that we have learned about forming new teams is to first put a very tight and well functioning core team of, say, 2-4 people together. This makes the problem somewhat easier; it is easier to think about just a handful of people compared to ten. In fact, we often talk about how it all starts from finding just TWO people who work extremely well together. There is complete trust, they can complete each other’s sentences, and at the same time they bring different perspectives and make each other better. Sometimes we call them “magical pairs”! Once you have a solid core team, it is way easier to add people and grow the team. But if you don’t have a solid core, do not add new people to the team!

Ilkka Paananen, 10 Learnings From 10 Years

The idea for this article “Magical pairs” came from Ilkka’s post and from the thoughts I’ve been having. Thoughts about how game design work could be structured. I had been thinking about my days at Supercell and Next Games, and how I’d observed the best work done on designing the games like Supercell’s Hay Day, Clash of Clans, and Next Games’ Walking Dead: No Man’s Land.

In my thoughts, I’d think about two individuals crafting the shape, the form, and the final outline of the game. They’d continuously work together to revise and iterate each other’s thoughts. Aiming to get to the root of the matter, then expanding outwards and always wanting to see each problem from every angle. They were comprehensively challenging these thoughts, giving feedback to each other, building knowledge, and building the game.

Why magical? Because, in my opinion, the game design is more likely to become magical, if two people are working on the design, instead of one.

Example of magical pairs

Let’s take an example of the magical pair.

Two people walk into a meeting room. They stand in front of a large whiteboard — a discussion happens. One starts writing things down on the whiteboard, outlining three items. Each of these items represents a problem area within the game design.

This discussion and whiteboard work continues for two and a half hours. After the meeting, both individuals have follow-up tasks to take care of. The following day, these two people meet again and continue their work to solve the existing and new problem areas.

These and some very similar situations of magical pairs at work were the ways that I experienced the concept of “magical pairs” at work. They’d work together, bounce off ideas, get feedback from one another, but they’d then continue with singled-out tasks on their own.

Some detailed observations from two designers working on a game:

  • Complementing each other — The first one is a slow thinker, who takes their time to see all angles to a topic, then finally putting it to paper. At the same time, the second one, who is a quick thinker, comes up with millions of ideas, working on each of the ideas for hours, then moving to the next
  • Debate and iterate — The individuals will disagree on some fundamental elements and probably get a little mad in these situations. They’ll accidentally step on each other’s toes. But they’ll also come up with amazing ideas that exceed what either of them can do on their own.
  • Making it effective — They are keeping notes, preferably in one place, Google Docs, etc. They have decided what to do when they disagree on something. Their work is effective since they’ve decided who’s going to do what, before they get into the work.

Pair based work has been seen as an effective format in other areas as well. Let’s look at a more typical and formalized appearance of pairs working in gaming and tech.

Pair programming

The closest example of something resembling magical pairs, which has become more well-known, is pair programming.

In its details, as Wikipedia explains, pair programming is about two people writing code together on one machine. It’s a very collaborative way of working and involves a lot of communication. They do not only write code but also plan and discuss their work. They clarify ideas along the way, present approaches, and come up with better solutions.

One programmer, termed as the driver, has control of the keyboard/mouse and actively implements the code or writes a test. The other programmer, termed as the navigator, continuously observes the driver’s work to identify defects and thinks strategically about the direction of the work.

I’m intrigued about paid programming because the method is similar to what I’ve observed in the magical pairs who design games. Similarly, in magical pairs, you have a navigator who is thinking strategically, on a higher level, observing the driver and creating suggestions i.e. on Post It notes. The driver is working on the current task; they are in the weeds, working through ideas, writing things down.

Pair programming uses several techniques to its advantage.

Asking questions

  • Define a list of questions that you need to answer to come up with a suitable solution. Split up — divide the questions among you to find answers for the same questions separately. Search the internet or other resources within your organization to answer a question, or read up on a concept that is new to both of you. Get back together after a previously agreed upon timebox and discuss and share what you have found.
  • Ask each other questions! Questions are the most powerful tool to understand what you are doing and to come to better solutions. If the code is not easy to read and understand for one of you, try a different way that is easier to understand.


  • Documentation is an excellent example of a task where a pair can keep each other disciplined. It’s often a task left for last, and when it’s the last thing keeping the pair from the great feeling of putting the work into “Done” status. Working in a pair keeps the programmers accountable about some valuable but annoying things that they’ll be very thankful for in the future.

Pair Rotations

  • In pair programming, after working together for some time, one half of the pair leaves, while the other person onboards someone new to continue in the pair. The person who stays is often called the “anchor.”
  • The reason for pair rotations is to avoid knowledge silos, increase collective code ownership, and get some more code review on-the-go. Pairing itself is already helping with those things, but rotations can further increase the average number of eyes on each line of code that goes to production.

Show and tell

  • Show and tell meeting are a regularly scheduled developer huddle, a time of the week where developers get together, share what they’ve worked on, but also discuss tech debt, learn, share a significant piece of new code, etc.


  • Trust is the most important thing. “It requires trust between the two of you to create an atmosphere in which both of you feel free to ask questions and speak openly about things you don’t understand. That’s why building relationships within the team becomes even more critical when you pair. Take time for regular one-on-ones and feedback sessions.
  • To pair requires vulnerability. It means sharing all that you know and all that you don’t know. 


  • Never forget that communication is critical. Talk about what you are doing and demand explanations from each other.

Now let’s look at another crucial concept for fueling the magical pairs. 


The closest example of something resembling magical pairs outside of gaming and tech, and which is more informal, is the concept of Scenius.

Kevin Kelly, the founder of WIRED magazine, wrote in 2008 about Scenius:

“Scenius is like a genius, only embedded in a scene rather than in genes. Brian Eno suggested the word to convey the extreme creativity that groups, places, or “scenes” can occasionally generate. His actual definition is: “Scenius stands for the intelligence and the intuition of a whole cultural scene. It is the communal form of the concept of the genius.””

What Eno had meant was that genius is embedded in a scene, rather than in one individual.

When JRR Tolkien was writing the Lord Of The Rings trilogy, he didn’t produce his great work in solitude. Instead, he read drafts of LOTR to the group of fellow authors, including C.S. Lewis. This group was called the Inklings, who congregated in an Oxford pub, and they’d provided both criticism and encouragement on each other’s work.

The Inklings were so impactful on Tolkien’s writing that he dedicated the first edition of The Lord of the Rings to them. Tolkien wrote, “What I owe to them all is incalculable,” and singled out Lewis in particular by saying, “only by his support and friendship did I ever struggle to the end.” Tolkien couldn’t have made LOTR without the support of Lewis.

Here are a couple of rituals which can enable a Scenius to be formed in a games company:

  • Foster mutual appreciation — Applaud risky moves, allow for friendly competition between the game teams.
  • Share as much as possible — Create the stage for sharing ideas. Not only internally, but also externally. Listen to the feedback on those ideas.
  • Everyone succeeds — When there is a success, that success becomes the whole community’s success. The achievement becomes a sturdy feedback loop, where the shared experience uplifts everyone.
  • Playful work — Angel investor Chris Sacca has a favorite: “It may be lucky, but it’s not an accident.” Don’t do work inside a process; instead, let it stay wasteful, tolerate unusual and revolutionary ideas. It’s all about nonconformity.

Final words

If you have good examples of Magical Pairs in game development, please reach out to me on LinkedIn and share those stories. I’m planning to update this article later in the year after I’ve collected a few of them.