Coffee, cookies, and platforms: How to make developers love your platform

In this episode of DevOps Sauna, Pinja and Stefan talk about what truly makes a developer platform successful—and why forcing adoption never works.

They explore the “coffee and cookie principle,” the importance of trust between developers and platform teams, and how to create platforms people actually want to use.

Topics include building developer trust, identifying platform ambassadors, balancing freedom and governance, and strengthening collaboration across teams.

Whether you’re building your first internal platform or refining an existing one, this episode offers practical insights and real-world stories from the field of platform engineering. 

[Stefan] (0:03 - 0:08)

The more you can put into your platform that takes some of the tedious work away from developers, the better.

[Pinja] (0:14 - 0:23)

Welcome to the DevOps Sauna, the podcast where we deep dive into the world of DevOps, platform engineering, security, and more as we explore the future of development.

[Stefan] (0:23 - 0:32)

Join us as we dive into the heart of DevOps, one story at a time. Whether you're a seasoned practitioner or only starting your DevOps journey, we're happy to welcome you into the DevOps Sauna.

[Pinja] (0:38 - 0:45)

Hi, and welcome back to the DevOps Sauna. Today I am joined by my colleague Stefan Poulsen. Welcome, Stefan.

[Stefan] (0:46 - 0:48)

Thank you very much. It's so nice to be here.

[Pinja] (0:48 - 0:51)

Awesome. It's good to have you here. How are you doing today, by the way?

[Stefan] (0:51 - 0:59)

Good. The sun is shining. A good day in Denmark.

I can see my neighbor is trying to wash his car, so hopefully we don't get any noise from that.

[Pinja] (1:01 - 1:10)

Let's see how that's going to go. And it's not… That's the funny thing.

It's usually raining when I go to Denmark, so maybe it's a very… It sounds very weird that the sun is shining.

[Stefan] (1:10 - 1:19)

Like I grew up on the West Coast. We have like 360 days a year with very strong winds, and the last five are like gale force storms.

[Pinja] (1:19 - 1:19)

Okay.

[Stefan] (1:19 - 1:21)

So today is awkward for me.

[Pinja] (1:21 - 2:02)

Okay. But hey, we're here to talk about something else and weather as well today, but it's always nice to start with… That's a very small talk way of starting our ways in the podcast, but we want to talk about a little bit of platforms today.

We want to talk about implementation of those platforms and what does it actually mean when we want to get the developers on board, because we've seen some various ways of getting developer platforms implemented in organizations, and in some cases, there is a really strong mandate from the central organization where you're working. How should we do this? And trying to force the developers in, but how do you work with platform engineering yourself?

Does it work?

[Stefan] (2:02 - 2:41)

Yes. It works quite well, but we do see like… It's going to sound so harsh, but some of the bigger enterprises, they just want to adopt platform engineering, so they're like, we build a platform and you have to be on it.

But if you go back to the CNCF, where they talk about the platform engineering white paper, it's like, it's not mandatory. If you get 80% on board, it's a very good result, but that is tricky when you get into companies. Do we get a return of investment here, or are we just pouring money into something new that is never going to be used?

I do get why they mandate it, but it's polar opposite to the thoughts behind platform engineering.

[Pinja] (2:41 - 2:53)

And we, of course, want to empower the developers. We want them to feel autonomous when we're implementing stuff, because you get more bees with honey than with vinegar. Isn't that something like that saying?

[Stefan] (2:53 - 2:55)

Yeah. It's a good old carrot and stick principle.

[Pinja] (2:56 - 3:09)

Exactly. But it's also, if we think of the size of the companies and the complexities, do you see any difference between different ways of doing it, whether it's a small company or an enterprise level?

[Stefan] (3:09 - 3:45)

Definitely. Small companies, let's say they have, what, 5, 10 engineers, they will probably just have a script run somewhere where they just run the script. And over time, this script goes from 10 lines to 50 to 100 to 500.

And all of a sudden, you need to put it more into structure and have a system that can actually do that. But the bigger organizations, they have to think about how do you buy the software or build the software? You need to deploy it and so on.

