Developing and Deploying a Platform that the Business Understands and Developers Actually Want

Be visible to management, talk to stakeholders and listen to their problems, make your value measurable with metrics like DORA, create narratives, and show the hidden pain to make it personal: these are lessons that Lucas Hornung and Christian Matthaei presented in Selling Flux the Human Way at KubeCon & CloudNativeCon Europe.

A lot of platform teams face a problem: they build a lot of really cool stuff, and then their developers don’t use it. Their team had been in that situation for a long time, and they managed to get out of it, as Hornung explained:

We turned a technical vision into something that the business understood and that developers wanted; it’s being rolled out business-wide, and we did it as engineers.

When his boss called to tell him he would quit, it became unclear whether his team could continue. Matthaei mentioned being asked to be visible and give a short presentation to management: who he was, and one important technical topic. He quoted Simon Sinek:

If you want people with no technical background to understand what you do, start with why. If you want people to do what you say, to follow what you say, or understand it, you need to be visible.

You can’t just expect people to magically discover how much better your solution is, Matthaei said. You need to talk to people and listen to them. They decided to set up meetings with stakeholders, explain their problems, ask for advice, and listen.

Hornung mentioned that in a business context, it’s important to make your value measurable. They started using DORA metrics and presenting them in their company.

You can have all the technical arguments you want, but if people don’t feel it, you’re on lost ground, Hornung mentioned. To connect with people emotionally, you need to involve them by creating narratives and telling stories, he added.

A lot of our developers genuinely didn’t think they had a problem, Hornung said, so they made it personal, showing the hidden pain:

What happens when Hans-Peter deploys manually on a Friday afternoon and On-call Olaf gets paged at 2 AM?

The shift wasn’t “GitOps is technically better”, it was “GitOps means I sleep through the night,” he mentioned.

Be visible, talk to people, make your value measurable, create narratives, and make people feel hidden pain, are the five lessons that Hornung and Matthaei presented. They are simple, but not easy, and they learned them the hard way. If you want to turn your technical vision into something that business understands and that developers actually want, stop showing people musical notes; instead, play the music, they concluded.

InfoQ interviewed Lucas Hornung and Christian Matthaei after their talk:

InfoQ: How have you used the DORA metrics, and what challenges did you face along the way?

Lucas Hornung: When we presented our first DORA numbers, heads went up, people started nodding. Then somebody asked, “What are our actual numbers?” And we didn’t have them. So we ran a pilot, measured 77% faster deployments, got buy-in — and then the numbers didn’t check out. Our measurement hadn’t captured hidden asynchronous processing in the full deployment chain. We had to own that publicly, but it taught us something crucial: numbers open doors, but they aren’t the whole story. We pivoted to narrative, and that’s when things really shifted.

Christian Matthaei: DORA gave us a seat at the table. It turned a technical discussion into a business one.

InfoQ: How did you involve your developers?

Matthaei: We initially tried to convince developers with pilot results and technical arguments, but that only got us so far. The breakthrough came when we started telling stories through relatable personas like Junior Dev Hans-Peter, On-call Olaf, and Feature-first Fiona, making hidden operational pain visible and tangible. Once developers could see their own experiences reflected in those stories, engagement and adoption increased significantly.

InfoQ: What have you learned?

Hornung: Technical adoption is a persuasion problem, not a technical one, and it can absolutely be driven by engineers. We had no product manager, no executive mandate. We also had a problem that a lot of platforms have; we had to sell in two directions: up to management in business language and across to developers by making pain tangible.

Nobody actually teaches platform engineers how to do this, and it isn’t even part of the job description in most cases. We borrowed from Sinek, Carnegie, Knaflic, and Collins and built an approach from scratch. If you’re an engineer struggling with adoption, technology is probably not your problem. But we are also here to tell you that it can be done.

Matthaei: The turning point for me was stepping out of my comfort zone as an engineer and learning to communicate in ways I was never trained for. It wasn’t natural, but it worked.