Scaling engineering at Wolt with CTO Niilo Säämänen

Otto: Let’s talk about your background first because you have a very impressive track record, getting through the whole leadership path, from leading an individual team to then starting to scale the engineering organization. So tell us a little bit about how that all got started.

Niilo: I did run teams for about seven years before joining Wolt, but at first I was running the frontend competence.

We run a different configuration where the companies are small and it doesn’t really matter what you’re doing when you’re 20 people. You do whatever it takes to go forward and you have different hats and you focus on different things. What has really changed from that typical team we’d experience where you’re still coding a lot for, so for the first two years I was actively developing on the merchant side, on the consumer side various different services and being very hands-on, as you often are in the early stages of a growth company.

During 2017, I took over the remnants of what we had on the product as we had about 16 people. All in all in design, analytics, product/founders, and technology, and started scaling it from there. I think that was the big shift where you went from like not really developing actively anymore, only doing sporadic commits to different codebases.

And then really just handwaving, as I call it, going forward. I think there’s a pretty big shift over time when you start focusing a lot on recruitment, and then setting up minimal processes. I like minimal viable processes, so setting the foundations that can be really light, but they need to be set for you to be able to scale.

It’s a very different journey from those humble beginnings to the 400+ engineers where we are today.

Otto: Yeah, that makes sense. Was it difficult for a company who’s very focused on execution and building stuff fast recognizing that there’s a need for some kind of leadership and someone needs to look after this? One of the founders was previously the CTO and so there was some kind of an idea of structure there, but how did that leadership position first emerge?

Niilo: The first time that Miki [Kuusi] came to me and asked, Niilo, could you take over and try this out? I was like, “but do I want to stop coding or not?” And I was pondering about that. But how we did it was I wrote this initial playbook on the kind of best practices we’ve done so far and the things I think we should be doing.

And then before any kind of idea of adding different roles, we started with like, these are things we probably should be doing. From that we realized that maybe there’s a potential to actually do these things that need to be doing like a light version of the minimal process, maybe a bit of RFCs to how do we build things, how do we build the culture of kind of teams when we go beyond those 20 people kind of thing.

And then I agreed in the end to take up that mantle and start to try out this journey. It was a kind of trial to see if it’s fun for me and if it works for the company. And here we are today. I mean, yeah, I mean the, the titles like I never really cared for titles and I think at Wolt we’ve always been rather agnostic for them.

Lauri [Andler] is an amazing fellow. The co-founder who used to be the CTO of Wolt. I loved working with him. He was like this kind of genius individual contributor type of a CTO who built our logistics and was still responsible for a lot of the success of the efficiency of the things we’ve been building at that side.

But basically I ended up running engineering from those humble beginnings to today. So titles may have changed along the way, but I’ve been wearing pretty much the same hat from 2017 on.

Otto: Well, it worked well for both you and the company in the end, and sounds like you started taking initiative on things pretty early on. What did you want to fix first?

Niilo: When I took over engineering there were 16 people. We had built some of the foundational services, the product market fit was there, but it’s like at these very early stages.

We worked two teams and one big clump of people and everybody was building roughly everything because you’re really focusing on whatever moves the needle right now. And we knew that we were getting, or we were kinda raising Series A at that point, a big scaling round going forward.

And we were in general kind of figuring out that we have the baseline, how do we achieve scale from these initial markets? We were in three countries at that point and had somewhat an understanding of how we scale and how we scale operations and how the foundations of the technology work.

So the thing I really started focusing on is how do you scale these things? Building a startup is very different. You hire with a really high bar and you keep a really tight group of people and you don’t need much structure when you have 20 people.

But then when your aim is to go from 20 to 50 in one year, which was the challenge that was brought when taking this up, how do we make this happen? What I started with was really solidifying the principles of how we build things. What is a team, what is the relationship between product and engineering and data and design, and how do we build things together? So we set this foundation of these high-ownership teams and owning and really aligning them around business priorities; our customers rather than technologies. So we used to have two teams that were kind of platform and consumer and that’s it. And we were building a three-way marketplace with platform and consumer.

And it wasn’t really a way to scale it forward. So we started by splitting those up into kind of key customer-facing teams and putting the end-to-end team kind of philosophy going forward. So trying to have this end-to-end high ownership teams approach. And that’s the thing we actually still use today.

So we set those first versions of this model up in the first six months when I was actually helming this thing. And that was the first big thing that I did was revamping the teams and splitting a lot of the teams into smaller teams and starting to hire those specific areas up.

So that was like the first step when taking over.

Otto: Wolt is a lovely business model because you’re serving the consumers and the merchants and the couriers and it’s obvious that each one of those areas has plenty of things to improve.

Like those are the different ways to help the business grow. And then you just keep slicing those and investing more in those areas. You mentioned product management and the kind of business outcomes of those teams, and I think that’s an interesting part of, especially in the European startup ecosystem, we don’t have as strong of a history with very outcome oriented product companies and that kind of thinking.

So when did product management emerge somewhere as a role? It sounds like you were already thinking about those things pretty much from the get go?

Niilo: As a typical startup where you have strong founders who have a strong vision. So the first two product leaders were actually two of the founders. I think it was the summer 2017 when we were scaling, we hired our first external product manager.