It turns into a quite massive project for them. So, of course, they want more people to use it as soon as they have it, because it's the return of investment and you get your money back from the investment into this expensive piece of software you did. Yeah.

[Pinja] (3:45 - 4:10)

And one thing to mention, we had guests from Lego in one of our previous conferences. We were at the DevOps Conference in London in 2024, where we had Jonas Troedal-Rask and Waqas Ali from Lego, and they were talking about this topic. How do you make your platform so good and so great that your developers actually want to use them?

And what is the honey that will get them to use it? What kind of value promises can we make for developers?

[Stefan] (4:10 - 5:06)

It really depends on your organization, again. This is going to be so consultant-y, like, oh, it depends all of the time. But you need to show a value.

And if you're in a smaller company, the value it brings is it's easy to deploy stuff. There's built-in monitoring or whatever. When you go to the bigger organizations, let's say highly regulated, then you want to make sure that the platform includes all of your compliance and regulations and everything.

So not every single team has to sit and do this. It might be that it automatically scans for dependencies in your software. It does a snapshot for the software bill of material, upload it to the correct portal, notify security if anything is wrong or potentially bad or anything like that.

So the more you can put into your platform that takes some of the tedious work away from developers, the better. Just updating dependencies, a simple thing like running a dependabot in, let's say, GitHub, well, it's part of your platform as well. You just need to make sure it complies with your rules and regulations in your company or policies.

[Pinja] (5:07 - 5:16)

So it's not just that we — but then again, it's nice to have the value propositions, like this is what you're going to get out of it. But it's not, I guess, it's not as easy as, say, build it and they will come, is it?

[Stefan] (5:16 - 5:49)

That's actually a good pitch because I am going to state that in a presentation I'm going to do soon. Because it's going to be huge letters up on a big screen, build it and they will come. Because, well, if you don't build it, how are they going to come anyways?

There's the positive and the negative spin on that one. So it's more about what is the mindset when you say it, more than the fancy quote you can write on a blackboard and say, yeah, if you write, build it and they will come, you will misunderstand everything because you should build it for them. Yes, but if you build it for them, they will for sure come or remove some of the annoyances they have on a day-to-day basis.

[Pinja] (5:49 - 5:55)

Exactly. So I think that's a really nice way of looking at it. If you never build it, they will never come, right?

[Stefan] (5:56 - 5:57)

Why would they?

[Pinja] (5:57 - 6:29)

Why would they? There is nothing to come to. But let's think about one aspect of this.

So is it the organization's platform or is it the developer's platform? Because the name already suggests that it's a developer platform, but who is it really for? And in many ways, we can draw some equations here between not just how do you implement a developer platform, but anything in an organization, right?

So do you fully centrally control this or do you get full autonomy? Somebody might say chaos or anarchy to developer teams.

[Stefan] (6:29 - 6:32)

Have you been reading all of my slides for my coming presentation?

[Pinja] (6:32 - 6:32)

Yeah.

[Stefan] (6:34 - 7:33)

When we talk about freedom, there's always this balance between freedom and chaos, and usually people run over the hills like, freedom, we can build whatever we want. But I tend to say, if you want a good platform, you need to give up on some of your freedom as well. And when you give up your freedom, well, you need to get something back in return.

And that might be all of the boring compliance stuff here, if you're not into that. But you ask if it's the organization's platform, is it the developer's platform? Well, the original term was internal developer platform.

Today we just removed the internal one, but it should actually stay there because I've been with some clients where like, oh, developer platform, we can use it for our deployment of all of our projects, everything is going to be great because it's just Kubernetes. Like, well, it's a very different Kubernetes if it's running internally compared to when you run it at a customer's place. And it is always your developer's platform, no matter what operations team, platform engineering team you are, it's not your platform because you're not building it for yourself, you're building it for the developers.

[Pinja] (7:33 - 7:47)

That was one of the key things that Jonas and Vakas from Lego actually raised in their talk, to actually listen to the developers. What is it they require from a developer platform? We can call it the IDP with the internal there as well, but...

