Shownotes

What Is Platform Engineering and how will it work in an AI world? An In-Depth Conversation with Paula Kennedy

In this episode, Anne Currie chats with old friend and colleague Paula Kennedy, COO of platform engineering startup Syntasso about the fundamentals of platform engineering, its evolution, and its impact on organizations of all sizes. They explore how platform engineering helps manage the growing cognitive load in modern software development and operational practices.

This episode is a great companion to episode 3 - Niki Manoledaki's on platform engineerinf at Grafana Labs

Key Topics Covered:

• The origins and definition of platform engineering, tracing back to the earliest days of software development

• How platform engineering bridges the gap between code creation and deployment infrastructure

• The role of platform teams as enablers and marketplace providers within organizations

• Ownership, responsibility, and the importance of platform as a product mindset

• The impact of AI on platform engineering, automation, and operational efficiency

• Avoiding bottlenecks: scaling platform capabilities to meet rising code generation and operational demands

• Practical insights into managing complexity, security, and costs across organization-wide platforms

Timestamps:

• (0:00) – Introduction to platform engineering and tools for easy editing of recordings

• (3:00) – Defining platform engineering as the space between code and infrastructure

• (6:00) – The evolution from traditional IT to DevOps and modern platform teams

• (9:00) – How cognitive load and responsibility are distributed across teams

• (12:00) – Historical perspective: from separate dev and ops teams to integrated platforms

• (15:00) – The role of ownership and product mindset in platform success

• (20:00) – The marketplace model for platform services, enabling internal contribution

• (23:00) – The importance of clear boundaries and ownership akin to cloud provider models

• (28:00) – The influence of AI and agents on future platform strategies

• (36:00) – Recognizing system bottlenecks and scaling horizontally as a key challenge

• (37:00) – The timeless nature of operational principles and organizational constraints

Transcript

Anne Currie (00:00)
hello and welcome to asynchronous and unreliable a new weekly podcast where we discuss the most interesting ideas and concepts in tech. I'm your host, Anne Currie co author of building green software, the cloud, native attitude and author of the science fiction panopticon series. And today we're going to talk about the ops concept of platform engineering and who better to discuss it with than Paula Kenned, co-founder and COO of Syntasso and also an old friend of mine. We used to run a meetup together. So Paula, do you want to introduce yourself?

Paula Kennedy (00:32)
Hi, thanks Anne. Yes, we've known each other quite a long time, right? I was trying to work out exactly how long, but some years, yeah, definitely. I'd say at least 10 years. Yes, so thank you for having me on your podcast. I am very excited to be here. My name is Paula Kennedy. I am, as Anne just said, COO and co-founder of Syntasso We are a startup based in London. We make a framework for building internal platforms.

Anne Currie (00:39)
Ten years!

Paula Kennedy (00:59)
So it's called Kratix And if you want to learn more about that, you can check us out on our website, Syntasso.io

Anne Currie (01:05)
So it's interesting. The reason why you're here today is that I was watching you speak at a conference last week at DevOxx London and you were talking about, you know, introduction to platform engineering. And I thought, no, I should have got Paula in to talk about what is platform engineering before. I think the third guest on this podcast series was an absolutely amazing speaker from Grafana, Niki Manoladaki and she was talking about the very highest end of operational efficiency and platform engineering. And I thought, what we really need to do is roll all way back and actually have a discussion about what on earth is this platform engineering of which you speak. But she was going so well at discussing what the highest end of operational efficiency was and operational competence. Didn't like to roll her all the way back.

You're going to have to go a lot further back for us to explain what platform engineering is. But then you were on stage and in front of me and I thought, Paula, she can talk us through what is platform engineering.

Paula Kennedy (02:19)
It's so funny, right? Because it was, like you said, last week, I saw you on stage giving your keynote, which was incredible about AI and how actually we all have the power to use AI sustainably, responsibly, which was excellent. So I was really embarrassed when you came and watched my talk. I was like, no, having Anne in the room is always quite a lot of pressure. But thank you for watching mine. It was, like you said, it was more of a fundamentals of platform engineering.

