 get what we want to reach. And I believe that if you want to do platforming at an enterprise level, but pretty much at every level, right, you need to have a mandate. And you need to fit into some sort of strategy. And depending on where you are in your evaluation or budgeting cycle or whatever, your strategies have to vary. And then once you have the mandate, you have to make a good amount of things. You need to check a good amount of boxes to keep that mandate. And we are not going to talk about any product today. We are not going to talk about how to do platform engineering. We are exclusively going to discover the species manager, which I would describe as a fairly scared human being. And then we are going to discover what are the problems in the current stakeholder process that make platform engineering a pretty non trivial thing from a political perspective. Right, so this is what we're going to do. So species manager, and then for the first pillar that we're going to discuss is the platforming mandate, we want to understand managers and their decision making process in a little more depth. And then we want to understand vertical managers and their incentives. I don't even know whether that makes sense. But what I mean is, like, how are app dev VPs thinking about things? How are operations VPs thinking about things? How are CFOs thinking about things? Because the problem with platform engineering is that the that there are a lot of competing priorities in the in the in the in the equation, which makes it sometimes a little difficult. Yeah, so we're going to start with actually the species manager. And we are going to make it a little simple, we're going to differentiate two types, C level executives and middle management. And middle management just clusters, director, senior director, team lead VP, depending on the size of the corporate. And then we are going to look at two phases, because I believe that there are really only two phases, if you generalize a little bit, it's the strategy phase as the execution phase. So C level executives, if you're a C level executive, you need to understand what you're getting yourself into. You're essentially saying in your work life balance, I am taking in a good amount of cash compensation, hope I mean, in your best case. But and this sounds like a great idea. But I'm trading job security for this, like the likelihood of you surviving in your job for even a medium period of time is not super high. If you are and that holds true for, you know, CIO, CTO, CEO, you are always without any warning under the threat of being fired. And it is that is drastically more than if you look at any individual contributor, even as an individual contributor, let's say it's not a layoff wave, you are probably seeing it coming. As a C level executive, you're not seeing it coming because none of the other managers, including the CEO and the board have any interest in giving you feedback that tells you whether you are going to be fired in a month. So you are paranoid. You usually believe something is behind the corner. If you are reporting to the CEO, you're also usually scared of the CEO. And this makes it sound a little dramatic. But I think it is important to understand that they are very often very nervous. And that a lot of their decision making is way less data driven than you think, and way more, what has the CEO told me over a beer? And what was this one remark that the CEO make made? And then the thing that you're most scared of is your board. Board meetings are in the vast majority of cases at corporations and companies in a very, very uncomfortable situation to be in. You have people that see you, let's say once a quarter or once a once every like half every six months, they are judging you based on very vague metrics. They are very often not spending too much time. They're just looking at what feels obvious to them. And they have the power to just snap their finger and you're gone. And that means you want to look good in front of the board and you want to look good in front of your peers, pretty much like in every other role as well. And that's important to understand if you look at how precise they are sticking to their strategy and execution phases. If you're lucky, the C level executive has a good set of values and will stay within those values. Otherwise, they're optimizing on, you know, what's legally possible. Now, this might be a little bit of a, you know, dark view on the reality. But, you know, it's probably not that far away from the reality. Then you have the middle managers. The middle managers are squeezed in between C levels and the team. That is a, I think, good description of their reality. They are getting pressure from above and they're getting fresh pressure from from their direct reports. And they essentially have to be, have to implement what the C level promised to their peers and the board. And they are going and they are benchmarked very strongly against those metrics. And at the same time, they will get the questions and the direct touchpoints from the individual contributors, which is, is, you know, like a sandwich position that's also pretty tough. And they're also constantly afraid of being fired. If you aspire to be a manager, keep this in mind, you are, you are essentially selling peace of mind in the vast majority of cases. You also want to, they obviously want to shine. And they want to shine, making sure they're not deviating from plans. And this making sure they're not deviating from plans tells you why they're inflexible in just changing the course. Like I have it, like very, very often even if we are working with with other companies and the managers, then I'm wondering, like, it's, it would clearly be better to make the move now and change something. And they're not doing this. And if you want to understand why they're not doing this, then they just don't want to make a mistake. And they just don't want to deviate from plans. So this is the middle manager. Now we have two phases. In the strategy phase, the strategy phase is a phase that starts, let's say midterm, where they're starting together, intelligence, and the intelligence, especially on a company Y strategy that then trickles down. In this, in the strategy phase, the middle manager can input information into the into the overall C level decision making. But there are also a lot of things that have nothing to do with reality. It's just a C level thing that makes sense, or Gartner said something, or my colleague at another firm, my PA at another firm said something, it can be very fear driven, like, guys, we all have to do AI now generate if AI is so important. And then there are just, you know, some new initiatives bubbling up. Obviously best case it would be actually to do something that has direct data driven basis. But very often that's not the case. Depending on what type of cooperation you work in, this can be a three month cycle. If you are, let's say the scale up or start up, or it can be a 12 month cycle. If you're at Amazon, it's six months with their operation plans. So it really depends on what on where you, where you go in this strategy phase. This, this is where you actually want to where we are best case you are actually getting into your strategy phase and you are able to position the mandate in that phase by making very, very simple arguments that make sense to the managers. And we're going to look at the vertical structure of the managers later and what they are actually focused on and what they care about. But the first mistake that I'm often seeing when those mandates are positioned is that the people feeding into those strategies say things that don't really matter in the boardroom. Like even, I mean, Dora metrics, for instance, may be matter. But what really, really matters is things that feel way less obvious if you are in the nitty gritty building applications. One of the things that's, for instance, best in positioning this with with the sea level is to say, Hey, if we do platforming, you are now able to attribute the usage of cloud resources directly to the team. So you know who consumes how much. This is something that is not something you would think first off as the impact of platform engineering. But this might just be what is top of mind for your executives and to understand what's top of mind for them and how you can actually formulate this in a way that it will be finding its way into the general strategy, you have to understand what what's the situation they're currently in. Do they have to cut costs? Do they have to are you working in a in a bank and a new bank is killing them in features? And they have to develop features faster? Well, then the only thing you can they are interested in is feature velocity and development. Do we know that there is a significant problem with cloud costs and attribution? Well, then that's probably what we're what we're looking at. So you really have to develop a feeling and put yourself in their shoes and forget pretty much everything that you like from a technical perspective. Because the vast majority of managers, they've heard the word microservice, but they don't care. And also they can't conceptualize this. They think this has something to do with Lego blocks, or they probably have no idea what an API is they have very little idea of the software development process. And they also don't have the bandwidth or will to actually dive deeper. You have to find something that they are afraid of or that they are interested in that they want. And you have to count directly into into this. So this is the strategy phase best case, you can position something in the strategy phase. And you can make it a like you can make a direct case and you can take a direct mandate. Then in the execution phase, once the strategy is actually done, the strategies get surfaced to the board. There is an actual meeting where the sea levels discuss this and then they present this to the company and they also present this to the board. And in the boardroom, there are the the board members and then there is a like a like a group of observers and analysts that are just taking notes. And the board members, you have to put yourself into their shoes. They have very, very little touch points with these companies way too little, usually. So they are making pattern matching based on very few information. The most revealing information for them is what did they tell us in the last term? And what have they delivered? Plus what are they telling us now? Everything that happens in between is is too detailed. They don't really know. So and the executives know this. So if you're going into a board meeting, you want to give them a strategy that you know you can actually achieve. And you want to give them a and you want to fulfill those plans, you want to be sitting there in the next term and you say, this is what we promised. This is what we what we delivered. You do not want to be in a situation where you continuously have a sea level who has promised something and then nothing came out of this. There are very, very very of this, which is why when you're in the execution phase, nobody wants to change their plans. The if you are so that means if you're in the execution phase and you want to position a platforming mandate or you want to get in to that cycle, you will need to position this as a rescue mission to another strategic objective. You cannot come up with something new. You need to say, we had the strategic objective to fix CD or make ephemeral environments a reality, which then counted into feature velocity. We are clearly failing on this objective. I have a silver bullet that can help you shine when you do your next review. So I have something for you, dear manager, that helps you rescue a strategic objective that you are currently not delivering on. So that means in simple terms, you have to best case, just play the long game, bring it into the strategy process, or you bring it into the execution phase. And in the execution phase, you can only get it in if you tie yourself directly to strategic objective, and you essentially position this as a rescue mission. All right. If you don't fit into a strategy, you get no mandate. And if you don't have a mandate, you will probably not get very far. There are some other things you can do to essentially, and, you know, force your way through this, we're going to look at this in a second. But, you know, ideally, you can get a mandate. I have a pretty good set of data, because I just have a pretty good set of data. And I think that there are currently maybe somewhere between 400 and maybe 600 global platforming mandates out there. So around four to 600 organizations with more than 100 developers have a formal mandate for platform engineering. That is not that much. It's probably like five times more than last year, and it will be way more in 2024. But for 2023, we are still in the very early days. And that also means these mandates are something executives have probably not really heard about. Platform engineering is new to them. Gartner, you have these, you know, helper things. Gartner has it on the hype cycle. ThoughtWorks has it on the radar. But if you look at, if you have like if you have executives that look at these analyst briefings, at Gartner, for instance, it's hype cycle position two, which is peak of peak of inflated expectations or something. And that usually tells cautious executives to wait for another year. And so currently you have the first movers, if you want, or, you know, the second waves of the early movers, if you want. Good. So the next thing that we want to look at are the vertical managers and their incentives because they differ wildly. So this is a beautiful model from Gartner that one of the analysts showed me yesterday. And for me, this was really revealing. And it showed that the current incentives in the standard cooperation and the standard enterprise are really not aligned if it comes to platform engineering. Like you are fighting in uphill battle. And it really, it really made me think about where, like, how long platform engineering will actually take to go mainstream because of this. And I, if we will look at this, it's interesting to look at the cost centers, because all of this has something to do with, you know, costs and who's responsible for what. And it also helped me realize that the organization almost always thinks about the creation element of a workload, which is my interpretation why everybody is doing backstage, although, you know, backstage is a good product. But just looking at the average usage data that we're seeing from a portal installation after 24 months, it sees very little engagement and very little usage from the developers, which again is a risk. But I now I'm gaining a better understanding for why people are starting with that part of the layer. So look at, let's look at actually the creation of an application. So you have a product unit and that product group says we need a new application. And the app owner then guides the application developers and says guys, you know, why don't you figure out how we're going to build this? And let's say we're a pretty rudimentary shop. So we don't even have a cloud center of excellent, we don't have policies, nothing. If like in these very, yeah, you know, in that stadium, the application developers will then say, okay, well, this is how we're going to structure this, we need ABCD resources. And this is the rough budget. They will hand in the budget to finance and finance will not approve this. And then the application developers are going to start developing this. And when they're stuck, they're asking operations. But at sometimes they're essentially, you know, tying this inner handing goes over to operations. And then this gets actually maintained and developed. Now, you know, we'll all say, hey, you know, is this true DevOps, you build it, you run it. And it doesn't matter how often we shout this in the average enterprise. This is probably how it's going to look. Because application developers say, well, I'm not going to do the database updates. And I'm not going to be the one responsible for, you know, the production outage of a huge database. And, you know, I'm going to do my thing. And then at some point, I'm working with with cloud ops to actually keep it maintain this. Now, operations is sort of receiving all of these requests from developers. In the vast majority of cases with tickets through GRO or whatnot, service now. And they have this increasing lake of stuff that they have to deal with. And like this huge amount of repositories. And, and that is obviously, you know, like, like, like a tough situation. But essentially also, the second the application has handed over responsibility to operations, we are losing the the resources and their attached costs in the huge lake of other resources in an absurdly low number of cases are the teams even able to attribute the cloud resources back to the developers, which is a huge pain for the CFO because the CFO has no idea what's idle, what's actually being used, and what application developer development team is actually producing what costs, which is why you have all of these fin ops teams. Now, then usually they say like this sucks and we need a we need to fix this. And then they often build cloud center of excellence. They introduce they have architect groups and these architects groups have cloud policies. And so if the app devs design something, they'll tell them, hey, like, hey, guys, not another cluster, please use namespaces in different staging. And please petition this database in different ways to expensive and you're over, you know, it's just too complex. But they will essentially also not be really involved in the operations team. So what, like, who has what incentive? The operations team has is like, is increasing in headcount. The more volume they're getting. They have almost zero interest to intervene with what the application developers are doing, like the app devs do this, they do this, and they want to essentially, you know, keep out of their way. The last thing they ever want to do is refactor existing applications because you would need to go back to the app owner and you need to tell them, hey, we need to do refactoring because we need to, I don't know, streamline our resource definition for Postgres. So operations is essentially not highly incentivized to actually go upstream and change the workflow of the developers. So operations essentially, you know, focusing on what they're what's in front of them, maybe introducing terraform cloud at some point to streamline some things. But, you know, they want to they don't want to look left and right to too much. And the application developers, they want, I mean, they are annoyed by always having to go to operations. But they also just want to be left alone. And they their existence is tied to the fact that they have budgets with the finance team, they're building their thing. And every everything is fine. Finance is just annoyed that you have so much, like they the the CFO regularly calls the CIO and says, what the fuck is going on? We are increasing costs continuously. And like, how is that even possible? And the feature velocity doesn't doesn't increase. And that's because we have this huge lake of resources. Nobody knows what's going on. So the sea levels look at the IT department and the and say, like, my God, why is this so expensive? This can't keep growing. And now, if you go to them and say, like, hey, we want to build this platform, then they will say, yet another product that you're building, like, are you kidding me? Why don't you start saving costs on the other products? So, like, not a perfect situation in terms of aligned incentives and platform engineering is essentially building a layer across all of these groups. So, so what's the lowest hanging fruit for teams to do? Well, it's essentially optimizing the handover point between application developers and operations to make application developers request new services with operations. What is this? A portal like backstage. So this also this is in my interpretation why everybody starting with portals and platform engineering, which I've not stopped in super shy and saying that I don't think that this is the perfect thing. You should do it, but it's not exclusively was actually driving the return on investment. So why does this make sense? Portals give the application developers the feeling that they can self serve, which makes the operations team look good. But at the same time, portals don't really, really interfere with the things that operations do. And it doesn't really interfere with the things that app devs do. They don't have to change their workflow. What they actually would have to do is fundamentally, you know, change the way they consume and configure infrastructure. This is what they would have to do. But this is a tough problem. Doing the portal is sort of the the tame alternative. It's also good for the sea levels because the sea levels are being fed a thing by Gardner that I also just learned that says you have to map your estate, the never ending idea of a service catalog. And we have to get into macro, how do they call it, macro services. Macro services are a collection of microservices that have a certain capabilities, capability. The business should map them their macro service estate in order to help the business build hyper tailored applications for internal and external usage and to drive effects of scale. It's the Lego block strategy, super easy to understand if you're non technical and something that the sea levels buy very easily. What do you need to show nice Lego blocks a portal? This is why people call this platform engineering. Everybody smiles and says we now have backstage and we're doing platform engineering disclaimer, you're not doing you're not doing platform engineering, you're just putting a user interface layer on the mess that you have right now. This might feel great for the first 12 months, but I can tell you from a lot of failed installations that it's not so great and it's not actually keeping you in the mandate in the months 12 to 24. I recommend, for instance, watching the platform contact from Netflix 2022 and then the platform contact from Netflix in 2023 on how well that went for them. And I'm going to leave it at this, but this thing that we're seeing here right here is the fundamental problem and the misalignment of incentives. What we would actually need to do is and if we if we want to build like a platform as a service experience is build an abstraction layer for application developers where they can say they actually can really self service pick and choose things and the operations team really only build the fundamental blueprints for the conflict layer. Now you'll ask like, how is this different to scaffolding in backstage? Well, the answer to this is scaffolding and backstage is only once in the lifetime of a service at creation time. But we don't need once in the lifetime of a service. The majority of the lifetime of the service is post creation. You have an existing workload. You need a new database. Well, how is that going to work with scaffolding a new workload? It doesn't. We need to have a model that feels like Heroku, which means that we have an abstraction layer across all of these functions where the operations and platform team set the rules. The app devs stay on these golden paths wherever possible. We are tagging every single resource to make it cost efficient. We really have a internal platform as a service. But this is very difficult to get because of that misalignment in incentives here. OK, this sounds like a super gloomy thing. Why is Kasper saying this when he's always advocating platform engineering? Well, I'm saying this because I think it's really important for you to understand that this is a tough shit. And so, yeah, the competing priorities are incentives. They suck. Let's go through them again. The CEOs want to save money. The business units want tailored software fast. The CIOs are overwhelmed with pretty much everything. The app devs just want to be left alone. Operations wants to keep their job and also their footprint. Like how great is it if your estate covers, I don't know, 200 million in spend and you have to actually reduce this. This is really not what you want. Everybody is afraid of restructuring. Everybody has seen the trauma moving from on-prem to the cloud and how much time that costs us. Everybody is afraid of replatforming. If you say that people get nervous and also everybody loves building and tinkering stuff, very few people like to then actually or are able to then actually deliver systems that work at scale. Now, so let's say you've went through all of this and you've been able to get to a mandate which you might not been able to do this this year, but next year or latest in 25 you are going to do this just because, you know, Gartner says so and it's the general trend and then you have your mandate. So what do you do? The answer is you run. So and the key importance here, so he is saying 200. So there's a little bit dispute. My colleague says 200. I think it's 4 to 600, but it's a low number. And a very, very simple rule of thumb is overcommunicate, always under promise and always over deliver. And that is something that I'm notoriously bad at. So I'm not. I don't want to say that I'm doing this well, but it is very, very, very important if you want to keep the mandate in the next year. Do not promise the glorious world. Watch the Netflix talks again. This is non-trivial, what we're doing here and it's early days. The likelihood that you will nail it on day one with a large scale platform that spends the M over Kubernetes to serverless and will do automated integration tests and deploy with automated sign off capabilities and strong our back from Dev to production within 12 months. That is essentially zero if you want to roll this out across 500 developers. So don't tell anybody you're going to do this because the reality is you're not. If Netflix is not able to do this, you are not going to be able to do this either. So make sure that you create realities and real experiences as soon as possible. Rather than make sure you start and you anchor very early that what I've essentially just said, tell this to your manager. Tell your manager, most platform teams get me wrong. Kasper said so. Don't say Kasper. Just say like most platform teams get this wrong. They always start too large. I want to start small. I want to build something that's 10x better, but only for one team. And I'm telling this to you right now. Don't expect the world. We're going to make one thing well on a small scale. And once this works, we're going to go to the next one. Nothing is stronger than real users. Let's say we want to use this. And this is like it's such a trivial thing, right? I mean, I could, you know, could put this on Instagram, but users that say, I want to use this platform, those will make sure that your platform endeavors are alive. And you only need one team that says, this is 10x better than what we've had previously. And so what you should do is you should focus on that one team. If you have the mandate, don't do a big bang. If you have a mandate, don't spend too much money. If you have a mandate, don't do everything at once. Look at a team that likes you. That's interested innovation. That is on an incredibly simple tech stack, containerized on Kubernetes with Postgres, NNS3 database and DNS. Period. Not more, not less. And now double down on them and focus your everything you do on making the experience for them amazing so that these developers start screaming if the managers want to take it away. Because managers, you know, less than a year ago, but managers are still very afraid of the buying power of the developer. You know, developers are hard to get and developers are, you know, need to be maintained, need to be happy, dah, dah. So if a developer tells the manager, oh, this is 10x better and I'm so much more productive than what I have to do, you have just one. That is what you want to achieve. You have 12 months to do this or essentially one strategy execution cycle. And so that's what you should be focusing on. You rather win one small team, 100% than 10 teams, 10%. That's not going to work. Then think from the business backwards. If the business units have no idea of tech and they want to see their microservices as Legos, well then show them the Legos. Perfect. Show them shiny user interfaces, show them Dora metrics on some fancy dashboards. You know, it doesn't make feature delivery faster or anybody more productive. I know that, but the managers don't. So let's not question this. Let's just do it, but don't allocate too much time to this. Quick and dirty. Honestly, get something out of the box that can visualize this that looks nice. You know, I don't think many people will look at this or touch it much. Doesn't matter. Just make sure you serve this because it will appease them. Then think application developers first, not operations first, operations should essentially follow. Application developers, the experience for application developers has to be amazing because if they scream, they have the buying power, they are the cost center, right? And operations is not. Whether we like this or we think it's fair or not, whatever we can debate this, but the reality is if app devs scream, right, enjoy, you have a case. If app devs don't like it, you do not have a case. And so think app devs first and work backwards from there. If you have a cloud cost center of excellence, they should be your friends. And they should know that a good internal developer platform can make sure all the resources are teched. So you have attributions. You can make sure governance is actually enforced by design. Architects can be part of designing those policies, designing the golden paths, making sure they're actually baked into those workflows. So architects are a very, very powerful ally to have and should probably even be part of your platform team. Then you can always, you know, light a candle in the night and pray for a text say we see IO. That's always something that is worth doing. Good. This is the end of my gloomy little talk. And now I would love to take some questions or disagreements or you can scream at me, whatever you feel like.