And from that on, we started pairing up. Every team should have a dedicated product and engineering lead. But to be fair, though, I think how we really scaled product management was when we were probably around 60, 70. We already had maybe like five, six people in product management at that point.

And, when we hired Vincent [Ho-Tin-Noé] who’s my counterpart for product, who came from Amazon and Essence and has a good background for this from Canada. I think he’s the one who really built the modern product organization. So all kudos to him. We work very closely together. It’s super fun.

Otto: There’s also a component of how engineers think about these things and sounds like it was maybe part of the initial principles in how you build, how interested and how motivated have the developers been in shaping the direction of this, and do you think it kind of changes over time? Have you been able to keep that as a part of your culture?

Niilo: I think every engineer, especially every senior engineer, should be part of thinking about product problems and our early engineers were very product-minded. I’m also a bit biased here because I really value product-minded engineers, so we’ve always over-indexed on hiring product-minded engineers.

I believe that the best teams work in a way that the whole high ownership team model that we work is that every engineer should understand customer problems. Engineers, I don’t care how deep you are in solving logistics problems, you should understand the value you’re trying to create.

And we try to do a lot of ways to enable that. So basically putting engineers close to their customers, close to their operational counterparts, understanding data, understanding user research, bringing that context. But in reality, how that works is a lot of that context is brought by the product management or organization because that’s part of their job.

So there’s a lot of these, like staff engineers for example, are really crucial in thinking about the new features we’re trying to build and finding that right ratio of existing potential of existing technology and the value we can create to find those really valuable decisions from prioritization, because you can, I believe visions are easy and cheap to build. It’s really a lot harder to execute those visions in a way you get incremental value and that’s where engineering is at the kind of crux of it all. So yeah, definitely you have to have a very product-minded engineer. So it’s not just about the role or the title you have, it’s about the approach you’re making.

Otto: Indeed. It’s easy to imagine big things, but then figuring out how to get there step by step, that is a difficult part, and it requires that both engineers and product managers understand each other at a good enough level.

Niilo: It’s something that becomes even more important at the scale where we are today. So like today, most of the discussions aren’t about, like you have big visions for the future of search and how personalized everything will be, and you get your ducks in a row and that’s a beautiful thing, but it takes you four years to get there.

Otto: That’s another interesting aspect. You need to be moving pretty quickly, especially in a market like yours where there’s plenty of competitors and everyone’s kind of trying to grab the cities and countries around the world as quickly as possible. So how do you think about moving fast? How do you talk about moving fast?

Is it part of your recruiting somehow and since when have you formalized this as part of your culture?

Niilo: In the early stage when we were doing product market fit, I think we were really focused on excellence and building the best product in the market. We were really this more Apple in the beginning and the first two years were crafting the excellence of the little details everywhere, right?

And we still wanna keep that excellence up, but I think that fastness really came from when we started expanding globally. So around 2017 because in a few years, we went from three to 23 countries pretty much. And we are still kind of going deeper and deeper into those countries. So there’s a lot of this expansion to be done in a country and potentially in other countries as well.

And I think it’s like you realizing that every market has modern competitors. There’s typically two or three modern competitors, and it really matters on how far you get on that kind of ladder. If you’re player number four, it might be really hard to make it a competitive business out of it and actually get enough customers to get that flywheel going because you need the right restaurants.

But it needed enough customers and sales for them to work and so that the couriers have enough work, they’re motivated and it’s like this balance between these three when you’re doing it. So it’s the competitive nature of the business where it really kind of drives it because it’s really obvious that you need to move fast and you need to be able to make changes fast. So the way we’ve always, or at least about after 2017, we really focused on trying to, from an engineering perspective, like trying to build the tools to be able to move fast. So we may not build like every feature to be the fastest thing specifically, but we build a lot of tools that enable the country teams, the operations to kind of really run their business and really strong tools to get them to influence their business in the markets.

So that we can still build pretty good engineering products. We built pretty high quality tooling. Our internal tooling is the same level as our external products. We actually have a really massive amount of operational tooling on how you run this business. And it’s built with and crafted with care and love and like thinking about efficiency and customer experience and conversion and other typical things that you think about in a customer business, we’re trying to think about the same things. Building the internal tooling so that we can create a product that really scales and allows us to make fast choices because the choices have to be quite fast in the market.

So it’s kind of a, like, that’s been one of the things I think the focus was really great to be a global platform that enables customization really well, but by the local teams.

Otto: Figuring out how to platform this and how to build a great product that’s easy to customize while moving really quickly is a really tricky problem. At Smartly, we had a little bit of a problem that we wanted to move fast, but we often did it with one-off changes and kind of stuff that wasn’t as sustainable.

Niilo: I mean, definitely. We always had this principle that we wanted to build global-first, that everything needs to be localized. Everything needs to be kind of configurable locally. And the minimum requirement of doing things was stupidly. Of course, we did hacks every now and then.

Otto: So is there a lot of pressure coming from the business side to engineering?

How, how do you deal with that and how, how do you kind of communicate your existing priorities to them?

Niilo: I think there’s oftentimes too much pressure coming on. We are a very humane and collaboration-oriented bunch of folks. And the culture is very related to instant communication. So we actually do give a business a lot of straight access to teams and engineers where they just can ask questions and can bombard them with issues.