Paula Kennedy (02:47)
And then on the back of your recommendation, I watched the talk actually that you did with Niki and you're absolutely right. Incredible, incredible content. I actually then felt a bit intimidated to come on here and follow that because I was like, wow, she's smart lady and knows her stuff and went very deep. But I'm very happy to do the beginner level, what is platform engineering? So, in my talk last week, what I described it as the most simple is.

It's everything you can think of in the gap between code being written at the top level, kind of the application level and that code being written by humans or by agents in this current day and age. But code is written to create software. The code runs somewhere. So typically infrastructure could be on your own, could be cloud, et cetera. And everything in between, between making sure that code is kind of exists and has somewhere to run. You could describe all of that as being where platform engineering comes in. And so it's not new. That's the thing I always find very interesting about it. It's not new. It's a problem that since the first piece of software was ever written, we've had to solve that place of how do we run it? How do we do it sustainably, safely, securely, reliably, et cetera. There's a really great quote on, who's been attributed to a few different people, but the one I like is from Sasha Rosenbaum. And she used to talk about, everybody has a platform. It's just whether you're whether you know it or not, everybody has something that is a platform because you have some stuff that's going on to make your software run. It's whether you're actually curating that platform, or it's happening to you, basically. And so it's lots of different parts. This is the thing I always find interesting is it's a mishmash of security and observability and networking and user access. And I mean, it's all the pieces and where we cut that line as to who's responsible for what, that's where the interesting stuff happens actually, because DevOps is that mantra of you build it, you run it. What we've seen with DevOps is teams kind of doing that vertical slice. So they're writing the code and they're having to figure out quite far down the stack for themselves.

That was the idea of DevOps was reduce the friction between those horizontal silos, Dev and Ops. And let's make it so that DevOps means you're doing everything kind of right the way down to the infrastructure layer. And that's been popular since what, like 2009. The challenge with DevOps has been that those teams, this whole full stack developer term, which don't know if I like that, but you know, people do.

Anne Currie (05:21)
Mm.

Paula Kennedy (05:38)
It's a lot, and there's been a rise in the usage of the word cognitive load. People talk a lot about cognitive load. It's come from developers being asked to do much more and our tooling landscape getting much more complicated and microservices where everything's broken down into little pieces. There's lots of contributing factors that have meant there's more and more things to think about. That's all cognitive load is effectively. And therefore DevOps is great if you're a certain size, if you're one team and you know, if you're a small organization, one team, one or two teams and everyone's kind of doing it, that's great. When you get to a certain scale and every DevOps team is solving that gap between the code and infra in slightly different ways. So you've got multiple different solutions. So you've got five different kind of infrastructure as code tools and you've got four different databases and you've got five different programming languages and then your security across that estate becomes complicated and unmanageable. And how would you audit it? And how do you know all the versions of all the things and it, that's the complexity. So platform engineering, sometimes people accuse it of, I heard someone say it's basically DevOps in a trench coat. It's not that it's a way of trying to solve some of those gaps and basically raise up the value line, something we should talk about when I was at Pivotal. You'd raise up the value line so that a platform team can offer a whole load of those complexities. They can solve the networking, the plumbing, the stuff that the developers don't want to solve. And if they can offer those things self-service with a platform or platforms, plural, then dev teams can self-serve the things they need.

They can still do their own dev and ops because they're still operating some of the stuff that's in their part of the stack. But a platform team takes care of a lot of stuff. So it's just shifting that boundary.

That was a long answer, I'm sorry.

Anne Currie (07:44)
So, that's all right. So, now I'm gonna do as I always do, roll us all the way back and then actually most of this thing is gonna be actually about what you've just said and we'll approach it from a number of different angles. I'm quite, I haven't really been involved in doing the platform engineering stuff. So, treat me as if I am a total fool. I'm sure you will find that difficult.

Paula Kennedy (07:56)
Okay. Okie doke.

