How to Build the Best Platforms for Software Engineers

The truth is, and most developers don't like to hear this, but when implementing platform engineering, we're kind of stealing some of your autonomy. The platform is built for software engineers. If the platform is bad, it could be the case that the platform team is building a platform for themselves, not for the software engineers. Is this a common thing? Sometimes I. Think it's even better to have no platform at all than a bad platform.

How many developer hours have I saved by creating this coded path? Don't build a cool platform. Build a platform that developers want to use. We'll use in the end if. You want to learn about platform engineering, then this episode is for you. I have two platform engineering enthusiasts joining me at the table and the dynamic was just fantastic. Atnan Al Shar and Yomer do Yom, so enjoy. I saw this trend online and it was maybe a couple years ago.

It was DevOps is dead and platform engineering is the new

DevOps or it basically killed it. A lot of people are like click baiting and engagement farming specifically through that phase, but I'm curious what you think about that. I think the platform engineering as a discipline or as a practice that's coming up right now, it's getting more mature every year. I understand why the title was dev OPS is that I think they're trying to jump to the next

phase. And the idea here is that how platform engineering is being pitched is try to counteract kind of the DevOps movement of look, we understand you build it, you run it, but we also want to make it better and remove all of the negative connotations that happened with DevOps over the past 10 years. So I think that makes the title that I think that's why they said it. I guess I don't. Know so do you agree? Do you disagree? Yeah, I agree. Yeah, yes, yeah. That's funny 'cause I disagree.

OK, tell me why. Yeah. I, I don't think it's, I think that was that. I think it just doesn't work in a current age of technology anymore. That was, was of course created or thought of in 2008. The world has changed quite a lot since then, right? Containers were the thing, Kubernetes wasn't there. So teams taking full autonomy of their complete life cycle was possible back then move ahead to

10 years later. Communities, clouds, infrastructure, codes, all these things were also put onto teams had to maintain all of these things as well. This is really where platform engineer stepped in and said, hey, we tried to take small things that you're currently doing and centralized them in the centralized team in this in this platform so that you can just focus on writing codes and being in flow. And we take care of all the other underlying infrastructure that's needed.

So The thing is that I think it's OK. It's that's like it was in 2008. I would agree with that for sure, definitely. But in the current age of technology, I think platform engineering makes DevOps work again. OK, gotcha. Yeah. I like it. Yeah, yeah, yeah, I like the idea. I think it's, it's evolution. It's that's what we're seeing. I agree definitely on that. Just giving the chance for

social engineers or developers in general to go back to what they do best and that's writing code that's that's talked about from 2008 to now. The amount of stuff a software engineer needs to maintain and work on and create and learn to get their idea to production has grown rapidly, right. You just mentioned how many AI tools are coming up every single day or other tooling related to the software development life

cycle. A software engineer team to maintain that and keep an eye on it while writing code, while ensuring that code is secure, scale a bit, can be deployed to production. All of these things it's it does does not scale. And that's why platform engineering is what I say, I think what we see as the solution for this. But developers are also very particular with regards to the tools they like, or with regards

to applications they like. Like if I, I put myself in a position where I have a platform that is made for me to be more productive, I really like the productivity side. So that if you're talking about marketing, that's what hooks me that I get buying for that. But then if I don't have that experience, I get frustrated, right? Because this is the platform that I'm on and I can't really change anything because this is the choice of the organization basically. So doing this I feel like is a

fine balancing act. Is that what you've noticed as well? Yeah, it definitely is. I would say to the developers, be on the lookout for if it's a good platform or a bad platform. So it's a good platform can

actually help you get more productive rights, gives you the right tools and a bad platform will have weird abstractions that nobody wants to use, makes it even more complex to do your work, which platform engineer was never set out to do right. I think it's even better to have no platform at all than a bad platform. And in the end, a good platform

will also have escape hatches. So the moment you a tool is not supplied by the company or by the platform and you really need it for a specific use case, you should be able to use the escape hatch, get out of it and be able to use it to yourself. It does mean however, especially in compliance or regulated environments that you need to go to security yourself, get affected. Make sure that it's set up properly cause platform team will not do every small use case

