7 Ways to Fail at Building a Platform

Why there are platforms in the first place

(0:00) Well, hello, thanks for having me. It's always nice to be able to come talk with people. As I said, today I'm going to go over the ways that I, and other people, have seen things go wrong when you build out your own platform, which I'll get into briefly. You could go at it the optimistic way: how do you succeed in building a platform? But I'm going to do the negative stuff.

(0:30) In infrastructure and operations, I think it's good to start by thinking about why we're doing any of this in the first place. Whether you're in DevOps or operations or whatever, the whole point is eventually to have some running software, an application that someone is using to run their organization. So it's good to keep in mind, with all of this kind of discussion, that the apps are the whole point.

(1:16) In that endeavor, the first thing you need is some programmers. We all know programmers. I used to be an application programmer myself: you sit there, and you're the one writing the software that does the apps and things like that. And nowadays, as I think some of the sponsors mentioned, if I recognized some of the keywords, there's this new type of programmer. Some people would call it the centaur programmer, where you're using AI to augment the way you're doing things, generating code, using tools.

(1:51) So we have not only the fully human programmers, but we have that type. And some people would argue we have the reverse centaur, where the human is really just there to type in passwords and, I guess, drink coffee. So we've got all of those people: the point, the business, and the programmers. And I think there's an even newer workload that's interesting, especially if you're out there DevOps-ing and thinking about platforms. It's a workload we haven't really had much of before, and we'll call it the normie workload.

(2:38) Now, some of you out there have your harnesses, your Claudes, your Codexes, or maybe, like some of my friends, you've built your own harness on an open whatever. But imagine if you had all of these normie people, who aren't IT people, with the same tools, hooking up to all of your IT services, just like a developer would. Think about the kind of load, the kind of things that they would need. They become, equally to those types of programmers, a new type of user that you have.

(3:13) And you see surveys of that slowly rising. Here's one from Anthropic about what normal people, not that we're abnormal, but regular non-IT people, normies if you will, have been doing: about a third of Claude Cowork sessions are business operations work. These surveys come out all the time, because we're all very interested in spreading the use of AI beyond us nerds to the rest of the company.

(3:53) But think about this kind of usage, the strain and the requirements it puts on the infrastructure you have. It's not just one person. It multiplies out to thousands and thousands of people in an organization. So imagine thousands of people taking a PDF and converting it to slides, slides they probably shouldn't have made in the first place. They probably should have just sent an email, or done nothing at all.

(4:31) So you get this huge rise in consumption of what you have there. And all of these things drive, I would argue, a renewed need for the platform. Which brings in the next person, as they're called now, the platform engineer: the operations person, the infrastructure person who's responsible for, put simply, making sure all that stuff works. That it runs, that it's just there, that there's no interruption in service, that it's secure, and, hopefully, that in being so efficient and productive, it doesn't drive your organization out of business because it's so expensive to run.

What is a platform?

(5:09) You look at various sources and, oh, platforms, everyone's looking to do it. And if you look at surveys, there are already lots of platform teams in place across organizations. So the next thing to think about is: what is a platform? There are two things you can look at here.

(5:39) One of them is the Cloud Native Computing Foundation's reference architecture from a couple of years ago, which is great. I like it because I used to only be able to use the diagram of the best platform in existence, where I work, the Tanzu Platform. But you don't allow commercial pitches here, so you can look at the vendor-neutral version too. Look at both of them, and hopefully what you get in your head is that a platform has all of the various components, what we called middleware or services back when I was younger, whatever those developers need above the raw infrastructure to run their applications.

(6:14) And depending on how you think about a platform, it also has a lot of what, to use an older term, we called the software development lifecycle, the SDLC: the tools that developers use at build time. And think about that normie workload as well. They need access to data, they need somewhere secure to run their little apps, they need access to compute. So you build up this whole platform that helps those personas, the developers and the other people, use your compute, and that also lets you govern it and control it a lot more.

(6:45) Like I was alluding to, platforms have been around for a long time. Probably before this, as always, the mainframe person here would say, "we've always had a platform, we just didn't call it that." And whenever you hear a phrase like that, you know you'll have to figure out somewhere else to go for lunch.