Anne Currie (08:15)
So many years ago, nearly 20 years ago now, 15 years ago, I was head of IT for an enterprise. And we're talking about enterprises here. All of this stuff is about enterprises. And it was back in those days, it was very common. It was certainly the case that you had a software engineering team, you software developers, and you had an ops team. And the software engineers wrote the code. They just, and they wrote their bits of Java or C or whatever they were writing. And then the operations team managed all the databases etc and you as a developer didn't touch those things because you were not trusted. Rightly so. you weren't trusted to touch those things. We had things like

Paula Kennedy (09:04)
Yep.

Anne Currie (09:08)
PCI compliance, which meant you weren't allowed to touch things because you were a security hole. And then so the developers would write the code and then they'd chuck it over the wall to the ops team and it would be the ops team's job to make sure that it ran and it ran reliably and it ran securely and and they had to apply all the patches. And basically never the twain shall meet. They were totally separate. And that caused all kinds of problems, cultural problems, because obviously, you know, kind of like, well, what is the relationship between those two teams? It's a bit like, are the ops teams, you know, effectively the servants of the software engineering teams? You know, it's kind of like, what is your relationship here? And DevOps was invented to solve that.

Paula Kennedy (09:34)
Yep.

Yeah.

Anne Currie (10:02)
by getting everybody together effectively and saying it's everybody's job to know what's going all the way through. I mean, the classic thing was that the software engineers would write the code, but then the ops team were on 24 seven call out.

Paula Kennedy (10:17)
Yeah,

absolutely. Trying to fix code that they'd never written, didn't know what it was supposed to do and how the heck were they supposed to like fix it?

Anne Currie (10:27)
Absolutely. And so DevOps was kind of the approach to everybody together and, but then, as you say, the problem with that is that that's all very well, but that's a lot of stuff for everybody to then know.

Paula Kennedy (10:46)
It is.

Anne Currie (10:48)
And I thought, the reason why after seeing your talk, thought, yes, yeah, you really need to come in and explain this, is that I thought that the talk that Niki did, the podcast that Niki and I did a couple of weeks ago, episode three, it really illustrated what complicated and clever stuff in ops team that was a totally dedicated ops team could do. And then it's just not, it's not realistic to have people to say, well, you've got to keep on top of all of this stuff and all the software engineering stuff as well. So, you know, platform engineering was brought in as a way of ordering, organizing the relationship and splitting that cognitive load. Is that right?

Paula Kennedy (11:44)
Yeah. Yeah,

that's it. And it's, what's interesting, actually, is if you think about the, like, where cognitive load sits, right, so one of the I gave a talk a while ago, which is, I think it's called whose cognitive load is it anyway.? And it's it's honestly about and Rachael Wannacott I don't know if you know her, she excellent speaker, she gives a talk about cognitive load being like energy and you can't actually destroy it, but you can redistribute it. It doesn't go away because complexity exists in the system. And all you can do at any point, at any point is distribute the cognitive load as evenly as you can so that one team isn't overwhelmed. And you're absolutely right. What we've seen is DevOps try to solve the lack of collaboration ultimately because two teams with different concerns, like developers were trying to ship features, ops were trying to keep the steady ship and not have any outages. It was just constant friction, right? And organizations were slowed down by it. DevOps tried to solve that by merging them together and then teams can have full control, kind of the top to the bottom of the stack. And then we've seen this being overwhelmed. Platform engineering has come in to try to say, okay, if we have a dedicated team taking some of those concerns, it is taking that full set of decisions, knowledge, and spreading across people. The idea though is not to recreate the dev versus ops. The idea is that the platform team serves as an enabler to like you mentioned about ops being a servant. You could think of, we talk about platform as a product actually, which is the mindset of the platform is a product being consumed by the developers as customers.

