How to reinvent franchising with tech and transparency

Something is wrong at Dodo Pizza.

We set a challenging goal for ourselves to create the world’s most advanced IT system for a retail business.

We put together an IT team of sixty developers and analytics and gave them the freedom to follow any unorthodox development practices they deemed helpful.

They all worked like crazy and built an impressive large-scale IT product that now makes it possible to manage a chain of more than 300 pizza shops and process tens of thousands of orders every day.

Yet the people inside and around the company have become, to put it mildly, pretty frustrated with their work.

[big_small_image image=“15019”]

When somebody starts talking about Dodo IS—that’s what our IT system is called—and how it can help us in the near future to manage our business even better, some people simply laugh.

Because they’ve seen our gargantuan backlog, and they’ve been waiting for some features to arrive for months, sometimes years, ago. And still, nobody can tell them when these features will be introduced—if they will at all.

Even our most loyal managers working in our corporate chain have just given up on Dodo IS. They appreciate its advantages, ignore its imperfections, and don’t expect anything more from Dodo IS.

This attitude doesn’t help, to say the least. It creates a toxic corporate culture.

For example, we encourage developers and office managers to go to gemba and learn how we can improve our business and make a better product for our partners. They do go, knowing crystal clear that their insights will be buried in our enormous backlog.

It’s a schizophrenic experience. So, we decided to do something about it.

Here is what we thought. If we could bring more transparency to our development process, it would mitigate half of our problems. Our managers from different departments and franchisees want to know the plan.

What features are we rolling out next week? In half a year? In 2019?

If we had that, they would get the bigger picture like the IT team. Moreover, they would be able to weigh in with their arguments and maybe change some priorities.

And the problem with new ideas would be solved naturally. Any suggestion would take place in this master plan depending on its urgency and importance—after an open debate, for example.

There is a rub. We can’t write a plan for a year.

Having such a plan flies in the face of all that we know about IT development, agile corporate culture, and modern management.

Nowadays, even much more established companies have to adapt to a fast-paced and constantly evolving modern world. But when you run a startup, everything changes every week.

You can’t commit to your long-term plan because your market (or your understanding of your market) might do a 180 by the end of the day.

So how a company can stay flexible and, at the same time, have a long-term plan offering some clarity and transparency to everyone involved? Without trying to oversell it, I’d say that this is one of the most painful conundrums in modern management.

I wish I could say we’ve solved it. So for now, our team is open to suggestions. Meanwhile, after racking our brains, we’ve come up with a few “hotfixes”.

First, we put together a three-month development plan that lists all the new features we’re going to roll out. It’s a short-term projection, but the IT team is committed to pulling off everything that makes its way into this plan.

Second, we created and shared “The Map of Opportunities” for a year out. This is another list of all the features we deem useful enough for our business to implement within a year. It doesn’t mean that we’ll actually do everything that’s listed there. “The Map of Opportunities” isn’t a commitment—it’s a picture of possible investments of our time and energy.

Third, we introduced new company practices to work on both lists. The IT team holds a meeting every two weeks where each manager can suggest a feature. Our partners can also chime in and send us their ideas and queries via email.

With every suggestion, we now have three options: add it to the current dev cycle (ditching some other feature or hiring more people), put it on the list of opportunities, or just bury it. When the three-month cycle ends, we’ll start a new one, adding features from our year list to it.

Sharing both lists with franchisees is crucial to our new practice. Now our partners and even other members of our team can see what we’re working on right now and what’s coming down the pike. They also have some say in the process and can follow the changes we make in our plans.

The same can be said about different departments that have their own expectations about the development of our IT product. Seeing all the tasks and ideas, they can now make a better assessment of the real value of the features they are requesting.

Is this system perfect? Probably far from it. Will it work? Who knows—we’ll have to see. Our small blog will keep you in the loop.