From “No Time for GitOps” to Enterprise Adoption: Selling Flux... Lucas Hornung & Christian Matthaei

In this talk, Lucas Hornung and Christian Mate from Chebo's platform team discuss challenges faced by platform teams when their innovations go unnoticed by developers. They share insights on transforming technical visions into concepts that resonate with business needs and gain developer interest. The session highlights the importance of visibility, communication with stakeholders, and measuring value effectively. They identify five key lessons: being visible, engaging in conversations, making value measurable, creating compelling narratives, and making people feel the hidden pains associated with current processes. By employing these strategies, the team successfully promoted tools like Flux within their organization and fostered improved collaboration.

Hi everyone, my name is Lucas Hornong. This is my colleague Christian Mate and our team is right here in the first row. Great to have you guys. And we are the platform team that keeps Chebo's web shop alive. It's our job to not only manage the infrastructure but to enable developers to work with less problems faster and with less complexity and still in a stable and secure

manner. Our cluster runs on Kubernetes. We manage our Google Cloud infrastructure with Terraform and we use Flux to manage our cluster. That being said, this isn't a GitOps tutorial. In fact, we'll barely talk about GitOps today. What this session is about instead is a problem that a lot of platform teams appear to have, which is that they build a lot of really cool stuff and then their

developers don't use it. And this team has been in that situation for a long time. And we managed to get out of it. And this is the story how we did that. How we turned a technical vision into something that business understood and that developers actually wanted and that's now being rolled out businesswide. And we did all of this as engineers. We'll share some lessons about that

that we learned along the way. And um all of them are simple but not easy. And especially as engineers, we have to learn them the hard way. Now, when people ask me who or what is Chebo? Quick show of hands, by the way. Who here knows Cheibo? Nice. Okay. I don't think we have physical stores in Amsterdam, so this is cool. I find though that it's best

to ask a German on Reddit. And as it so happens, I have a German right here with me who can tell us. What a coincidence, right? I'm a German and I also have a German girlfriend. And if I asked her, her answer would be this. Let me read this out loud for the audience in the last row. Yeah. Nobody knows. They just are. And we are just

as baffled as you. When I was young, they sold coffee and then one day I was buying half of my bras, excuse me, clothes from them. And what should I say? It is exactly it. But Lucas, what's the real deal with Chibo? Tell us. I'm glad you asked. If you look at this picture and you're thinking that looks like a traditional German coffee company, you'd be right

because Chebo is in fact a traditional German coffee company that happens to sell a lot of other stuff too. In a nutshell, it's the kind of store that you go to when you need coffee, clothes, but also an inflatable paddle boat. And since not everyone buys their goods in an offline store these days, it also just so happens to run one of the top e-commerce businesses in

Germany. And it's important to point out that this company started in the 1950s by selling coffee via physical mail. And that gap between selling coffee via physical mail and running a pretty large e-commerce business, that's what we're bridging here at Shibo Tech at times. So it was 2025, pretty early in the year, and I was on holiday with my family in Malaysia. Very nice country, great beaches,

you know, enjoying life. and I get a call from my boss and this guy never calls during holidays, right? So, I'm like, "Okay, that can't be good." And in fact, he calls me, we sit down, we have a video chat, and he tells me, "I quit." And that's my actual face in because we had been trying to roll out GitOps companywide for years. And I didn't know

if that initiative had come to an end. Now that our boss was leaving and I didn't even know if my team was going to exist when I come back because it happens you know when when leadership quits sometimes the team dissolves. We've all seen it. Luckily for us though once again I have somebody who was on the ground in Hamburg and who can tell us exactly what

happened. Yeah. Meanwhile in Hamburg I was still there. I was a good colleague, right? And I had a clarifying conversation with my former boss's boss and he told me something that stuck with me. He said, "We know your experts in what you do, but the relevant people in this company don't really know what you are doing or who you are." And then he said and that includes

myself but he continued why don't you do a short two two three minute presentation about who you are in one important technical topic and I was baffled and I asked him are you serious my personal career and the future of the whole team hangs on a two to three minute and management looked at me and said Yes. And I was like, "No, no." But he said, "Yes."