So it's less about being servants, but it is certainly about offering a good experience to those developers actually, and making sure that they have what they need. And you're right, when you have some amount of specialism in the platform team, they can do some of the amazing stuff Niki talked about. The real fine tuning. One of the things that blew my mind and heard her podcast with you was about how she could talk about sort of charge backs and costs per product and actually allocating. I loved yours and her reflection on when you get to that level of specialism within a platform team and optimizing and tuning and clarity, sort of transparency of data, transparency of ownership. It's fantastic as long as your organization is ready to see that as kind of ownership and not blame, right? Because That can be challenging, but that's exactly right. What you described like platform teams are shifting some of the cognitive load out of this. They'll, they'll own some parts of it, which frees up the developers to focus on the stuff they're good at writing code, writing features. The platform team can focus on and get as advanced as, as advanced as Niki, you know, much more kind of scaling efficiency. Again, guardrails you mentioned about PCI compliance, right? When you're enterprises, you've got to have a lot of those things built in and therefore platform teams can specialize in that. One thing that we've actually noticed, because actually platform engineering is not new, actually. I mean, I feel like I've been talking about it forever. One thing that's interesting though, if you think that platform engineering is designed to take some cognitive load, one challenge that we've been seeing is if you shift all of the cognitive load into the platform team, if you're not careful where your boundary sits then the platform team becomes overloaded because they're trying to do so much, especially when you've got multiple, let's say DevOps teams in the past. And then the idea is those DevOps teams say, well, you can take care of my database, but every DevOps team says that. So platform teams now what running five different database tools. And so once people start thinking about this way of working, it's easy that the platform team suddenly becomes the bottleneck.

So one thing we've been trying to talk to customers about, and people in general in the community about is this more like your platform should be a marketplace where you've got producers as well as consumers so that your developers are consuming the platform, right? They need a service, they get the service. They can also be providers into the platform. Because if you have a developer team who's a specialist team in a particular type of code or particular service, they can contribute it to the platform.

Paula Kennedy (16:26)
So if your platform becomes a marketplace, if you think of something like, my friend Abby does a really great analogy. think of like Etsy or Uber, Uber doesn't have the people who want taxis or the taxi drivers. It just provides the marketplace where those people meet in the middle. If your platform can do that so that your platform team is offering the platform, but database specialists can contribute a database service. Networking specialists could contribute networking access.

Anne Currie (16:42)
Mm.

Paula Kennedy (16:56)
Your developers can then consume, your specialists in your organization can contribute, and your platform team doesn't have to know everything about everything. And that's sort of how we think of platform engineering at scale, actually. Cause you don't want to just shift the bottlenecks, right? That's the other problem.

Anne Currie (17:16)
Well, yeah, that's true. But it's interesting what you're saying that. I think what I was taking away from Niki, and I think what I'm taking away from you as well is what always struck me about the issue with kind of like you've got dev and you've got ops and there's no DevOps, the pre DevOps days is that you do need to have a chunk of ownership of what you're providing, the service you provide. So one of the things that you talk a lot about is platform as a product. If you have a product, if you are offering a product, you choose what features go in the product. You choose what your product is going to offer and what it's not going to offer. You're saying about one of the issues of just endlessly taking on new databases and things like that.

It's a bit like chucking code over the wall. You know, if someone says, well, you know, I'm chucking this database to you over the wall. You don't have ownership if you can't say no. But if it's your product, if it's your product, you own it. You have the ultimate say you can say, well, you know, actually, I don't, I'm not going to have that part of that database in our product because it's insecure or I don't have the resource to adapt that. I just don't choose to put it in the product for many reasons. You can use it, but you'll have to look after yourself. you know, you choose.

Paula Kennedy (18:37)
Exactly.

Anne Currie (18:39)
Do you want me to look after it? In which case it has to be one I want.

Paula Kennedy (18:42)
Here's four other databases that I have. Exactly. That's exactly it. And it's so interesting, right? Because some of the, the best solutions I see is exactly that where you, you've got the product mindset. And it's a bit like when you're going to AWS for your cloud services, right? That's a very clear contract of what is owned by you and what is owned by AWS. There's no blurry boundaries. If you've written the code and you're running it somewhere on the cloud, like

Anne Currie (19:03)
Yeah.