that there is right. They will just support the main tools that are needed within the company. So yeah, developers should definitely be on the lookout for a is the good platform or is it a bad platform? Yeah. And if people are listening and they say, OK, well, I have heard the term platform engineering. I'm on a platform, but I don't think it's a good platform. What can they do basically? In that sense, I guess you also want to see how the platform team is engaging with software

developers. So in essence, in principle, the platform is built for software engineers, right? That's the main idea. If the platform is bad, it could be the case that the platform team is building a platform for themselves, not for the software engineers. Is this a common thing? Sometimes, yeah, yeah, yeah, yeah, yeah. Because building a platform is fun for platform engineer engineers, right? Definitely. I can say that. And I do want to build it in this nice looking way and stuff.

But you're building a product, right? And the product is for customers and you need to know what they want. Otherwise there's no adoption. It's very simple, right? So it could be the case that the software engineers then need to address this with the platform team and tell them to set this is our requirements. This is what we want our like what what Kevin was talking about like golden paths or so have to be able to work and be

productive. And that's the, that's the way where you can get a bad platform to a good platform, have feedback directly to the platform team and it's clear what you want as an end user. You're the main customer here for the product. So if you're able to do that, it it should be able to get you to a better platform with time and keep that feedback loop going with the platform team. Because in the end, what feedback you're giving should inform the road map for the product.

It's interesting, right? Because if I'm building a product that is not for developers, in this case, I have to do I have to put out the best product for those users? Otherwise there's not going to be usage. But I feel like with platform engineering, the role is inverse. And you're saying if you're a

developer, you have to go to your platform team. And I feel like they should come to me and ask me what the best thing is. Yeah. Of course, of course, of course, right. But like most of the time, people in platform engineering teams are very technical people, and I like to use new tools, use technologies. So they focus on building these do abstractions instead of actually solving what you need.

Yeah. So one of the tips I always give teams is especially if they're a platform initiative starting in your organization, try to be a early adopter, engage early and show what kind of things you're running into, sell them solutions. So but for example, say, hey, it's getting something from ideation to production, takes me 3 weeks. Like I want to be able to be able to quicker spin up services. That's not solutions, it's an issue, right?

And then they can figure out, OK, how can we solve that with the tools that we already have? Gotcha. What is the best platform you've seen work in an organization when it comes to I think your example from idea to production? The best one, yeah, the I think the best one is the one that will really help developers. So and it's it's very smooth. So the interface, it can be a nice looking, nice looking portal. But in this case, it was actually AC light tool that they used.

And they could basically just create this C light tool, create a YAML definition, send it to an to an to an API somewhere. And this would spin up stuff in the Kubernetes cluster so that they can run their their applications. And that would be exactly the same as it's locally being done, as in tests, as in excitation, as in production. The environments were identical. So the things you were doing locally, you could spin it up within seconds, would be exactly

the same as production. And I think from a developer perspective, that is very cool, at least something that you don't see very often. Yeah, exactly. The environment and how you reproduce that locally compared to all the other test and production environments that you have. Also same with data availability. If those are not in place locally or on test and acceptance environments. I've just been frustrated because you want to go to

production with confidence. You want to say I don't care that it's Friday. I have the confidence in all the safety net that we have to be able to do so There should not be this mantra of it's Friday. We don't release if we have a really good system that actually enables us to release whenever we want. So yeah, I definitely get. That and I think with the CLI tool part, that also brings it

closer to developers, right? They're also in their IDE, they have the terminal, everything is in one place. We can do what you want to do without the need to go to different places and try open tickets with that operations or whoever know you have everything you need in one place and your productivity is much higher than going back and forth, right. So yeah, that that makes. Sense and that's also that's a very important part as well, right?

Because we are the truth is and most developers don't like to hear this, but when implementing platform engineering we're kind of stealing some of your autonomy. Yeah, because now you don't get to decide how you do things specifically we lay out this pad for you. This called a pad like I've not explained before. And the moment you do that, we need to also give you something

back, right? You cannot just always have to come to us and be like, hey, can you do this for me or create a ticket or use Slack. So we need to be able to deliver all of these capabilities in a self-service manner that can be can be done through a through a portal or through a CLI interface, depending on what the developers want, right? And a good platform engineering team will go to developers and actually ask like, hey, what do you want? But we don't see that happening that often.

