Warm Up Chat: Sami Pippuri, Whim - Part 2

Lauri (00:05):

Welcome to DevOps Sauna. My name is Lauri and I am the chief marketing officer at Eficode. You are listening to the second episode of the discussion between Sami Pippuri, CTO of Mass Global, a company behind Whim and Eficode's CTO, Marko Klemetti. Whim wants to offer a digital alternative to owning a car. And we had a unique opportunity to get to talk to Sami about technological and cultural aspects of building successful digital services. The first episode before this one focused on technology choices, user experience, and DevOps as a culture. This second episode you're listening to now focuses on aspects such as organizing and scaling up the teams and building the commercial model for the services. Let's get going.

Marko (00:52):

Can you tell me where do you currently operate? Because that of course I presume has its challenges when you do a service like that.

Sami (01:03):

We are live in the Helsinki region, well, Southern Finland actually site, because we just added Dorko a while ago and then Vienna, Austria, Benelux region. And basically between Belgium and Holland, we have services as well as trialing in the UK, in the Birmingham region, as well as in a suburb of Tokyo called Kashi Wenoha. So, those are the main ones currently, but obviously we want to be a global player. And we just announced a few weeks back that there's some developments going on in London. For example, being present in the UK in Birmingham is a good start, but obviously London is the place where you want to be, but it's also a very ruthless market.

Sami (01:58):

So, you can only launch there once and we want to make sure that the service is up to scratch.

Marko (02:04):

Yeah, when I think of, for example, Unity, which is the game development engine and the organization behind it, what they've been doing is an engine that you can then transform your games into several platforms. And in a way, to me, Whim reminds me of the similar way of creating services. But when you go to new areas like Vienna or London, can you use the same technologies or do you have to change them a lot to match the targeted area?

Sami (02:41):

Well, Whim was designed to be extensible in this way from the get go. And I think that would go also to the accessibility of the team and kind of the segue to the scaling topic.

Marko (02:55):

Definitely.

Sami (02:57):

We did design the architecture to be basically that there is a core of the service, which has, the core business logic pricing rules and these kind of things, user information, all this very sensitive stuff.

Sami (03:14):

And then there is a completely separate Serverless project physically, but a completely separate stage where all those integrations live. And the point about this was that, while it might be somewhat difficult to scale the team around the core services, because they're all so tightly connected and you have to be aware of all the design decisions, et cetera, but then there's very strongly defined schema as how that core communicates with the rest of the world. And it does this via integration stage and this integration stage is much more strictly defined. And so there's kind of a sandbox where all the integrations work as a translator between the internal schemas and the outside world.

Sami (04:11):

And this page was designed to be very extensible, both technically as well as from personnel point of view, because the integrations happen all over the world. It does not make sense to centralize everything in Helsinki. It makes sense to hire people with the local knowledge, local language and so forth, because transportation tends to be quite local.

Sami (04:38):

A lot of the transport operators, they operate on the local language and so forth. So you need local support. So it has to be relatively simple, relatively quick, to get going to onboard new people. And that's how we designed it. So going to someplace like Vienna, it's a matter of finding the necessary services, contracting the necessary services, and then working on the integration in the specific stage of building this translator, basically between the providers and our schemas. And obviously that's not all going into a new market and new language, et cetera.

Sami (05:19):

So you have to do localization. You have to figure out what kind of packages makes sense and so forth. But technically speaking, the bulk of the work is in this integration layer. And then the rest of it is more like fine tuning for the market. So this seems like a validation of the design per se, that I've been able to relatively quickly and easily get to new markets. Going into new markets, obviously with a base scenario is always faster than building something bespoke or very optimized for the market, but you need to get the learnings first. How do people actually commute and how do people use services in order to then maybe build the next layer, which is to promise people a kind of a subscription plan. So, yeah.

Marko (06:18):

Sounds awesome. You've scaled up the team. And, that's definitely interesting. You've grown from the one person plus the founders into 80 people, which is, well to say the least insane, and it might easily go wrong and many organizations have gone wrong. So what was your way of scaling up the team and still being able to develop and release the application in an organized manner?

Sami (06:46):

