Host Intro (Gene Kim)

In 2022, Daimler Truck was spun off from Mercedes-Benz to become the world's largest independent truck and bus manufacturer. This separation opened the door to creating a modern development environment, emphasizing developer experience and adopting a DevOps culture.

This next experience report is from Michael Vormittag, Head of SAP Delivery, Architecture, Analytics and the CTO Office of Daimler Truck. He'll be co-presenting with Marko Klemetti, CTO of Eficode. They will describe a unified developer platform called the Truck Toolchain, or T3. This platform is designed to enhance developer experience and pave the way for future technical innovations, including GenAI-based tooling.

They will describe the process of a massive separation of a business unit, including its R&D and developer tooling components, and lessons learned for any organization currently developing or enhancing its own developer platform. So here are Michael and Marko. We can see you just fine, and we can see your slides.

Marko Klemetti

Oh, fantastic. Hello?

Host Intro (Gene Kim)

And we can hear you. Thank you.

Marko Klemetti

Super. Hello to everybody. So cool to be here. My name is Marko Klemetti, and today we're going to be talking about a story: how an organizational change leads to changing technology, and how enhancing technology then forces changes in the organization.

With me, I have...

Michael Vormittag

Yeah, my name is Michael, or Michel in German, from Daimler Truck. Gene introduced us already.

Marko Klemetti

Just a very brief introduction into the company. I'm the CTO of Eficode. Eficode is a global DevOps consultancy organization, 600 professionals. We're mostly in Europe and the U.S., and we work together with roughly 1,600 clients worldwide doing things like what we speak about today.

Michael Vormittag

And Daimler Truck: as also introduced, we are a commercial vehicle manufacturer, one of the biggest in the world. We have, even after the spin-out of the Daimler company and separating from our sister company, basically Mercedes-Benz, still over 100,000 employees worldwide. We produce in 45 production sites globally. We have a combined history of 127 years with our ex-partners at Mercedes-Benz, basically when we started inventing the first truck. At least that's what we claim.

We are here in a way forging a new company, but still being a very old one. A lot of transformation is going on, and we will also be talking a lot about transformation. One thing we won't focus so much on today is the whole zero-emission transformation we are doing, but I just listed it here because it's definitely a big thing in our industry.

We are moving from the combustion engine to zero-emission vehicles, whether that is battery electric vehicles, hydrogen vehicles, all sorts of different products in different markets. We already have 10 of those in series production. So a lot of change is happening in a lot of countries.

Today I want to specifically look into how this change actually leads to change in technology. As Gene was saying, Daimler Truck and Mercedes-Benz split into two totally independent companies. We were before a huge company of about 300,000 employees. We are still a huge company of about 100,000 employees, but we are separating all the functions.

As you can imagine, there are probably some things which are relatively easy to separate. Building a truck is done in a facility to build trucks. If you split the companies, it's not so difficult because they have been building trucks all the time, and the other facility has been building cars all the time.

But everything we do and what we are going to talk about is actually quite different. All the central functions, the ones that provide enterprise solutions for the organization and global tooling for the organization, stayed with the old company. So we are currently in an interesting and unique opportunity to build all of that stuff anew.

Of course, this means a lot of change, especially in IT: how we can use this opportunity of organizational change and then actually transform it into technology impact, technology change for the better. Using this in a way as a startup opportunity in this large ship, basically, to move it into a prominent and productive future.

So the question we want to talk about is how this organizational change can actually amplify a technology transformation.

I want to give you a target. One of the dimensions we wanted to look into is how we can actually use this change to reduce our application landscape. Because as we are a big company, and most big companies which are long-term on the road tend to add applications and applications. We are big. I told you we have 45 sites. We had even more before. We have different regions, different countries, so there are applications all over the way.

One of the targets we had in the company to use that organizational change, and of course the more limited personnel we have, and the newfound opportunity to build new central structures, was that we said we want to cut down our application portfolio by 40% to be a leaner, more efficient organization. We are already there, even though we still have about a year or so to be 100% separated from Mercedes-Benz. We are already reaching these 40% and will probably overachieve.