So again, I would like to encourage developers just to go to a platform team and say, hey, this is really something that would help us a lot or this is the pain points that we have. Yeah, you get that. What does a platform make sense, right. Because if I start to start up with you and I and you as well, the three of us start a start up, we're not going to start with a platform. I, I would assume. OK. Thank you. Because that's my assumption. That's a good, that's a good assumption.

But then at some point, I don't know if it's a scale or amount of people or amount of applications or maybe even domain, and some of the complexity that comes with that

defines when a platform does make sense. I think we, I remember reading somewhere, it's like there's a number of people, but that's very specific. So we also need to look in words and see how it is. I would say whenever you have a team that's growing and you see that, let's say the productivity or the speed, velocity, whatever is said the same, that's when you start considering what's happening, right? So within a start up, you're like 3-4 people, you work within each other.

There's no need for a platform, right? When you start scanning a bit more and you see that, OK, we're getting more productivity, we're getting more features shipped. Perfect. As soon as you hit that, let's say stagnation and and velocity, this is where you might consider a platform and the reason behind it, I guess it's more people are

working on more tooling. There's not a lot of standardization, which means some people are getting stuck somewhere or there's this no consistency in in deployment and then yeah, you have that issues. This is when the platform makes sense, I would say. How do you then start from that aspect? So you're saying velocity stagnates or it even goes down based on just time progressing and complexity building up? Does one person take ownership

of building a platform? Do you form a group that then takes ownership or what is the next step? If you are at that scale, I would say one person would be enough. Really. Yes, I would say so. Because then you don't want to dedicate the whole platform team just yet.

Yeah, You want that one person who is very close to what's happening with like in terms of the software development life cycle again and start talking to the developers and understanding what issues they're running into and then grabbing all of these issues and stuff and start working towards let's say the first golden path, right? This is where we want everyone to follow kind of. And with that, you start having a couple of people who are like you're evangelists, right?

The people you're going to start with, they are, they are trusted people in the organization and they would be able to give you their feedback. Once you create the golden path. And with time you start obviously scaling that to the rest of the organization and see how it's performing. You need to measure it as well, right? So it's not just creating it and that's it.

You need to measure it. And with the scaling that's happening to the organization, you start adding more people to the platform team to be able to support the the developers, right. So I would say that's how I see it at this deal. Nice. Let's put a pin on on measurements because I think that's interesting, but I want to learn from your perspective, Yalmer, the people that are, let's say first movers or that join a platform team, can that be anyone or what capabilities

do they need to have? Can it be a software engineer? Does it need to be someone else? What have you seen? That's a good question. I always like that the platform team is a mix of people that are have been working in social developments because then you know the pay points, right?

Yeah, you are the users. Yeah, indeed. Which is kind of the best ideal situation, right? But in the end, you also need to have the experience of, OK, I'm not just building a application for end users, but I'm building a platform that will be used by multiple different teams, different kinds of requirements. So you also want the experience of like more, well, system engineerish people.

And I think the combination of combining them together is really when magic happens, then really the issues that are need to be solved in companies are being solved and being done in a matter that's easily repeatable, compliance and secure for an organization. And again, that's really the magic for platform engineering. Nice. But then the looking back into that first mover, can that then be either a system engineer or software engineer or what would be your preference? Do you have a?

Preference. No, I don't. I think it doesn't really matter what kind of skills they have. I think it's where they will focus on. I think if you want to become a success with your platform initiative, it's not something that you should be like, OK, we're going to build this in two years and then we're going to release it like it's like horrible, right? It should really be something like, OK, what is currently the biggest bottleneck? OK. And let's just see if we can fix that it.

Can be that simple? It can be that simple. Platform engineering is this is the discipline of building internal developer platforms, which sounds very scary, but we also tried to enable flow within developers. So just start there, figure out what's your biggest bottleneck, waiting three weeks for a COP approval. All right, let's talk to them. How can we improve this? Is there a COP approval always needed?

Stuff like this is already platform engineering because we're increasing developer flow, developer experience. Maybe it's been my like kind of how I view the word platform engineering. It's not so grand. But if you're saying it's as simple as removing the biggest bottleneck and trying to figure that out already means that you're doing, you're thinking of or your platform engineering in that way, that makes it a lot more simple, makes it a lot more digestible. Yeah, yeah, yeah.