Yeah. To add to the insanity, the 80 people was in the technical side of things. So, I think the company itself is around 120 plus. So the bulk of personnel was on the technology side with different kinds of peripherals. Of course, obviously there's growing pains. So, I would be lying if that was not the case so, especially when the times of the rapid growth a couple of years ago, there was maybe not a day that goes by on when people are wondering that, "Okay, why are we not delivering more?" I wish there was some kind of a silver bullet to say, "Okay, this is how you do it." But in the end, I think most organizations probably bump into similar things, but there has always been nuances.

Sami (07:38):

So, in our case, maybe one of the problems was that we were not on top of the full stack of services, as in, because we were basically selling through what our partners had to offer. So the weakest link in the chain was what we had to work with. And typically that was working with legacy systems, some work with basically XML over sockets and taxi ordering system is most likely developed with visual basic and so forth. So technically, building the error resiliency for these kinds of services was very difficult. And so, if your service depends on a public transit operator that has monopoly in an area, there is not much you can do if that service fails.

Sami (08:43):

And then on the process side of things, obviously when we grow quickly, then we do introduce different kinds of inertia in the team. We have people who are still learning, maybe making mistakes while we are under pressure to deliver something. And maybe some creating technical depth very quickly, because we're under pressure. It's all very classical things. How I'm managing that, I can always think of ways how things could have gone better, but I think overall nobody has able to do it better either. So I need to be happy about what has been achieved there, but yeah.

Marko (09:32):

I guess my question would be more of, did you decide to go for self organized teams or did you have functional teams or do you still have functional teams based on certain areas of integration or UX or similar, or more multidisciplinary?

Sami (09:49):

Yeah, so we had functional teams maybe a bit too long. Maybe that's one of the things that I would like to go back and change a bit earlier. So in the middle of the rapid growth that you kind of forget to think about these things a little bit, but so yeah, we had functional teams quite a long time. Now in the past year, we've been basically moving into more of a feature team type of a scrum team approach, which has not come easy either as a change. But I think overall, that is what I believe in as a team of this size, that there has to be this kind of Amazon style, two beta teams that have a very strong product ownership and are empowered within their scope, but also have a responsibility to deliver. So having a more integrated product slash dev team that is small enough to not have friction, I think that's really the way to go. And I wish I would have made the change earlier like that. But now I think that that's proven to be the model, how this thing works.

Marko (11:14):

Yeah. On the other hand, to me, it seems like the development never choked in it, which means that it hasn't been too late either. And I also feel that in many organizations, the move is always painful. It always takes some time, it always takes more resources than you would have had just the staying the same. So...

Sami (11:35):

Yeah, of course the problem is if you have any in your team. It's to do with the actual individuals, even though it's very easy to look at things on paper that, here's a beautiful chart, how we will deal with all kinds of scalability issues, but in the end, it comes down to the people that you have, and you have old timers who've been there from the get go and know exactly how things work, and those are such a valuable asset, but then you have newcomers who are just learning about things and they haven't even seen Serverless before, maybe and so forth. So even though they are great developers, but just takes them time to get up to speed, and then you figure out, okay, you have maybe three or four, say backend developers with the required skills. And then you have five or six different teams where you need such a skill, then what do you do? So you really have to pick your battles and also try to not overstretch your people. So it's just very tough in making those priority decisions.

Marko (12:48):

Yeah. Can I ask what's your geographical division between the developers and even nationalities, or have you preferred having one location, one nationality type or have you decided going... You already said about having the local knowledge in different sites you operate in, how does that work in the team selection?

Sami (13:10):

So my philosophy maybe because of my background, as well as being that I don't really care about people's nationalities or language as long as they speak English.

Sami (13:21):

So I started out hiring people from... Well, my first hire was not even graduated back then. But because if I had the benefit of actually using a company specialized on Serverless back in the day, so I had experience in house or not on payroll yet. So I was able to build up the in house experience, meanwhile, working with outside help. And so I started hiring a little bit across the board, but actually my first Finnish speaking engineer, I think joined two years in. So I guess because after working 10 plus years in a multinational environment, I just saw that, why would I limit my choices to, say perhaps less than 50% of the market in terms of developers even in here in Finland?

Sami (14:25):

So that early stage we were, of course, a team that mostly fit into one room here in Helsinki, but especially when building this architecture to be scalable and with the integrations, it was a choice early on that the integrations should actually live outside the bubble here in Helsinki. So, we started working with, first computer companies and then freelancers in different regions. So outsourcing essentially to Poland, et cetera, but also in German speaking market in Japan, et cetera. So, that was the scalability bit there. On the core side, I think most developers do work in Helsinki. Over time, we have expanded a little bit, then there's kind of a learning route so since the technology in the backend is the same, essentially for the core, as well as the integration, then the more experienced integrations guys has a kind of additional appetite, maybe in getting it more involved into the core development, which is of course more challenging, but also more maybe rewarding.