And it has caused trouble, but we’ve been able to manage it, I think rather well. There are few teams, for example, on the courier operations that are often a bit overburdened by this because there are so many stakeholders in the 23 countries. There’s so many people who need help as such.

But I think there’s a few things, like the way we do roadmaps is we always go collect kind of a very structured bunch of feedback from the country. So we kind of ask them for impact estimation. So there’s a little bit of a friction to kind of giving feedback, giving feature requests because everybody has an idea, but ideas would have a cost.

So kind of figuring this one out. But we do this relatively freely, so everybody in the organization, even like support, everybody can provide input. And then from that we kind of identify and vote and we’ll get the impact estimations and figure out the kind of biggest impact tickets from the operations side of things, but that’s just one input for this. Of course for prioritization, you need to get your actual, like your intelligence, your data, your user research, your intuition, like the different parts of the kind of equation to get there. So you can’t just listen to your internal users, otherwise you end up optimizing for the wrong things.

But we do a lot of that like feedback and then we communicate the roadmaps pretty openly. So we do this big fancy shows and presentations per group nowadays, but used to do it for the whole kind of product at once because it was small enough. And then we regularly update the things we release.

We often use a pretty simple way. We use like newsletters that are really big where we can try to kind of focus on the impact of what we’ve been building, and the feature. So this thing was released, this is what it does, and this is how much it impacts things. And we do the same in Slack.

So we do these product announcements where we celebrate all the releases and all the country teams have access to it and they can kind of comment and adopt them. And generally, actually surprisingly, it works really well because it’s very open. So the adoption is pretty fast. The teams take the new features into use pretty well.

Otto: And how close are the engineers to the rest of the organization, to the customer? Do you do something specifically to get them to learn more about the problem space or something like that?

Niilo: The one thing is we always encourage everybody, we don’t enforce it so that you have to do it, but we encourage everybody to do is delivery days. So like when you can go delivering as a courier yourself, everybody in the courier group, of course, does deliveries because that’s what they build constantly.

But we also want people to do it themselves. It’s actually a really good way of understanding our business. Like doing the courier shift really gets you… you meet the merchants. You meet the consumers, you understand the kind of gamified time limit approach to it.

And it’s very addictive to do. And it’s fun to realize these little things that might be off in the flow really well from the consumer and the merchant, and the courier side. So it’s really important for engineers to do that.

The other thing we do is we do support side by side. I think every two weeks. Our support is relatively high grade, so we don’t allow engineers just to kind of go and, you know, just write things to customers straight up because there are also a lot of angry customers. Because when when you contact support, you’re already normally in trouble. But you normally sit with a senior customer, somebody who’s been doing the customer support for a long while, and you help them with the cases and you understand the situation. There’s also a different language just used and kinda stuff.

We want to maintain high bar in support. So we don’t allow us to do straight up, but we do the side by side approach. Same with the courier side. We do them once a month. It’s just so that we don’t disrupt the local operations. Because if you suddenly have like 50 engineers doing those deliveries, it’s just actually disrupting the city a bit.

So you need to kind of take it into account. But those are the ways to kinda get into the customer, into the merchant, into the kind of courier mindset. The specific teams, like merchant teams go regularly to meet different merchants from different countries or different profiles of merchants to understand that.

We’ve actually dreamt of having our own restaurant for a while. So we could really staff it and have like proper people playing the whole restaurant flow themselves and the courier interaction flow. But no budget for it yet. Maybe next year.

Otto: That sounds like a lot of fun, and sounds like you’ve really designed everything quite well for the pretty unique business that you’re in. So to be able to deal with all the complexity and opening business in new countries and all of that, you kind of built the culture around it.

How much of the culture emerged almost like automatically from this? How intentional were you in introducing some of these things and how would you characterize the culture nowadays?

Niilo: Every company has values but only good companies actually live by those values. I think we did okay. We were already around for three years or something when we set the current values. So values need to be reflective of how you actually operate.

Culture can’t be a copy-pasted on top of things. So I think it came from the early stages. From the founders and the kind of early team and how we approach this kind of mission. And I think that culture starts from the top as they like to say.

And I think that’s where it trickled at the beginning, but after we made the values, I think we got pretty deliberate about it. So when we onboard people, we always have a session about the values and we have our stories around the values and the kind of founding stories. And we used to fly everybody to Helsinki to meet the kind of core team as well.

And we wanted to lead that culture really strongly in the beginning. Nowadays we do it mostly remote. We still try to do that quite often. We also use the kind of culture in how we evaluate people and how we hire, how we do bar raising, and also how we look at the performance of people.

We have to be somewhat deliberate about it. But it all started from like, we were like that as a startup and then we codified it and then we ran with it kind of thing. But before that, so it was, was what we were in the beginning.

So it wasn’t invented as such. It came from that time to capture that kind of early ownership and kind of entrepreneurial spirit of startup that really kind of does bring a lot of value to it and find ways to scale that. How do you really do that when you have 6,000 workers and with very different backgrounds and very different roles?

And how do you keep that going. We used to have these Wolt One parties where we had the whole company together, before Covid was the last time we unfortunately had that. But at that point we already had about 20 countries and we had people from those 20 countries together.

