If you think that making global products is easy, you have never set up a Xiaomi Robot Vacuum Cleaner.
It is difficult to make global products. Everywhere has its own characteristics, its own market. And any product should work well on each of them.
Briefly about our business and the issues that the IT team faced
We are building a QSR (English quick service restaurant – fast service restaurants) and are expanding through franchising. At the heart of the business is Dodo IS, a system through which all processes pass, from order acceptance to ingredient supply management.
Now Dodo IS operates in 16 countries and for 3 concepts (pizzerias, coffee shops and doners). Our strategy is the constant opening of new countries, the development of master franchising (that is, when a partner comes, opens several pizzerias in the country and then begins to attract franchising in this country). We must be ready for such growth, for the constant connection of new countries. 60 countries, 100 countries. More than real.
Today we have 3 brands, but it is already clear that there may be 5, and 10, and 20. Not now, but they will be – new concepts with their own characteristics.
And how then to ensure the variability of the system and its support? How to scale without hiring 100,500 additional developers? How to determine which part of Dodo IS to invest more in and which to put on hold? But how to open new countries in general, because they have their own laws and peculiarities everywhere? Answers to these questions needed to be sought as soon as possible.
In addition, all requests for improvements came to our large IT team. And every time I had to decide:
“What is more important? Launch a loyalty program in Estonia or in-app stories for Eurasia?”
“What is more important? Do centralized menu management or custom tracking?”
“What is more important? Integration with aggregators or paid delivery?
These questions seem strange, incomparable, but at the same time they are quite logical, because in the conditions of restrictions one has to make a choice, and the choice is at completely different levels.
Who do you think should answer these questions? Who should choose? Business team of a specific market, CPO or CEO of a company?
I’ll tell you how it was for us. Over the past 5 years, we have gone through many transformations. We worked at the same pace (common start of iterations, everyone has a sprint of 2 weeks), experimented with LeSS and managed Dodo IS for all countries as a single product, divided it and made LeSS Huge, leaving relative freedom at the team level.
But always, over the past years, there was one common feature that did not work. All requests flocked to the IT team and somehow resolved at the level of CPO or the owner of a particular product. It seems to sound logical and simple, but in reality our business teams (and they work in a particular market) faced the fact that they didn’t know whether we would continue to work on these business tasks or not. Product and CPO had to constantly balance between markets and try to build in the backlog the tasks needed by all markets, and not to forget about support.
Such a system at scale gave more and more failures, tensions and the actual separation between IT and business.
We needed a new structure. But not one that can skillfully find answers to these questions and deftly juggle priorities. We had to come up with it in such a way that these questions did not exist in principle.
And we tried to create it. It was based on the concept of market and global teams with a very simple and clear division of responsibility.
Market Teams make products and change Dodo IS based on the priorities of a particular market. They make decisions as quickly as possible, the main thing for them is the speed of adaptation to the market. The versatility of the teams is their core competency, they can get into any part of Dodo IS. Market teams are only responsible for supporting specialized market solutions.
This is how the market teams of the new concepts Doner 42, Drinkit appeared; new promising markets UK and international; several Pizza Eurasia teams.
Global Teams make products and change Dodo IS for all countries and brands, their priorities are driven by the global goals of Dodo Brands, namely Plan 333. They make solutions as flexible, adaptable and reliable as possible. They predominantly work on their components.
These are production, accounting, CVM (loyalty + client profile), Data, SRE and others teams.
Interaction of market and global teams
Over the past few years, I have studied a lot how IT works in other franchise networks. And there is one feature that greatly hinders development. They don’t have a global part. They only have local market solutions for a country, region or several regions. And if the master franchisee of the region has built a strong local IT, made some decisions that will be useful to the entire brand globally, it may take years to sell these solutions to the top. And not the fact that it will be possible to sell. This model assumes a very large composition of local market teams (albeit grouped by region).
Our structure and processes make it possible to replicate solutions from the market to the global and from the global to the market. In both directions. If the market team has made a feature that can be useful to everyone – cool, the global team can adapt or another market team will take it and adjust it for themselves. Or the market team can immediately make the solution available to the rest, simply by giving support to the global team.
The global team has made a new loyalty system – super, market teams have full access to the solution and can adapt it at home.
This results in a two-way interaction that maximizes both the opportunities for markets to use off-the-shelf tools and results in global teams being able to integrate disruptive market solutions that have already been tested.
Currently, this model involves a large global Dodo IS platform team and small market teams, although on the horizon of 5-10 years, with the opening of new markets, this balance will change.
Interaction is based on shared code
All this would not work without one important component. A common code available to all teams without exception. Any code can be changed by absolutely anyone in Dodo Engineering, no matter what team they are from.
There is an approach called InnerSource. It’s like Open Source working within the same company. All the principles of Open Source development, completely open source, there are component owners who are responsible for its long-term stability and development, and any person from the company can contribute to it by going through a review or any other rules set by the owners. Balance between the speed of markets and the stability of global products.
InnerSource is not free. Its effectiveness directly depends on investments in engineering, tests, and the quality of global products that will change dozens of teams. If the regression is not automated and it takes a couple of days, you can forget about quick changes. This seems to be a banal idea, but without it nothing will work in practice: the market team will get into a virtual queue to make their changes, test them, stumble over the fact that the component is not ours, we need the help of another tester from the owner team, and it is not available, in short, game. Back in 2017, we began to actively invest in engineering practices, and now these investments are paying off, having a direct impact on the business.
How does this structure work in reality?
I will analyze a very simple real-life example illustrating the work. We have a Doner 42 market team whose task is to develop their product. And this product needed to do paid shipping.
On the one hand, the guys could go to one of the global teams involved in delivery or the core part of the order taking and agree to make a paid delivery function for them.
And if they did not have access to the code, they would have to do so, or hack something that was not related to the system on their side.
But InnerSource makes it possible to do otherwise. The guys go to the core components of delivery or order acceptance and quietly build in the paid delivery function on their own, de facto opening up the opportunity to use this feature for teams from other markets. They do not have the goal of making universal solutions, they do not have the goal of making a solution for others – they solve their own problem.
At the next stage of development, the global team will take the functionality of paid delivery for support, finish it where necessary and will be fully responsible for its performance.
Which teams are responsible for support
Support and provision of SLA for services depends on what kind of solution it is – market or global. For example, the Doner 42 mobile application is wholly owned by the Doner market, respectively, API and mobile are in their possession and ensuring 24/7 work falls on the shoulders of market teams.
If the market team makes a change, for example, in a tracker, i.e. in a global product, support for that solution remains with the global team. Thus, global teams independently establish rules on how changes can be brought to them, Pull Requests, requirements for them, test runs, something else. Ensuring work 24/7 – on global teams.
What has changed in the spring of the 22nd
In the new reality, we have 2 key goals:
save the business in order to develop in the future;
We, like any growing company, have a stable direction (business in Eurasia) and investment projects for growth. We stopped some projects for growth, focused on Eurasia, in fact, on the task of maintaining business. This is where the maximum effort was focused.
To keep the business going, we had to overcome the following challenges:
Survive a significant increase in the price of ingredients.
Solve problems with payments (disabling cards, Apple Pay, DDoS attacks on payment services).
Increase the revenue of the Eurasian market.
Move to local servers.
All we had to do was stop some of the global goals and transfer the guys to the tasks of Eurasia. Since the market teams were already tightly integrated with the business teams, it just seemed like an extension and a helping hand, with no major shake-ups, no new products, no clarifications of what to do and what not to do. The shared code helped make this transition seamless. I even find myself thinking that such a reaction and transformations went somehow too smoothly. But it is so!
A year has passed, the flight is normal
Such a structure with global and market teams is not my invention, not something supernova, it is a very simple and logical solution. For us it looks too obvious now. The process of restructuring and adaptation took almost a year. The effect is positive, ambiguous questions have disappeared, each product has its own goals, while there are many intersections, everyone knows about each other and does not slide into a situation where two teams do the same thing. And if necessary, they are easily rebuilt, the crisis has shown this.
This model allows us to scale. Today we have 16 countries and 5 market teams. Markets will grow and there will be 60 countries, and 15 or 20 market teams, while all of them will continue to work according to the same principles: markets for speed, global for flexibility, common code for everyone.