Sami (15:44):

On the client's side, maybe we've been a little bit more spread out. So using resources in Helsinki, but also freelance resources that were maybe familiar to me earlier, or have come up as people move around. So, overall I think most of the work gets done remotely, or even though people might be sitting in the same office, they still slack around and et cetera. So say the current situation with COVID, maybe it has not really changed much in the way how the team was already operating. Certainly people can't meet up for a coding session, et cetera. So we'll be using some tools for those, or pair programming and visual studio code live extensions.

Marko (16:42):

Yeah, that's actually interesting addition because as I said, it's been many of the organizations who already have the so-called agile and DevOps practices in place and use modern technologies like managed services or Serverless have not seen much loss in the speed of deliveries, but it's more of maintaining the culture and collaboration between developers and obvious code live differently is really interesting. Last, I would like to talk a bit about the commercial side, because of course, building these services, building them the way you have done is not free and it does not come free and it needs knowledge. So my, approaching the topic, I would first ask, how have you built the commercial model of Whim, if I may ask?

Sami (17:34):

There's kind of two ways how you can build transit solutions. So there's one way, which is maybe the Google way where you focus on curating information, et cetera. And your aim is to attract as many eyeballs as possible to monetize them in different ways and from typically advertising, et cetera. So if you're saying about, if you're not paying for the product, you are the product and our way was always that we want to make it a product where the customer actually pays for the service, which is natural in transportation, because people are not questioning the fact that whether they should pay for a bus or a taxi, it's an existing business. That brings us to the pay as you go tier of the service, which is typically just very simple. Here's a service and it has a price tag and you can click and buy and that's it.

Sami (18:38):

You're not charged any extra. You're just using the service to get onboard a bus or bike or whichever, but maybe the unique aspect of Whim that it's known for, and why it's known for as the Netflix of transportation is the subscription tier. And that's what made one of our partners famous and the transport environment. And already back in the days when I was joining the team, he was on the media saying how he wants to give everybody a free taxi rides with 100, well, not free, but taxi for everybody for a hundred Euros a month. Those kinds of bold claims are why we were able to get the exposure. It's because there's a lot of different companies that were getting services and trying to live on a 1% commission or something from a ticket.

Sami (19:42):

But the point was that if you start to aggregate a lot of people, a lot of traffic, then you start to be able to optimize your phone system, as well as the transit system, as a whole and move the investment that people make for owning private vehicles, which is, you have a car loan, you have a leasing car or something like that. You're spending 300 to 600 Euros a month on that. So instead of that sunk cost that people are making for the physical asset, move that investment into using services. And by that, then you're able to move from the current say 50 to 100 Euro price point that people pay for public transport to maybe more of 200 euros, 300 euros price point for replacing a car. So there, the subscription is such an important thing where you can guarantee people that you know exactly what your cost is going to be one month by one month, and you can opt out when you want. That has been maybe the guiding light of our being and the reason why we've made the headlines that we have.

Marko (21:04):

Yeah. And I also feel like if we look at many of the success stories such as PayPal, they did similar operations in the beginning the same way, so that you at first provide credits for the ones who will become your users and teams that start optimizing that system. Definitely sounds interesting. Maybe from the commercial point of view, when you started and you started scaling up, how did you, first of all, have bravery into building a service in the beginning already that was aiming into a big success? Was it supported by some evidence from the media or something very similar? Or did you just go all in already from the beginning?

Sami (21:53):

At the time we started this, or when I joined, I had already spent almost a decade in talking about the concept in different kinds of environments. And so there was a clear resounding backing for it that, okay, now it's time to really try this out. And we believe that this is the future, and we want to be building the next generation of a product. So we did start with quite a lot of ambition, and I believe that this is becoming a thing with part back in the days that we probably have to do a lot of education, educating, "Okay, what is it and why," but seems like the market was actually coming to us faster than we thought, perhaps even too fast, because the appetite was growing faster than we were able to meet it. But, I'll take it that way rather than having to talk to a vacuum that there's nothing coming back.