But shortly after that, I listened to a talk where the speaker said, "If you want people with no technical background to understand what you do, start with why." Sounds familiar. That's Simon Cene. It felt like I had discovered fire. I had never thought about reaching people on that level. It was like I had been searching for the Holy Grail and then somebody came around the corner and

presented it to me on a silver platter. Here you go, sir. >> Thank you. Meanwhile, I had been taking the situation headon like a professional. you know, anger, denial, bargaining, depression, acceptance. And then when Christian presented these ideas to the team, I jumped on them because before I studied computer science, I had studied political science and I knew start with why. And I knew a lot of

books that go along with it very well. Philip Collins's The Arts of Speeches and Presentations, you know, how to stay visible in the political crowd. Okay, wait, have I lost you guys? Cuz a tech audience isn't always the right one for political science. Anyways, so we discussed that and we came up with something and Christian actually gave a presentation in front of all of Chibiotech and then

it all clicked. So after this brings us to our first lesson. >> Exactly. >> Which is be visible. All right. If you to do what you say and to follow what you say or to even understand it, you need to be visible. The thing is that so far we had been staying amongst ourselves and we had always developed all of this really cool stuff and we had

figured look this is an offering. If developers don't want to use it, that's fine. That's on them. you know, at some point they will realize how much cooler our stuff is and how much better it is than what they have and they will come and it just didn't happen. But then Krista gave his presentation and it all >> Exactly. It clicked right because after I gave this

presentation, Lucas and I sat down together and right in that moment we decided we would be visible. We did not want our work to be insignificant and most importantly we wanted what we do to have an impact. And maybe you've watched the documentary The Last Dance about Michael Jordan's final season with the Chicago Bulls because for us it felt exactly like that. We would make one final

attempt to place our technical vision in the right places and we would make it count. one last dance. And to avoid being invisible, we had to start talking to people. And this brings us to our second lesson. You need to talk to people, right? You can't just expect them to magically discover how much better your solution We also couldn't expect management to just know that we were

creating value. But really it should be this. You need to listen to people. So we set up meetings with stakeholders and we told them about our problem and we asked them for advice and then we just listened. You would be surprised how much you can learn and how much support you will get by listening. But support alone isn't enough to get business to care. Right, Lucas? That's

Talking to people only meant that now they knew our faces. They knew of our existence, which was great. But the one thing that we needed them to understand is that our work is actually relevant for what they do. That we create verifiable business value. And so we set up another presentation in front of all of Chiotech and we used the Dorometrics to compare tech leaders with Chebo

and we told them look you know this is this is the gap. Our work creates verifiable business And I remember that moment because heads went up and people started nodding and I figured we got them right. That was really cool. Then somebody else got up and he was like, "What are our numbers? Do you know?" And we didn't because we had never actually measured any of our

services with Dorometrics. And that brings us to lesson number three. Make your value measurable. Any business decision, at least obstens ostensibly, is based on numbers. If you don't have numbers in a business context, you don't exist and what you have to offer will not be taken into consideration. It really is that simple. So, we got ourselves a pilot team and we implemented flux in one of their

services and we started measuring. We got those numbers. And if you've read storytelling with data by no spellman, you will know that in order to bring your point across, you make it to have to make it clear and concise. You have to make it a comparison using colors and make one data point stand out. In our case, that was 77% faster deployments. So, we had measured this.

We had wrote an internet article about this with this headline and we had given a two-minute presentation about it to Chibo Tech and it was really great because we got management buy in and then the numbers didn't check out. Um, always always always double check your numbers because if you other people will do it for you and it hurts. Am I right? >> Oh yes, they will.

Because this first occurred to us when we sat down with this pilot team and discussed the migration of the next services and they were like you know that our deployments aren't actually faster, right? Well, it turned out that our measurements hadn't included the whole deployment process due to hidden asynchronous processing technical detail, you know. So we were devastated. Our whole business case rested on this and our

main selling point to management no longer applied. So we were worried that management could withdraw the commitment and we already saw ourselves losing this momentum we've created. As it turns out, change is hard and people will fight change. So we needed better arguments and we needed more time and we needed both fast. But then we had an idea. What if we could somehow make flux a conversation

