Delivering tomorrow: The future of software needs (better) platform teams | Camille Fournier

[intro jingle] And so, today I am here to talk about how we can actually deliver tomorrow - and deliver that future of software having better platform teams. All right. So, to introduce myself, - I actually decided to start with this quote from Fred Brooks. The scientist builds in order to study; the engineer studies in order to build. I consider myself both a scientist and an engineer. I studied computer science, probably many of you did, - in undergraduate and graduate school. And for much of my career, my title has had something - with engineer or engineering in the word. So, I do a lot of both of these things, right? I read a lot, I go to conferences, I learn so much from that. And then, when I'm building teams and systems, - I also consider myself to be building in order to study - and then share with everyone else what I've learned. And so, as a result, I've written a few books, - including my most recent book, which I co-authored - with my friend Ian Nowland, on platform engineering. This is a book for leaders of all sorts. If you are familiar with any of my work, I hope you know that I believe - that leadership isn't just management. Leadership comes from technical leadership, - leadership comes from product leadership. Leadership comes, yes, also from people leadership. There's lots of kinds of leadership that we need. And this book was written after spending a lot of time - building platforms and building platform teams - between both me and Ian, and having a lot of ideas - on how to do this and how to do it well. And realising that, for a lot of people, - platform engineering is a little bit about the Gartner hype cycle, - I can't believe there's a Gartner hype cycle for platform engineering. This is kind of wild to me. And platform engineering is a lot about technology for a lot of people. The first thing they think about is IDPs or Kubernetes or what have you. I like the fact that this cycle, - by the way, if you look at microservices, - it's up there in the slope of enlightenment. It's about two years from the plateau of productivity. That is wild to me because we've been doing microservices for how long now? And we're still figuring them out in some places. But the reality is that technology - is really only one element of platform engineering, - and it's important, but it's only one. And this is actually why I, after spending about the last year - thinking about what do platforms mean in an AI world, - maybe everything I just wrote about and published a year ago - doesn't matter anymore because we've got AI, - and AI is going to kind of magically solve all these problems for us. And I actually really did spend the last year thinking about this problem. And I kind of concluded that, actually, because technology - is really only one hard element in the work of platform engineering, - platforms are actually even more important in the AI world. Because platforms are not just about technology. Platforms are about systems. And systems themselves are more than technology, right? Systems are more than intelligence. Systems are about specifications, they're about reliability, - they're about maintainability, they're processes, - they're kind of means of control. And humans build systems all the time. We have how many billions of general intelligences on this world? And yet we are still building systems, we're still building processes. We're still building combined building blocks of things to do stuff, right? And that is a lot of what platform engineering does, - is help us improve our internal systems. However, platform engineering often fails. And in my experience, the limiting factor - is usually the maturity of the approach. There are no silver bullets for building platform engineering teams. In this talk, I'm going to talk about a few of the concepts that are in my book. There's a lot more in there - to help you kind of get a foothold in, okay, what do we actually need - to think about to do this platform engineering team thing successfully? So, I promise I'm going to give you some ideas for paths forward here. But before I do, I actually wanted to take a few minutes - just to remind you about this No Silver Bullet concept, - because it is, in fact, something that Fred Brooks, - that guy I quoted at the beginning of the talk, - who wrote The Mythical Man-Month, if you've ever read that, - something that he wrote about. And he wrote about it in 1986. It's actually one of the essays that's in The Mythical Man-Month, - but it was written 40 years ago. And it is an incredible essay. If you go and read it, you will be amazed - at how relevant it still is today. What he basically says is, look, - we are not going to see technical improvements - that will give us an order of magnitude improvement - in productivity of building software systems in the next 10 years. So, this is '86 to '96. He was definitely right about that. And the reason he gives is that - there are these essential difficulties of systems. Essential difficulties are the sort of essence of building software systems - that cannot be easily tackled by improvements in technology and tooling. So, these include things like complexity. As software grows, the number of variables grows, - the number of interactions grows, it is a nonlinear complexity increase - as software systems grow, I'm sure you all know that very well. Conformity, I think this is actually - one of the hardest difficulties of software systems. They have to conform not to the laws of nature or the laws of physics, - but the laws of humans and their whims - and whatever the product manager decides would be cool today, - and whatever we actually think we need to build - to enforce those compliance restrictions and on and on and on, right? Changeability, our software must change all the time. Even if we don't want it to change that much, - the environments it runs in tend to change. The hardware changes. The operating systems change. We have security patches we need to make. And that changeability is expected to happen much more frequently - with software than it is with physical objects, right? And finally, invisibility. Software is not visualisable. And that means that it's very hard to make a graph or a chart - or a diagram that really shows you all the things you need to know - to understand a complex software system. Again, it's very hard to have a mental model of everything that's going on. And there have been many false hopes for solving this problem - that, again, managed to somehow still be relevant today. He talks about programming languages, and he talks about things like object-oriented programming. But even, frankly, you know, I have seen in my career, - functional programming came up, and everyone was like, - oh, my God, it's going to change the world. We're all going to be so much more productive. I knew that that was not going to be true - because I learned functional programming in undergrad. It's useful, no doubt about it. There's a reason that everybody uses at least some of it today, - but it has not actually made us 10x more productive, right? He also talks about something called automatic coding, right? Which is this idea of if we just could write a high-level spec, - then the computer can translate that spec into code for us, - which sounds an awful lot like vibe coding. And what does that really mean? Well, first of all, we have the question of whether a human language - is ever going to be really specific enough - to turn into the kind of specification that we tend to want in computer systems. But even ignoring that, ultimately, - the problem of figuring out what to write, the problem of figuring out that spec is actually really hard, right? I am not yet worried about product managers - taking all the programming jobs because, - in my experience, getting that spec is more than - just having a couple of passes of conversations with our users, right? So, not to leave us all in despair, Brooks gives a few paths forward. And in fact, I believe that these paths forward are the thing - that have given us the most increase in productivity - in programming over the last 40 years. His first suggestion is, buy software, don't build it, - which, oh my God, guess what? Guess what we all do now, right? Whether you think of that as buying or not, we all use the cloud, - we all got outages yesterday, probably, - we all use open source, we all use libraries, frameworks, - operating systems that someone else built, - we are building on huge, vast arrays of software that someone else created. And we're just adding a tiny bit to create our applications, right? Not writing software at all is way more productive than writing it. He suggests that we all start doing much more rapid prototyping - to do requirements refinement, which I think has been widely adopted - in the industry through Lean and other kinds of Agile processes. He also suggests incremental development, - grow rather than building your software. Again, I think another thing that has been pretty widely adopted, - we all kind of understand, yeah, we're going to make - smaller changes frequently, or at least that's the ideal. And he suggests that we invest in great designers. This one, I'm not sure we've done so well as an industry, right, - where we really respect those who can think about - how to simplify systems effectively. So, we have seen aggregated productivity increases - from all these suggestions, but they've also introduced their own difficulties. And platform engineering is an organisational evolution - that, I think, aims to tackle some of those difficulties, - such as the difficulty of buying, right? So, great, we're all building on top of large sets of existing software. And so, what happens? Well, you're building an application. You're going to write what we call glue code in this book, - which is the integration code, one-off automation, - configuration, administrative tooling. It's that binding agent that takes your application and binds it - to all of its underlying open-source cloud infrastructure, et cetera. And that's all well and good for your greenfield applications. But as your company grows, as your team grows, - as you build more and more applications and put more and more glue in there, - and all of a sudden, those underlying components start to change, - and you've got to change this glue code that isn't really - the thing that your team is probably most interested in thinking about, - because it's not really your application value. And this starts to slow you down, right? So, it turns into technical debt or whatever you want to call it, right? But having all of this application layer glue code - sitting in every single little application - creates a lot of duplication and slowdown in our teams. And so, we've all gotten comfortable with this idea, - or at least we're all trying to think about this idea, - we can build platforms to solve this problem, right? Which are self-service APIs, tools, services, knowledge, and support, - arranged as compelling internal products. And if you build a good platform, - you actually reduce that layer that people need to think about. You've reduced the context space, which, by the way, I think will be very useful - for your agents trying to generate code and build things - as much as for your humans trying to generate code and build things, right? So, a good platform should help us in this AI world. However, the AI world and the modern world has other difficulties, - which is that as we've figured out how to become more productive, - well, we have and we haven't, right? So, I would argue that the lesson of the Agile DevOps movement - was basically, make lots of change very quickly, - so that you can detect failures and fix them very quickly, right? And look at the DORA metrics, right? It's lead time to change, - it's how fast you detect failure and fix it, right? You're sort of attacking both sides. You want to quickly change things, - quickly fix them, great, beautiful. The best of us have done this at human scale. And let's be honest, many, many companies - haven't done a great job of this, even to this day. Now we're about to add AI agents - generating more and more and more code. And in my experience, that's the thing - that everybody has sort of figured out how to do. Even AI may very well help us in other parts of this pipeline. But mostly, we're just using it to generate lots of code, - which means we're going to have bigger change sets, - we're going to have more to ingest. And I don't know about all of you, - but I sure don't want my developer spending all their time - code reviewing AI stuff, and then scrambling - to fix AI stuff when it breaks in production, right? And so, platforms already have also taken over a lot of the concepts - of that developer pipeline, SDLC, whatever you call it. And investing in them and continuing to invest in platforms - is going to be really important if we want to be able to take advantage - of this new AI boom, both in code generation, yes, - but also in observability, in recovery, right? You really want to have a layer of people - and products and systems that are thinking about that holistically - on behalf of your organisation. Because platform teams are there to drive the evolution of an organisation. They are not there to do big revolutionary things, - but to help us adopt those new concepts successfully. So, what is platform engineering? It is the discipline of developing and operating platforms - with the goal of managing overall system complexity - in order to deliver leverage to the business. And we do this by taking a curated approach - to building platforms as software-based abstractions, - serving a broad base of application teams, - operating them as foundations of the business. So, this is the way we decided to define platform engineering in our book. And we spent a lot of time thinking about this because we really wanted - people to get away from the idea of platform engineering - as being about a specific technology, - but also because we wanted people to think about - how do you actually build a team to do these things. Because the central question of how to improve - the software art centres on people. And so, my first piece of advice is going to be about - how to set up the teams and how to make sure - you've got the right people involved to hit these goals. So, let's start with the goal of managing complexity. If you want to manage complexity, you are going to need to build software. It is not enough to do great automation to do real complexity management. You have these very wide APIs - coming in through all of these underlying components. If all you do is vend those components, - make it really easy to provision those and then hand them off to people, - you've not really diminished that complexity boundary, right? Now they still have to know about all those different systems. So, our platform engineers need to be willing to write meaningful code, - to create coherent holes out of these underlying components. I emphasise this because I have met platform teams - that are really mostly in the sort of infrastructure and DevOps mindset of - we do a lot of automation, it's very important stuff. But if you're not really willing to write a lot of code, - you're not really going to really meaningfully - affect that complexity boundary. However, sometimes I end up with platform teams - that are only software engineers, and they have other problems, - because software engineers love to write software. They want to write frameworks and libraries and tools. They want to write blueprints, all very useful things. What they don't love to do is operate software. Unfortunately, if you're not willing to operate things, - people are not really going to value your contributions - as much as maybe they even should, frankly, right? People understand in this day and age, the cost of software - is not just in its original creation or even in small bug fixes. It's in maintenance operation upgrades. That's why we all love SaaS. That's why we all love the cloud. Operational ownership is an important part - of really providing leverage to your businesses. And so, platform teams do need to have that operational component, - which means you need operational experts. You need people with a systems focus, - whether that's infrastructure engineers, systems engineers, DevOps, SREs, et cetera, right? Those operational superstars. Finally, we have this question of improving productivity. Anyone who's been in the industry for a long time maybe has worked - at a big company where they had an old infrastructure engineering - or infrastructure technology team, centralised team. And they may have done those first two things, - but they really did not care about the people using their software, right? They were really focused on managing costs, - managing their own efficiencies. And I think this is a big reason people ran as fast as they could to the cloud - when the cloud became available, to get away from that bottleneck - of having all the choices made for you by some sort of faceless internal team. We do not want platform engineering to turn into that, - which means we need to think about it as a product. We need to think about the people that are using what we're offering - as our customers, we need to have that product mindset. This may or may not mean that you hire product managers, right? But it certainly means that you have a customer empathy - and product approach to the way you choose what you're going to do. So, my first piece of advice is, as you're thinking about - creating platform teams and as you are a member of teams, - look around you and ask yourself, do we have these components - of software engineering, operational ownership, - the system skills and product focus? And if we don't, how do we get that in our team, - whether it is by hiring or by skills uplift in the members of the team? Okay, moving on. The hardest single part of building a software system - is deciding what to build. And deciding what to build for platform teams - is actually quite challenging, in my experience. This is a really big area where people fall down. And they fall down in two different ways. And I will start with the first, which is that they over-focus on themselves. We over-focus on ourselves as a platform team. What do we think is cool? What do we think is important? What are we struggling to support ourselves? These are the things we tend to gravitate towards building. And so, this is an old American movie reference, - but there's this concept of field of dreams. If you build it, they will come. We have this great idea, we're just going to bring this cool open source in. We're going to package it and make it very, very useful for the company. And we're going to call it, you know, our magical XYZ, - and everybody's just going to adopt it, right? We're going to make everybody migrate off of their old VMs to Kubernetes, - because everybody's really excited to learn about how to containerise things - and do all this work, and Kubernetes is the future. And I'm sure many of you have seen something like this happen - at your companies at some point. And sometimes it's the right thing to do and it can be successful. But a lot of the times, this idea of, we'll build it, - and people will just naturally gravitate towards - this clearly technically better solution is really a folly, right? People are not thinking about that. That is not their priority. They are not just going to come because it is a good idea. It may not even be a good idea for your company. A lot of times it kind of isn't. It's also important for us to remember that the computers - are not our customers, and the computers are not our stakeholders. And what this really means is that you don't want to focus - on your own internal efficiency and your own internal toil metrics - above and beyond doing things that help accelerate your business, right? We are here to make our businesses successful. If you're building platforms, even though you might be - internally focused, your job is making a business successful, - which means that you need to think about - what does the business really need to succeed. I can't just focus on myself and my internal problems. Okay, but the other extreme is people who think - that having a product mindset and being customer focused - means that we're going to get a list of stuff to do. You guys are just going to bring it to me, application teams. What do you want? Please bring me your features, - and I will triage them, and we will implement them and it will be great. Of course, my team is going to turn into a bottleneck. We're going to turn into triage mode. And this is a very unpleasant experience - that I've also seen happen quite a bit, - where you do end up in this kind of feature factory mindset, - where you're just constantly taking in requests, - you're implementing them as fast as possible, - you build a Rube Goldberg machine, - where, like, you've just got this, then this and this, - because you're just trying to get it done as fast as possible, - which means you're not really thinking about the architecture of your platform. And good platforms should really allow - some reasonable amount of customisation and self-service by the users. You really don't want to have to implement literally every little thing - that everybody brings to you, because then you end up - like our poor friend here with just a pile of incoming work - that you are never, ever done with, - no time to think, no time to breathe, right? We can't just expect to get a fully featured list of things - from our customers and implement them and call it a day. So, we've got to do the hard work of product management, - of owning our strategy and identifying shared challenges. And yes, of course, that starts with talking to our customers. That's kind of obvious these days. But the real thing, if you take one thing away from this, take this away, - which is that your best new products or new features - are already being developed by the application teams themselves. That, in fact, most useful things that platforms do - are from an application team that had a problem that they needed - to solve for themselves, and so they built something. And the good platform teams are keeping an eye - on what's going on in the larger company. And they say, "Ooh, those guys really did need a key-value store." And so, they pulled in whatever they chose to pull in, - and they put some wrappers around it. And this is not going to scale for the whole company, - but it's clearly something that that team and that team and that team also need. And so, we can take it, we can assimilate it, we can expand it - and make it a platform offering for the company. That is where most of your new features are really going to come from. Yes, the larger landscape is also going to be a factor. Of course, there are trends that you cannot ignore, - like containerisation, Kubernetes, things like that. But while you're looking at any of these, you really do want to think very carefully about the true demand. Will teams commit the time to do the work to use your system, - to help you test it, to help you vet it, - to learn how to use it, to migrate if they need to migrate? Be realistic. You cannot expect people - to constantly be migrating to your new thing just because you want - to introduce something that's a little bit technically better, right? You are creating costs for the organisation. You can spend some energy on thinking about how to make migrations easier, - and I very much encourage people to do that when they own platforms. But ultimately, right, it is very important that, - as you're thinking about new things, you really think about - what's realistic for your organisation to absorb - when it comes to change at the platform level. Okay. So, I've talked about of people and product. Let's talk about something that's slightly more technical, briefly, - which is really about how to approach deciding - how to really build these things. And particularly when you have systems - that maybe are not scaling as well as you would like - and need some serious changes, how do you approach this? And I think it's important to remember - that enthusiasm jumps when there's running systems, - and it's much better and easier to build things - when you've got something working. And so, the advice here and the caution here - is to think about how to avoid the rewrite or V2 trap. Where we've got something that works pretty well, - but we're going to go over here, we're going to build our V2. We're going to build our much better build and test platform. It's going to be amazing. It's going to be so much better. It'll take us six months. And then two years later, we're still not done, and people are still not using it. And what's going on? So, one thing that is really important for you to remember, - all of you engineers in the audience, is Hyrum's Law, - which is that if you have a sufficient number of users of a system or an API, - it does not matter what you document the contract to be. Contracts solve very little. It matters what they observe as behaviour. They are going to depend on all observable behaviours. People are going to depend on you in excess of your SLOs, - and they are going to scream bloody murder - if things start failing in ways that they didn't expect. And if you change things you didn't expect, it's very difficult to really know the entire impact of a running system. And this is why it is so hard to build a complete replacement - to the side of a successful running system. Additionally, for our platform teams, - we need to think about the kinds of people we have on our team. So, if you're familiar with [Simon] Wardley, - he's a writer, done some very cool things. One of his essays is about pioneers, settlers and town planners. And it's this idea of different types of teams that do different types of work. Your pioneers go out, they take big risks, they find new things, - they try stuff, they don't care if it's super sustainable, - they're just trying to get out there and see what's going to hit. Then, your settlers come in, they stabilise, - and your town planners, if you get something - that's really stabilised and important, will come in and really make it scale, - make it very bureaucratic, but very functional also. Your platform teams tend to not be in the pioneering mode. A lot because it's just really hard - to do the job of platform engineering, which, as I mentioned earlier, - there's a lot of operational concerns with platforms. We're running these systems for multiple teams, - which means we can't be just disrupting things all the time - because we've got a system out there that doesn't really scale, - that fails a lot, that isn't reliable. We want to be running a lot of foundational parts of our businesses. And that means you're much more likely to be - in that settler or town planner mindset. It's just the nature of things, right? It is very hard to go from pioneering mindset - to settler and town planner mindset and back and forth. And it's very unusual for you to have - members of all of these mindsets in the same team. If the first thing your team thinks about when you propose a new idea - is how it's going to fail, they're probably not in that pioneering mindset. And that's totally okay. That's actually good, right? That's what you want. So, you've got to think about your platform teams. I think one thing that is fun about running platform teams - is that you often get to own your own strategy. As the senior manager over a platform area, it's very rare - that you have somebody else telling you what your strategy should be, - because it's not usually that you have a business head - or a platform product head that's like, well, here's what we're going to do. Platform engineering head, your job is to just implement it really effectively. You actually have a lot of strategic ownership, which is great and scary. And so, I think it's important to remember that - as we're leading these teams, as we're setting these strategies, - we are an evolutionary part of companies, right? Our job is to help select the next most important things - for the organisation, help people slowly adopt them, - help the things that are no longer serving the organisation - die off over time. This is a long running strategy. It happens over time. You are never actually done with it. So, those are a few ideas, a few sort of sampling ideas - of things to think about as you're building out platform teams - and being a member of platform teams as a leader of any sort. And it's just important to remember - that, unfortunately, there really isn't any silver bullet. You can't just adopt IDPs or read the SRE book - and magically have a great experience of running your platform teams. It's very hard, it's very long, a lot of work. But a few paths forward to think about. You want to bring the right people together, - because it really is important that you've got a good blend - of people on your platform teams. That good blend of people is going to be the real difference - between success and failure in the platform world. As I said earlier, build on the work of others. Your customers are doing that rapid prototyping that you need - to find your next product. It is okay. There is no shame in taking a good idea from one team - and making it something that everyone can use. That's a lot of work, and it's, in my opinion, really fun work, right? So, don't be sad that your job - isn't being super, super cutting-edge innovative, - because the work of scaling a big, platform-level product - is very intense and pretty fun. And remember that your platforms are going to grow. They're going to grow through evolution. They're not revolutionary. You don't want to be disrupting your company excessively - as you build out these platform products. I think that platform engineering done well - can harness and amplify the power of AI, right? It should allow you to have smaller context windows - exposed to both your application developers, to the agents. You should be able to get more done. It should allow you to think about how you can - increase that throughput of change, - which creates better productivity for your developers, - as well as just generally better support and leverage for the company - through that concentration of expertise at the platform layer. And thanks for coming to my talk. [outro music] [music ends]