Knowledge of A Lifelong Software Engineer

In this interview, Ben, who leads engineering for Delivery Hero, traces his path from a self-taught teenage programmer to the natural successor for the company's CTO role. He shares hard-won lessons on building trust as a leader, keeping hundreds of coordinated delivery steps reliable at scale, and turning customer rejection into product learning. He also describes steering Foodpanda's platform through COVID-driven demand spikes, weighing technical debt against business impact, and staying focused on the customer experience above all else.

Hi, my name is Ben. I lead engineering for Delivery Hero. Delivery Hero is one of the world's leading food delivery and e-commerce 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, two or three 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 start digging more and I want to 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 like watch me.

I started as a software engineer as a kid, for very egotistical 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.

I entered university, and I was already on the side working as a programmer. Back then, in the day 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 going to 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 okay 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. So I was working for a company in Austria called Global Blue. So 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, 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 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 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. What got me into Foodpanda is I really like to build consumer products that are on a global scale or on a multi-country scale, and that are simply on the phone of everyone around you.

From the outside you say like, how hard can food delivery be? Like you open the app, you press a button and you get food delivered. People think it's simple. It is 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 ten minutes late, which in e-commerce terms is nothing. Whoever delivers ten minutes earlier or not, who cares? But if you're a hungry person, ten 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 out in the industry, you really don't see it so much.

Delivery Hero owns Foodpanda, 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 Foodpanda role.

So I went through an internal interviewing process and became quasi the natural successor to the Delivery Hero CTO.

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 team 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 a thousand suns, and they let us know our customer service was swamped with regards to 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, okay, 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.

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 three 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, quite frankly, also 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 undercommunicating a lot. So that's one.

The second one is that the mindset of the engineering team also needs adoption, as incident times need to become shorter, stability numbers need to go up, and mobile app quality needs to be driven up, because at huge scales of millions and millions of daily users, even 0.01% is a lot of people that you affect.

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. 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.

The 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, and what you should do.

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, okay, 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. Okay, tomorrow is a bit short in terms of implementing something, so simply handling all of this. So the first couple of months were chaotic.

The second one, how to deal with technical debt, technical debt being either architectural legacy or code quality 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. I think one thing above everything is that 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, okay, 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. Be very open minded and just be very positive and try a lot of things. 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.