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 realizing 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. 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]