There is a huge opportunity, and we are very happy in hindsight to do this move of separating from our old parent company and really having a way more lean and more consolidated and effective application portfolio.

One of the topics I would like to talk about today is especially the tools, the DevOps toolchain landscape.

In the past we had a lot of toolchains, to be fair. I made it a bit abstract in our slides here, but just for you to understand, and I think a couple of people who are in bigger organizations might understand and relate: you have big organizations. Our research and development organization in the past was thousands of people, so they decided they needed a toolchain for their tooling to build things for the cars and the trucks.

Already here we have different organizations. Then, as these organizations are thousands of people, they decided maybe we need two different toolchains because there are different things: something more cloud-based, something more on-premise-based. So you end up in different toolchains.

Then other organizational parts realized, this is so customized, what the people over there in research and development did, and it's actually so far away in the organization that, for example, I need to build my own Confluence. So they built their own Atlassian stack and realized it works because it's maybe less customized.

But then at some point, and I think a lot of people can also relate to this, the person who did it leaves the company. Then you end up having a more or less maintained infrastructure, with maybe no migration concept at some point if you realize that maybe it makes sense not to have 50 different installations of the same tool going on.

All these things happened in the past, and we had a variety of toolchains. We used the Daimler Truck transformation as one of the opportunities to centralize the toolchain. I am not saying we are 100% there, but what we are aiming for is to consolidate all this into one toolchain, which has a set of tools.

It doesn't have all the tools everyone requires. That is also a fact. But it tries to have the big ones in place so that we build a foundation for whoever, no matter in which part of the organization, is actually leveraging the right thing at a cost-efficient and manageable scale. Then we won't run into the issue that you have something productive and relevant that is only maintained, or you don't really have a feeling on how it is actually going into migration if you need it.

This is what we're currently doing. Looking forward, of course, that's not the end. It doesn't stick with exactly this tooling, even though some of them are important and some will be long term. The tool landscape is changing, especially now if you think about AI. A lot of tooling comes into place.

The question has to be: what do we need to provide to our organization? Our vision is: be clear, be foundational, but also be dynamic. We need to adjust this. This is not easy for a large company. Some of you might relate to building this paved road for the company, building this foundation, and building processes for how you interact with it, interchange tools, and make sure everyone in the company has something they can use.

I hand over to you.

Marko Klemetti

As we've seen with Daimler, the lessons learned are something we've seen along the organizations working to build the future of software development, being the leaders in the market. There are four key areas that organizations need to pay attention to.

The first one, of course, is business agility, where everything started here in Daimler. It was the carve-out from another business, but it could also be something when you are going beyond SAFe in your organization. We already today had a presentation of the Spotify model. You might be going toward stream-aligned teams and using Team Topologies, for example, to do that.

The key of business agility is not only to think about your teams or the R&D, but aligning the whole organization to your value streams.

The second one, as said, is consolidated toolchains, which started from the abundance of DevOps tools emerging for the last 15 years, and also the fact that shadow IT means there are tools hidden in the organization that are maintained by someone and used by many, and you don't have exact knowledge about this.

But then also it includes platform engineering. It includes building the developer experience, but it's not just limited there. It's more than just that: to build the consolidation in the toolchains and align it to your business strategies.

The third one, which I today call the DevOps safety net because it gives an idea of what it means, is the healthy DevOps culture and extensive automation, as we already know; quality assurance; security; and for companies such as Daimler, building compliance into the automation and the continuous cycle.

It also gives you the feeling of security that when you're implementing new features, and as the fourth one you're implementing, for example, AI-driven tooling or AI-driven development in your organization, you know that everything is still working as expected.

That's kind of the key to building an organization that is functioning and being fast when the value stream changes or there are changes in the technology.

We want to share a few words also about AI because it's a focal thing in everything that's happening for Daimler. It started from the organizational change, run by the change in the toolchain and consolidating that, but also all of the challenges that come from how the market is changing.

I'm quite sure you don't know this, but punch cards, the ones we fed to a computer back in the day, were already invented in 1725 in Lyon, France. They were used for a device called a loom, a device which weaves cloth. It showed or created the pattern in the cloth.