Especially if you these days you heard these big tools coming around like backstage and platform orchestrations and all very scary things. Golden paths, paved roads is what I've heard is like the huge paths that are in my head, like yearly ventures. Yeah, yeah. It is. It takes like I think like one of the best one I've seen. I have built it myself.

It took them like 7 years to get to the to the end state where they currently are where everything is self servers and done automatically to like a select bolt and stuff which is incredible. Seven years. Yeah, seven years. That's the way you start, right? You start with small things, soften bottlenecks, increasing

flow for developers. Yeah, I was going to say, if they did nothing and then released the seven years, they must have had some serious business backing, some serious belief that this is going to work. Now they all start small, right? Every year a great story starts. That's nice. And they need to showcase the, the progress, right? You cannot say, OK, I'm going to do this in two years. Then the idea is already done. No one wants the platform anymore.

They're already past the, the whole problems that they're they're into. And they're like, we're frustrated enough. We're not going to wait for two years. So getting that quick turn around, trying it with people. I think with the first movers I had a different also opinion on this. I think if you are able to find who are, who is the team or the, the, the people within the organiser are very excited and are like looking forward to it. Use these people, yeah.

Yeah, use the energy. Go for them, yeah, because they are the ones that are going to help you the most. Most. Yeah, all the. People that complain go fix it now. Honestly, like that's feedback that's incredible. Like one of the hardest things is, is getting good feedback from from developers. How are they actually using the platform? And developers that are very angry about stuff within within an organization. Amazing. Use them if you can onboard them

and make them a supporter. The rest is going to be smooth sailing. Yeah, yeah. I feel like the developers are very critical. And the way for them to keep being critical is to actually do something with the critique, right? Make them feel heard and then implement it. I've also seen companies or organizations or teams where critique is labeled as negativity and then people kind of shut down and they're like, well, if I said this, you would just think I'm, I'm very negative.

You also have the those people that are very grumpy and everything is just shit. But yeah, I feel like if critique is very valid, something needs to be done with it or you need to accommodate for it in some way, right? We're focusing on this and this is then maybe next or This is why this is not a concern at all. So have you thought about XY and Z? But there needs to be a two way, an equal level of dialogue. Yeah, we mentioned that one of the success metrics is a

seamless developer experience. How do you measure that? What does success look like for people that are building that platform? OK, that's a big sign. No, no, perfect, perfect. So multiple metrics obviously,

and multiple things you need to look at. I really like them. So there are a couple of of metrics that I'll talk about now. It's first of all, it's the onboarding time. OK, So I read this summer, I think Spotify did this, can't remember. It could be. And they measured the time from the first day you start working at an organization until your 10th or request. OK, the 10th, not the first till.

The 10th so they see how how much time it's taking you to be familiar with your work, be familiar with what's the landscape around you and how fast can you actually help and and assisted to collaborate and and provide your value. And that's why they tend. OK, so that's a really nice metric. I really like. I think another one is called service create time. How much time it takes to create a service goes to production as I'm not, by the way, correct me if I'm wrong.

So I'm just reciting my head. So that's also a very nice one. Others could be obviously you can use also the space metrics, daughter metrics are typical frameworks that you can also have a nice one which is very small and can help is the NPS not promoter score. OK. And that's also to gauge the sentiment towards the platform, which it's a very lightweight, it's very small form where you can send it away like every month survey.

And yeah, it's a very small survey, like 3 questions that's it. And then you can track it over time, see how people are are feeling about the platform. And then you can also correlate it with what features you've released. So then you can have an idea of am I right, Am I on the right path or not? Yeah, I think freeze out some stuff. No, I, I like it. I wish, I wish all companies would do this. OK, right.

Because I think also the state-of-the-art platform engineering reports came out and again, like I think it was like 60% of the companies under measuring that platform

engineering success, yes. Interesting, I saw that yesterday I. Think, yeah, it's still crazy. Like the number is also not, not not going up or go down. So they're just basically just doing plus initiatives without measuring if what they're doing is a success. You know, plus engineering is all about flow and increasing productivity, right? That's the promise. So if we don't have a baseline like how do we know if we're actually becoming a success with our initiative?

Also don't forget about business metrics, right? So we talk about all of these things. These are more platform engineering related to the team itself. Also want to look at the return on investment, right? Because you still want the buy in and you still want the funding and you still want the backing of the executive and the business. You also need to check the return on investment for your platform. How much money are we putting