(7:17) We've had platforms for a while: we saw things like Cloud Foundry. There's this great definition of a platform from Evan Bottcher that you're supposed to use all the time, which I forgot to put on a slide. And later today you'll have one of the Team Topologies people talk to you, and there's the whole notion of platform as a product, how you set up your organization for the various types of applications you're deploying. Then we had this period where everyone was fascinated with containers as a service and infrastructure.

(7:53) We'd been paying attention to how we make application development easier, and then we were like, how about we pay attention to how we make it easier to configure and install application infrastructure and set all of that up? And at some point, as you remember, DevOps was killed, so I guess we're at a zombie conference, which is fun. Nowadays, like I was showing you, there's been this increasing interest in platforms. How I account for that is the saturation of Kubernetes usage over time.

(8:31) There isn't a 2026 survey yet, but you can see the rise in, as they say, container usage. I mean, it's not like they're using Mesosphere or anything like that. There's been steady growth in people not only running it in production but getting things staged. So Kubernetes has essentially won as the infrastructure thing, and people have been deploying it for many years. Once you get it all set up, what you end up with, from the perspective of those developers and now those normal people, is that Kubernetes is a fantastic way to deliver a blinking cursor.

Let's build a platform!

(9:11) You have the infrastructure, someone can set up all of their stuff, and then they get this. And from a developer's perspective, now you need a platform: the runtime environment, the frameworks, access to security, access to the data sources you have, on top of that. I don't know if you are or have been an application developer, but there's nothing an application developer likes more than not developing applications and instead building infrastructure.

(9:42) So they get very excited. A coworker of mine uses the coffee machine as the example: what developers, and infrastructure people, love doing is building a super custom coffee machine, with all the knobs and dials, so they can make coffee in exactly the unique way they need. You may even have people saying, yeah, whatever you're trying to offer me, I have special needs. I have unique needs, and we've got to customize it.

(10:13) And of course there are always people who want to build it in whatever the new interesting thing is, as we'll get into. If you manage infrastructure, you can predict what happens if you leave it to all of your development teams, let alone those normie workloads. They probably have special needs too, and they don't even know there's a platform to go to. They just install and build something that runs for the needs they have. Especially if you bring in consultants and FDEs: "ooh, central infrastructure, bad idea, let's build our own platform around that."

(10:46) What you end up with is a proliferation of platforms, all sorts of interesting platforms out there. And what you see historically, and I doubt this will change in the future, is that while those platforms are nice and new and shiny at first, pretty quickly they get a little creaky. They don't get updated. The teams that worked on them more or less move on. They're application developers, after all, and they don't really know all the infrastructure needs you have. And then we get to what I think is one of the unfortunate credos, the realities, of what an operations person or platform engineer does: they take over the management of all those platforms, and it becomes not their mistake, but now their problem.

This is me

(11:32) They go into this landscape of all the platforms that were built, their job is to keep things running, and now someone has said, why don't you keep these things running? And they had very little say in what was going on. So, this is me. My name is Coté. Everyone calls me Coté. Like I just mentioned, I've been lucky to write several little books. They're actually more like 80-page things, but they feel like writing a book. I don't know if that's a booklet, a pamphlet, or whatever.

(12:03) I started off at Pivotal, which was acquired by VMware, and then by Broadcom, so now I work at Pivotal-VMware-Tanzu-by-Broadcom. I've been there for about 12 years, and what I focus on is studying how large organizations use software, and all the stuff under software, to get better at running their organizations. Before that, a long, long time ago, I was an application developer, and then an analyst at a little analyst firm called RedMonk, and then at 451 Research.

(12:33) I'm originally from Austin, Texas. If you work in tech and you're from Austin, Texas, you have a compulsory two-year term at Dell. So of course I worked at Dell for a little bit, in M&A and corporate strategy, which was fun. If you ever get the chance to work with business people, MBAs, you should time-box it to a maximum of two years, as I did. You'll learn all sorts of interesting things, like what a pivot table is, how to do slides, and how to value companies. But you really shouldn't do it for more than two years, because you'll go crazy in that different culture.