And the coolest thing was those 500 people at that point, they were like, you have had people from Norway, and some folks coming in from Japan as well. And it was like, it just kind of like everybody was in the same kind of… you talked to everybody. It doesn’t matter what country they were from, you realized this was your crowd.

This is your kind of bunch of people. And I don’t know how we got there. I don’t know what magic we did to get those people in all these very varying countries from like, you know, the Middle East and Azerbaijan kind of region stuff to Norway and Sweden, which are kind of diametrically opposed in cultures almost.

And how do get them to kind of be the same? But we did. So I think we did something right there. I think if you characterize the culture. The three of our values I always use as an example are ambition, excellence, and heart. So like we want to do common things uncommonly well.

We want to be really deliberate in doing excellence, especially in engineering I think is an important part of it. Like even though you wanna be super ambitious, you wanna really like drive this at a world class scale even if you don’t have the resources and you’re starting from a small country and just wanna still do that.

So you wanna be really ambitious but you want to do it really well and then you want to do it together. That’s what the heart is all about. Got really collaboration and teams over individuals kind of approach and those are the three values I like. There’s also others around attitude and willingness to learn and willingness to teach, but I think they’re kind of like part of these main three in my view.

And I think they work really well. They’re simple, but they carry that approach that we have. But in engineering specifically, I think excellence has been a great choice because we were very deliberate in the beginning about trying to do quality even though we were moving fast. I personally value that a lot.

Otto: Yeah, I’ve always loved the Wolt app, for example, which is kind of famously one of the better apps in this category. And just put my last order in a couple of hours ago. So been a happy customer since Miki, the CEO originally installed it on my phone and made me start using it. So it’s been very visible in the product from so early days, which is actually really surprising because usually when you’re a scrappy startup, you just don’t get to focus on that kind of stuff. But what really set the bar high there is there anything that you’ve had to change as you’ve grown? Like you figured that this thing that we thought is important was actually just a characteristic of being a small company and maybe we shouldn’t talk about that anymore?

Niilo: As you just mentioned, when Wolt was small, we were kind of like a mini Apple. We were building this intuition driven, very strong, intuition driven, beautiful crafted app. And we still want to keep the beautiful crafter thing about. I think what’s really changed along the way is that we still have some intuition in the mix, but we are really, really over-indexing on data and user research these days, and have been for a while now already.

So it’s like this brazen belief that, you know, this is the way we’re gonna build this and spending, you know, four months building a feature without testing it or understanding if there’s any value in it. I think that’s something that really has changed over the years.

I think we made a lot of the right choices because we had a lot of really smart people helping that. And of course we were lucky in timing and all the other things that helped when a company is starting out. And I like that we were very deliberate about that in the beginning. We debated endlessly about little details and the approaches we wanted to take and the level of what is ready to be released for customers. I think it set a lot of the foundations.

We still build the app and we really are holistically interested in the ratings of the applications and the customer experience approach. And it’s one of the differentiators we have in the market, I think. But we are very much more data-driven. And really that pure intuition from the initial beginnings has really changed along the way.

At some point, we build the full end to end review capability. So you could review based on dishes you bought and everything, you could review everything and we would know what is verified, what you do actually eat, and based on that, have this kind of moderation tools and merchant tools where they can answer.

And this whole end-to-end package. And then we launched it and realized everybody was reviewing mostly deliveries rather than the restaurants. And the merchants got really mad about it because they were like, you know, why are you whining to me about it? It wasn’t my fault. And then we realized that maybe we need to iterate a bit on this.

And we just basically built the whole thing based on a hunch. I think these days we have a very valid feature, but we built it like four-five years ago. So it was like in retrospect, one of those. I think at that point we started moving a bit more towards this kind of outcomes-first thinking in our product development.

But yeah, so mistakes were made along the way.

Otto: What about building the team and recruiting and trying to somehow apply your culture there: How do you do that in practice? How do you evaluate that in the recruiting process versus how much do you take a chance and leave it up to the kind of onboarding and the teams to figure out?

Niilo: It’s always a balance. Like we’ve always hired with like two major levers. One of them was culture fit and the other one is just excellence in what you’re doing. A craft excellence side of things. So we typically try to have a minimal amount of interviews. So it would be minimal for us to evaluate your skill set and try to evaluate actual cases where you would work with us and how that would work.

But the first interview is typically about culture evaluation. And the second one is typically about technical craft evaluation. Of course you do cultural evaluation along the way, but the beginning is typically where we start with more like how do you look at ownership and what sort of areas where you’ve taken ownership. I love to identify potential in people.

It’s easier if you have somebody from, I don’t know, Google in your pipeline, and they have a good track record of things. You kind of have a pretty good inkling that this person is gonna be a pretty good engineer. Of course you evaluate and you look at the tech skills and everything else. But it’s a pretty good kind of indicator for that. But I really like is finding those underdogs and those people who may not have a good CV who are accidentally at the older enterprises where they might have ended up when they were young, for example, and they might have not used the right technologies.