topic? So this is one of the coffee machines in our headquarter. And for the people in the back row it says don't be Hansspa use flux. Just an FYI there's no Hanspa at Chibo. We checked. No hard feelings, but it's a coffee company, right? And that means that people gather around the coffee company and they talk about things. And we actually managed to give them something to

talk about. Suddenly they were wondering who is this Hanspa? There's no Hanspa as Jibo. And they were wondering what is Flux and why isn't he using it? And this brings us to lesson number four. Create narratives. The thing that we missed with all our technical arguments was that we didn't connect with people emotionally. You can have all the technical arguments you want. If people don't feel it,

you're on lost ground. And the way we discovered to do that is to tell stories, connect with people, involve them in the problem. Christian, would you do the honors? >> It would be my pleasure, Lucas. May I introduce this is the team very important tenant and they maintain a very important service obviously and first we have the junior developer called Hanspa and he keeps messing things up

why because he does everything manually. Right next to him there's on call Olaf and he does a job that I think a lot of people in this hall know about and don't envy him for. He fixes whatever hunts pa breaks. And sometimes he does that in the middle of the night. Can I just have a quick show of hands here? Who here had to fix something in

the middle of the night that somebody else broke? Yeah. Right. Precisely. And we always made it very clear that these are problems he wouldn't have with proper Git Ops deployment processes. And last but not least, there's feature first Fiona. She's the product owner of this team and she really only cares about new features. And these characters were featured prominently during our 90minute tech talk. And they helped

us to make the hidden pain visible. And spoiler, it wasn't speed. So suddenly we even gained unlikely allies. Developers who had never backed our efforts before were suddenly on board. Turns out on call Olaf's pain is real and they felt it. And this brings us to lesson number five. Make people feel hidden pain. Because one of the biggest problems we had was this. Developers kept telling us

we don't have these problems. Our deployments are already stable. They are already safe. But by creating this narrative, by making it relatable, by showing that this could actually happened to them, they could see it. And most importantly, they could feel it. They understood why we wanted to implement GitOps. And they were willing to do it because they saw a direct benefit for themselves. >> Do you hear

the music? >> No. And that was exactly our problem. All this time we have been building really cool stuff obviously but we expected developers to discover this on their own how much better and how much cooler it was in comparison to what they already had. So, in other words, we were showing people musical notes and expecting them to know how they sound and we realized they never

did. So, let's recap. Be visible. Talk to people. Make your value Create narratives. and make people feel hidden pain. Those five lessons are And we certainly had to learn them the hard way. If you want to turn your business understands and that developers actually want, stop showing people musical notes. Play the music. If there's one thing you take from our session today, this coming Monday, take one

of the technical problems that you've been unable to solve and place and turn them into a business problem. Then go to one decision maker and tell them that story. This is Lucas Hornung and this is Christian Mat. Thank you very much. >> Thanks. >> And I think we're open for questions, >> We are open for questions, of course. At the microphone, preferably, >> right, beautiful talk. Awesome.

Um, Borland uh with Impera. This is something that you don't get out of high school, right? This skill set. >> So, >> how would you um especially now in the age of AI, right? Because we're going to use we're going to lose juniors because everybody wants AI and not junior devs, etc. So how do you get this skill set and perhaps the the whole skill set of

of working with people and not with computers to the juniors and meteors in general? >> That's a really good question actually because we've been learning along the way, right? Um I would say that the first thing is motivation and the second is exposure. Uh at least in my opinion is best to take people with you, you know, juniors with you into those meetings with people that are

supposed to adopt what you're and make them get a feel for their audience. That's that. That being said, I don't think the way we did it is very uh common. But yeah, interesting. Um we we we're trying to to be a role model here and to get our juniors on board and also to to plan additional work on ex on these exact topics when we're doing some

technical stuff that we are respecting at least talking to the right people telling them get getting them on board also um and this also helps helps the juniors at our company. >> Yeah. >> Yeah. In the end, it's because I'm also playing this role that you uh that you've been doing. >> Okay. >> And it's it's very interesting to think about, right? Because the the juniors, it's