[Stefan] (7:47 - 7:48)

Ooh, I never say that.

[Pinja] (7:49 - 7:51)

Let's not use that.

[Stefan] (7:51 - 7:53)

IDP has many meanings.

[Pinja] (7:54 - 8:17)

Let's not use that. But basically, do you listen to the developers? As you say, you need to give up some of your freedom to get something centrally working.

And in many, many cases, we're talking about bigger corporations. We're not talking about startups. We're not talking about something that has three developers in all of the organization.

So that's, I guess, the cognitive load being freed means that you need to give something up.

[Stefan] (8:18 - 8:55)

Exactly. Like getting a, just like a built workflow template, getting template repositories, like just simple bits and pieces that are built in, like even just taking care of secrets when you deploy into different environments, making sure you don't have to think about that, because that can get a bit tricky. Even if you throw something as awful as certificates on top, you can just see all of the developers, their brains start to melt because they don't use certificates on a daily basis.

That's operations or security who does that. Remove it away from the developer, make sure you have a workflow, something set in stone that works. And you can do that in the simple script as well.

It doesn't have to be some crazy big project.

[Pinja] (8:55 - 9:45)

Yeah. And I'm just thinking about the dependencies between developers and, let's say, we can go with the ops team or the platform team as often we do nowadays, that if we get it to function really well, that there is no barrier between the platform team and the developer team and multiples of those dev teams. I think if I were a developer, what would I really want out of my flow?

So that's maybe the next thing. How does the developer's perspective is taken into consideration? What is their flow like?

Do they really, really want to go in and do all of that stuff? Or is that at least what I would expect, that I would have good cooperation with the platform team and there would be no bottlenecks. But of course, when there's a handover, when somebody else is taking care of something of mine, it might cause some delays.

[Stefan] (9:45 - 10:55)

You can go into any size of organization, there'll always be this one guy or maybe two or three guys. I was in an organization, I think we had around 100 developers in an office, and there were always two guys coming out like, oh, you should do this, you should do that, tweak this, tweak that. This is how it should work.

Yeah, that's 2%. We're 98% happy here. They will come with small requests every now and then, but if we can satisfy those 98%, I'll happily be the guy who takes this discussion over the water cooler with this guy and says like, yeah, but that's not the vision for our platform.

If you want that, you can get it running on your side. We'll happily provide your interconnection so you can use that. But please let me talk to your product owner before you do that, because I want to talk to them about the risk of you hosting this and doing everything on your own on the side.

Is that really what you should be building? My focus for the developer is to become a master of your programming language or programming languages, understand all of the aspects of software development, and understand your domain. Don't worry about all of this infrastructure stuff.

Don't start writing Terraform. That is not your purpose here. Of course, we do have some of these full-stack developers that can do it, but that's not the standard case.

[Pinja] (10:56 - 11:39)

No, and if we think of what would actually developers want to do, is it that you want to go into this Terraform and you want to go in and dig deep? Maybe that's then not the role that you're supposed to be in. We always have that one developer person who the enforcement is the exception and then enforcing the rule by doing that.

We always have those people like, I'm going to do everything by myself. I don't want to lose control to somebody else. So if you think of building the trust in the community, because that shifts that a little bit to the culture side of things, do I as a developer, do I trust my platform team?

Do I trust the organization, how they've set up the platform? So how do you think that we get the trust in the community and between dev and the platform team?

[Stefan] (11:40 - 12:15)

It is a lot about collaboration. Like you say, trust is so important. If I'm sitting as a developer and I don't trust operations to do it well, then we have an issue.

Then we need to roll back to good old DevOps practices and figure out what's the culture, how do we deploy things together, how do we collaborate? We need that in place no matter if it's platform teams or operations. It needs to work.

We need to have a good collaboration. We need to have a good culture where we can be open and talk to each other and figure things out. But if we don't have that, we're never going to have the trust in the platform and people are not ever going to join the platform unless they're forced.

And then we're sort of losing.

[Pinja] (12:16 - 13:43)