(13:13) Anyways, that's a little too much about business people. One of the things I get to work on is updating these two papers that we've had for a while, which the rest of the talk is based on. One goes over the premise of this talk: why building your own platform, that landscape of coffee machines that our core platform engineers and operations people have to worry about, isn't a good idea. On the positive side, back in 2017, and obviously before that, we were some of the people who started thinking about platform as a product and writing it up, so I updated that paper recently as well.

(13:54) There are about seven of these things. Some of them are a bigger deal than the others. Also, I wanted to have seven, so some of them are a little bit scraping the bottom of the barrel. But seven seems like a good number.

#1 Unexpected scope creep

(14:24) The first major one is what you'd expect. When people want to build their own platform and they think about what's required, what's going to be needed to have just that baseline platform above the blinking cursor, it's very easy to underestimate the full functionality you need, the scope, as people would say. As a reminder, let's go back to what's in a platform. Since you don't like vendor talk, we'll use the CNCF's.

(15:00) When you look at this, it's one of these diagrams that's almost useless, in that it's everything. It's the maximal, full view of what a platform is. But it does end up being the stack of capabilities that your developers, and I think these normie people, end up needing. There's a lot of stuff in there that not only has to integrate together, but there's also selecting it all, putting it together, and, as we'll get into, the ongoing updating and maintenance of it.

(15:33) So this is a really big endeavor that requires a lot of people, a lot of effort, and ongoing work. Looking above that blinking cursor, there's a lot of functionality that goes into a platform: not only for developers to be successful with what they're doing, but also for operations people, just to keep it running, to keep it updated, to make sure it's secure, and on and on and on.

(16:03) Then, on the process side, there's also a lot of organizational change and process. They say when you go to presentation school that you should never have a slide with a whole bunch of text on it that no one can read, and I always think it's great to break that rule at least once in a presentation, which I'm doing now. This is another great CNCF thing: they have a working group that wrote about the platform maturity lifecycle.

(16:37) If "maturity lifecycle" upsets you, you can think of it as the process organizations typically go through. There are five stages, and I recommend reading them. There are about three versions of this paper, the latest in beta. It's really instructive if you're going on the journey, whenever you hear the word journey, that's not a great word, the journey of building a platform. You have your initial stages of standing it up, and then over time you try to change your organization around to be responsive to what you have.

(17:11) According to common knowledge, first-hand experience and anecdotes, if you will, and also this paper, going through this whole cycle is more or less a three-to-five-year journey for larger organizations, often just to get to the middle. Building out all of that capability takes quite a long time. It's not like, oh, in six months we'll have a platform up and running. There's a lot involved in having a platform in a larger organization.

(17:42) There's a variant of this that I think of as the center of excellence problem. Whatever you want to call it, you have a center of excellence: a bunch of wise people, often seemingly high above things, looking down, and they determine you need a new set of platforms based on industry trends. You might be going about your daily job, and I hear this all the time from people I talk with, there's always a "they" involved: "they told us we need to put this new platform in place."

(18:18) And they want to kick off, this is where you hear the word journey a lot, a transformational effort to replatform and move things around. This has its own scope problem. Not only do you build out that initial platform, but when you're replatforming you have all of your existing applications, and now you need to move all of them to the new platform. There's that saying that the last 10% of the work is 90% of the work, which I think means your estimate of the first 90% was wrong. There's all the customization your applications need, the way they run, changing things around, and it takes much longer than people scope it out to be initially. You get into this sad carousel state. And that, of course, is the happy path.

(19:12) That's assuming it all works. I'm sure if you've ever migrated more than one application, in this room it always worked perfectly. But when you talk with your friends who aren't here and they struggle through it not working, you can be more sympathetic, because there are always some little bumps along the way, if not gigantic canyons you weren't anticipating that you just fall into as you go along.

#2 Underestimating the ongoing investment

Part of all that is underestimating the ongoing investment. A lot of times, when people want to build their own platform, it's not only the idea that we have unique needs and we have the capability to build out our platform,

