From Video Game Cheat Codes to Scaling Billions of Orders

"You've got to be really at home in chaos," says Benjamin Mann, CTO of Delivery Hero. When COVID hit, his company went from luxury service to essential lifeline overnight—while user demand exploded and governments demanded immediate compliance with new regulations.

Mann leads engineering for Delivery Hero, one of the world's largest food delivery platforms serving billions of orders across 72 countries. From a kid writing cheat codes to beat video games to scaling platforms for millions of daily users, his journey reveals what it takes to thrive in hypergrowth chaos.

In this interview, Mann shares hard-earned lessons on managing technical debt, the art of overcommunication, and why customer obsession trumps everything else in engineering leadership.

Benjamin Mann: Hi, my name is Ben. I lead engineering for Delivery Hero. Delivery Hero is one of the world's leading food delivery and Krikuma platforms, serving billions of orders every year in 72 countries in the world. I lead all of engineering, and there are quite a lot of engineers around the world, so my job is basically ensuring that we're building the right things for our customers in the foreseeable future, 2 or 3 years down the road.

My mother always says it's lucky that I'm curious because my impatience will just not allow me to give up on things very easily, so I keep digging more and I wanna know more. I am fascinated by hard things, the harder the better. I'm very stubborn, so I usually don't take a no, so when someone tells me you can't, my initial answer to it is watch me.

I started as a software engineer as a kid, for very egoistical reasons. I was very into video games. My mother, in her wisdom, decided not to buy me a new video game until I finished the old one, and I was stuck at a certain game. So in order to get myself a new one, I had to figure out how do I beat this game, and that introduced me to the wonderful world of cheat code writing and that just awoke in me a fascination of building things and making things and breaking things, to be honest. And that never left me.

Benjamin Mann: I entered university, but I was already on the side working as a programmer. Back then in Austria, you had to start university at the beginning, so they teach you things like Java 101. Man, I'm already working as a software engineer. I really don't want to do Java 101 again because I'm gonna be bored. So the first time I quit, then a bit later I tried again and then I flunked out, failing some of the tests that were mandatory to continue. That was the end of my university. Not very successful.

So I was working freelancing on the side and it was a great life because there were not a lot of people doing what I could do, so I made quite an OK amount of money for my age and I would probably have done this for much longer if not my mother would have one time said you need a job, right? You cannot work like this forever, and I'm like, do I have to? And she insisted, so I started to work in my first company.

Benjamin Mann: So I was working for a company in Austria called Global Bloom, where we introduced a lot of products that today in the industry of tax-free refund and tax-free shopping are common, but they really weren't when I joined them, so we built a lot of them for the first time. All of a sudden, the VP of engineering back then moved to Singapore and he asked me, "Ben, do you want to come along and help me build the Singapore engineering team?" I'm like, why not? And then simply moved on through various phases.

I became a senior engineer, a principal engineer, tried management once. Hated it. I went back to becoming a principal engineer and swore myself, I will never manage people again in my life. Walking into a team environment where trust is lacking is, I think, the hardest one to solve because it will take a long time and you can't screw it up. If you make one mistake there, you're back to zero.

I learned that if you want to have a team successful, you really need to focus on yourself, how you are as the leader of this team. Because your team will never do what you say but always do what you do, so they will always follow your behavior and what you see is acceptable or good or what the kind of role model that you are as a leader, you will see that in the culture of your team.

Benjamin Mann: Most of the time positive lessons, sometimes you learn that the hard way, but then I gave it another try a couple of years later and then I've never looked back and then I just moved from role to role and then from company to company leading bigger engineering teams, always very focused on building products for end consumers and end users. I really enjoy building at scale.

Benjamin Mann: What got me into Foodpanda is I really like to build consumer products that are on a global scale, on a multi-country scale and that are simply on the phone of everyone around you. From the outside you say how hard can food delivery be? You open the app, you press a button and you get food delivered. People think it's simple. It's really not.

The amount of steps, the number of steps that you need to execute near perfectly as a business and as a tech in order to guarantee that the customer gets their food in 25, 30, 35 minutes. It's insane. Literally hundreds of steps that fire in parallel and in sequence that need to be coordinated with each other with very little room for error because one tiny mistake, the customer gets their food 10 minutes late, which in e-commerce terms is nothing. Whoever delivers 10 minutes earlier or not, who cares? But if you're a hungry person, 10 minutes feels like a million years. Hungry people are not patient people in general.

Now I'm loving this part of the industry the most, and you can see tiny changes have this almost butterfly effect through your entire delivery chain on both good or bad. As long as you're outside the industry, you really don't see it so much.

Benjamin Mann: Delivery Hero owns Food Panda, so technically I've been always working for Delivery Hero since day one in Foodpanda, and my boss approached me one day. "Would you want to have a conversation about becoming my successor?" Then I met the Delivery Hero CEO. I started to see this really as something that I would even enjoy more than my current Food Panda role. So I went through an internal interviewing process and became the natural successor to the Delivery Hero CTO.