Sami (22:56):

So we did start maybe for an MVP... I mean, we could have done maybe faster an NVP, but then we did start to already build the product with the vision that this will be a continuum that we are taking this to scale. And that's probably a reason why I thought that Serverless would also be a good technology for this because of both technical scalability, but also as a growing company, when you want to attract senior talent, you need to present people with a challenge that they can learn on the job and use maybe not fleeting edge, but new technologies. So, that's why I thought that it's a good choice for this kind of a task as well.

Marko (23:49):

Yeah. Thank you. As a continuing question to that, did you see any points in time where say a marketing effort or similar brought you so many new customers or new users, that you saw very tangibly that technological selections you had done were paying off because of the capability to save for Serverless, for example, or how did you manage all of these rapid growth points?

Sami (24:17):

In terms of marketing activities, there's a lot of nice learnings in this. And one of them was that maybe first off we started with the digital marketing and online thinking that, "Okay, these are modern users." And we reached them through digital channels. Well, it turns out the learnings had been that the digital channels did not really work that well in acquiring people who are buying transportation services. So actually our marketing team realized that somewhat strangely that people actually resonated better with the physical advertising, like actual bulletin boards next to the bus stops, et cetera, to be present in where people are moving on a daily basis. That was an incredible realization. So we went more billboard style.

Sami (25:21):

Over time, we have diversified from that. So now there's a mix of both. So if there's a marketing campaign digitally, it might be to do with sort of say, display advertising, but more and more engagement type of advertising or promotions that there's a lot of people have downloaded Whim, and they might [not reacted 00:00:25:45] at the moment. So that's a nice asset to have as a targeting, which leads to one interesting story that our marketing team sent out a push message to inactive users, giving them some credit in the application. Unfortunately, that push message included a deep link into the application that went into a view that was not using any kind of a cache or any sort of a prebuilt type of an offering so it wasn't fully dynamic. And it seems like the campaign wasn't very effective.

Sami (26:23):

A lot of people clicked on the message and opened that view, which then hit our database correctly. And as well as our service that we use to price things, so two things happened. But I think that since we're using RDS before, before RDS proxy existed, we had suddenly, I can't recall how many hitting the database in parallel. And the database ran out of connections on one occasion. And once that was up again, I think it ran out of memory. And then, secondly, this star service we're using ran out of API quota. So our system was down essentially for these people. So that marketing campaign was highly successful in engaging people, but the end results were maybe not so good because we had not experienced this kind of thing before. A huge traffic spike into a kind of less than optimized part of the system.

Marko (27:33):

Yeah, honestly, I have to say that every company has had to have a similar experience at some point. It seems like it's mandatory and it's only the extent of the damage that's then controlled by, well, oftentimes luck instead of preparation, because there are always times when something like this happens in the most unexpected times. I, of course, have first seen Whim as you said in billboards on the bus stop myself a few years back. And that, for me, verifies what you said, because then of course, it's where you bump into the services where you actually need it. And that was intelligent in my point of view. What's next for Whim or Mass Global for that matter?

Sami (28:24):

Well, now the service I think is entering this space where we're kind of want it to be already awhile ago, but basically going into new regions. So, there's an entry to Japan, there's entry to central Europe, wider UK, et cetera. And then secondly, taking a step forward in terms of the servicing of the end users. So as a product, there's evolution on the side of the business, as well as the promise side of things. So something that I'm actually pretty happy about it has been utilizing more data in order to serve the end user better, that's always been what was sought after with Whim in the first place. Getting to a point where we can start maybe anticipating things that, "Okay, what is likely to happen next?" How to maybe match different kinds of services better to an end user and "Okay, this, this person likes to city bike."

Sami (29:42):

So it's quite likely that they will pick a city bike if presented the option for this kind of a journey or that this person does not want a city bike because they never rented one and they've rented lots of cars. So, okay, let's look at it. If we can provide car options that are maybe more suitable for this type of journey, as well as combining things in a more high level. There's this large toutedconcept called multi-modality, which is where your combined different, say an East quarter with public transport or taxi with long distance rail and so forth. And we tried that out already from very early stage, and it did not really work as expected because it's a very hard problem to solve, trying to match different kinds of availability and schedules seamlessly together.

Sami (30:37):