(19:53) that misunderstanding of the total scope of things. There's also the idea that it'll be cheap, because here we are, your staff, you already have us, so it's going to be very affordable. There's no better way to get corporate permission to do something than to say it's going to be, if you don't like the word cheap, affordable. You'll have ROI, a return on investment, and you've got a successful business case. Now think about that scope, the amount of capability you need, and how much it costs. Sorry, this is in dollars, but if you take a rough estimate based on an average salary for a team of about three to eight people building this platform, you can see that over five years these costs add up to, more or less, not free.

(20:48) Go back to that scope, and to one team of three to eight people developing a platform over time, keeping it updated, adding new features. Now you've got to have all your AI stuff in there, so that's a whole bunch of new work. In my experience, when I talk with people in larger organizations, they tend to have more like three to eight teams of three to eight people, and that starts to stack up as an expense. And of course it's not a one-time expense. You don't just pay for these people for five years and then say, thanks,

(21:21) see you later, and that makes your spreadsheets look pretty. It's a permanent investment in keeping that platform up to date and built, and that doesn't even count the people who run and maintain it. Instead, I like to collect numbers from people who decided not to build their own platform. You can see the efficiency ratios, however you want to measure them: the number of developers the platform engineers, the operations people, support, the number of apps they support, or the number of app teams.

(22:00) The point is that if you already have a platform, if you don't have to worry about building and maintaining your own, you get huge efficiencies. You only need a handful of people to actually run these platforms. I know you can't click on it now, but if you get the slides later, you can go into the details of how these organizations work and how they got there.

#3 Platform as a project

The third thing people tend to fail at is that they think in terms of platform as a project. I already mentioned this: you think that after five years you're done, you delivered the thing. Or, I don't know if it's more common, but another version is that we'll hire some consultants to come in and build us a platform, then they leave, and now we have a platform. That's another example of not my mistake, but now my problem.

(22:54) You have this notion that when you build your platform, you think about the capabilities you need, you build out those capabilities, and you probably have whatever metrics, SLAs, OKRs, KPIs, on a dashboard, always showing that you're delivering that service correctly. That's more of a project mentality. Thinking instead about the developers who use the platform, you think in terms of platform as a product.

(23:26) That's why I started with the ultimate use of a platform, those applications, and then the people who are the users, the customers, of the platform. What I've seen in organizations that are successful with their platform, well, they could be successful for other reasons, I suppose, is that they have more of a product management idea of the platform. They're constantly paying attention to what their customers, the developers, and probably those normal people as they use it, need.

(24:01) Just like, as you saw from our sponsors and from people in my own organization, we're very interested in what people want and need so that we can sell it to them. Similarly, a platform-as-a-product mentality is that same thing: how do you evolve the software, how do you make it desirable and useful to the customer base you have? One simple way of putting it is that these platform teams tend to have someone called a product manager, instead of just a project manager.

(24:32) So that's one thing to check when you're building things out: do you have a product manager? In the application world, what a product manager is is extremely well understood. If you ask people what DevOps is, you get a delightfully philosophical, all-over-the-place conversation. Product management is very locked down as far as what it is and how it works. So if you don't do it in operations, what's very handy is that you can just read a book, or talk to your robot, and it'll tell you exactly how to do it.

(25:05) You can even get certificates, which is kind of amazing. One way to get into it is to think: all right, if our customers are developers, and this other workload, how could we find out what they want? One method is, of course, to send out surveys, otherwise known as going and talking to them and asking them. This is a list of common questions we've used over the years for that kind of survey. And one of the mechanics of product management versus project management is how you measure whether you're delivering the right thing, whether you're being successful.

(25:41) So you send out these surveys, and initially what you're trying to rank is what developers don't like, what they complain about. Having been a developer, I'd say that, other than building your own infrastructure, the number one thing developers like to do is complain about their hardships and why things aren't working out for them, so they'll happily tell you what's wrong or answer a survey. From that first survey you find out what the biggest problems are, the bottlenecks, the barriers. You go back to your business friends who know how to use Excel, they do the sorting, however that magic is done, they tell you which are the worst, and there you go: you have what a product manager would call a backlog, the things to pay attention to.