in? How does that match up to how much money we're getting out of it? Right? So one I think measurement I heard as well is how many developer hours have I saved by creating this golden path for example. Cool. Yeah, which is very nice. But then you also, that's a hard one. That's a hard one. But you need to measure before your platform as well. So the idea of measuring is not just after we're done, it's also before, right?

So before we start, what's happening and the reason behind that, like memories and organizations are very short term because if the platform is successful, they're like, oh, life is amazing now, right? Five months ago we couldn't do anything, but now everything is perfect. So you need to also see what was happening before to justify how good your platform is. Yeah, I feel like like a survey is the easiest thing for me if I were to be in control, the lowest hanging fruit that I could do.

The only thing is some people don't like surveys. But in any case, I feel like if the survey is something we do something with and people can see results, then that incentivizes people to give their feedback. That is 1 The other metrics I feel like are sometimes very hard, right? There are frameworks for measuring developer productivity, but they can also

be manipulated, right? If people know how they're measured, especially on individual level, if it's actually going to that scale, then people manipulate it, right? I'm more productive. Actually. I do many pull requests. My 10th pull request was on the first day because I just changed 10 read bases. So yeah, I think it's interesting to look at how metrics operate and then also how an organization revolves around those metrics.

Now, the companies that don't do any metrics, that for me is very interesting. And I have no clue how they then indeed say, OK, this is successful, but it also how they keep investing. Is investing always a

conversation? Because I feel like if you set up a team, even if you start from from something, if you start small, you need to have good backing, right, That this is actually going to increase productivity. And if you don't measure that, I don't know what people are actually doing or how they can do this continuously. That's a good question. Yeah, yeah, I, I also don't know, like I think in the beginning you also ask like when do we start the plus for engineering?

And I think for me, it should always start with measuring that something's going wrong, like with the increased productivity, decreased productivity, decreased experience, and then you start the plus initiative. So the moment that they don't measure anything and then they try to uphold this story of being like, oh, we're going to increase productivity and developers are going to have a bad experience. It's all just fake because there's no numbers, just fluff.

Yeah, it's just fluff. They just need to believe that it's it is and how. And then eventually, of course, they will stop talking to developers and then they will figure out that, oh, they are just building a platform because they're like building a platform. That's also probably why they're not measuring, because they're not actually helping developers. They're just building and using cool tools. So I think most of those companies that are not measuring are probably scared to measure.

A lot of red. Flags. Yeah, it's definitely a red flag. Yeah, yeah, yeah. Yeah. I would I would tell them to go shameless plug or read my blog. OK, yeah. On the website platform Engineering Matrix on xavia.com. Go check it out. Go check it out. Interesting.

When we talked about developer productivity, right, that's the smallest thing that you can do when you're already doing platform engineering, it kind of triggered something in me because nowadays, early 2026, organizations have an opinion on productivity for software engineers specifically because of AI tooling, right? If I have an agent that can do something or I can vibe code something myself, why is it so

slow in my organization or what some leaders think? And then it's like, yeah, you guys need to be more effective or we need to modernize and we need to do that more quickly or we need to save developer time. And people all of a sudden have an opinion, which I think is very interesting. I'm curious to hear what you've seen or how you also view that people having opinions on developer productivity. Oh. Yeah, I like that.

It's a good one. Yeah. You know, there's a lot of in the report words coming out that developers spend most of the time actually not developing. So let's say it's 2030% of the time actually writing codes, right? And the rest is just meetings and getting stuff to production and creating ServiceNow tickets and stuff like that. So if you then improve the way in how fast they can write codes, you're only improving the

small increments of their work. It's 2030% if all the rest is just in getting stuff for production, making progress, all all all those kind of things. If you really want to improve the federal productivity, you should not look at you should also look at them helping AI right, But also how to get stuff faster into production, how to make sure that we actually get security on board faster. How these fast flows, these golden pads, because that's really where most of the ball is

being dropped right now. That's the, yeah, basically the resistance where the device gets stuck, and if you just improve it in front of that, it gets stuck more and more and more. Yeah, I like that a lot actually, that perspective. Is that also If not. And I wanted to put you on the spot quickly. Why not? There's this statistics you always gave about, I think about AI adoption and how executives look at it versus development. Yeah, yeah. Because I feel like this is