Benjamin Mann: We experimented with a new way of deploying software and managed to basically undeploy parts of our infrastructure, causing a significant incident. I have this great example. It was a couple of years ago. One of my engineering teams had this great idea of what they want to build to improve their search results. They built the perfect solution and we rolled it out to the customers, and they hated it. They hated it with the passion of 1000 suns, and they let us know our customer service was swamped with complaints about why are you doing this? You've ruined the app experience and so on.

This happens. You have two ways of reacting. You can be really depressed and say, oh my God, we screwed something up, we made a mistake and the world is ending, or you take this as a learning opportunity and say, OK, we went into this feature thinking we're going to build something that our customers love. Now we've built something that our customers truly hate. So while the product that we've built may not have fit this, the end result was still a great one. Because now we know more about our customers and in the next iteration of the product repeat our process and build a better product at the end of it.

Benjamin Mann: I learned there that in hypergrowth and hyperscale environments it's very easy to forget that people that are new to this don't have the entire history of what happened before. There are people coming in and they don't understand the entire history of a decision you've taken 3 years ago that puts you in the spot where you are today. So you need to constantly repeat not only the history but also where we are going so that people stay aligned, that people stay focused on what matters, that people understand why their job is important.

So you need to overcommunicate a lot and every leader that I know, including myself, thinks they are way overcommunicating, but in reality are under communicating a lot. So that's one. The second one is that the mindset of the engineering team also needs adaptation as incident times need to become shorter, stability numbers need to go up, mobile app quality needs to be driven up because at huge scales of millions and millions of daily users, even 0.01%, it's a lot of people that you affect and sometimes, especially engineers that are a bit longer in the organization, they need a gentle reminder of that mind switch, not because they don't care, but simply they forget how big you become, and that's why this overcommunicating becomes really important.

Benjamin Mann: I think one very helpful skill to have as a CTO, you've got to be really at home in chaos because you will have a lot of random things popping up. Position of a food delivery company at the outset of COVID was an interesting one because user demand spiked overnight. Governments all of a sudden had very concrete ideas of what you need to do and what you have to do to provide for the society. The business has very strong ideas of where to handle the growth that has come and how to handle the demand, and very likely the platforms have not been built for this growth.

So the challenge was multiple at the time: how do we ensure that our platform, which overnight became an essential service for a lot of people, people really couldn't go out and needed food, so it becomes from a luxury thing to a really essential service for survival that completely also changes the game on reliability. You cannot be down then all of a sudden while at the same time accepting the fact that we now have a growth in usage for which the platform was not built.

So the first couple of months in Foodpanda, the main mission was, OK, let's make sure that we keep that service up and running. Even if it's a bit rough around the edges, and let's make sure that we deliver the things in the time that we need them where it's most critical, and let's ensure that whatever curveball comes from the side, like for example, one government deciding starting tomorrow you don't accept cash payments anymore, only electronic payments. OK, tomorrow is a bit short in terms of implementing something, right, so simply handling with all of this. So the first couple of months were chaotic.

Benjamin Mann: The second one, how to deal with technical debt, technical debt being either architectural legacy or core qualities or whatnot that you need to fix. I try to teach people to look at it from the angle of what happens if you don't fix it. There's the point in time where this impacts your business negatively under which conditions, and then have an eye-level conversation with your business stakeholder about where should that point be. And when is the right time to fix it?

Engineers struggle with quantifying this a little bit, which makes it hard because then you get into this discussion. Oh, it's technical debt, but is it really important? Can we fix it maybe next quarter? And by having this continuous discussion about when in time this particular technical debt will become a problem for the organization and for the business result. You take a lot of this vagueness out.

Benjamin Mann: I think one thing above everything is, as a software engineer, you need to have an unbelievable laser focus on the experience that you give to your customer because I fundamentally believe in order to have a successful business, you first need to provide outstanding experience to the customer. No matter what the product is, no matter what the industry is, I don't think you can build a long lasting, profitable, great business without taking care of the experience of your customer first.

Sometimes our engineers forget that a little bit in the heat of timelines and complex requirements or unclear even situations that you intend to jump into troubleshooting mode before you really understood what the trouble is. It's our job as engineering leaders to always bring them back and say, OK, what problem are we trying to solve for the customer here? Let's figure out really what the problem is first and then think about how we'll solve it. Sometimes we tend to skip the clear definition of what's the problem and start with how we're going to solve it, and I think that's dangerous.

Benjamin Mann: Be very open-minded and just be very positive and try a lot of things. So in my almost 20 years of managing people in various sizes that very often think, can we succeed outside of our country, my experience with everyone who tried is yes. Don't give in to that almost imposter kind of syndrome that asks you am I good enough to succeed in the outside world because I can guarantee you from my personal experience that yes you are, and there's not even a question of a doubt around that.