It's not an easy task, but one by one, you can start introducing those kinds of things. And especially with micro-mobility, connecting to the next sort of a transit hub in a seamless fashion. I think those are the next things to look at from the product point of view, as well as maybe you will see some of these refreshed elements in the application itself. There's been a lot of iterations on the design front, and there are some very nice new designs that have been there for a long time already. And now we're kind of rolling them out into the application itself, screen by screen. So you'll see a lot of evolution on that.

Marko (31:23):

Sounds interesting. Is there something we haven't discussed that you would like to say?

Sami (31:30):

We've touched it probably, but they're looking at how your team process as well as technology comes together. I think that's a very interesting topic for myself having spent maybe the last year looking at this. How do we maybe make some minor adjustments, changes on where does work happen and by whom? And so moving from this very core centric, one location, kind of a centric model into maybe a little bit more spread out, maybe even vendor wise, a little bit more spread out, kind of an operation. That's basically what I've been doing in the past year or so.

Sami (32:22):

And because of course, times may be a little bit different right now, but once things start to get back on track, I think by default, we are going to be back into the timeframe when it's very hard to find people to do stuff. You have to take a broader view in where can you find people and there, you need to be quite flexible in using say very skilled externals for doing certain things, say, defining an architecture or defining your data pipeline that you can then start building with maybe your own or less experienced people.

Sami (33:04):

How do you plan transitions from, or bringing in new people? How do you plan things like say taking a dedicated team from a remote location to take over certain elements of the operation. And so that's kind of how I became so enthused about this topic about scaling, which scaling can mean up or down. And sometimes you need to make adjustments to your core team. And sometimes you need to make adjustments to the external teams, but overall it's really about constantly trying to balance things out. And I don't think that you can learn with the team that is stable like that. You have to allow for some room for adjustments. And originally when starting to go with this, and having a very tight team that fit into one room here in Helsinki, it was somewhat a foreign idea when I got lots of different inbound requests about, okay, I have this great team available and blah, blah, blah.

Sami (34:24):

I'm not having any of that. But once you hit that a scaling threshold and the ceiling where you can go with that core team, then that actually became the alternative or the way that I wanted to start doing things where you would find a trusted partner or find a trusted team that you can onboard as your own, even though they might be external and might be remote, and they probably are remote, but that actually does work. And going back, I might want to actually do it a little bit earlier to actually bringing on board a trusted team that is there as an integral part of the operation.

Marko (35:09):

Interesting. Have you looked at, for example, Base Camp is known for having this remote only type of approach to working, or then in complete other direction, the way Supercell, for example, has solved this team problem?

Sami (35:31):

Yes. To some extent. So obviously based here, I know a fair bit of about Supercell and basically Base Camp has been, of course, in the news quite a lot lately. And DHShas been a vocal guy, and I followed some of his writings and the way that Base Camp develops software and both of them probably have their own reasons and why it works for them in that context. So something like Supercell, they have their time horizons are maybe in a couple of years of developing something new and so far that, and they have plenty of money in the bank, so they can afford that kind of thing, that they have a team working on something for what, three years, and then it doesn't launch. And they perfect that art, whereas then maybe something like Base Camp mostly operating on the web, purely digital products, they also run that their own clock cycle pretty much. I think when it comes to something like Whim, the situation is somewhere in between.

Sami (36:43):

So whereas you have maybe very strong product vision, what you want to do, what the business is, et cetera. And so there, you have to have a core of the team that really understands what the vision is, and what's in scope, what is not in scope. And then build this particular investment area teams that then are getting a target, what to do so in that sense, maybe a little bit like what Supercell is doing, but with much more guidelines in terms of what is expected. So not completely self organized organization, like in the way of how he says how he is the least influential CEO. So you need in the operation, wherever you do need a top down guidance that, this is the playground, but then how you actually then organize the team where people are, how do you run the meetings, et cetera. Now that should be up to the team to decide how they work most effectively. So I guess, Whim they're somewhere in between these two models.

Marko (37:59):

Great, thank you for your insights and thank you for sharing your story.

Sami (38:04):

Thank you. Thanks for the opportunity.

Lauri (38:07):

That was it. You might now feel a sudden urge to do something similar. Here is how to get started. Read our blog post "Kick-starting Your Startup with Serverless" by Severi Haverila or download our DevOps For Executive's guide. Either way you won't go wrong. You can find links to both of them in the show notes. It's time to say until next time, take care of your self and keep building a strong product vision, and great teams.