very. Yeah, yeah, very relevant. I think it's a new report from IBM and they say that 80% of the executives see that they need AI to stay ahead of the game from the competitors. And then 20% of the executives say that their infrastructure is ready for AI.

So if we want this to work and we want to use AI to stay ahead, we actually need to first look at our infrastructure and how we're supplying tools and LLMS and models and APIs to our developers instead of just looking at the developers being a go fester with AI because your infrastructure, your platform is not ready for AI. It's.

It's very revealing the statistic because then there's this huge disconnect and what you mentioned, like now with the advent of AI and how executives are looking at it, 2026 executives think this is the current landscape where it's completely different. There's no connection whatsoever. Part of it is metrics and what we talked about. They have no idea what's happening. They cannot see numbers.

This is what they love, right? They want to see numbers that are very easily measurable and they can describe something for them and they don't have that. So that's the disconnect. I think it's with metrics with more knowledge going up top about the current state school. And then also platform engineering, again, having it ready for hosting your LLMS or hosting your AI workloads, making sure that you're also using AI within the company in a secure way and it's a compliant

way. Platform engineering also solves this problem, so. You mentioned the OK, if engineers are actually 30% doing hands on coding and 70% is processes or meetings or just somewhere it's clogged throughout the process. If I then as a platform team focus on removing those bottlenecks, less meetings, more focused time, is that also platform engineering? Good question. I think a part of it, yes, of course less meetings is not is not really platform engineering,

right. Well, if you're having meetings about going to production and stuff and that gets automated, then it's probably is platform engineering. But I think it's on the the fence of just improving how you work being being more lean as a as a company and the platform engineering can also support that a little bit. Gotcha. Yeah. It's an extension of what what you're achieving is. Then an extension of it is maybe less meetings, less processes,

less. Because it could be that all of us are in a platform engineering team at a client somewhere and then we see that meetings are actually the issue, right? So we can build whatever tooling. But yeah, we're going to optimize also that same 30% or a little bit more because there's it's not just coding to go into production. But if meetings are really the issue, then that's a very interesting bit for me. And that's kind of organizational behaviour that

needs to change, right. I saw that SML kicked out. I don't know what the statistic was. I think it was like 1600 people and almost all of them were middle managers. And then I talked to some people that work there and they were like, yeah, one of the reasons I left was I was just getting dragged in meetings. And the people that were organizing those meetings, they didn't really have any influence. And they were kind of in the middle and they're trying to

manage. But in the end, they just clocked the system throughout. He said that's the reason I left. So yeah, I think a lot of people are going to be a lot more happier, a lot happier in the end. While also ISML published kind of record numbers. So it's kind of a disconnect there. But I thought it was interesting that is more behaviour and organizational change.

Because also throughout this conversation, I was wondering why platform engineering is not just called developer productivity, but all of those meetings and behavioral change that also influences developer productivity in the end. So yeah. Yeah, Maybe I'd speak a little bit because the definition as well, right, Platform sharing is the discipline of building an internal developer platform.

So that's really the the product and what we are trying to achieve with the product is developed productivity. But you can also do developer productivity in other ways instead of having this centralized platform rights, because you just look at processes and change that instead of it would still fall on the platform engineering. But again, platform engineering is a slippery slope that everything can fall on the platform engineering these days.

Yeah. But in the end, it's still about developer productivity, developer experience by having this internal developer platform available for your developers, but it doesn't have a start there. Gotcha. Yeah. If I then look at platform engineering, do AI tooling, does that also fall under that? So whether an organization uses

cloud code or you mentioned Replit before the show and also Microsoft Copilot specifically or GitHub Copilot even, does that all fall under platform engineering in your perspective? Yes. Yeah, yeah. OK. I think it has this place there.

Yeah. So platform, the platform especially if you have if you have like Kubernetes platform or something, it's the perfect way for orchestration of applications, but also large language models or other models or maybe you need specific GP us to train specific models. That's all something that the platform can orchestrate for you. So it's definitely has its place in order to enable AI within organizations.

Plus especially in the clouds of entity these days you can actually have something running locally on sites offline ish in your internal network instead of buying something from open AI or or cloud for example. And then if you're setting up your, your landscape in a way which follows our the principles we talked about. And so your NLMS, your data, everything related to your organization stays within your, it's a environment because you are following the secure way of