Paula Kennedy (19:12)
It's very clear who owns what. And if the internal platform has the same mindset, there's the product, here's the boundaries. We own this, you own this. And if you have the concept of being able to especially have a self-serve platform as much as possible, Developers get what they need. They can run it. They are responsible for the parts that they write. The platform team is responsible for kind of keeping that service available and owning it. And then that contribution model, like you say,

You might find a team that wants to try out a new thing. And out of a, if you're an 80,000 person organization and you've got the platform team, they may say, right, well, it's only going to serve your team. Have at it. You go for it, but you build it, you run it. That's your thing to own. And there will be very valid use cases for some teams to have specific things, right? Absolutely. And then there could be things where a team is experimenting with a new tool.

And actually it's going to benefit the whole organization. So the platform team could say, okay, perfect. Give it to us. We'll take ownership. And that model of kind of clear, it comes actually down to very organizational context as opposed to actually technical, right? But it's very much ownership, right? You absolutely nail on the head and it's exactly that.

Anne Currie (20:12)
Mm-hmm.

Yeah, absolutely.

I was very struck with that. So I'm going to use a term that I've heard young people use. I like it a lot, which is main character energy. In Niki's talk, Niki's podcast, thought she had a lot of it. seemed like she and her whole team had a lot of main character energy. They had a ownership. They were saying, ah, well, we want to do this and we want to do this and this is what we're going to offer. We're going to be like the stars of the world in terms of operational efficiency. And we're going to contribute to Kubernetes and we're going to contribute to Kepler because it was full on main character energy. And it seemed like she was attributing that to the fact that they owned it. It was their platform.

Paula Kennedy (21:05)
Yeah, yeah, yeah.

Absolutely. And I think that's the, that's a, it's a really good way to think about it. But the caveat I would say is actually that when you're building a product, like with any product actually, and I see this a lot, unfortunately, is that when you're building a product, there's a, it's human nature, but there's a very strong tendency generally for people to build the product that they think other people are going to love. Right. And particularly what's interesting in platforms.

Anne Currie (21:41)
Ha!

Paula Kennedy (21:43)
is it's being built by engineers for engineers generally. And so then you get a vibe of, I'm an engineer. Obviously I know what other engineers want. So I'm going to build that. And that is sort of the opposite of product thinking, right? That's not doing user research. That is not thinking about your user centered kind of design. It's, I'm just going to build the thing that I think is right because that obviously makes sense, right? 

So, I really do like the main character energy, but there's, there's a caveat. There has to be a checkpoint to make sure that actually you're building a product for other people in most cases. And an anti-pattern we see sometimes is where organizations mandate that teams must use the platform. What you want to have is that your platform is good. 

And it might not meet every niche case, but it's better than teams having to do it themselves, right? It's the easiest thing to do. Therefore teams want to use it, but you have to keep in mind that you're building it for them and not for yourself. So if you are, if you go on a journey of I'm going to build all the things that I think are the best and the coolest, it might not win over your customers. I'll say that.

Anne Currie (22:58)
No, I can totally see that. Yeah, you don't want to just exchange the dynamic from, you know, it's yeah, the dynamic is trying to avoid kind of one person is in control and one person just has to do what they're told.

Paula Kennedy (23:15)
Exactly. It's an exchange of value effectively, right? You're building a product. You want people to use it. I mean, they're not paying you, but there's a contract is how we like to think of it, right? There's a contract between the developers and the platform provider, and it needs to be clear bounded. Everyone knows who owns what, but the platform doesn't exist for funzies It's not... Shelfware, it's not your shiny experimental toy that you've built. It's there for a purpose. It serves the consumers of the platform. So it has to be what they need actually.

Anne Currie (23:52)
Yeah, that makes sense. That makes a lot of sense. 

So one thing I want to talk about in the future is how AI fits into all of this, because everybody's obsessed with AI and rightly so.

Paula Kennedy (23:58)
Yes.

Yes.

Can't have a podcast without it, right? You've to talk about AI.

Anne Currie (24:18)
But I don't want to go into too much detail on this one. It's like, presumably you have been doing some thinking about how AI fits into all of this. If you give us a little hint and then maybe we can either have you back or one of your friends and colleagues back to talk a little bit about how AI and platform engineering, what's the current thinking there?