Exactly. And then, yeah, so we're going to lose the people by forcing them, right? People don't want to be forced.

I was part of this one transformation case a couple of years ago. This was an agile transformation. And in many ways, as we said before in this podcast, we can think about the implementation of any other, let's say, might be a tool, a way of working, and think about how you can implement something new in an organization.

But especially when we talk about platforms, it's supposed to be for the developers. And we did this agile transformation which was supposed to be for the developers. And of course, since this organization had, I want to say, five developer teams, we had to agree on certain shared rules and processes.

And one of the scrum masters was really unhappy. He was also the lead developer in that team. And he said that, oh, we're losing all the autonomy in the team because we now have these mandated rules.

So there's always this growth pain, right? Why am I, even though if the door is basically open, here's the platform, we heard you, there will always be certain people in the organization who will be doubtful about the implementation of the platform, even if they say that, hey, this is to help you and the value has been communicated very well. But how do you co-create and where would you start with the, I don't want to use the word stubborn people, but let's say the ones who are doubtful about the implementation of a platform, where would we go?

[Stefan] (13:43 - 14:07)

I will probably go to a different team and onboard them first, because don't go for the stubborn one first, because you're going to be spending so much time onboarding them. It's way easier. Let's say get the other 60% onboard and they will see the light and they will talk to the other colleagues and like, oh, this is actually quite great.

We don't have to worry about backups, recovery, host names, URLs, anything is taken care of for us now.

[Pinja] (14:08 - 14:28)

Yeah. So if we think about it, we can call this identifying the champions. It might be a team.

It might be a couple of people. Do these people usually, because you've been working with the platform implementation a lot more, do you see that it's usually easy to identify the ambassadors and the champions in an organization for platform engineering and platforms?

[Stefan] (14:29 - 15:48)

It's usually quite easy because when you've been in an organization for quite some time, you know your people. You know who to go to talk to about this guy who knows a lot about Elasticsearch or this guy knows about SQL servers or whatever. So your business bonds with them, like an unofficial bond in your organization, and you bring those in every now and then to make sure you actually have the champions for this upcoming feature or capability in your platform.

And you need to take your maturity journey into consideration as well, because if you start out by some ad hoc team building things that look a bit like a platform, you can't just super scale up to everything that is self-served and scalable and people can commit back to your platform. You need to take this, oh, I hate saying journey, but it is a growth journey, but everybody hates hearing journey. But you can jump to the CNCF and have a maturity model for platforms as well.

So you start provisional and you end up in the, I cannot remember what the last level is, but you'd go more and more towards autonomous operation and people can commit features back to a platform and so on. And you get self-service when you reach a certain level as well, because you cannot jump from level one to level four straight away. You need to take all of the steps in between to prepare your organization as well, like culture and readiness for technology.

Nobody can step from zero to hero.

[Pinja] (15:48 - 15:59)

And in my mind, it's not always perhaps the person who's good at tech, right? Not to be the ambassador for these cases, right?

[Stefan] (15:59 - 16:41)

Hardly ever the guy who knows all of the tech. You need to have certain degrees of, it's going to sound horrible, but communication skills, because you need to be to some degree extrovert and being able to go to teams and talk to them. I run this coffee and cookie principle where you take a bag of cookies and a pot of coffee, go sit next to someone you've never talked to before.

If you bring cookies and coffee, they're going to be happy. Build this good entrance into a good conversation with them and you know they're not on your platform. So start asking what's missing in our platform to make sure that guys support you.

If you want to move, don't say when you want to move, like if you want to move, make sure you keep open doors all of the time. It's sort of like being a politician.

[Pinja] (16:42 - 16:43)

It is, yeah.

[Stefan] (16:43 - 16:49)

You need to push them a bit every here and then and just make sure you push them by slow steps.

[Pinja] (16:50 - 17:20)

There are very interesting strategies. It's like being available for those questions and to also hear the opinions because they might come from a very different place than we might anticipate in the first place. It might come from fear.