But, the key is if you identify those, some of our best staff engineers came from these companies where you wouldn’t anticipate having young, passionate, really great talent. Of course they have some talent, but typically they’re very differently focused. But finding that kind of potential is something I’m very passionate about personally trying to glean that from the ways they approach ownership, the ways they have kind of gone beyond the obvious or tried to change things that’s fighting against the wind mills and kind of figuring out how do they want to drive their piece or their impact.

So that’s what I personally really kind of love. But we use the values and we use questions based on the values typically to evaluate in the culture of it, kind of thing. So they are a part of that. Part of the evaluation package have been pretty much since the beginning. I think you have to have cultural alignment in a company if you want to build a culture-led company, because recruitment is the biggest value you have.

Otto: Yeah, companies have a very different way of, for example, prioritizing work and expectations around how much ownership you need to take on things. And someone might be really great contributing in one environment where someone’s kind of processing the product feedback for them and giving them tasks.

Niilo: I think we’re pretty good at evaluating it at recruitment phase because of course the earlier you evaluate this, the less cost there is for everybody involved in getting this right. But it happens at this, it happens kind of like, wouldn’t I say constantly, but it’s, it is a continuous when you’re hiring a lot of. That it happens. I think as you mentioned, one of the biggest reasons is exactly the kind of, how well are you kind of taking ownership on things. Like the typical problem tends to come, especially depending a bit on the background of the people is they, they like are great when you give them a task, but we don’t want to give you a task.

Otto: Even the technical evaluation though, it’s something that many companies don’t seem to be doing too well. It feels sometimes that companies are outsourcing technical evaluation to the previous companies and looking at resumes like, do you have a Google there? And then if yes, then welcome. How are you testing the technical skill sets and who’s doing that?

Then how long does it take to get a sense of if someone is good enough?

Niilo: Yeah, we try to do the minimal amount of effort to do the evaluation because it’s a lot of work to interview a lot of folks. And also, you need to be good for the people. You need to be fair for the people in the pipeline.

But we are used to being very holistic about using homework for everybody. So every single person did a test no matter what, from director to whatever level. Every single person in engineering did the homework and then we evaluated that with a bunch of peers. First evaluated offline and then also online.

So basically did a live interview and kind of different scenarios from it and challenged your assumptions and kind of really dug deep into it so we understood if you did it yourself and asked, you know, silly and wonderful questions based on it, and tried to make that kind of like a peer review moment work.

I think nowadays we also do like a fast track interview for really senior engineers where we do live testing more. So you can also kinda like choose, do you wanna do a home test or do you wanna do a live testing? Because typical live testing is very bias heavy and certain people are really good at live testing or live coding, for example.

But they might not be the best engineers. So you need to give this kind of optionality for the people. But I don’t think we do anything magical in reviewing folks. It’s not anything overly complex. It has a bit of algorithmic complexity and there’s a little bit of just good code standards we look at.

But then the real beef just comes from that competence interview where we have this role called competence lead, which we have some deep experts from a specific technology who’s also this kind of advocate for that technology in many ways. And they’re also part of crafting the tasks for the technology. And they’re often part of the interview. We often have a staff engineer, especially if they’re more senior engineers, there’s a staff engineer doing the kind of tech evaluation. And then we have always somebody from the team, so always somebody from the team they would be joining. So kind of this peer kind of evaluation.

But it depends on the case. So if they’re more junior, we might just have people from the team doing it. But everybody’s trained, so everybody’s doing the tech interviews is trained into doing tech interviews to try to overcome the biases that come with engineers. Typical engineers want to compare people to themselves, and that’s always like, you have more context of the problem being solved.

So it’s a really biased way of looking at it. So trying to figure out ways to ask things and expect answers that are kind of fair for everyone and trying to do that. But we’ve done a lot of iterations on the tasks and the interview model. And we spend a lot of engineering time doing that, right?

Because if you’re growing fast, it’s a very important thing to get right. It’s not like we don’t like Google or these guys who try to do these complex… When we were tiny, a company, we used to do like some binary sort shit or some other thing on a whiteboard.

But it’s like nowadays. Luckily we are focusing more on the actual problems you would solve at work. So you don’t have to memorize anything. It’s about creative problem solving. That’s what we are doing here and trying to showcase that.

Otto: That’s great to hear. I know I wouldn’t pass any of the Leet code exercises that some companies are doing nowadays, and they are not very closely related to the work that we’re usually doing.

Even though you said you’re not doing anything magical, there was a lot of good stuff that many companies have not thought about because oftentimes you just get someone to interview the candidate without preparing much and without necessarily being an expert in whatever technology they’re gonna be talking about and so on.

So you just need to get a lot of things right and be very systematic about it to run a good quality recruiting process.

Niilo: I think it’s like if you’re a growth company, hiring is a first class citizen because that’s going to be like half the things you spend on is trying to get better people so you can scale up your environment and what you’re building. So I think it’s also a candidate experience. I’m really passionate about candidate experience.

We measure it really holistically and we often look at the people who don’t get to join us, sending us messages saying “Next year, I’m gonna apply again.” And I love this sort of dedication that people also often also give us feedback. Many have told us that this was the best recruitment process that they’ve had.