Paula Kennedy (24:43)
Glad you asked that question, Anne. So yes, we've been thinking about it a lot as everybody has. What's been interesting to observe, mean, things in the AI is supposed to be moving so fast is actually scary. And I can't work out if that's just a feature of getting old, but I also feel like things are moving faster, right?

Anne Currie (25:02)
It's crazy fast, it's unbelievable. It's not just that we're,

Paula Kennedy (25:06)
Not just old, not just that we're getting on a bit. So

if you think about it from a, from a kind of, again, beginner sort of way of thinking about it, right. We've seen AI around in things like co-pilot, helping developers write code, but it's been more assistant to developers than kind of going off and doing its own thing. Then more recently we've seen the rise of agents, agentic AI. Everyone's got agents doing everything where agents are sort of replacing developers. no need to write your own code anymore. Agents will do everything. 

A couple of observations. One is that AI helps people go faster, helps organizations go faster, let's just say, but any bottlenecks in your organization, any constraints, anything that's a bit janky just gets amplified by AI. So if you haven't got good documentation for your AI to consume, if you haven't got good guardrails built in or If you kind of accidentally, developer could delete production code, then funnily enough, so could your agent. there's, there's a lot of great things about AI, but it can amplify everything that's wrong in your company today. AI just amplifies it, makes it easier to do things faster and wrong. Let's just say, the way we've been thinking about it more actually is thinking of AI agents more like, I mean, like developers actually. So where you may have an org where you had a small team, maybe a hundred developers. If each developer is now managing a team of agents, you could see 10 X, 50 X, like multiple increases of code being written and generated, like good code as well. Like, I mean, there's vibe coding, but obviously more good code happens. Then platforms actually become more important because You need a way to be able to run that code safely. You've still got the same gap. 

If you think about agents as people, like the kind of the gas town style where your agents will get names, I don't know, but like that whole, as I described at the beginning, if you think about what is platform engineering is everything between code being written and being deployed, it's all that gap in the middle. If you're 10Xing, 100Xing the amount of code that's being written, it's even more important to solve all of those challenges underneath to make sure it's secure, to make sure it's got the right guardrails, to make sure it's not doing like, like say weird, got weird access to certain things that you wouldn't want it to have access to. It's, it's the platform is actually the way to be able to make it like better of running AI generated code. And so it becomes more important. So it's a thing where we're certainly looking at a lot and we're seeing a lot of interest. We're seeing a lot of people come to us and ask us about how can they deploy AI code more safely?

Platforms are actually a way to do that.

Anne Currie (28:05)
Yeah, no, that makes a lot of sense. Yeah, huge amount of sense. That's come up a few times on the podcast. I think operational jobs will last longer than software engineering jobs. mean, the company that I was a head of IT of years and years ago was an e-commerce company. And even while I was there, a whole load of software engineersstopped doing what they were doing, more we repurposed to something else at the time. They used to do, they used to draft HTML for the website. And we, at the time it was before content management systems, but we wrote our own content management system. Well, once that was in place, then you didn't need HTML developers, you didn't need software engineers to do that stage. You could just have marketing folk talking directly to graphics teams and then putting the stuff live because

Paula Kennedy (28:56)
Yeah.

Anne Currie (29:01)
it was a clear interface to how you actually put it live and it was designed so that they couldn't destroy the website while they were doing it or introduce security holes. yeah, the developers had to be taken, software engineers had to come out of that because they were bottlenecks because they were on and they slowed everything down.

Paula Kennedy (29:10)
Yeah.

The worst thing actually is for the platform to be the bottleneck because, even with, with what we were talking about before with the cognitive load splits and you're trying to reduce cognitive load on developers. So you're shifting it into the platform team, but you don't want to overload the platform team. 

