Blood, sweat, and mini teams: why Belka Games restructured Clockmaker team and what results it led to

Vitaliy Kuzmin

Almost two years have passed since we ventured on a bold experiment to restructure the team of Clockmaker. We switched from a functional structure to the fashionable, somewhat mysterious, not completely understood, yet very enticing structure of mini teams.

Obviously, each of these configurations has its pros and cons. One of them might easily take root in one company but not in another. This article is an attempt to look over the road we’ve traveled, gather all our experience together, and present it to our colleagues. We hope you find something useful in it. And if you decide to share your experience as well, that would be fantastic.

Problems that prompted this decision

Two years ago, we were switching Clockmaker to a new engine. The course of its development was documented in a roadmap. Of course, we tried to foresee all outcomes, but the project was eight years old at the time and had built up a decent legacy, so we often bumped into unforeseen challenges. As a result, the version scope grew, release deadlines weren’t met, and PMs turned gray before our eyes.

Consequently, as the icing on this cake of chaos, the update’s key feature took longer to develop than planned and, in addition, it was redone several times on the fly. In mobile gaming, this rate of development is an unaffordable luxury.

With this kind of workload, all the flaws in the structure become apparent. Ours demonstrated two key drawbacks that prompted us to transform: 

• Bottlenecks. Over time, our team grew to over 60 people, and its size prevented the PMs,  producer, and functional leads from working effectively. The number of tasks for each lead significantly exceeded their capacity, so we had tasks that got stuck for a long time when they needed management approval;
• A different team of employees worked on different features every time. They didn’t have the cohesion of tight-knit teams.

Surprisingly, even in these circumstances, the game’s revenue continued to grow steadily. To some extent, success weakened our vigilance and made us close our eyes to serious and obvious problems (we recognize them now, but alas, they didn’t seem to be an issue back then). 

The bigger these problems, the harder the fall they cause. For us, this happened when we reached the end of the first wave of the pandemic. Our revenue started to adjust, but our problems didn’t go anywhere. The emerging conditions gave us subtle hints that changes were needed.

The solution, or vive la révolution!

At that time, our competitors in the market released updates every month and fueled the growth of financial indicators by stuffing games with fresh content. We decided to join this rally as well. This goal was as clear as the fact that achieving it would be practically impossible under our present structure. 

But why mini teams in particular?

We had little to no experience working in mini teams, so we decided to look at our colleagues in the industry. In many ways, of course, we were inspired by Spotify’s much-discussed approach to creating “Squads”, autonomous cross-functional teams responsible for their own features and forming so-called bigger “Tribes”. However, by that time, its drawbacks had become evident, so we veered pretty far away from it. Considering that Spotify itself wasn’t using its own structure, we made the right choice.

Thus, we arrived at the first insight into our future structure and documented it in a presentation to the CEO.

Here is how the mini teams concept addressed our problems point-by-point:

• We eliminated PMs and functional leads bottlenecks by introducing the role of a team lead for each team, who took over all operations: managing weekly plans, creating and allocating tasks, and conducting one-on-one meetings with employees;
• To eliminate producer bottlenecks , we introduced the feature owner role — basically, a game designer who can make product decisions and lead a feature from concept to release;
• We assigned employees to a specific mini team to create a few cohesive groups that work together on new features;
• We developed the independence of mini teams, encouraging decision-making and any initiatives within them;
• We set our desired pace for updates (at least once a month) to better understand a team’s capacity, pay more attention to the priority of tasks, and, as a result, remove anything unnecessary from the scope. 

The main catch was that mini teams were conceived as autonomous and self-sufficient business units. They were supposed to have exactly the same number of specialists in all roles so that they wouldn’t have to borrow specialists from other teams while working on their own features. And that meant we had to seriously expand our staff.

We needed to prepare watertight arguments and figure out how we could adapt the model at the lowest costs. I’ll skip ahead a bit and say that not all our teams are 100% staffed as initially intended. But we’ve reached a kind of hybrid structure where we share resources on Slack when someone isn’t overloaded with work. The mini team leads post requests for specialists there. 

After a short pitch to the CEO and a series of questions, the green light from the boss was in the bag. It was time to act.

Our interpretation of mini teams and what our structure looks like

We consider mini teams to be self-sufficient and (almost) autonomous business units, each with a clear specialization and responsibility for part of the overall scope of the next update. They are self-sufficient because their members can lead a feature from the idea stage to its release into production.

Generally, a team consists of the following members: 

• Game designer, aka feature owner, who is responsible for documentation and making sure the vision for the feature doesn’t fall apart during development;
• Developers;
• Artists and UI designers;
• Animator;
• Tester.

A team lead manages each team. They facilitate the development process and are responsible for people management: one-on-ones, goals, and development plans. Managers also need to be managed, so our structure places a project manager above the team leads. The PM is responsible for coordinating the team leads, putting the update together using the puzzle pieces supplied by the mini teams, and monitoring deadlines.

We divided our mini teams into three areas of responsibility:

• Implementation of rich key features. Our major product increment is generally temporary events with new game mechanics;
• Operation of our current arsenal of events with old, time-tested game mechanics;
• Technical work. Generally, this isn’t related to business logic and is hidden under the hood, but it is no less important for the product. 

We still need teams that are formed according to function. For example, narrative designers are not assigned to feature mini teams and are brought in only when needed, because mini teams don’t have full-time work for them.

Functional managers haven’t gone anywhere either. They have acquired the proud title of “experts” and are outside the mini team structure. Their main focus is improving the quality of work among specialists in their field. In other words, the tech lead reviews the developers’ code, the UI designer lead examines mockups and offers edits, the QA lead makes sure the test cases cover everything, and so on. In order for experts to develop specialists to their full potential, we tried to free experts from operations as much as possible. For this reason, team leads handle tasks in the task tracker and their allocation.

