Inside the Unit System: Divide and Create

Alisa Tkach

The simultaneous creation of a number of products requires the development teams to be flexible. But it works!

The simultaneous creation of a number of products requires the development teams to be flexible. But it works!

The Mercuryo team is rapidly growing. As more and more developers join us on the journey of helping businesses go global, it gets harder to delegate responsibilities efficiently. 

You may have hundreds of talented and motivated people on your side but won’t reach the goals without a steady, highly-efficient workflow.

How Unit System Started

In 2020, we realised that our current task assignment model is no longer efficient. The workload was spread over the entire team, pressuring everyone from CTO and professional leads to project managers and developers to work on all the issues at the same time.

One of the major concerns was ineffective knowledge distribution or a general lack of it.

We also had problems mixing up the roles of product owners, tech leads, and project managers. The management structure ended up being blurry. Tech leads were focused on numerous tasks simultaneously, and onboarding was a struggle. To add insult to injury, our daily dev meetings started taking more than an hour, and that was probably the final straw.

Anton Shamanaev, Mercuryo’s Chief Project Manager

It was more than obvious that something had to change. So we’ve sat down and determined our basic needs and demands. 

Unit System Goals

An effective parallel development was the first one on the list. To improve overall speed while maintaining high-quality results, we needed our developers to focus on one thing at a time. Another two priorities were decreasing tech leads’ workload and making smarter use of developers’ work time. 

As for the ultimate goal, we aimed for creating a healthy environment that would allow Mercuryo’s dev team to employ and develop SCRUM (an agile, lightweight framework aimed at improving development processes) practices. 

Once we brought out the burning issues, the solution came on its own: we agreed to split one big dev team into several units.

Unit Structure

Imagine a structure of a development department divided into horizontals consisting of a project manager (PM), a system analyst, Golang, PHP, frontend, iOS, and Android developers, DevOps, and quality assurance engineers (QA). 

Each unit operates as a full-fledged team with a tech lead in this system. The role of a tech lead can be assigned to anyone and typically goes to the most experienced team member who is not new to solving development and other issues. The tech lead and project manager are responsible for the result.

What Do Units Do?

Units are engaged in the turnkey development of epics (a big chunk of work that can be broken down into smaller ones) from scratch. The result of a unit’s work is a new product or a feature released to production. 

Units are also involved in planning, estimating, problem-solving, and deploying and passing QA as they even have their own testing environment. Finally, they are responsible for releasing the feature in production.

Unit Principles

Principles determine success, and no wonder that Mercuryo units have a set of them. 

Sharing is another fundamental principle of the Unit system. So if a developer suddenly has nothing to do in the current sprint, the unit will either do refactoring (restructuring the code) or offer the resource to another team for a limited period.

Working On an Epic

Now, let’s move on to the slightly mysterious epics and the structure underneath them. Suppose someone comes up with a new feature. Who do they talk to about its implementation? When there was no dedicated point of contact, the approval process was slightly chaotic. Now, the product team handles these requests. 

The team would listen to the idea then estimate the entire business logic. They discuss the key points and requirements at this stage, including budgeting, capabilities, and lots of other things. Once the basics are consolidated, the project management office reviews the data and assigns a unit responsible for this epic. 

Then, it is the turn of PM, a system analyst, and architects to create a technical design and flow of the epic. These measures will help seamlessly integrate the new feature into the existing infrastructure. After the unit team gets acquainted with the grand design, they decompose the epic into the tasks. Tasks, in turn, are arranged into sprints, and developers start working their magic. As a final pre-release step, QA steps in and checks the feature’s workability in the unit’s and pre-production test environments. If everything works smoothly, the feature is then released.

However, this is the perfect-world case scenario. In reality, nothing ever goes so smoothly. Bugs, errors, and other surprises occur regularly, so the journey is usually a lot longer and has a fair share of twists and turns. 

Unit Evolution

At first, we thought about forming new units from the newly-hired teammates but ended up with a different approach. Adding a few newcomers to the experienced teams turned out to be the best solution as they get training from senior developers and tech leads directly. 

Afterwards, when there are enough people to do the split, the unit will be divided into two new teams. And in this case, a senior PM will be leading their own unit and supervising a few others. 

Final Thoughts

The Unit system proved to be effective and gave us the freedom to start implementing previously unattainable SCRUM practices. However, nothing is perfect, and quite a few problems and new challenges are still on the agenda. Resource and knowledge sharing, a few bottlenecks, shortage of specialists, and reasonable long-term planning are some of the things we keep working on. 

More articles

#general17 Mar

Behind the Institutional Price Forecasting

#general14 Mar

Fintech On-Rise: The Philippines

#general17 Feb

Cryptopowering the Creator Economy