Punch cards, in a way, have been our way of using computer language to tell the computers what the computers should be doing. But now, with the emergence of generative AI and AI tooling such as GitHub's and GitLab's tooling that you would use on your daily basis, we already see that in the future looms a time when we use natural language, our language, to tell the computers what the computers should be doing.

Daimler, as a big organization, will be seeing soon Adobe talking about the same topic more extensively, but in Daimler it's also interesting how AI is put into place because it's such a big change, and it's gradual in what's going to happen.

Michael Vormittag

Yes. Thank you. Our perspective here, on the one hand, is with the change of technology. We are looking into AI-driven tooling. We will look into a variety of different things we need to consider.

One of the main drivers for me, or one of the main changes I see here in this transition to agile, is that we started with the organization change, and now we're looking into a technology change to continue the cycle. We're really looking into something that applies to way more people than before.

Everyone who is developing code will be somewhat AI-enhanced, but not only them. Also everyone who is doing any task in business is actually in the future AI-enhanced. If we think about the tooling and what we need, I think it's very important that larger companies think about how we actually control this, how we govern this, and how we set the right things in motion so that we fulfill what we think makes sense for us for safety, compliance, security, and social or ethical behavior.

That's why I believe every company like ours, and that's our approach moving forward, needs to at least build something like a minimal viable governance around AI. I call it minimal viable because I know that companies like ours, and I'm pretty sure a couple of people here can relate, if you talk governance, it's very easy to...

Before, on the DevOps safety net: big companies tend to build a very strong safety net. That's a risk. We want to be fast, especially if we talk DevOps. We want to have control, we want to be fast, and we want to be productive and effective in what we do. Everything we need to do in these controls needs to be not too much, but also not too little.

For example, what we need to look into is how use cases are developed. Is there any ethical consideration I need to do on a use case? In many cases, maybe not, and then it has to go smoothly through a system. But maybe in some cases it actually has implications. Those things have to be looked at.

You also need to be clear as a big company: I don't want everyone to use every AI tooling. I should know what it does, where it's trained from, and what's behind the scenes on it. I need to have some sort of central control over these things, and I need to check what the legal requirements are in different regions.

We don't want to make it too extensive. We want to make just a small grasp of this challenge that we have. We have a challenge to manage this organization, to manage the organization in a way that it can actually handle this transformation properly. That's super critical for us: to balance what the organization has to do and what the tools actually can deliver.

With this, we in a way close the cycle of these three things we have here. We have the construct we build as a company around AI, but on top of this, it's not only what we build around AI, but also the AI itself. That's also a claim, and that's why we call this section: AI to development is like agile to waterfall.

Marko Klemetti

It'll change the organization. It's not just that I put a tool in place; it actually has to change the way we do development. If I use an exaggerated example I use very often: if your value stream is here and only 5% of that value stream is the actual software development that we today know is mostly impacted by AI tooling, and you improve the software development by 50%, you only do 2.5% impact on your whole value stream.

Michael Vormittag

Totally. We believe, to close the circle, that this transformation will lead to a transformation in software development, once on the governance side of a company, which I talked about, but also in the very way of how we do development as software engineers. I don't think it has been explored yet.

That's also an ask we have to the audience after. I think it's a very interesting theme: how is software development actually going to be changed at scale? Will we be looking into a manifesto of generative co-development for how we actually should build software in the future? How does the organization have to behave to be capable of dealing with this? How do the roles have to be changed? Will there be AI refactoring, hardening sprints, documentation sprints, or whatever?

Marko Klemetti

Or do we have formal verification such as in aviation or in the medical industry, where you create formal verification and a program emerges from that? We don't know. That's our ask for the audience as well, starting the discussion from there.

It's not even looking too far in the future, because I think the reality is now for this. If you look in the future and we actually have certain functions which are provided automatically by an LLM backend, then things will change again. But even now, I think it's a super interesting topic to discuss.

Michael Vormittag

I think we made it on point for 20 minutes. It was a pleasure being here. Thanks for hosting us.

Host Outro (Gene Kim)

Fantastic. Thank you, Michael and Marko.