Same thing with AI agents, actually it's exactly the same principle. So you've got more and more code being generated. Does that mean your platform is the bottleneck? That is a thing we're going to see. So, I talked already about that producer consumer model, right? So that the platform can scale to offer the services that are required. It has to have those intentional guardrails to make sure AI is being used safely. But the world we haven't really seen people talking about yet, but it's coming. actually, well, I'll go out on a limb make a prediction here.

Anne Currie (29:55)
Really?

Paula Kennedy (30:19)
The world I think that is coming is that plugging in agents at the platform level. So we got probably, I mean, I'm sure there's a lot of people out looking at like agents doing provisioning of infrastructure, right? Again, needs the guardrails in place to be able to make sure you're not spending masses on AWS accounts, et cetera. But there's ways in which, as we think about bounded context, who owns what and the clear APIs.

If you are already in a situation where you have a mature model, mature way of thinking about who owns what, and you have a sort of a mature platform team who are thinking about some of those advanced level things that Niki was talking about, or even maybe not that advanced, but like you've got a clear way of knowing who owns what, how to attribute costs right, kind of correctly, how to build the security in so it's first-class citizen of the platform. If you're then able to plug in AI in the platform itself.

So the AI is able to do lots of the, take on some of the operational concerns within the platform safely. What you're trying to do is make sure that the platform isn't the bottleneck. And I mentioned Abby, Abby, my friend at Syntasso she does an amazing, she did an amazing keynote at KubeCon Amsterdam last month, feels like weeks ago. It was last month. But she talked about where is your bottleneck? And she gave an analogy of Do you scale by getting faster bikes, e-bikes? If your commute is very long, do you get a faster bike or do you actually need to do kind of the horizontal scaling and actually get wider cycle paths so that more people can kind of travel at the same time? As she talked about, there's always a bottleneck actually. There's always a bottleneck in your system and it's identifying where it is and then relieving that bottleneck and then solving the next one and solving the next one. So if AI is going to overload us with code And if your platform is becoming the bottleneck, that's going to be our next frontier to, I guess, solve for. And that's where it's exciting. It's exciting for us because we live and breathe that stuff. yeah, it's pretty exciting.

Anne Currie (32:26)
Yeah, constraints. Yeah, we've all read all the IT revolutions books. Although I would say I really like the Goal the book that Phoenix Project was kind of an extension of, which was kind of the first crossover of the Toyota production system.

Paula Kennedy (32:33)
Exactly. There's always a constraint somewhere.

Anne Currie (32:52)
to technology, to, well, the Goal was about applying it generally and then the Phoenix project was about applying it to tech, it's all, yeah, it's all very good stuff. So.

Paula Kennedy (33:05)
This is funny,

none of it is new, right? And none of this stuff is new. It's all just like Daniel, my friend Daniel Bryant, he always says like, history doesn't necessarily repeat, but it rhymes. Like he always says that. And I'm like, yeah, it's very interesting.

Anne Currie (33:17)
That is very true. 

I'm very happy with this episode. And I now think our brains are full. But thank you. That was absolutely fascinating. I'm so glad I came up to you after your talk and said, can you come on, come on next week.

Paula Kennedy (33:28)
And it means my talk must have not been too bad at Devoxx because you came and asked me, so I was really pleased. Thank you.

Anne Currie (33:44)
It was very good.

It was very good. And it was lovely to see you again. It's been lovely to have you on the podcast. I'm sure that because I really enjoyed doing these podcasts, because it's really nice to have a chat and find out what everybody's up to. So I'm sure I will ask you back and all of your colleagues and of your platform engineering friends.

Paula Kennedy (33:57)

We have many, many opinions, Anne, so, you know, ask any one of us. We've all got very strong opinions about these things.

Anne Currie (34:10)
That sounds excellent. Well, thank you once again for being a guest on asynchronous and unreliable podcasts. And thank you to all our listeners and watchers and hopefully I will catch you on the next episode. Goodbye.

Paula Kennedy (34:20)
Thank you very much.

Anne Currie (34:34)
Thank you very much for listening to Asynchronous and Unreliable podcast. If you enjoyed the show and you want us to create more content, please do show your support by hitting the subscribe button below. It really does make a difference. Thank you very much.