So I like the fact that we tried to keep it so that you will be joining a team and this is working with the team instead of us grilling you about the different aspects. It’s more about together solving a problem and then nudging and making it a really psychologically safe situation because that’s how it should be in working environments. But it’s worked really well for us. So for any growth company, I would really recommend spending extra effort in engineering hiring processes and making it important for people because there’s a lot of value there.

Otto: It is, but it, as you said, it’s important. One of the most important things, and you can be spending a lot of time on recruiting. So making sure that, I think also developers will appreciate when the recruiting organization works really well and they know they can trust it and they know they can trust their future colleagues because they understand that they’re going through this thorough process and and so on.~~ So it is really important for many aspects.

Niilo: I mean, it’s, it’s true. And I, I think like the worst years, I spent probably like 80% of my time in interviews. Just like back to back interviews concept, because I used to interview everybody, every engineer until we had a couple of hundred of them. So I did a couple of thousand interviews along the way for that.

Otto: You’ve been growing really rapidly all this time, and what’s your take? Does it make sense to be blitzscaling like that? If you were to do it again, would you do it a little bit slower or what’s your take?

Niilo: If I had the choice, I would probably grow a little bit slower because you have so many business requirements constantly, they’re, to really trying to kind of like always behind the need you kind of forget to realize it because it takes about six months to hire and fully onboard and have somebody fully operational. You don’t even realize how many things you’re solving when you’re already hiring the next one. So for example, this year we took out a little bit of a breather in the summer. So we didn’t hire as many people for like three months in the company. And we realized we were really shipping a lot of things in the autumn because most people weren’t focusing on recruitment, and they were really crunching features and getting that value out because it takes a lot of time from the organization as well, if you’re hiring a lot of folks. So there’s a balance to be done. Like we did it as fast as we needed to. Also, because Covid kind of was really surprising for an exponentially growing business to be even more exponential. It was painful at times, especially from an engineering perspective. So it was a bit of, like, special times to get to this point. I would do it a bit more managed. I think culture is easier to manage if you have enough time to onboard people properly. And if you have enough time to make teams really effective, like individuals might be producing code, but teams take a bit more time. And if you’re ramping up like half of the organization or new teams all the time, it’s really hard to find people who are bringing their culture in. Then you need to kind of fix those mistakes and not all the teams will be as effective as they could be. So you might have a lot of engineers who are great, but they’re not doing the best work of their lives because the environment isn’t really there yet. But then you get to the point where you’re kind of wasting talent and you don’t wanna waste talent. If you want to hire the best and give them the best jobs, and the best problems to solve, you’re failing if they’re not solving those problems. So yeah, I agree. I would, I would go a bit slower, but not much. Maybe 25% slower. That would be ambitious enough. But you would have enough time. That’s what I would do. So we’d be like a year behind from this current situation basically. That would be ideal. But we did okay.

Otto: Can you identify any inflection points in the scaling, like when things really changed either for you in your role or as an organization?

Niilo: I think they actually go pretty hand in hand with the roles. I think there’s two obvious ones. One, one is around 50-60 folks when the tiny tribe becomes a village kind of a moment where kind of like people still know each other, but you need a bit more structure. You’re not just a bunch of teams. You’re not just like 10 teams doing random things, but you start building a bit more unity around those topics. So you start between 50 and 100 depending on what you’re trying to solve. And that’s typically where for us, that was a painful time because we needed to make a lot of these foundational changes. So we wanted to do a more deliberate technical lead role. So we started the lead engineer, so staff engineer role from nothing. And before that, we were team centric and no kind of technical authorities, but then it became obvious that you needed some at that scale to think of that more abstract level of technology rather than the single team’s focus. It’s really about focus, not about authority, it’s about do we have somebody thinking about the bigger picture, kind of a thing. And at the same time, we wanted to also introduce some engineering leadership because for one, I had 20 something reports and I was dying. So we needed to change that as well. So like 20 leaders is a bit much when you’re trying to run things. So we introduced this kind of a director level where people are running teams of teams kind of a thing. And both of those went pretty smoothly. But there were a lot of talks, a lot of workshopping and a lot of going through the organization to make people understand, and you always need to make people understand. You need to give them space to speak their voice. And that’s also culturally and humanely important. So you need to do a lot of these discussions and back and forth influencing to kind of get that hurdle done. Well, once you get that done, then not that many things change because you’re just kind of parallelizing that environment going forward. But that was the first big from that initial making of those like six teams out of two, that was the next point when we had a lot of pain in the organization. Also because we wanted to align on what we are building a bit more. So really high ownership teams, but at some point the teams need to go in the same direction. And that sort of creates a bit of schism because you’re giving more directions, but it’s also what you need to do at scale. I think the second one came up probably around like 200-250 folks, like roughly when people don’t really know each other anymore. And it starts getting, you get more of these kind of middle management grows a bit more because you just need more support to make this kind of abstraction work, so that people know what the other people are doing and we are kind of somehow aligned on what we’re building. And you need to build a lot of structures around that. So you get a lot of these, a lot more of these middle roles and a lot more kind of communications is breaking down. Everybody complains that we’re becoming corporate because somebody suggests a process in Confluence kind of thing. And it’s just like growth pains for people who joined a small company, when they grow with it to understand that it’s a different world. The people who join at that point, typically they’re like, fine, this is the world we joined. But when you have a lot of folks growing with it that it’s a very painful transition to do when you have more managers and more product management and more specific roles for specific things and you start doing some — you don’t need to do layers and such, but you don’t normally have those more specific roles for specific things and you might build a more platform specific kind of areas where you have more kind of technical focus, and then not every team is owning everything anymore because something needs to be commonly owned and these sort of patterns that come up with it. So I think those are the two painful moments from a kind of organizational perspective. And also personally, because leadership is all about giving away everything and you just need to give away more and more. And in the end you’re hopefully doing nothing but waving your hands and sitting in podcasts.