it's not like you can get a um a certificate in how to talk to people, right? You can get a certificate in how to use Kubernetes >> and that can be fun and that's very um interesting for most young guys, right? But they're not like, hey, I'm going into tech because I want to talk to Yeah. No, you don't you don't really >> true. >> Well, I

I I mean, at least from my standpoint, take people that studied a social science and then switch to it. >> I'm the classic nerd, so it's still possible, right? >> Yeah. Any any more questions? Yeah. >> Hello. Thanks for the call. And uh why flux instead Argo made this journey easier for you guys? >> Why flux instead of Argo? >> Yeah. I mean, obvious question. Actually, back

then when we when we compared both tools, it it was a better better fit back then um for for Chibo than than Argo was. we were we didn't plan to have an um web interface at all. So we so we wanted to just implement it in our current CI/CD as setup that that actually someone um during a merge merge uh request using GitLab can actually just see

okay everything happened and I get an external notification that that everything got deployed and this was totally sufficient in our case. There was no additional um things planned originally. Um but of course I mean the question is always there right is it still the best fit? Does it make sense to migrate currently? It's it's doing doing its job perfectly for Chibo. >> Yeah. So, you show how

you're playing the music now? Uh how you make the shift, right? >> How does it look like today? Like how many videos do you create? how much what is your new routines as in like on a month by month things that you can do >> so um videos are actually um good thing to put out there because uh we record everything that we do in terms of

you know explaining and introducing new technology. So now when people ask, hey, could you could you just give us a quick 1-hour call? Um, we aren't that many people. We can just point them to the video and say, you know what, uh, you go watch this first and read the documentation that we write. We have very active and very dynamic documentation um that is always kept up

to date. Uh, and then you approach us with the open questions that you have. And um what tends to happen is that the understanding becomes deeper because now it's a conversation. It's no longer this okay I have something to say I'll stand in front of everyone and just broadcast it. It's it's an individual and you have an exchange about the topic. And that also leads to different

kinds of demands where where people are like okay look um I've looked at flux and I've looked at flagger for progressive delivery but really what I want is this other thing which is like longrunning canaries. Is there any way we could do something like that? And um for us that's pretty cool because uh that plays the ball back to us again where um we don't always have

to do the whole process but we're already talking to somebody and we know that there's demand. So we go from there. Um what we are uh in the process of building up are open hours at the moment to talk to people regularly um to make sure that we have them covered. >> Hi. >> Uh wonderful talk. I think we all suffer the same experiences that you do.

I have two questions. The first being um these lessons that you've learned. >> Yeah. Have you in any way formalized them in your organization to so that you will make sure to reuse these lessons in future projects? So some kind of project life cycle guidelines or anything similar that others can follow for their projects, >> right? >> Not yet. >> I mean rudimentally, right? >> Yeah. But

I mean mainly these these guidelines are within our team. So, so infrastructure for this web shop for Chibo and we we're trying to respect them as good as possible not only for flux but also for for new projects we want we want to approach and we want to implement because it I mean flux is replaceable right this is just the topic we work on mainly the last

year but it can be anything right but getting the people on board emotionally uh involve them right get their opinion feedback Feedback loops also an important thing. We also introduce feedback loops. This is the the thing which will definitely help to get more understanding, more acceptance and the willingness to adapt. Um but spreading it within the company also for other departments sounds like a good idea. >>

Um then the second question is I uh I saw that in the description of your talk you also list some of the books. >> Yes. that you use as inspiration >> um for >> your methodology. But uh is there any additional like um learning material or other sources of information that you used that uh you can recommend? >> You're the book nerd. >> I know. I know.

Yeah. Political science for the win. Um if you want um I I have a personal list that extends beyond what we have listed in the presentation because it was kind of um we wrote this last year in October right so since then we have added a few things about you know negotiations other other kinds of soft skills um randomness nasim talib is is pretty cool right now

you know anti-fragility that that sort of Uh if you want uh we could connect and I can give you those books. >> Yeah, that would be great. >> Sure. >> Maybe uh I don't know if it's possible to post multiple files in the talk. Um >> yeah, if not if not I can I can amend the list also want to. >> Yeah, definitely. Okay. Yeah, sure. Sure.

No problem. Thanks. Yeah, good