Below is a diagram of our organizational structure.

We don’t deploy mini teams on every project. The main criterion is the number of employees. For us, establishing mini teams makes sense if the total size of the team exceeds 50-60 people. In other cases, we keep the functional structure. 

Keep in mind that selling this whole idea to your team won’t be easy. We’re only human, so we like to resist change and actively strike down anything that goes against the status quo. We held many meetings explaining in detail the value of new improvements and announcing the goals we’re pursuing. Some people liked the idea while others still treat it with hostility. Here are a few words of advice:

• Secure the support of the team leads and experts first. Make them your allies. It’ll be much easier to sell the idea to line employees through opinion leaders;
• Be honest with your team. We openly said that this is a big experiment for us and it may well end up being unsuccessful. We didn’t exclude the possibility of returning to our previous structure and discussed this with the team;
• Make it clear that the structure isn’t nailed down and specialists might rotate between teams. This is important for employees who don’t want to get bogged down in repetitive tasks.

Important caveat

There is an important caveat that helps the entire mini team plan become fully operational and meet our requirements for release frequency. We call it “parallel development” or “overlapping development”.

The idea is that mini team Alpha is working on update #1 while mini team Bravo is working on update #2. Therefore, they are not competing for resources, and their tasks don’t overlap because each team is developing its own feature. A feature’s full development cycle takes 2-3 months on average. Having started development at the right spots, we managed to reach a release frequency of 1.5–2 months. 

Mini teams’ weaknesses and problems

Of course, every system has its shortcomings, and the one we built is no exception. Let’s run through the main issues.

Large “transaction costs.” Every mini team should have synchronization points to coordinate work and understand what it’s leading to and what stage it’s at. Our teams sync up through chats on Slack, the project in Asana, and meetings on Google Meet. It’s just the number of these meetings that is a painful moment. We started with this plan:  

• A conference call with all team leads and experts on Monday morning;
• 15-minute dailies with the team every workday (Monday through Friday);
• Reviews and planning on Friday afternoon.

Over time, the mini teams became more and more independent, and we started doing dailies three times a week: Monday, Wednesday, and Friday. Some teams tried to combine Friday dailies and planning sessions into one meeting. They also gave experts the option to join their daily and planning sessions as long as they were personally invited or considered it necessary to raise an important issue.

The need to write a Statement of Work 2–3 updates in advance. If this isn’t done, the team will simply have nothing to do. Ideally, the team should bang out releases one after another cooperatively and seamlessly. For example, by the time UI specialists have finished designing feature A, the SoW for feature B should be approved by the producer.

Did we manage to do that? Again, not entirely. But we think we have made great progress in this regard. Our current planning horizon for a project is six months. That means we know which features we’re going to make in the next six months and there’s an SoW ready for each of them.

A lack of flexibility. First, it’s difficult to rearrange plans during continuous production when features are being made one after another. Mobile gaming is an unstable environment, and sometimes you have to abandon a half-finished feature if faith in it has vanished and an idea for a better feature has come along.

Second, some features got killed more than once and required major revisions. We tried to give these revisions to the team that initially made the feature since they had the most expertise and the lowest barrier to entry. Since the teams alternate releases, the revisions sometimes had to wait 2-3 months, and some producer somewhere was sad for that whole time.

Let’s talk about the positives

We’ve already highlighted the flaws of the old functional structure: leads, PMs, and producers were overloaded with tasks, the teams didn’t work in harmony, and processes got slowed down. In the new structure, we hoped to bring the teams together, reach a steady pace of releases, and unburden leads and management where possible. Let’s discuss what we’ve achieved one by one.

Cooperation. The members of our mini teams are constant, which means internal processes have been honed. The animator always knows the best form to send the animations to the programmer in. The programmer, in turn, sets up a database for the animator in advance. Thanks to this cooperation, it is much less common for team members to have to clarify something and get sidetracked. Integration happens on the fly.

Engagement. When big companies expand their staff, it is much harder for employees to understand their impact on the product and their contribution to a common goal. When you have 20 testers in a department, it’s more difficult to recognize that you’re doing something important and useful toward a global objective, and many people start to simply “do their jobs.” On a mini team, a sense of purpose returns: the unit has clear KPIs in front of it, the work of one person directly impacts that of the rest, and, as a result, every person is as engaged as possible in the process. 

Fewer bottlenecks. Now team leads allocate all operational tasks to teams. Functional leads are no longer bottlenecks, and what’s more, they have more time to refine processes and help employees in their field develop.

Releases are more frequent. Each team works on its to-do list independently from one another. Their areas of responsibility don’t overlap. Each team submits its features by the deadline, and, thanks to this, builds are released on schedule. 

Results

Did we achieve our goals? Definitely. Switching to a new structure, along with other changes, helped the eight-year-old game Clockmaker discover new financial potential. In large part, this is because new content is more frequently released to production. Recall that we went from a longer development cycle to updates once every 1.5-2 months. As a result, we set historic records for daily revenue twice.

Are mini teams a panacea, a solution for all your problems? Definitely not. For mature teams, the switch will certainly be painful. And, of course, it should be justified: you have to clearly understand which problems you’re addressing. If you have an established organizational structure that allows you to tackle your business challenges, think 10 times before shaking things up. 

For us, we decided that the structure is working, and at the moment we’re trying to implement it in another project by learning from the experience of our pioneers and adopting best practices, but fine-tuning and adapting them to the present reality.