Hello and welcome to Becoming CTO Secrets, the podcast by CTOs for CTOs and those who still want to become one. I'm Philip Deutscher, external CTO, CTO coach, and founder of the Becoming CTO Community. My guest today is Daniel Krauss. He is the co-founder, CIO, and CHRO of Flix. That's the umbrella organization for brands like FlixBus and FlixTrain. Many people know it, and it's an exciting counterexample to the idea that a CTO always has to be the best programmer in the room. Today we're talking about organization, architecture, AI adoption, and the important question of why AI is much more than just an engineering topic. Daniel, welcome.
Philip, great that I get to be here. Nice to meet you.
Even more so. Daniel, you're officially — and now I'll quote LinkedIn — you've announced yourself as Chief Organizational Plumber. You're officially co-founder, you're the CIO, you're the CHRO. In my podcast we often talk about the CTO role. How would you describe your own role? Where is it perhaps bigger or even different from the classic CTO role or the classic CTO image?
You know, among the three of us I've always been the tech guy, and way back I was also officially CTO. Now, over time we kept growing, also inorganically — M&A topics — and in such a situation we once brought in an external CTO who wasn't part of the founding team, and at that point he already had to give up his C-level title because only founders had carried the C back then. And he was a great guy, a top CTO.
And then I thought, you know what, if I now take his title away and basically just formally reset him to VP Engineering, that felt like a crappy message to me. So I said, you know what, then this CTO title just won't exist at us anymore. And then I trimmed my own wings, so to speak, and from that point on I was CIO, because as I said, I would have found it inappropriate to say, you know, there are two CTOs and just because I happened to have the privilege of being a co-founder, you're now VP Engineering and I'm the boss. So I think we solved that very well in a Solomon-like way, and since then I've been CIO. And over time I also took on responsibility for the People function, and in the course of that I kept asking myself, what do you actually do all day? So the answer is, programming it certainly hasn't been for a long time, which from Flix's perspective is probably a good thing.
And I've actually been spending my whole day identifying challenges and removing them so that our team can act as quickly as possible. There are hundreds of brilliant people, right? And above all, I'm very proud of the Flix tech. Because I raised it with my own hands, so to speak, and I naturally have to make sure they can run as fast as possible. And then I thought, actually I feel like Luigi — and Luigi because Luigi is green, obviously a big advantage over Mario. And the result was that I'm basically the Chief Organizational Plumber. Andre finds it a bit silly, but I think it best describes what I do on a daily basis.
But that means the VP Engineering still reports to you, and you're then basically also the unofficial CTO, even if you don't officially have the role.
Yes, you could say that. Although we're much bigger now. That means the CTO role does exist at our company. Hanna Huber does that, and as you correctly say, she's one of my two directs. The other direct is our CRO, basically our People lead. And within the tech organization there are now several VP Engineerings. And unofficially, it's still the case that the big topics — when we talk about how we build our tech organization, how we build the architecture underlying our platform, and what big guiding principles we adopt to properly frame the almost daily technical decisions — I do still get involved in that, partly for fun, but also because I think I can still add more value there.
Very good. I actually sent out some little digital helpers beforehand — some people call them LLMs — to research you a bit. And one thing I noticed, they all consistently omit that you were once CTO of Flix. Even when I pushed back saying that can't be true, they maintained that there are no more traces of you ever having held that role.
Well, that's a question of how they look things up, right? There are people who document each step and change, for example on LinkedIn. I never did that. For me there's just a block of time listed, and I kept tweaking the title at the top. That means there are no steps that changed. So the way LLMs work, I can at least understand the answer.
Yes, exactly. If they only look there, but normally there should certainly be other publications where you were still listed as CTO from that time. So I was still somewhat surprised that it doesn't show up anymore, but then we're back to the point that we shouldn't trust everything we're presented with. By the way, not with employees either. But let's talk about the CTO role itself, because many developers have a very one-dimensional image of the CTO. I don't know if you've perceived that too from your time — best coder, deepest techie, or the highest escalation authority. What's wrong with that image from your perspective, or at least incomplete?
The escalation authority is indeed something that's part of the nature of the job, because the C comes with Chief, and my day is shaped by the fact that problems that can't be solved further by the organization end up on my desk, and that's okay.
But the best programmer I certainly can't be, because if you hold the C — whether through career or through founding — then you also need to be able, in my opinion, to build a very well-functioning organization, which in turn consists of people. And my goal from the beginning was always to find people for each activity, and there are many roles that are significantly better than I am. In classic engineering, I had to — and I even started with our first intern at the time, who's now a Principal with us — the people had to be better than me, because otherwise you end up with some kind of dwarf startup. And the consequence is that I'm now probably one of the worst, or maybe even the worst coder, which fits quite well, because coding was never what really gave me much joy.
And as for technical knowledge, it's always a question of context. In such a tech organization we have teams that deal with a product, or we have areas that deal with one side of the platform. And there we naturally have specialists who definitely know the details better than I do. But the big picture — where is the journey heading? Partly also with — you could call it information, but when I as a founder think about where we're leading the company together, it's not factual or technical information that I'm withholding, but simply what's in Jochen's and Andre's heads, right? That's what emerges there. But in day-to-day business I do have an information advantage, and translating this galaxy-spanning information advantage into technical thoughts that ultimately lead to an architecture, but above all to an organization that enables it — there's Conway's Law that binds both things together.
That's naturally something you need to be able to do as a C — as a CTO — but that's exactly where the rub is, as you said. A CTO must really understand the context of the business, because very few businesses are pure tech plays. We earn our money by transporting people, our customers, from A to B, and we do it better than everyone else with the help of tech. But I don't earn money directly with tech, and that's the case in many situations. And then as a CTO you especially need to have understood that context.
Right. And now that's obviously the attitude or opinion you've developed over the years. You told me in our pre-conversation that you used to tinker with computers very early on and enjoyed it, but programming itself — and you just said it again — never gave you the most joy. Nevertheless, that led to a path into a tech role. How does that come about? And did you also program at Flix yourself in the beginning, or were you from the start more in a business-type function?
At the very beginning I did do some, but mostly infrastructure-related, right? That was it. And maybe that connects back to way earlier, when we used to tinker with computers, when I was somehow working on graphics cards with a soldering iron, which was successful for a while. The stuff that blinks and so on — that always appealed to me. So this DevOps role was where I saw myself most, also not always super successfully.
Now I have to smile, some thoughts are coming up. We once had a one-euro promotion, and because we naturally expected traffic — and back then everything was still on Hetzner — I had to change something in the configuration. And well, in the end my wife picked me up and we didn't spend Friday afternoon at Tegernsee, but in the office, because the configuration wasn't exactly a success. So things like that — I was still deeply involved in those, and small things like that.
But the big things — early on I either brought in people I already knew and trusted, or worked with externals, which wasn't always successful, because during my studies — you know, programming is like learning a language, and I always had a challenge finding a very good way to translate my thoughts to the machine. But I also had the same challenge putting my thoughts on paper, right? Nowadays it works, you learn it all, but I wouldn't become a poet. And that's why it bored me relatively quickly, because I was so self-limited, and that stresses you out, and then you focus on other things. And you know, when you solve everything with for-loops, you also eventually know that you're not the best programmer on the planet.
On the other hand, the interplay of people and organization always fascinated me — whether it was as a sports coach in my youth or as a campsite supervisor, I always found it great to motivate and inspire people to work together on a bigger goal. And then I had the privilege of combining both, and made it through with sufficiently little hard programming.
And how much technical depth do you really need at the end of the day to lead a tech organization like yours? Where is solid technical understanding indispensable? Is it still needed, or do you say no, it's all just organization and business?
No, you definitely need it. And my answer is now — before the era of LLMs, where you can pull out almost everything except the hallucinations — it is important for two reasons. A) to be able to question decisions meaningfully and not always just ask 'why? Why?' like my four-year-old daughter. And B) to also have a bit of credibility, because as I said, you need to ensure you build an organization that ultimately follows you and says, okay, we'll do it this way because it makes sense and not just because the boss says so or out of principle or something, right? And then you need some street credit.
And especially when you're in the thick of daily business or facing the board — which we sometimes abbreviate — it's quite funny with us, because I'd immediately be called to order. I recently posted something about APIs because I actually just wanted to describe what our future very open architecture looks like. And then I got feedback right away, because they said that's not right — we switched to an event-based architecture a few years ago, with Kafka, and technically they are events and not APIs. And I said, okay, I know, and then it's quite good that you get feedback and B) are also called to order, but that you also understand all of it, because the people who work closely with Kafka immediately understood what I wanted, even if I described it content-wise incorrectly. But there are hundreds of other people who then say, oh no, maybe the time of events and Kafka is over now. If the old guy says we're doing it again more on the API level, then we'll just tinker around with things again.
And that's why it is, I believe, indispensable to at least know what you're talking about, especially regarding the fundamentals. And in particular, the same thing you just said becomes even more important in dealing with LLMs — to call them out, as you would say in poker, when they hallucinate. Or again, to be able to assess the results. And that's why, in my opinion, no matter how little I — when I'm occasionally in our Git repo, it's rare, but still — you naturally have to engage with how technologies evolve, right? So that in discussions, for example, about which model we use how, you can at least ask meaningful questions. I think you have to ensure that, and in a technical context those are often technically meaningful questions.
Yes. And on the other hand, especially in the LLM context, it's not just technical questions that arise, but also questions about costs, guardrails, data privacy, and so on. So also questions that can have a bigger business impact. And good to know and hear that you still have the aspiration to not just be present in these meetings but also to ask the right questions and not let yourself be bullshitted. I think that's also, in the context of other CTOs I talk to, a quality that even when you eventually say, yes, I no longer have the aspiration to understand everything in technical depth, but at a higher level — and I still want to be in the loop on that. And that's how I hear it from you, that you still practice it that way. Do you have an example of a bad decision from your CTO or CIO journey that shaped you? I mean, you just gave the example that you had a one-euro promotion and you sat there and couldn't deliver on the weekend, right? So if you ever committed something half-finished and closed your eyes, or if you just half-knowingly scribbled something into the configuration yourself because you thought it would hold, it would be fine.
Those aren't the things that in the early days — we had to rely on externals in one or two places, also in areas that were critical for us. And in our case, that's everything related to the core platform, pricing, sales, the way we plan our routes — those are things that are kind of the secret sauce, and making yourself dependent on third parties there is difficult. And the reason we did it back then and had to do it was also that I hesitated too long on decisions at the beginning. Tried a bit to the left, tried a bit to the right, maybe also started too big on some design questions — directly tried to paint a dream architecture, but you know, then it takes forever and in the end time ran out, then you had to deliver and then you just — so that means you had to hand the whole thing off to externals due to time constraints and gave things to nearshoring, offshoring, and they didn't deliver or didn't — well, what do you mean didn't deliver, right?
It's funny because if you really think about it, I didn't define a clean MVP at the beginning. It was all much too big and that led to me being close to the deadline and not being able to deliver it myself anymore. It's also naive to think an external can deliver. I mean, sure, you have more capacity, but you also have to brief them. You also have to define a clean MVP, because it's always a triangle, and then you have the additional dependency, and the others are building on something that you and your team should actually be building in your core area. So I had two or three situations where we had to free ourselves again, where I thought, you locked yourself in prison beforehand too, you could have solved that differently. And I believe the cause was, as I said, always not enough decisiveness and this tendency toward perfectionism, which techies also often have. I really want to build it beautifully, but in the end what matters is whether it runs and does what it's supposed to. In our case, at the very beginning, selling tickets. Yes, it's super simple. And it doesn't have to be the most beautiful piece of software the world has ever seen. Nobody cares.
Yes, you also said that larger tech roles consist of a lot of organizational building, perhaps even more so five years ago than now. What does that mean for you in such a large tech organization as yours, perhaps also looking at how it was in 2020/21 and what has changed since then. You certainly think differently about organizational building now than during the Corona period or before.
Yes, so — a) more isn't always better, and b) you tend to overshoot the target. And the question is always, when you look at your organization, where do bottlenecks arise — where does it get stuck? And that's frequently in a similar pattern regardless of organization size or structure, where the bottlenecks stand. And questioning and resolving that is, I believe, a recurring art. But of course, an organization changes globally. When we started, it was quite simple — back then we still had small servers, right? We were just moving from Hetzner toward the cloud, a different world.
And there was — I still remember — there was a backend team, then a frontend team, then a mobile team, and then an infra team. And we built it that way. And eventually they were all waiting for each other because nobody had end-to-end responsibility, and because nobody in that setup had any product, feature, or customer topic in mind. Because what is a Head of Backend — I mean, just the name alone, nobody cares.
So then we rebuilt for the first time and said, okay, how is our company structured? What domains does our company have? And then we built domain clusters. And that also triggered major rebuilds, because naturally, when someone is only responsible for the backend, the code that person builds looks different than when they're responsible for an entire feature or product. So we rebuilt quite a lot, which then also enabled us to set ourselves up in a more distributed way from a monolithic structure — which is perfectly fine, depending on the use case — because otherwise we wouldn't have been able to scale to that degree.
And then we had these domains, but then I noticed that the way our overall business was structured, it wasn't optimal anymore. That means I copied something into tech that was already suboptimal. And then I realized, actually my job is to look together with my business colleagues, with my co-founders and C-level, at what our operating model actually looks like. Because otherwise tech always lags behind in a suboptimal way.
Yes. And then at some point we actually — I mean, for us it's relatively simple. You could say it's a two-sided marketplace. That means I have a large area in the demand context, B2C, and then a large area in the supply context, B2B, all the partners and so on. And what has become much more important over time is this foundation area, which naturally includes DevOps and this whole cluster of stuff, but also a lot of enablement, which now becomes even more important because with this AI hype, even if it enables more and more people to somehow create things, to write code, who don't perfectly think about architecture and database design but just code something — you naturally have to contain that and at the same time enable it so that no crap comes out.
Yes. How do you currently recognize whether a team structure is good or bad, or how do you ensure that architecture decisions aren't made detached from the business model?
So the architecture decisions — we make those together. There's an Architecture Board at our company, where all the seasoned experts sit and provide fundamental guidelines. That's important because through this alignment you also create a certain cruising altitude where a large part of the daily prerequisites are discussed together, so you don't make micro-decisions that only produce a suboptimum.
And whether teams function well — I actually see that in a funny way now. Yes, you have the classic metrics like DORA or how many bugs they ship and how long it takes to fix them, etc. But my view over time has also shifted much more toward business. If a team is good, it creates real value. That means more revenue, more customers, or lower costs. And you notice it when people have an intrinsic interest in it, when even the Product Owner knows the P&L, where his products figure on the P&L. And also developers who question it — what does it actually cost and what does it bring? What's the ratio? When this contextual knowledge about the business and the numbers finds its way into a team, a real development agile team, then I know, ah, this is going in the right direction.
Can you always answer so clearly for a tech team that's responsible for a platform what value they deliver? Probably yes when they deploy a new feature, but when they take shortcuts to deliver certain things faster, the cost of that — that revenue maybe grows less quickly or even goes down — might only come in half a year or a year.
Yes, so on the one hand it's a question of how you define a customer. A customer can also be another team, and then the question is, do I make that team faster? Throughput time improvement. A classic example we always had — and it starts with transparency — we had a Foundation team that was responsible for Symfony when we were still on PHP, and we were on some Symfony version that was no longer supported. Everything probably full of security holes nowadays. And then it was said, we have to upgrade now, and of course it's expensive effort. But it wasn't listed anywhere. It wasn't on any roadmap, nowhere, because it was such a tech topic, tech foundation, whatever. I said no, I want this to be made transparent. I want to know the effort, and I want to know what you think the benefit is.
So as a CTO, what question did you ask the team before making such a big technical decision? Did you always directly ask what the value is, or what question did you ask?
Why are we doing this? And then you naturally get killer arguments like it won't be supported anymore, it's buggy, but then I say okay, but is it also faster? Do I get something for it? Is it somehow cheaper to operate because it needs fewer computers, whatsoever? So you have to ask the questions in a way that connects the technical benefit with — because you have to give people your way of thinking. That means, I had earlier — the definition of 'everyone knows that' and so-called common sense — that's only common sense if you've explained beforehand what common sense is. Not everyone has the same common sense. And then you have to tie the threads together, and I don't just let every killer argument — security is always such a trump card — go unchallenged, but you have to ask three or four questions, and then you notice that in good teams, as my grandma would say, the penny drops, and they start thinking about things more holistically.
Because in the end, the discussion about tech debt — we all have to pay taxes, it's like that — but you have to be aware of it and can't just accept it nonchalantly. That's too short-sighted for me.
Yes. Now Flix, viewed from the outside — and you said it too — is a mobility company. Internally, though, it's actually a massive travel tech platform. What is the technical core of what you build or provide that many people from the outside don't see at all or massively underestimate?
So, the technical core has at least three parts in my opinion. You could probably add a fourth. The obvious part is more or less classic e-commerce — we sell tickets.
The second part, the actual nucleus, is our inventory. Like in an online shop — if you find as much of what you want as possible in the online shop, it's normally relatively high up in the selection when you're thinking about what to buy, where to surf. So for us it's the collection and combination of all the destinations we offer, which then results in the timetable. How do you make it as clever as possible so you have high frequency, make it cost-efficient? How do you build our inventory, our timetable, optimally? And that's already very complicated in terms of optimization.
But it naturally gets even more complicated when your partner companies are locally present. I can't just move them around arbitrarily because they have a certain local gravity. The second thing is, we're always competing with the train, the car, sometimes the plane. That means you always have to set an optimal price point — what are people willing to pay for mobility and for the FlixBus or FlixTrain — and to figure that out, collect the data, process it, and decide as quickly as possible. Classic pricing, revenue management — that's the third elemental part. That's also the part where we started working with artificial intelligence in a technical context, classic machine learning, well before the current transformer hype.
And then there's the part that I've been treating a bit stepmotherly and unfairly — the operational part, because you mustn't forget that we have a fleet of several thousand vehicles that are on the road 24 hours a day all over the world — Chile, India, here — and I always want to be the first to know when something isn't working optimally. So this operational monitoring, fleet management, traffic control, and so on — that's basically the last part that I've, as I said, treated a bit unfairly.
What were some of the technical or organizational bets in the early Flix years that turned out to be the right milestones in hindsight?
When we did our first big M&A, putting FlixBus and MeinFernbus together, I looked at both systems and the MeinFernbus system seemed superior to me — better. And even though it obviously wasn't my system at that point, I decided to shut down the former Flix system, tell the team we're building something different now, and sometimes —
How much pushback did you get internally?
It was a positive surprise paired with a new mandate, so to speak. Not that much pushback, honestly, with the decision. We also started introducing Java as a major second language alongside PHP for the first time, which has now actually spread widely. And it was quite good that we already had such a long nucleus, because at some point in the enterprise area PHP reaches its limits, and I was quite glad we went straight to Java and didn't go super fancy with Ruby back then — oh God forbid, that would have probably cost me a lot of nerves.
In that period we also made really wrong decisions. We went with Angular because we thought it was hipper than React in the early days, if you remember.
That mistake was made by many.
Yes, exactly. That was all terrible. Where there's hewing, there's chips flying. As I said earlier, when we rebuilt the organization and the platform came under pressure, we did the decoupling with sidecar container systems. That's always only an 80% solution because you don't actually separate on all layers immediately — things still hang together at the database level. But it was good enough in terms of effort.
And then, funnily enough, sometimes you also need luck. We had very senior DevOps colleagues — great guy, Steffen — who started tinkering with Kubernetes, and we were relatively early on that, and that was a good decision. The containerization and then also a bit of the abstraction to the hypervisor level. And we had another colleague who also, funnily enough, almost more from a playful nature — we had RabbitMQ for a whole while, and then he started looking into Kafka. And we really had some pain at the beginning because there was still a lot of PHP and it all really creaked, but in hindsight, adopting Kafka early was also a good decision.
And that we really switched to the cloud, to AWS, very early on — that was also, I believe, a good decision, because otherwise Hetzner — great company, yes, Franke obviously — but that would have blown up in our faces. So looking back we made some good decisions, and that's roughly a summary of the ones that were important.
Where I hesitated a long time and we paid a lot of tuition was a bit the question of native or hybrid in the mobile context.
Yes, but by and large you've answered that. I honestly don't even know — are you going native?
Yes, I would say we're still largely going native. That's changed a bit with React now, but we haven't really gone big on Flutter or anything yet. With things like that, it's interesting — I have a feeling that bothers me. I don't want to say I have no good feeling or anything, but I have no feeling that bothers me. I'm now technically so far removed that I always think I know something or I read something, but at the same time you naturally can't annoy people with qualified or dangerous half-knowledge. So mobile, I believe, but I believe more should be possible with us — but believing, as the saying goes, means we don't know.
Yes. What about you — you've done a lot with internationalization, you've made acquisitions and worked with that. What is particularly difficult in the topic of cultural integration after an M&A, especially in your environment?
That depends. To reference my old MeinFernbus — I decided from that point on to really regularly, actually weekly, now every two weeks, be in Berlin. That was important to bind the cultures of Flix and MeinFernbus together — best of both worlds — but also to preserve both legacies together.
The cultural aspect is always relevant. In the case of Greyhound, it's 100 years and there's a different work culture in Texas. You have to approach it personally, and it's not about tech or not tech, but simply about finding things that connect you. And above all, not being arrogant or condescending about it. Technically, since my bus history, we don't integrate anything; we switch off and copy the reservations and customer data. And if we see that Greyhound has features that are important, we program them into our ecosystem, but we don't stitch things together. That doesn't work, in my experience.
But you also always have to be ready to learn. During COVID, we took over Kamil Koç in Turkey and weren't on the ground enough back then. We all remember that. We went live and I had a good feeling, but we hadn't understood how different the partner model of the Turks was, and there was quite a bit of feedback, and we had to work over Christmas. And now also in India, we're increasing our local tech footprint. Why? Because I believe we need to do more local for local, because our customers are simply used to something different. How the attack works, how transportation works down there. And you have to admit that either you engage much more with the Indian market and spend time in India, or you say, okay, I always have a capacity issue and need more resources, and then I have some Indian resources because they understand the market better.
If you think about Flix today, do you still see real startup DNA in the company? Or is it, I mean, that's what many founders mourn with a tear in their eye when their company gets bigger—the actual startup DNA, the drive, the agility. And the bigger the company gets, the more professional it might become, but also more sluggish. How much startup DNA is still in Flix from your perspective today?
The part about getting bigger and more sluggish if you do nothing, that's true. Period. I don't accept the tears, because especially the founders who are also competent in their target area—who else is going to change it? Nothing has ever changed from crying. You can shed a lot of tears. That means you have to be open and acknowledge that it's a fact, and then actively tackle it. And I do try to maintain this startup DNA in the sense that people are willing to take risks. They want to make decisions and not always CC 1,000 people and delegate everything upwards. Especially decisions, they take the accountability. That's something that is very important to us. And that's how we try to preserve the DNA. And you know, we had just before—well, it's been a year now—there were things, decisions were made and they struck me, and then you click on it and eventually it says, 'Yes, the C-level decided that.' Not only did I think, 'Oh, you should know that because you're part of the C-level,' but also, what is the C-level or the board, how abstract is that? Someone ultimately has to take accountability for a decision, and if it's a joint decision, then I expect everyone to take accountability, then you can also write a name down. If it was a disagree-commit, then ultimately the CEO, Andrej, takes the accountability. That's also okay, but some abstract entity... like the federal government said, 'Yes, who was that? Which department decided?' Someone has to take responsibility for it, and that might be a bit more difficult in politics in a coalition. In a company, especially in a founder-led company, it's very simple. You just have to want to.
Yes, absolutely. What was the most important factor for your success in retrospect? Was it something like the early M&A you did? Was it technology? Were you just at the right place at the right time? Was it the business model? Or can you not really separate it? Or what do you think?
I believe so. I think serendipity, timing, right time, right place were certainly decisive, but then the execution, the unconditional will to win, the love of competition, really taking on the challenge, is key. The fact that I was part of the founding team as a techie, and also in the beginning, when it was tough, how often Oechsle and I discussed things, because you know how it is, tech always takes a bit longer, gets a bit more expensive, and an external CTO, if it doesn't fit, you can also put on the street. So we had to deal with it because I was just around. And then I believe the fact that I might not be the best in individual areas—we talked about programming at the beginning—but by always having to stay open for the best possible feedback, and that leads, I believe, to better technical decisions. And that's why I'm particularly proud that in all these 15 years—and you can ask Claude or the LLM of your choice—we have never had significant downtime. Ever. Actually.
Okay, I find that somewhat surprising, but very good. I've never managed that before. In none of the companies I was in was there ever no significant downtime. Hopefully that wasn't because of me. But anyway. You formulated a clear thesis in our pre-interview, but you said the bigger impact isn't just in developer productivity, but in business functions. What did you mean by that?
Well, of course, developers, especially when it comes to repetitive tasks, get incredibly faster with a lot of support, and of course, you can significantly boost productivity there. But if you look at the complexity in processes in companies, it grows through the processes, because you have a lot of matrix, because you have cross-functional areas, then I do have the impression that AI helps a lot with all the business functions. And because it now works with language and not like RPA and UML as notation and everything very formal, anyone can now put everything they have in their head onto paper with the help of LLMs. That's a huge benefit, and the leverage is, in my opinion, greater in the business. And the way of working, but also the awareness of how technology works, down to the costs of tokens, that's something that I have the impression is coming more into the awareness of the business colleagues and must come, than with the techies. With the techies, I have the impression there's more hesitation, because this special quality, this creative aspect you had as a developer, seems to be being improved by LLMs, which I don't believe at all. I always say, we have Makita tools in the basement without end. And technically, I would be able to build a house. I would be the last person to move into a house I built myself. I'd call a craftsman who can do something with this Makita stuff. Except for hanging pictures, that's where it stops. Although I could actually buy everything from IKEA or at the hardware store of your choice. So, you understand what I mean? That means, I understand the insecurity, but I believe the top people will survive and become even better. But I believe the interesting learning is much more now with the non-tech colleagues.
What is your adoption like right now, especially in engineering?
Engineering is well over 90%. We mainly use Claude Code. We rolled out Claude Cowork to the entire company a few weeks ago. So that's really taking off now. In the beginning, everyone worked with Claude, the chatbot, or Copilot, or also internally FlixGPT. But that's something else entirely when you have the toolchain, and Anthropic has done a really good job with Cowork for the business colleagues as well.
Do you see higher adoption in tech than, for example, in the rest of the company in the headquarters?