(26:26) Of course, there are other constituencies, or, as people say, stakeholders, from security and governance who might have something to add, but we'll simplify it. Then you survey them again at some point. If the ordering of those things in the spreadsheet has changed, you have feedback that you've done a good job. If the ordering hasn't changed, then what you do differently than in a project is go back and think: how should we implement this differently? Whatever the new feature may be. How should we implement access to various types of inference

(26:57) for the AI stuff, since the developers still aren't happy with it? Let's try something else. It's a very product way of thinking: not just saying, well, we built the Kubernetes cluster, so that's what they wanted, see you later. Instead, you follow up with them and see if it's actually providing what they needed. And there's an interesting new thing to think about here with agents in particular. Back when we had just developers, they were very good at following the way you're supposed to interact with the platform, which, whatever you want to call it nowadays, is generally through the build pipeline.

(27:36) The build pipeline would go out, depending on how you have things arranged, and do all the configuration you need. But what we've seen, with your centaurs and reverse centaurs, when you've got agents running around, is that they don't really care about your build pipeline. They want to get in there and figure things out however they want. Especially, as we've seen recently, they like to go find image registries and totally mess around with those, which is great. So instead of everything going through this pristine path, you have all these little things scurrying around.

(28:15) This is an example of product management thinking: you have a new need, a new customer, agents, and how they want to operate, so you need to construct your platform a little differently. And of course, when you introduce the normie, they don't care at all. They're just going to have their agent borrow a password from somewhere, or try to do whatever, and things are going to go all over the place. You have no control over what's going on.

(28:45) If you've ever used agents yourself, you notice this. You want to do something, and it's just like, give me a few minutes and I'll do it all, without even looking up your runbook or your methodology. It just discovers things for itself. So instead, you think about how you'd construct your platform to funnel everyone, your new constituency and your existing ones, onto a path, so they're not scurrying around doing things.

(29:19) Again, there are very well understood ways of doing this, and all sorts of things you can learn from. But you have to study it: if we have agents running wild, how do we constrain them, and how do we also help them do things in the native way they want? I was talking with one of the product managers at our company yesterday, and they brought up a good point that intuitively makes sense: agents don't really need UIs. In fact, UIs are very unhelpful to them. They just want APIs and command-line interfaces, which becomes a whole other kind of surface, and even a different way of using it than developers using their command-line tools.

#4 Homegrown lock-in

(30:00) Another issue that comes up quite a bit, and one of the reasons people give for building a platform, is: we're going to be locked into whatever else we might do. If we build our own platform, no lock-in. We don't want lock-in. It's worth thinking about what lock-in actually means, what it should be. I don't want to judge anyone's life choices about what lock-in means to them, but here's a way of considering it. First of all, if you build your own platform, you're of course locked into your own platform.

(30:32) Which sounds comforting and nice, but you don't have any support from the overall industry. You don't have any way of changing things around. Switching costs can be very high. These are the things I think are good to consider when you're worried about openness and lock-in. A long time ago, there was this notion that what people really want is the freedom to leave.

(31:03) A huge amount of what lock-in concerns is really a type of portability, being able to move things around, which again comes down to: what is it going to cost us to leave? We tend to blanket-think about lock-in that way, but it's better to evaluate whatever choice you're making against that criterion: does it give us the freedom to leave?

#5 Retaining skilled people

Now, there's a whole other type of lock-in, which is retaining the people who can do things.

(31:35) Retaining skilled people. A lot of times people use the phrase "technology is easy, people are hard." If I can give you one piece of career advice, it's to never say that to anyone. Think about going in and saying, I'm valuable, and you should pay me, and someone says, but I thought technology was easy. You should always go in and say that the people part is difficult and the technology part is difficult.

(32:05) It's all difficult, which makes the whole situation something valuable and worth paying for. So try not to say that technology is easy. It always needs to be difficult. As evidence of that, you can see, again from CNCF surveys, that one of the things people are always concerned about when there's a new technology around is: do we have the skills needed? That is, people who can do the work, presumably at an affordable rate. Not to get all supply-and-demand on you, don't worry.