Otto: That’s great. I find your example of complaints about becoming corporate really interesting because indeed, as a startup, you’re probably hiring startup people. And many of them have never been a part of a bigger organization. So when you start getting more meetings, it kind of looks like this is some kind of fault of a company becoming corporate, but then when you have people who’ve been there, they kind of just recognize that this is pretty normal and that’s required to kind of survive in this new environment. So you probably have to change something also in what kind of people you’re bringing into the organization.

Niilo: I mean, yeah, the bigger you get, the more you hire people also from bigger organizations because you attract people who like bigger organizations at the same time. But you still want to keep the same culture, kind of ownership drivenness, but you have more people who are, especially in like product engineering companies who might have a really valued kind of experience from it. And it’s actually really valuable because they also bring you maybe some good ways of working and some things that kind of challenge the things that you’ve homegrown along the way. It’s also important that around the 200 point, to up level some leadership from externally. So I think in both of these points, it’s important to grow from the inside, to have a balance of growing from the inside. For your culture and for your technical digital knowledge, you need to have those champions. But you also need to bring some outside in, people who give you fresh perspectives and challenge you. Because otherwise you end up just building this weird silo where you don’t really know what you’re doing because nobody’s challenging you because you’re just having people who grew up with you in the same kind of environment. And as a leader, you need to have at least one person who constantly challenges you. Otherwise you’re bound to make mistakes.

Otto: That’s good stuff. I remember Slack CTO, Cal Henderson was talking about the percentage of his organization that’s been doing this role before. So you have an idea of like have they been in a similar place versus did they grow up from this organization to this position, et cetera. And you wanna find some kind of a balance with that so that people challenge each other based on backgrounds from other companies or sometimes just from more context from your own.

Niilo: Yeah, definitely. I think it’s actually a good metric to follow. Maybe I need to add that to my HR palette of metrics to follow. Another metric to follow when companies get bigger is engineering time spent in meetings and having an understanding of how much time they actually have to produce something. That’s a good one.

Otto: You’ve talked about the high-ownership teams quite a bit. There’s a balance to that, which is the amount of standardization you need to do, and often companies who talk about this empowerment, they choose to standardize almost nothing. While then there’s a bunch of companies that try to standardize almost everything. So what’s important to standardize or what do you hope that you started standardizing a little bit earlier?

Niilo: It’s something we’ve been fighting actually recently. So far, for example the teams have really decided the technology at Wolt. We have quite a wide plethora of technologies in use, and some of them were mistakes, some of them were amazing successes.

But there’s been a general light touch way of administering or giving instructions on this because we believe that the great engineers we hire can solve the problems in the right ways. But the bigger you get, the more … standardization in general comes from a problem where, from my perspective, teams know how to solve their problems well. But when you have 60 teams, there are problems that affect them all that are not the team’s problem. So it’s a problem that a team would think about or want to solve, but it’s something that the company has to solve. So the abstraction of decision-making makes it a bit difficult. So you have high ownership teams, but they won’t have the context to make the right decisions.

And for example, we really try to give them that context, but I don’t think it’s enough. Like it’s a bit of an illusion to think that they would think they would make the right decision if they would have all the knowledge. But giving them all that knowledge and context would be too much work.

Not efficient anymore. So there comes a time when you have to start doing more standardization. I do believe the bigger companies get there is a bit more inertia and a bit more like, what you own becomes narrower because it’s just a matter of scale. So it also means that there’s a lot more things to dictate things around you. In technological terms, the things that probably should be somewhat standardized are between services, core infrastructure. How do we deploy our services and how do they talk to each other and what sort of safety measures do we have around them? Our build processes, our observability, our release capabilities.

So we can do automatic releases, maybe. Something where we haven’t really succeeded in yet, which is feature flagging or configurations. These are certain things that we should be, you should start building common layers from a tech perspective. And normally these are things that are somewhat team centric, but often between teams. So how does our logistics talk with our consumer? They’re different domains, but all the business goes between these two. But that’s something that you really need to somewhat standardize and hopefully not have like 70 different ways of doing HTTP calls between these kind of things.

So there’s a lot of things where you actually have to start doing standardization from a tech perspective. Then also a bit from process perspective. I mean the basic good craft of engineering is actually really process heavy. You have PR reviews, you have certain quality standards, you have contribution guidelines, you have testing guidelines, you have testing standards. You have numbers about your test coverage, and your failure rates, and stuff. It’s a lot of process already inbuilt in that. And you just have to start building that at a bit bigger scale. So looking at that from a big, beyond the team perspective, I think comes into play.