provisioning infrastructure. It's scalable, it's consistent, it's the same across from local up into production. You don't have any fear of let's say having these LMS go outside of the environment. Everything is compliant. That's if you still follow that before transfer engineering software, you build it to run it, and you have developers also creating infrastructure and there's like 300 tools.

For one thing, you might find it very difficult to kind of clamp down on what's happening and understand what's running in your landscape with AI, with data being fed into the anonyms with all of that. You can see where this is going to go later on with like data breaches or problems within your organization or these things we've already seen like people use ChatGPT online and then upload company data, which is

also a huge problem as well. So if you're following the principles, if you are providing these golden paths for developers and you have a very consistent way of provisioning infrastructure for developers, add on top of it AI. And that's also very good for you because then it's secure, it's compliant, and it's within your own environment. So it's stood for as the principles of building infrastructure that you already specified in the beginning.

What is your opinion on I love this term shadow IT because we already mentioned, OK, if the platform is bad, then it's it's worse than not having a platform at all. And typically one of the symptoms that I see is that people just get whatever tune and they don't tell anyone.

It's like very hush hush. And I know what I'm doing. OK, no personal data, no, no coding. But but yeah, I have this thing and it makes me more productive. Yeah, I get it right. And from a platform engineering perspective, it's it's horrible to to see shadow IT because it's the side effect of basically having this incompetent platform, right? I there's something that I cannot do or you're not providing me the service.

All right, I'm going to my manager and he just puts his credit card on his new AWS account and well, I have a non compliant Awsifier, which is of course good for you, horrible for the company because it's it's not secure, it's not compliant, it's not regulated. Nobody's checking it. What happens if this manager leaves? Will the any of us account just closes?

Yeah, so I I get it. But I would really say to developers, if you're on the brink of, of doing this, try to go to the plus regime and be like, hey, I really need you guys to either change step it up. Otherwise I will go and do the shadow IT route. Maybe that will be a wake up call for them. I'd be like, OK, maybe we should really change something because they are having actual issues we're not solving and they are figuring out themselves. Yeah, interesting.

It's also the escape out, as you mentioned, right? So being able to I'm also also like a huge amount of people using the platform, but also taking their own path. That's fine. And the idea here is that there are still guard raids, of course, but you're also able to explore your on your path on yourself by yourself, sorry. And that's within the guard raids.

So we're still secure, we're still compliant given you're not using the golden path, which is fine, but you also are on your own path to discover or innovate or have a new idea in mind, but within the card rates. So you're still within that area of the platform team. And that's I think also something that the platform team should be very clear on how intuitive it is to use the escape patches as well, is that it's very clear that you can go both ways.

We always prefer Golden Path, yeah, but you also can take your own path if you need to. I think that a lot because I was thinking if everyone needs to go to this platform engineering team, right, Either for the escape hatch or for the golden path or for new requests or for this is not smooth yet. Can we fix XY and Z? They might also become a bottleneck, right? If you get so much feedback, then your throughput is kind of throttled and you have to shift

through. OK, where's the value and what do we prioritize? But that also means you need to manage expectations of the priorities. You're not going to pick up yet or not going to do at all. And you have to have kind of an equal level of dialogue and make people feel heard. Otherwise you'd lose interest completely. And the bigger our organization skills, I feel like it is funneling towards this team that is then responsible for platform engineering.

Have you seen something like that or how do you accommodate for platform engineering or the team that is responsible not being a bottleneck? I think you you start first of all with whatever the platform or the the minimum viable product is ready for the first team. You don't announce that to the whole organization. This is the first thing. It's not all in. They need to set to the team and they would be, as I mentioned,

the evangelist. They would take you through and you work very intimately with them, get their older feedback, all of the bugs they're facing, making sure that the process is iteratively improved, and then you start scaling slowly across multiple teams with a full scale like organization. If the platform is very well adopted, I'm assuming people will help the platform team to get through a certain bottleneck when like a lot of things are not happening.

If they are fully invested in the platform, then it comes to like huge scale. I don't know to be honest.

