Markus Lorenz
Welcome to a new episode of the beCommerce podcast. As you know, we've rebranded our podcast to address more topics in the e Commerce Industry and our today's guest fits perfectly in that shape. Please welcome Oliver Thylman. Oliver is co-founder of Giant Swarm. And I would definitely call him a serial entrepreneur. Giant Swarm is providing a full service container platform with a special focus on micro services, which is basically built for developers and through their flexible setup, they can attach any storage back-end, you might have give a full automated Kubernetes infrastructure, or other toolings around running microservices on top of the stack. Very cool. But Oliver, please introduce yourself, the company, please tell us why your Twitter profile says you're a developer whisperer.
Oliver Thylman
Hi, thanks for having me. First of all, it's wonderful to be here. Yeah, so me, Giant Swarm. I actually started in this internet business at the end of the 90s. Like the first internet bubble, internet statistics and lots of different things. Actually, I actually did SEM before it was called SEM and bid on, on Go To and other things. So really been in this entire thing early, very early, built several companies in the advertising space. Also. Retargeting, which is where the Ecommerce part also comes in, obviously, always explained to people that ad cloud, the company I previously was one of those companies that made the shoes follow you around on the internet. So that's always my explanation of what we did there. And now we actually to a certain extent, again, in the E commerce market, so Giant Swarm is now, seven years old, fully distributed, fully remote. We built the stack, we wanted to have our own company, while we looked for something else to do after we sold the last one to Deutsche Post DHL in 2011. And left at Cloud in 2013. Really looked around, looked at lots of different things, built what we have now on the side while building a nonprofit. And other companies wanted to have it too. Because in the end, what we figured is that microservices is the correct trend. Developer led enterprise is a trend that is happening. API driven infrastructure is a trend. And with Kubernetes, as a base building block in the entire thing, we see that there is a very good abstraction layer in the sense that developers build software and deploy it through cubic meters. And somebody else manages that platform, which is why we provide it a fully managed service and have built ourselves a platform that allows us to manage hundreds of Kubernetes clusters with lots of different tools. And be it just a monitoring stack or be it a database, all the things that we manage for our customers. And do that at scale for especially bigger customers. Examples would be Deutsche Telekom. Adidas the entire ecommerce backend of Adidas. So I know ecommerce and the importance of not having downtimes, Shutterstock in the US and many others. But it's always big commercial toolings, Klingele is another one that runs the many, many different web properties through us, where they all figured that Kubernetes is not a core competence. And hence they said, well, Giant Swarm should help us handle that and just give us more speed and more reliability.
Markus Lorenz
That's super interesting. Oliver. So you mentioned a stack of customers, which is very impressive from my perspective. And also you mentioned during your conversation, one other important topic from my perspective, which is the people that you're completely remote. And maybe we figure out today, those two dimensions, people and customers, and why people are happy working at Giant Swarm and what makes your customers happy in the end. Because I know that your Chief Customer Officer at Giant Swarm, so you're the CCO and maybe the audience is not very familiar with that wording CCO. Maybe you can introduce a little bit the duties of the CCO. What is your purpose at tGiant Swarm?
Oliver Thylman
Actually, I always tend to say I'm responsible for all our customers when they're there. I'm not I'm not there for the acquisition of new customers. Therefore taking care of our customers are happy and are using the platform as optimally as possible. And that really means running our account engineering and solution architecture, part of the company. So to explain that a bit, we have account engineers that are responsible for customers and that just take care of their needs. And solution architects that are sitting inside the different teams. So we have a team around AWS, a team around Azure, a team around managed apps, a team around monitoring, and so on and so forth. And the solution architects sit in those teams and other specialists for the subjects and get pulled in by the account engineers into the customer meetings we have. And we have weekly, or even sometimes weekly meetings with customers. And really, not only run the infrastructure for them, but also help them to get into this cloud native micro service way of working, agile way of working.
Markus Lorenz
Okay, super cool. So that means if you're responsible for that dimension, on the customer side, what is important for you, in general, to to make your customers happy, because in the end, you have very big logos on your side, and what is important for you as a CCO to keep them happy, and which services maybe from your side, make them happy.
Oliver Thylman
I think one thing we're focusing on is very transparent and open communications, we make clear from the beginning that we're in this together, and we need to walk the path together. It's not about a certain goal, it's about having an enjoyable time while doing it. And that open communication is, I think, the biggest distinguishing factor. We don't shy away from saying it's our fault. We don't shy away from saying it's your fault. Without fault, being a blaming system, but about just figuring out what we need to improve. And I think that's the crucial thing that we really, we really believe in agile in the fact that it's build, measure, learn, and iterate and iterate quickly. And that's the important part, I think. And that's what makes customers happy that it's so different. It's not a, you issue a ticket here, and then join from start to work and throw the issue back, and so on and so forth. And it goes as far as like, like, how do I? How do I make sure that customers are happy first, first, we talked to them weekly. So we kind of know like we ask, are you happy to a certain extent. And we sometimes have very, very close relationships, we have shared spaces and houses at conferences with customers. By now we have monthly meetings, we started having monthly remote meetings with customers, where we ship around beers or wines or cocktails and have customers hold talks like we don't. We don't talk, we talk. I'm moderating the entire event, but its customers are talking about subjects that are relevant for them. And then we have an interaction between customers, we really connect with customers a lot to make sure that they talk to each other because I mean, I can have a suggestion on security tooling. But it's a lot better for different customers to talk about their experience with different security toolings. And to grow together because they actually like they actually can talk openly. And they figure that out in those meetings that were actually very frank and open. And try to share and try to make sure that these are the problems we still have that we need to overcome. And we're not saying oh, that doesn't exist, and we don't want to talk about it. So now I think that's important.
Markus Lorenz
Super cool. So open and honest conversations with the customers from what I get is important for you over having racy metrics, and contract details. Let’s totally underline that. And basically important for the collaboration with the customer. And how are you managing the customer happiness, are you choosing an NPS tools or other tools?
Oliver Thylman
Do I have the discussion often? I don't have NPS or anything else we don't like discussing from time to time if we need some kind of tooling. But at the moment we don't, we don't have that many customers. And my goal is to really know them and for the account engineers to really know them and to create an atmosphere where they will say if they don't like something and I can really understand. I don't care for a 9 or a 10, you know, and we had that from time to time. And then you get back at nine and it says, yeah, because you don't give it 10. Like, okay. So it's really, it's, again, that open communion, I want to know them and do it like that.
Markus Lorenz
Yeah, got it. It was just referencing that measure of thing. And I was interested in how you're doing that. But if you're not that broad scape of customers, and you're really looking for a special one, then this approach fits totally from our perspective. So from your perspective, as a CCO Why are customers not happy with their suppliers, especially in the tech industry, when it comes to service offerings from tech vendors or agencies?
Oliver Thylman
That's a hard one way or the other. I think I can say why we're different. For example, if there's a P1 issue, and if something really happens, the message goes directly to one of the core engineers that built one of those systems, like we breathe DevOps, we built that platform, and we manage that platform. And we really think about it. And it's the same thing in the other direction. Like, it's not only if you build it, you run it, if you run it, you need to have built it. And it pings directly the person that has built it, we don't don't ping some kind of level one, whatever, support engineer that has a list of questions to go to, and then escalate later. And I think that's a big difference. We have a hard time explaining why our management managed Kubernetes, sometimes different now, because like you have AWS has managed Kubernetes. The big difference is, we have managed Kubernetes, in the sense that we have dedicated people managing it and helping you and telling you what to change on your end and changing stuff on our end and working together to make it into a reliable solution. Manage Kubernetes on AWS, as a managed master that's actually at the rescue still needs to build up. For us, it's you press a button and the clusters with toolings in it, and monitoring in it, and so on and so forth. And it's being monitored by people, and so on and so forth. So I think that's a big difference. And I think we have that engineering mindset. Like it's not, it's really we're getting better by the minute. We're telling you when something is wrong, and we're improving it. And we have to develop a mindset that we need to get that together with you bit by bit. And we need to know what we're talking about. And we get questions, and we have a real engineer answering. Yeah, that's the important part that you don't get, let me ask somebody that you get a real answer quickly.
Markus Lorenz
Yeah, that's super cool. So that's more an engineering approach rather than a sales approach, which you mentioned. And this also leads me to my next question, because you mentioned beforehand that you're not taking care about sales from your side. From observation, it's crucial to understand within the sales phase, the customer so understanding customer really deep and the first phase of the collaboration, and how do we ensure on time swamp side that you get the customer needs and a complex ecosystem so that you are deeply understand what are their pain points, and how you solve it, because from my observation, sometimes you have sales guys on the market, who are just over promising and don't understand really the business needs and how they transfer to into technical requirements. So how you ensure that
Oliver Thylman
Well, first of all, I think we have good salespeople of course, costs and buzzword bingo, consultative selling, like we can't just go in any way and say like, this is the solution. That doesn't work. And once we're at a certain stage with a customer, the account engineer starts joining the calls. So we'll figure out who's the account engineer that has a fitting customer profile, where they can start telling stories from other customers that fit the solution that the new customers are looking for. We get so to a certain extent, these accounting leaders are a bit of pre-sales to a certain extent also, the pre-sales engineer that how they are sometimes called we're trying to create that mix and not have it too far split. It's just, I mean many of those calls too. It's just that it's not my responsibility. To drive that sales path forward, which is again, a totally different game and about, like, Okay, how do you get that funnel going? And how? How do we make it repeatable? And so on and so forth. I like relationships, and the relationship isn't there at the beginning. So there, we have to figure out how to make that. To create that. Another thing we often do is we just connect them with customers early on, we just say, Okay you seem to be very simple, similar to customer x, we have had a chat. And when they come back, I want the same thing as that customer. It's a lot more convincing that a customer tells them what they like about JSON than me saying, I think we're good.
Markus Lorenz
So we're back on that open communication, which you will figure out firsthand. And for me, also, listening to clients is important because you improve the competitiveness of your current services, you learn something new about your services, maybe where you have to add something, you also identify your opportunities to develop new services. So that means if a customer comes up with a new problem as a service company, you said, Oh, shit, maybe we don't have that service right now. But it sounds interesting. So let's do it together. And if you don't avoid feedback from your clients, because you learn, and then then you're basically a more effective competitor, you know?
Oliver Thylman
Yeah, and especially, I think, I think the important part is, as you said, listening, and I always joke about this. I was called by one of the big ones out there recently, and the first thing that sales guy said, so what are your problems? That's not listening. Like, yeah, that's the standard, you don't freaking care. You know, you need to really listen and make sure you have empathy. And then people start talking to me, because you really care. And then you figure out other things. And no, okay, well, this Manage Communities might not be the first step, but you actually need a few apps in there. But we have three of the five apps you need and the others might be coming. So can we start? Do we start with a trade like, this isn't a clear path, this is a za service, you sign up with your credit card with? Yeah, well complicated,
Markus Lorenz
It’s about that, that you give more than you would would expect in the first phase, I would say because then you're on the point where the customer in the end, and also observed that when it comes to a later on to the collaboration with the clients, you have this two dimensions, the work of service was the quality of service. And in my opinion, there's a huge difference between the quality of the work and the quality of the service. And so only when a service and the work from the service of the company is percept. Well, from the client, you did your job well. So how you measure are managed your quality of service, because it sounds like that you're doing amazing quality of service, you know.
Oliver Thylman
Yeah, but we have the same problem as a security tool, like we suck if it breaks, and otherwise, you just don't notice. We have very few downtimes. And we have a lot of alerts that are coming in that we fixed without ever telling the customer. And we're trying to, again, make them transparent as possible and just show customers what we're doing. Yeah. Because many of these things are proactive, like we get alerts before it breaks on their side, and we fix it before it breaks. And that is what we're trying to show. But it just involves a lot of statistics, you know, just turn them. These are the number of alerts and excel explaining, we want alerts to happen. Like it's not that zero alerts are good. Zero is not good. We'd like to miss something. And we want lots of messages in Slack with our customers. So they asked lots of questions. If they don't ask questions, we see a problem. Because they don't develop further. We just want to be sure that they understand that we're actually doing something, because otherwise the quality of service is great. Like stop running. And fast. The problem is rather that it's so good that they stopped coming to the meetings and stopped coming to Slack because it just runs and then we start seeing a problem because then it's just it's not that it's too good. It's that they don't notice anymore. And then make sure I got got that point
Markus Lorenz
Interesting. What is about your employees on Giant Swarm, so I perceive the following when it comes to service companies. You have to train your employees in a way that they are realizing how to get this customer satisfied and to get rid of this “hey, this is not my term or this is not my responsibility”. “This is a different department” and so on and so forth. So how you are engaging your own employees regarding customer satisfaction and make them aware of that the customer satisfaction is the one of the most priority or that most priorities you have on the company.
Oliver Thylman
Two things. First of all, it's onboarding. Like we make sure they join us in, in meetings and figure out how we talk to the customer. Because how we talk to the customer, as I said, is probably very different. A lot more frank and a lot more open and a lot more direct. Where others like, what did you just tell? Like, we always give the example. We had a guy that got a request from a customer at like, 1837 o'clock in the evening. Like, like, Can we still do this? And, and, and one of the solution architects, like, messaged me, like, Okay, I really haven't eaten yet. And I need to eat something, because it's really late here. Because there's a time difference and stuff and like, what do I do? Tell the customer that you're currently hungry, and that you need to eat something? And if it can wait for tomorrow? Because then yeah, sure, it can wait, nope, no problem, thanks for telling me the reason is, it just works very well. The other thing is, as much as the customer is the most important one, there are other things that are more important. We always, we always say like, first of all, our people are most important. Because happy people build a good product. And the good product leads to happy customers, happy customers does, like doesn't, it doesn't work from that setting. So it's really like us, we make sure our people are happy, and we make sure they can say anything to the customer. And we have that back. Like, I delegated a job to you. So like if you screw up, it's my fault, you know, yeah, got it. Um, we need to make sure they feel secure, that I might rip their head off in a private meeting afterwards, but towards the customer, I will never know. And, that security is important. So they can have that honest conversation. And I think if you make sure they understand that they just need to answer honestly, then the customer is satisfied with getting an honest real answer. And all things come by themselves.
Markus Lorenz
Cool. Yeah. absolutely interesting. Maybe we switch to that second part of the interview today, because we're actually deeply involved with your employees. And I really like that methodology to say happy people will or a good product will be followed by happy people, which you mentioned