Am I losing my control here? Am I going to be made redundant if this works too well, for example, with the new technologies? There's always somebody, even though we're talking about technical people who might know that this is not exactly how it's supposed to work, but we have our own beliefs about things.

[Stefan] (17:20 - 17:32)

Yeah. It's just so rare that people are made redundant by building a platform. Like if you do end up being redundant due to a platform, then you probably wouldn't have that job in the long run anyways.

Sorry to say.

[Pinja] (17:33 - 17:35)

It's probably not the platform.

[Stefan] (17:35 - 19:22)

No, no, no. It's not. And some companies, when they shift from the old ways of doing things, they had a DBA sitting in the basement typing all of the databases all of the time.

He was the only one who could do that. Then you hyperscale up to platform engineering. Everybody does everything, the DevOps projects and whatever they do.

All of a sudden, they have lost this guy who knew about databases. But when you have a platform, you actually have room to have the specialist in because you need a specialist in your platform to run the databases, make sure they're distributed well, optimized and everything. But he's too expensive to have that single guy in one team.

And if he lives inside a team, he can hardly ever go to other teams if you go into the bigger organizations because then you need inter-team accounting or whatever. Yeah, but we need him 50% of our place. He needs to be 25% in this one, 10% in that one, and 15% in the last one.

So where does he belong now? So he loses his sense of belonging and he gets super frustrated because everybody's pulling him in all sorts of directions. But if he's sitting in a platform, he can better say, all right, here are my priorities.

I need to make sure our backups and restore are in place. Good. I need to make sure they're optimized, they run well.

Good. Next step, can we actually tweak and twist this with some fin up practices to make sure we actually run it more efficiently and save some money? Or should we start looking into letting a cloud provider run managed services instead of us spending a ton of time on tweaking and twisting it inside of Kubernetes?

Or even worse, we put them in our grand big Kubernetes cluster that is also running our workloads. How do we make sure we can back up, restore all of that if it's in one cluster and so on? There's so many complexities you can move away if you go for a managed service instead.

But when you get big enough, you might want three or five database people that run this as an internal managed service officer because you have the advantages of scale at that point. So many, many platforms in the end.

[Pinja] (19:22 - 20:17)

It is. And what I've seen also in a company where we did a huge, huge basically platform engineering, it's not a migration but a transformation where they took their ops team and made it into a platform team. And just empowering the platform team was really nice to see.

And then taking ownership. So it's not true, of course, it's not just with developers, but it's an ownership change for the platform team. But it was also nice to see some of the developers race to the challenge themselves without actually having to ask like, hey, would you like to be a champion?

But they ask like, hey, how can I provide input for what we're doing here? And just having that principle in mind, like listening to your developers and listening to the people whose life this is supposed to help. And of course, you can do internal marketing, right?

If we think of internal campaigns. And one thing that always seems to work is the stickers. People love the stickers.

Everybody loves stickers.

[Stefan] (20:17 - 20:32)

Oh, yes. I was at a small event yesterday and you could just see people grabbing stickers, even though they might already have for this vendor. Still, they keep pulling the stickers, putting them in the bag.

And they put them in the bag like, oh, I don't have any stickers. I'll just take a few more.

[Pinja] (20:33 - 20:42)

They have trade value. When you go back to your office and your home base, you can trade them for good karma with your colleagues. Isn't that true?

[Stefan] (20:42 - 21:35)

Even better. So if you have your own platform, your own logo, your own name for it, you can use those stickers to your advantage. Because if it's a good logo, like AI can create a ton of logos these days.

So a good, nice logo, something that people want to have on their laptop. You'll see people go like, oh, are you on this system? Oh, yeah, I am.

Oh, nice. How does it work for you? So just by having that sticker starts a conversation between different teams all of a sudden.

Or do you have the same issue as us with things like X, Y, and Z? Well, can't we just grab one of the guys? Let's just go into a room on a whiteboard and talk about what's the issue here and figure out how we can resolve it.

Or at least give our feedback on how to resolve it. Because you need the feedback from the water cooler, but you also need the quantitative feedback where you get a ton of responses in a survey or something like that. You need a bit of both.