Then there’s the question of choosing technologies and frameworks, which is an endless debate, which we are right now on at Wolt. I think there’s a balance to be done. I don’t think you need to force everybody to use a single solution, but there is probably something that you need to do around how many things you’re using and core systems at least. So in core feature development so that you can focus on the essentials, which is creating that customer value.

And there are areas where you can do deep tech and you can do Elixir for a specific thing when you want to have a super high IO chat solution. Or you can do that, but it needs to be really self-contained and then most of the things you build need to have a kind of good build baseline.

The way I would approach this is that we would invest—in an ideal world, you would do this earlier than where we are today—and you would invest more in specific sets of technologies. So you would invest more heavily in building a great communication protocol, adopted with great libraries for specific technologies that you get everybody to adopt and build in the core systems.

So then you just have a secure layer where you can, with a single contribution, make sure that you have the circuit breakers in place and object pooling and whatever you need. And maybe some nice little database magic there to make that happen.

You have engineers really crafting that with care so that everybody uses that. That would be like the thing I would’ve done earlier than what we are doing today. And we are focusing quite a lot on it. But like one year earlier would’ve been the right time I think to get to that point. It’s an “at scale” thing.

You need to solve this only at scale. Before this, there’s a lot of other things you need to get right. There are places where standardization and this gentle enforcement comes into play, I think when building tech. And I know there’s a lot of schools, some people start this very early on and are really kind of more holistic about dictating this.

But I still believe that if you want to hire the best engineers, there needs to be freedom for them to find the best solutions. But at scale, those solutions have constraints. There’s also talent and attrition constraints. So a team might decide to use a technology that nobody else uses and then they’re not here anymore.

And then you’re stuck with your beautiful, I don’t know, I think I heard Zalando had a beautiful Haskell service that nobody wanted to touch. Their modern, beautiful Haskell service once the team left and then they’re actually stuck with like, hey, we have this new team and nobody wants to build this technology and we’re kind of stuck with this and what do we do now? And then it’s very costly.

Otto: Would it be nice to wrap up just hearing about your personal self-development and how do you become a CTO of such a team when you really don’t have any more senior engineering leadership in the company supporting you or like there’s not that many references directly around you, so how do you just get better at what you do? How do you study?

Niilo: Yeah, it’s an excellent question. The way I approached this when Miki first asked me to do this, I did two things. I read whatever books I could find about this, and the other one is I found whatever people I could talk to about this. So basically doing very broad research on the topic and kind of understanding… I’ve always been interested in leadership personally, so it’s kind of like the thing that I was curious about, social psychology and how do we do organizational intellect, and how do you work together, and what matters?

And then I just deep dive into that a lot. But I think the two things that really work for me … And everybody learns differently. Some people have different types of learning, so make it a bit different for whatever path you want to do.

But the two best things, especially in a growth company, number one thing by far, the biggest thing is having the right mentors. Because as you mentioned, there was nobody, when I took this role, there was nobody in the company who was doing this. There weren’t that many people in Finland who were doing this well. I’m a bit opinionated about this, but I think there’s a lot of people who do leadership in tech spaces really badly and I wanted to learn from people who did it well.

So through our investors, luckily I found some people from Finland who used to be at Google and more modern companies who had some really good thoughts and who challenged me in the right ways. And then later on I talked with some folks who scaled up Spotify. And then I talked a lot with people from like booking.com and Airbnb was where my main mentor actually, who’s a good friend these days, Mike Curtis, came from.

And having the right level of mentors for the right level of scaling has really helped, mostly for learning from their mistakes. Like they have really good hindsight on what they did at what scale and why. And then just drilling down on these and for at least for six months, you get really valuable things and you’re gonna keep maybe a few years of failures yourself doing that. So that’s been like my warm recommendation. And I was happy to introduce people for this as well, to find the right mentors, because it’s a supercharging thing.

I think the other one is, well, I like books, so books are good. Or it could be podcasts, could be whatever way you consume information, but finding the kind of great thinkers of your time in especially the forward looking things.

If you’re trying to kind of change the world, you should probably start by yourself or try to find those things that kind of resonate with you. There’s a lot of good books. My latest books … one of my favorites, even though it’s a bit old now, is Radical Candor. I still like it a lot.

There’s High Output Management from back in the day, these kind of classic management books. There’s Marty Cagan’s product books that are pretty good for understanding the kind of product business modern-day thinking. And then there’s a bunch of books about social psychology and Google’s project Aristotle and all these kind of like thinking more about the humane aspects of leadership, which I really personally care about.

Like the trust building and how to create an environment where you don’t need hierarchies, you’re really building it team’s first kind of collaboration aspect and that sort of thing. So I think that books and mentors have been really useful, but the one kind of supercharging thing I think is like, if you’re building a growth company, your paradigm changes every six months.

Your leadership, what you need to do and what you need to solve changes at least yearly completely. So you need to constantly kind of let go of the things you’ve been doing and thinking you’re doing well, and then step up into a thing where you’re sucking. Basically, I’ve been sucking for the last six-seven years, but I’ve been sucking successfully, so that’s been the journey.

Otto: That’s a great way to wrap up the conversation. Thank you so much, Niilo, for spending your Friday evening with me, and enjoy the weekend.

Niilo: Thank you, Otto. It was a pleasure.