(32:36) From 2017 to 2025, it's stayed at more or less the same rate when it comes to skills and Kubernetes, 40% down to 36%. It's usually the second concern respondents have. They're always concerned about getting people who are skilled at it.

#6 Resume-driven development

Which leads to a phenomenon we often see, called resume-driven development. If you think about it, there's a scarcity.

(33:08) Skills are an issue: we can't find the people who have the skills to build and run our platforms. And a phenomenon occurs when you're trying to attract people. One of the ways you attract people is to say, we're working on new technologies, we do exciting new stuff, so come work here. So, as was studied in this paper, you get, I don't know what the opposite of a virtuous loop is, a bad loop. You post jobs that look interesting and fun to attract people, and then you get this feedback loop where the people you're hiring know they should be using the new technologies.

(33:48) They want to be highly employable, to use the new stuff, so they start thinking about how they can make decisions that make their resume look better, that make them more hireable by other people. And this has another negative effect that I've seen a lot over the years. We built out our own platform, we had a team of people who, over however many years, got really good at building it. They went to all the conferences, they understood how to do stuff, they learned from their errors, and then, mysteriously, they found a better job at a different organization. They went off somewhere else with their skills and their resume, and now you're again left with not my mistake, but now my problem.

(34:25) That asset you'd built up got up and left. It's a fun paper to read through if you're into how systems cause problems.

#7 Keeping up with security and compliance

The last thing, especially nowadays, but it's been here forever, is one of the things that consumes a huge amount of time with platforms and any type of infrastructure. For some reason, application developers always manage to wiggle out of it being a primary concern for them, which maybe is the problem.

(34:59) It's keeping up with not only security but the compliance you might have, the governance you need built into your platform: how it can run in multiple regions, how you can bring it back from regions you don't want it to be in, how you can fit new laws with very hard deadlines you have to comply with. Especially if you're a large organization operating globally, there are always new laws coming out, banking laws especially, resiliency laws, so you always have to comply with something. And then of course, thanks to our friends the robots, there's just the raw security, as we've seen this week, and last week, and the week before that, and on and on and on.

(35:37) What you see is this huge rise in security problems, in CVEs. And this year isn't even over yet, if you can read the year-to-date down there, but there's already been probably a doubling in the number of CVEs, which cause you to shut down your site for a couple of days, or to figure out how to redo all your certificates because of one weird little thing. That one probably wasn't AI.

(36:08) That's what they call a between-chair-and-keyboard problem. But this problem gets even worse. We can kind of rely on developers to be sane, to use, for one example, a registry that we control instead of just going out to the internet and using whatever. But again, look at our normie friends. They don't care. Their little agents will happily go out to whatever repository: there's this cool thing called Homebrew that'll let me install something so I can suck all the text out of your PDF, and then I'm going to install LibreOffice and make slides for you.

(36:44) It's very exciting. And they install all this stuff, and you have no idea where it's coming from. With a platform, you have a lot more ability to corral what's going on here and have much more control over it. And figuring out how to keep up with and build that yourself is just another type of work you need to do, more scope that typically isn't anticipated.

Stop building your own platforms

So looking through all of that, as they used to say when I was growing up, don't take my word for it. Listen to the other people. Look across the industry at the other people working in this platform space, and they've decided over and over again that building your own platform typically shouldn't be the default choice.

(37:26) It's much better to find a platform that already exists. If you already have one, that might be nice too: you've gone through all the work to get it up and running. But it's worth asking, why don't we just not worry about spinning up a whole platform and building it out, and instead share the platform knowledge that other people out there already have? So that's what I'd recommend: you should probably stop building your own platforms, and start building your own apps.

(37:57) Spend more time doing that. Because with all those custom coffee machines, what you usually want is just a button you press and the coffee comes out. That's a nicer way to experience things in the morning than artisanal things. Hopefully you can avoid all of those seven, or more, pitfalls. So with that, thanks for giving me the chance to go over this stuff.