[Pinja] (21:35 - 21:52)

Yeah. So if we start to sum up our conversation, how do you implement anything well in an organization? We have the context of platforms today, but if we start from building the trust, if that is our key, that number one thesis of today, what do you think is that what we could go with?

[Stefan] (21:52 - 22:29)

Yeah. You need something that actually works. If you supply a platform where the, let's say the uptime is 50%, nobody's going to join our platform, especially if it runs production workloads, but getting a good stable foundation up, make sure it runs well.

It's reliable. Start adding the smaller and smaller features, making sure that people can actually onboard it, like small steps. We see so many big projects where people are drawing a humongous platform engineering project with a timeline of three to five years.

It always fails. And then it turns into being mandated because now we spent five years building it. So you have to be there, go back, build something small.

[Pinja] (22:31 - 22:41)

And if our number two might be the developer experience, why did you want to do this in the first place? Was it to actually think about the jobs to be done by a developer? So the journey, the flow, right?

[Stefan] (22:42 - 23:22)

Yeah. And there are all of the additional benefits. If you build it well for the developers, you have all of the workloads in some structured manner where you can sort of start by packing all of your workloads into smaller clusters or bigger clusters.

You can start saving money. So that's a good side effect of it as well. And when you get hit by registrations from the EU or wherever you are, all of a sudden you have a platform where you can actually apply all of this stuff and you get it.

It's never going to be free to do the governance and compliance stuff, but it's easier to do when it's in a structured system. I know you've been to a ton of customers where we talk about tool chain consolidation as well. This is just like additional layers on top of that.

[Pinja] (23:23 - 23:40)

Exactly. But it's kind of how to make it all work together as well. And maybe the third one would be just don't force it.

We know how much money has been invested in this, in many of the platform projects and implementations, but do not force it. Okay. It's maybe one of the key things.

[Stefan] (23:41 - 24:13)

I was talking to a client that was trying to figure out how they could promote their platform even more inside their organization. So what have you been doing up until now? Nothing?

Well, try bringing a bowl of candy, standing next to the escalator in the morning and just say, hi, it looks like you're going up to the third floor where we know all of our developers are sitting. Have you heard about our platform? Can I give you the elevator pitch for it?

That's when you need those ambassadors that are ready to take that step. It might be an ambassador from your own platform team or even bring somebody else that wants to be the ambassador for your platform.

[Pinja] (24:14 - 24:15)

That's always helpful.

[Stefan] (24:15 - 24:23)

It's a tough task to sell, but you can do it well and you can do it way more easy if you have something that brings value to the developers.

[Pinja] (24:24 - 24:39)

Yeah. We know that the price of chocolate is on the rise, but it's still, it must be cheaper still to bring the chocolate or whatever your organization prefers that you have available than to have a platform that nobody's using, because that's the worst case scenario.

[Stefan] (24:39 - 24:58)

Yeah. My cooking and coffee principles are going to drop because both chocolate and coffee are racing in price. This is going to be bad.

I need to figure out something new and I should probably not bring, yeah, I could bring cheap beer. I brew myself, but it's not politically correct to like hand out beer inside of an organization in the middle of the day.

[Pinja] (24:58 - 25:06)

No, no, that's not for a workplace. But on that note, I think that's all the time we have for this today. Stefan, thank you so much for joining me for this discussion.

[Stefan] (25:07 - 25:08)

Well, thank you for having me.

[Pinja] (25:08 - 25:17)

And thank you everybody for tuning in. We'll see you next time. We'll now tell you a little bit about who we are.

[Stefan] (25:17 - 25:22)

I'm Stefan Poulsen. I work as a solution architect with focus on DevOps, platform engineering, and AI.

[Pinja] (25:22 - 25:27)

I'm Pinja Kujala. I specialize in agile and portfolio management topics at Eficode.

[Stefan] (25:27 - 25:29)

Thanks for tuning in. We'll catch you next time.

[Pinja] (25:30 - 25:38)

And remember, if you like what you hear, please like, rate, and subscribe on your favorite podcast platform. It means the world to us.