Like maybe you know, I'm not sure. I think the best way of making sure that the platform team does not become a bottleneck is on to everything self-service. So take it OPS, you should not need to create a ticket for something standard, right? It should be self-service. You should go to portal, use CLI, use an API, whatever you should be able to request yourself. That's one. Two ways have very good in the

sourcing. So the moment that you need something, for example, you're very particular on the Ruby for wheels, for example, you want that to be supported by the platform. Sure, here's a repo go implement it. We have an example for Java Spring Boot or something. You can figure it, you can figure it out. If you need some help, let us know, right. Just implement it themselves and then keep a little bit of control over it.

That's the best case because in that way you can have a platform that supports build for use cases without having to skill the platform team increasingly. Yeah, interesting. That's nice. I was also wondering because I've been in a lot of small organizations. So then part of what I actually run in software, I need to be aware of the environment. I need to be conscious of get how much load can the team handle?

Do we go serverless? What what trade off do we make for cost of ownership in the decisions that we make? And I like those thoughts. And now I'm in bigger organizations and in bigger organizations, it's kind of smooth sailing because I don't have to think about that. But that also kind of takes away from it. So then looking at my personal skills, if I were to be at a bigger organization and I don't think of that like that muscle

will kind of atrophy. And I'm wondering what your perspective is on that because part of the developer ownership, it's, it's huge, it's way too much on their plate. I also say that the whole product sense is becoming more and more important as well. So if you talk about tooling, if you talk about creating software, if you talk about knowing your customer, thinking from a business outcome perspective, it's a lot that falls on the plate.

So I'm good with having some stuff fall away, but I'm, I'm very aware that the right stuff needs to fall away. And if I am in a bigger organization where things are kind of accommodated for? Will I then feel pain or experience kind of difficulties if I move into a smaller organization and all of a sudden those responsibilities fall again into the plate of the developer? I think that's really the balance between a good and a bad

platform. So in the end if you go back to before dev OPS, it was really separated by dev and OPS and OPS would be gatekeeping of rights and and ownership of of servers running and what kind of skill you need. Then DevOps, it became completely the something for the developers to take into account. And then you can say platform engineering supports developers that you are still responsible. We just help make it go faster. But you still need to think about it. So we're not gatekeeping

anything. We're not trying to just trying to make your life a little bit easier, but it's still on you. You're still responsible for making sure that the there's the right skill. And that's all those things still on you. We just help make your life easier. That's good, yeah. What were your thoughts? Yeah, I think, yeah, makes sense. I'm just trying to think of how you would go from like a huge organization of just doing one thing and then back. I can see the pain in it because

then it's a huge organization. Everything is very organised in a way. There are processes for everything and then you go back into like a small organiser, say, OK, how did they used to do this before? Yeah, that's a kind of a chaos. Might be why you leave. Though yeah, it could be, definitely. But yeah, definitely with a good bad platform part.

I think I still believe in the fact that developers should be able to let go of all of the things that made their cognitive load really high in the past years and make sure to focus on writing code, very good quality code.

Yeah. And that's the main thing. And then if they need to go back to it like a small organizations where the roles are a bit murky and you need to take more wear and more hearts, then yeah, I think you just need to exercise that once again and help with like the platform team or all of the learnings you had in the bigger organization, how things are done so. Fair. Yeah, there might not be a good answer there. It's just a choice in the end. Yeah, exactly.

Yeah. I really enjoyed picking both of your brains about platform engineering. Is there anything that's missing that we haven't discussed yet that you want to address before you round off? I'm going to give you both the second. This is the curveball I always throw, yeah.

I would say at least from my end, the thing that usually is missing when we're talking about like tech or trends or stuff like that is we talk a lot about the technicals part, but you forget the business part a lot, which is like, and then these are the people that are going to fund your initiative. These are the people that have the money, these are the decision makers, and these are the people you need to make happy so that your initiative keeps going.

So I think that sometimes gets lost, but it's very good to always focus on that part as well, I would say. Gotcha. You know, don't lose your your champions from the business. Side you need the money, yeah. So yeah, and and don't don't build a cool platform. The other platform that developers want to use and will use in the end and for developers, help your platform team build something that they want that you want to use. Good stuff. I love it.

Thanks guys. Thank you so much for coming on. This was a blast. Yeah, no worries. Thank you. Cool. We'll round off here. If you're still with us, let me know in the comments section what you thought of this episode and we'll see you on the next one.