# Platform Engineering Strategy: Golden Bricks and AI Agents

**Podcast:** Thoughtworks Technology Podcast
**Published:** 2026-11-12

## Transcript

Hello, everybody.
Welcome to another edition of the ThoughtWorks Technology Podcast.
My name is Ken McGrath.
I'm one of your regular hosts.
I'm very pleased today to be joined with a former colleague who's gone on to bigger and better things.
Abby, if you don't mind introducing yourself.
Yeah, thanks, Ken.
So my name is Abby Bangzer, and I was a former colleague first in Chicago at ThoughtWorks and then in London.
And since I've stayed in London and worked for a few companies here, and I'm now at Syntasso building a platform engineering framework called Craddix and also working a lot with the CNCF and Team Topologies folks as an advocate and ambassador there.
Cool.
Great to have you.
So Abby and I actually, for just disclosure to the listeners, have a lot of crossover in past career stuff, even though it's not direct.
So I came a lot from the DevOps delivery side and, as you just mentioned, platforms and so forth.
I thought platforms were supposed to solve everything.
What happened there?
I mean, here you are, you're building another platform.
What's different?
What's different now and what platform?
First of all, can I feel like you're showing your age alongside me of being like, but this isn't new?
Because I feel like for some people, they're just hearing about platforms for the first time.
And to be clear, if that's you, it's OK.
Like you as a listener, it's OK.
But platforms are not new, exactly as you're describing.
The interesting thing I think that's happening today is that we are.
entering into yet another one of those pendulum swings of the industry.
So we start with a pendulum swing of decentralization, centralization, decentralization.
We see that in all aspects of technology, of software development, processes, etc.
And we saw that with like the dev and ops separation into the dev ops decentralization.
And now we're talking about re-centralizing that unique aspect of tooling within an organization.
in order to create these internal economy of scales, these internal high leverage tooling supports.
And I think that is the thing we're talking about.
Whereas maybe 10 years ago, 15 years ago, when good old Heroku and Cloud Foundry and all those were taking over the world, those were third parties we were depending on.
Now we're talking about bringing this internal to our tooling.
And so maybe that's the nuance that we're seeing is a unique bit.
So there's a story that you tell a lot where it's the shiny object, if you will.
And again, maybe sharing too much, but I have a five-month-old Great Dane puppy at home.
And the day we brought Mongo home was a very fun day.
And every day since then has been a bit of a test.
So you have puppies for Christmas story that you apply to platforms.
What's that in your own words?
First of all, I just want to see the size of Mongo's paws in comparison to those legs.
Oh, man, that must be amazing.
He's 73 pounds at five months.
Oh, my gosh.
Yes.
So I myself have had a puppy.
Well, to be fair, it was a rescue, not a puppy, but still had that same settling in period.
And I think that it's...
The story I tell is that that experience that you're going through, that I've gone through, many of us have, where you're really excited because you've got this new fluffer butt who's come into your life, who gives you cuddles and joy and excitement, turns into more of a chore than just the joy that it's bringing.
All of a sudden, it's a number of walks a day.
We had four walks a day.
Some dogs need more or less and so on.
It's making sure you have the right food, finding the right foods.
Their stomach isn't upset.
It's making them...
the vet visits on a regular basis, not forgetting kennel cloth for the week before you have to go on vacation because otherwise you can't drop them at the kennel.
I've been there.
You know, all these things that you now need to like track and deal with because there's a heck of a lot more time you're going to spend with that dog and that puppy than that first day or first week where it's really the kind of excitement.
period.
And that's true for our infrastructure as well, right?
Because we often look at the fact that it's exciting to start with a clean slate, right?
Our new, perfectly polished Terraform modules, perfectly polished infrastructure as code of whatever flavor.
But the reality is, is that is just the tip of the iceberg.
We end up having to do patches and upgrades and new feature requests and everything else.
And so it becomes Challenging.
So who's dealing with all of that challenge?
Well, if you're leaving it with your centralized team, they have the skills and the knowledge to manage it.
But if you are handing those Terraform modules that are going to need the love and care over...
many, many day twos in the future out to your application teams.
Now they're getting that puppy for Christmas.
They think they're getting something great and shiny and new and a great cuddle buddy, but they're actually picking up all the vet visits, all the food they have to deal with, all the chewed up shoes and all of that.
And so you're giving them just a puppy for Christmas.
Yeah.
I mean, I love the analogy because I mean, it couldn't be more correct.
I mean, we write all these.
like worry about developer experience and that sort of thing.
And we get the app out there, but then it breaks, right?
And someone's got to do anything.
But that said, I hear mostly still from, and maybe that's because of just the audience that we have and that sort of thing.
We heard mostly from the developers.
Oh, it just needs to be easier.
But you don't, I don't think you're saying that's not really the optimization that is the most important to the organization.
And so what do you mean by that?
Yeah, I think.
To be clear, I think that is the optimization that the organization demands.
So I look at that as sort of the platform consumer side.
And I think the organization, that's why they're building this stuff.
That's why they're investing in any tooling.
A platform is just the tooling that lets people do their jobs.
Right.
And so whether that be something you can buy on the market, whether that be something you have to build, whether that be something that they have to build themselves in order to do their jobs.
This is the auxiliary tooling necessary to do their jobs.
And I think doing their jobs is still the goal.
The big thing for me is that we aren't focusing enough on the impact of poor developer experience when building those tools on the impact of that customer experience.
So I've been in software development for many years.
I was actually on a ThoughtWorks client and we were working with a large financial institution and they had a set of APIs and we were trying to build a new user interface off the back of it.
one of the things that these APIs had done and they were provided to us was that they had provided address one and address two as just a set of fields.
So address one, you know, you can think of this like shipping and correspondence addresses or address one and two.
They had like line one, line two, line three, city, state, zip code.
And then they had address two, line one, line two, city, state, zip code.
So we had these like, I don't know.
15 is 16 fields, eight for each address, just flat in the database.
So all of a sudden, any validation we want to do on the user interface of did they provide a complete address?
Did they provide a valid address?
Did, you know, does this make any sense?
Became something that was really complex for us to manage because there was no sort of grouping of these fields.
We had to group them.
Now, anything's possible in tech.
So when I say really complex, absolutely doable.
But that developer experience we had affected the user experience of our software that we were selling for the bank, that we were building for the bank users.
Same thing goes internal.
When we start saying the only tools you have to build these developer tools that are going to enable our application teams are not very developer experience friendly, then that just...
you know, kind of rolls downhill onto the application developers.
And that's why I say it's not that I'm changing the focus of the organization.
It's that I'm trying to plea to the people in that space and that platform and operation space to think about the fact that if they don't invest in their own tools and their own ways of working, they're going to really struggle to get the experience that those users demand and require, right?
So, you know, we all hear about the golden path, right?
And for those listeners that aren't familiar with it, it's like, you know, you create this path that's so easy.
Everybody wants to use it.
And if you want to go outside of it, you can, but the pain shall be yours.
But, you know, a lot of people find that pain, right?
The golden paths don't often succeed.
You know, what are people doing wrong there?
Or are they?
Yeah, I think there's two things there.
So I think it's, first of all, the right intention.
Because again, the intention is we want to make the right thing the easy thing.
And we want to make the easy thing the useful thing.
And therefore, we're going to create this singular way of doing stuff that's going to be both easy and useful and compliant.
And it's going to be fantastic.
So I think the intention is there.
And I don't want to question that.
Where do we go wrong?
Well, I think the first thing we go wrong on has nothing to do with tech.
It has to do with process and people and communication.
We don't in any way articulate why that golden path.
is meeting expectations so that if you choose to go off it, you know what you need to do.
So when people are going off these golden paths, they are frequently no longer meeting the expectations and often requirements of an organization.
They're no longer PCI compliant.
They're no longer ISO compliant.
They're no longer being tracked in the finance department correctly.
All these things because they just don't know.
And so I think the first thing that we go wrong with here is we don't document that if you choose not to use our golden path, here is your checklist, hopefully automated, but if not at least manual, that would determine that you are meeting company expectations no matter how you choose to get there.
So that's my first big thing.
My second big thing is then that we try and build the most perfect golden path and the...
only thing that has ever been true about software development, well, about life, but particularly software development, is that we know we're going to be wrong and that we need to be able to change.
And yet we build these golden paths as if we're going to be right.
And like, we know we're not going to be right.
We know that even if we are perfect when we're building it, the world around us will change.
And so I really appreciate that some people have come up with, I wish I could credit the right human, and I don't know who did it.
But there's been this movement towards talking about golden bricks instead of golden paths.
And this idea of saying, if you can break down this path into composable bits, just like you would with any other piece of software, all of a sudden you can offer.
an entire path to someone.
And if and when that person either needs a slightly different path or that path has changed because of an external factor, you're not ripping up the whole thing.
You're taking out one brick, you're replacing that one brick, you're adding one brick to the side and it's all okay.
So I think those two pieces make such a world of difference in having an effective golden something experience.
Yeah, I love that.
So in preparing for this, and you and I saw each other a few months ago at an event, if you ask the AI overlords and what have you, a phrase that gets assigned to you a lot over the last several months is just supply chain.
So we've kind of been talking around that a little bit.
What does supply chain mean in this context?
Oh, supply chain can apply in a lot of different ways, can't it?
So I think, you know.
if I place it into some of the things I was just saying, supply chain is one of the things that might be what you get for free if you depend on your internal platform instead of building it yourself.
Because there might be requirements to be able to document your supply chain as a part of your software delivery process.
And that might come for free if you use the platform, but something you have to do manually if you don't.
So first of all, supply chain is like an offering of a platform.
But then there's also the management of said supply chain.
So now this is where we start getting into the interesting, I would say, challenges with everyone uses the same words and means different things situation.
Because I like to look at platforms as managed services.
So if you're going to have something in your platform, and platforms have different levels of maturity.
So let me just preempt.
But if you're going to look at investing in a platform that is of a high level of maturity, what you are trying to do is you're trying to make the experience of a Heroku, a cloud provider, a SaaS provider, where people don't care how it's done.
They just care that it's done.
And they know what they can expect from you.
And they know what they have to bring to the party as well.
They have clear responsibility ownership matrices.
And I think that the supply chain, when you start mixing.
who owns what, managing the upgrades and updates of those supply chains gets hard.
So the example of the puppy for Christmas, I write a module, a Terraform module, it's perfectly secure and perfectly compliant today and perfectly complete on what is being offered from the cloud provider that's being orchestrated.
All of a sudden, the cloud provider comes out with a new feature that you need to make sure is set in a certain way to stay compliant and a new regulation has come into your business.
a security patch needs to be applied to the infrastructure underneath it.
Well, these are the types of changes that we all expect, but the module's in the wild.
Like, who's in charge of updating the module itself?
Who's in charge of pulling that module into where it's being run?
Who's in charge of running that module in the new place?
Who's in charge of making sure the infrastructure that had been templated from that module hasn't drifted?
What happens if it has?
All of that, if it's not a managed service, if you've given that template out to teams, becomes very difficult supply chain.
If you've kept it managed, if you've kept it behind an API, now all of a sudden that one team who understands the Terraform, understands how to run it against cloud services, now has the full control of that supply chain, the full ability to update and upgrade it as necessary.
Kind of related, you did a talk with somebody from a bank.
several months ago, and a statistic came out that something that we've again heard, I've joined my age for decades, but that basically 28% of IT spending was on application development.
So first off, is that a problem, right?
Because if I'm running my business, maybe it's okay that 70% of my IT spend is running my business.
Okay.
But is that a problem?
If it is, why?
And can I just throw agents at it?
Valid questions.
So that was a stat I believe I took from Deloitte, from one of the Deloitte papers, but I will have to go find the exact reference.
I've got it in the slide deck.
And I think that it is used to try and call out the amount of BAU or lights on spend versus the amount of innovation spent.
So whether or not it does a good job of that.
or actually captures that, I think that's what it is trying to elicit from the people who read the statistic.
So is it a problem?
Well, I would say that it is that comes down to what the company wants to achieve.
I would say that most companies would like to think that they are being innovative for more than a quarter of their total spend.
Now, not all companies.
There's many companies out there that are steady state, and that would be actually a very reasonable amount of innovation.
budget.
But I would say that many companies would like to think that they have higher than that for innovation.
So that's the, is it a problem?
And then you were saying, can we just, there was a second question, then can we throw agents at it?
Whether it's the 70% side of the 28%, right?
Like, you know, there's a lot of people out there and I use AI every day and, you know, ThoughtWorks were real big on it, of course.
But they think it's a silver bullet, right?
Oh, I'll just have agents go do the 70%, the BAU stuff, or well, I'll just have agents do the innovation.
You mentioned you work with team topologies and others.
Why are humans still important in the loop?
Yeah, that's a great question.
And I do sort of want to separate the need for humans in the loop and the ability to just have AI do it.
Because I think that those can be put as a...
as opposing ideas when they don't need to be.
So in my opinion, AI should be leveraged.
It should be used.
There is no doubt that its maturity has gotten to a stage where we should be leaning on it when and where we can, especially for BAU.
I think I would argue the innovation stuff is where you are your differentiators.
You probably want to own that a little bit more, but depends.
You're still going to leverage it.
It's just maybe not let it run ragged.
And so I actually want to...
call out that I was at this amazing conference in London yesterday called FastFlowConf.
And it was born out of the ideas behind Team Topologies.
It's not specifically a Team Topologies.
I think it includes Team Topologies somewhere in the name, but it's those ideas.
It's based in London.
It's been running for a number of years.
I think they had a Netherlands edition as well.
And we had a fantastic engineer from Meta speaking this year.
And Chinonso was...
sharing his experience of building a service for meta that did like network configuration.
And he had this image of where he was like agents floating around the team topologies set up.
So you have these streamlined teams, you have this platform team, there's agents around.
He's like, no, no, no, no.
Based on our experiences, agents are in the picture, but they are inside the structures that we already have.
So it turns out we don't need to introduce a new, like, thought process or way of working or interaction model.
They're just stream aligned team members.
They're just platform team members.
And so I do think you should throw agents at it.
But I think that the key is making sure that they are working in a safe environment.
And that's where the people are building those environments.
They're building those constraints.
They're building those boundaries for those agents to work in.
And I call safe for a reason because a lot of people are using are using the fact that when you're talking about laying things down on metal and on cloud providers and on things like that, you can't have uncertainty.
You can't have the creativity that is clawed and open AI and all of those codecs.
But actually what we're looking at is that what we need is we need the safety.
It doesn't have to be completely idempotent.
It doesn't have to be completely deterministic.
Else just write a script.
Use AI to help you write a script and that's great.
You can have agents doing the work for you.
Just make sure they're bounded in the right way.
So another thing you talked about is where the platform is more of a marketplace than a gatekeeper.
So, I mean, you mentioned golden bricks.
I love that analogy, by the way.
I'm definitely going to have to try to see where that came from.
Because a lot of times, like we talked with golden path or whatever, that the platform is the thing that's going to make sure you're good enough.
But, you know, you have this concept of it being a marketplace.
What is that?
What do you mean by that?
I think this is something that is emergent to a certain extent, just to call out.
This is something we're currently in final stages of publishing a white paper with the CNCF about.
And what the idea here is, is that in order to create these capabilities within your platform at scale, you need specialists that are unique.
There are only so many people you can hire that have the level of security, performance, database tuning, and so on experiences, which is why we struggled with DevOps and trying to push all those specialties out to the teams because we struggled to multiply those specialties.
So how do you get those specialties now to work within the centralized environment without still depending on a bottleneck of someone who knows how to write infrastructure as code with them or, you know, whatever?
Well, you make it so they can contribute.
And therefore, you create that marketplace explosion of value that companies like Apple did with the Apple Store or companies like Etsy do with the marketplace they built.
Like the engineers at Etsy aren't...
knitting sweaters every day.
I mean, they might be when they go home, but at job, at work, they are building the tools that allow those creative humans who created things to match with the people who are looking to buy their gifts for their loved ones and home goods and all those things.
And that's what we have to turn into as centralized platform teams is how do we enable the specialists who are unique and often underpowered within an organization to be multiply their power across the organization without having to bring them on the journey of learning all of our centralized tooling.
Like they don't need to know that just like an application developer doesn't need to understand Kubernetes.
Like how do we create a marketplace, central marketplace that both sides can gain value from by us taking the abstraction for them.
So how do you manage that as a corporate structure?
You know, I think of like you have like super flat organizations.
report to the CTO of ThoughtWorks.
But, you know, the CIO might have some things that she wants my input on, you know, or whatever.
And, you know, I have to balance that, right?
I mean, if they're reporting to the platform team, but this product team out there needs them and that product team, how do you manage that?
How do they choose prioritization?
All those types of things.
That's what hopefully the marketplace and what I've seen in practice in the kind of...
emerging companies actually removes as an issue because the marketplace sets a set of standards and a contribution model that then anyone can contribute within their own ways of working.
So more specifically, a platform may need to say that for someone to be able to offer an internal set of tools, an internal tool of some sort, they need to provide an API.
like open API v3 spec so that the API can be requested by a user.
They need to provide some level of documentation around ownership and how that's going to work.
They need to provide the automation that is going to manage a request.
So when a request comes in, what needs to happen?
What is that automation?
And then actually the platform can...
trigger that automation when a request comes in and can serve the documentation in the right places that the consumers can find it as they need to.
And there's more pieces to the puzzle, but you can start to see how that comes together.
And so in practice, what I'm seeing is that done right, this brings shadow IT out into the light because all of a sudden you make it really low barrier of entry to put something on the platform.
But the thing that you've made really low barrier of entry is a sort of experimental zone.
So anything can get on the platform, basically, like bare minimum requirements to get on the platform.
But it's tagged or it's packaged or it's quarantined in a like experimental alpha, whatever it is, zone.
And then there are clear maturity expectations as it goes to beta, GA, et cetera, if you want to use typical product delivery.
When you are in those different zones, it affects who can see and who can use your service.
So all of a sudden, people who go, I want to, you know, the CIO has asked you for something and the CTO goes, I disagree with that.
I don't want that.
Well, you go, that's fine.
I'm going to publish this within my group as the CIO's group or like within the CIO's group over here in that package.
And it's going to be great because anyone in the CIO's community can use that because it's been packaged as.
sufficient for team use, just not sufficient for organization use.
And then we can go through the process of having a communication channel open up of like, why was it not good enough or reasonable for the CTO group?
How do we find a way to make those things match or just accept?
Those will always be separate and that's okay.
And that's how like all of a sudden packaging things up in a marketplace, making things available, you all of a sudden have access to actually bringing bringing things light.
So the blog post I love in this spot is the, it's a really old blog post.
It's called, uh, let a thousand flowers bloom and pull out 999 of them.
And I think that it, uh, it's a great blog post to call out the fact that like some companies can work from a centralized model of we're going to find one thing and we're going to move forward.
But many companies and many cultures can't, or they are too late.
There are all are already a thousand flowers.
How are they going to deal with them?
And This is basically calling out that you probably have a thousand flowers in your organization doing things, especially if you adopted DevOps practices.
But a lot of them are probably not even visible to you.
So therefore, you have no idea how much of them align or don't align, which ones are fantastic ideas that should be leveraged more, and which of them are really bad patterns we really want to try and migrate people from.
bring them into the light, bring them on the platform, get them there as quickly as possible.
And then all of a sudden you can start picking out flowers until you get down to one that is a golden path that people can depend on, right?
So then like that separation that we just talked about of, you know, I think Microsoft used to call that blast zones.
And when they're talking about feature flags, it seems like the same kind of idea.
Is that accurate?
If you listen closely, you'll hear all the software ways of thinking and working coming out in me about platforms.
I think it is just software.
And yes, so absolutely, it is the same thing.
So how deep does that go?
So like if we think about a company that makes tractors, pick one.
There's all kinds of software now where these things are autonomous vehicles.
They can go mine.
the minerals without a human in there at all and so forth.
And they also write software that allows people to order replacement belts.
And they also write software that, you know, makes it so they only make right-hand turns in the U.S.
or left-hand turns in the U.K.
These are all very different things.
Is it still – is it one platform?
Is it by business unit?
Is it by tech stack?
I mean, how many platforms are we?
I know it's an impossible question.
I know it's an it depends question.
But, you know, for the listeners that are like, wait, but I'm too big to have a platform.
What are the thoughts?
What are the questions they should ask themselves?
No, it's a great question.
And actually, we've been very particular about speaking in plurals whenever we're working with the CNCF papers because that is you're calling out something that's.
accurate and true and that we are seeing in the industry.
So first of all, that when I use singular, it is out of error more so than out of, uh, out of intention.
But I would say that the, the reason why I, I, I do speak in singular quite a lot still is because it's about those patterns.
And so one thing I'll call out about platforms today is that there's.
they do mirror a lot of software engineering over the years.
And one of the big things that it's mirroring is that three-tier architecture.
And now we can have fights over like thin and thick controllers and all these other bits that are, there's no one answer to how to write software, but it's the models you're thinking in that really matter.
And when we think about three-tier architecture, we think about the display, we think about the, you know.
messy middle of business logic and we think about the sort of domain objects at the bottom and that.
And in the platform space, that's talking about things like MCP servers for access and portals and CLI tools and those things at the top.
At the bottom, we're talking about things like infrastructure as code, things like writing out to cloud providers, SaaS products.
you know, hardware, mainframes, et cetera.
And the messy middle is your business processes.
This is actually, the platform is that.
It is, how does it go from someone needing something to it being business relevant and compliant?
That is, hit all the tick boxes that business requires.
So I don't think you're going to have one platform in the sense of that you're going to have all.
All the capabilities written in the same language, in the same level of abstraction, in the same tech stack, in any of those things.
But what I think you can have is the idea that your platform is something that is consumable by API.
When you are getting something from your platform, it is compliant with your business requirements and you can trust it, that it is business process approved and that it offloads and manages the infrastructure.
down the back end.
And I think that is consistent.
And that's where these frameworks that you can use to sort of manage, you know, different platforms, different shapes.
But I'm seeing, so when people are using Craddix as one of those control planes, we're seeing them deploy multiple Craddix, Si.
I haven't come up with a plural yet for that.
Because they will, just like I did when I was a software engineer and I would have, you know, a PCI compliant zone in my cloud.
a state and then I'd have to treat that and I'd want to keep that as small as possible, as trim as possible and make sure it's always compliant.
And then I would allow like run rampant outside there, you know, to a certain extent, right?
But like it has different constraints outside and you'd have these different areas.
Same thing can go for platforms.
You might have a control plane that you consider that's within your compliance requirements, a control plane that is outside certain compliance requirements, a control plane that is at different levels of expectation, I guess, from the users.
Not to make it a product pitch at all, but one of the reasons I wanted to talk to you is I know you to be a very pragmatic person.
And we talked about the fact that for those of us, not that you have one, but I have a very gray beard.
Those of us have been around for a little while.
We've seen lots of platforms.
What's different about what y'all are doing with Craddix that made you say, hey, the world needs another platform?
I think the big thing is I didn't say they need another platform.
I said they need a way to build their platform.
I think that's the really key bit in the sense that I'm not building right now a Heroku competitor, a Cloud Foundry competitor, which, you know, that's showing my gray braid, as Bridget likes to say.
But, you know, it like, you know, Fly.io, Vercel, whatever the ones are people are depending on today.
What I'm building is the way for you to build that experience for the technologies and the processes in your organization.
So it's a layer below those platforms as a service.
And so, yeah, my team will probably kill me for this, but I love the first ever sticker we made at the company.
I was going to speak in the U.S.
and we were going to make some stickers because why else go to a conference?
You have to have stickers.
And I designed some stickers that were little burgers that said, your platform, your way.
which I will not say anymore to make sure I don't own any problems with copyrights.
But the idea there is that we believe that we can't build your platform for you.
We can't build you a platform that will work for your organization.
What we can do is give you the tools so that you can build it for yourself in a sustainable and manageable way.
So that's really the biggest difference.
Yeah, I love that.
We used to say, gosh.
15 years ago, you know, there's no condition delivery in a box.
Um, You know, there's too many people that have tried to sell platform in a box.
And, you know, frankly, it just doesn't work.
To be clear, it does work for certain deployments.
And it's just what we found is that at a certain scale and at a certain age of company and a certain complexity of domain, it isn't complete for their organization.
And so what you're basically creating is a two-track experience in your organization.
The track that can depend on that third-party paths that is a brilliant chef's kiss style experience.
And then the people who can't.
And often the people who can't depend on those because they don't have 12-factor apps, they don't have, you know, whatever is the requirement to use that paths are actually the ones working on the biggest revenue generating part of your business.
And you've created them a bad experience when that's actually where you maybe need the most agility being injected, right?
Or certainly the most innovative, even if not the best revenue, the best future potential.
So like I had mentioned earlier, we were at an event together a few months ago.
And the event was run under the Chatham House rule, which means I can't mention other attendees that weren't there or so forth.
But there were several people there who were, I think, very well respected.
One in particular said, you know what?
None of this stuff even matters anymore.
I just have seven agentic things run off.
and build seven different versions of the application, give each one to the users, let them choose the best one, and then I tell a different agent to go put it on Google Cloud, I don't need platforms anymore.
I don't need DevX anymore.
And I mean, this is one of the people that's been around for a very, very long time and has written some great books.
And they were playing devil's advocate a little bit.
You know, there's also some shred of truth to it, right?
And so, you know, in today's age where I can just go tell my AI tool to do things, is this still as important?
Is it more important?
Is it less important?
Is it just a shift?
I mean, what's this due to your thinking?
I think the biggest thing is that they said they don't need a platform, but they have one.
They have a few platforms in there, right?
So first of all, I heard you say they're going to go deploy it out to Google Cloud.
That's a platform.
There you go.
They also said that they're going to go after agents.
Well...
If they're a single developer, they might not think of it like a platform.
But the minute that you have multiple people in your organization, depending on agents of a certain shape or size or scope or context or domain, they become platforms.
So I think the big thing here is that I want to call out is this concept of a floating platform that Gregor Hope visualizes so well.
So Gregor talks about a floating platform as the idea that in comparison to a floating dock on like a lake.
So if you've ever grown up going to a lake and there's that wood platform you get to jump on and jump off of, it's often anchored in some way.
And if that lake changes height too much, it can get sucked sort of under.
And if it's not like buoy oriented, if it's actually anchored to the bottom, that's what's happening to the technology we depend on to deploy our software.
So again, platforms are just the tools necessary to do our day jobs, like to create value.
And if we start anchoring ourselves to the tools available today, if we had done that 20 years ago, we'd still be talking about like cooling at scale across the organization.
And we'd still be talking about, you know, the data center design.
Now, we still are in parts of the industry.
That's important, but not at scale.
That's pretty much a commodity at this stage.
So what is it about today that has become commodity for tomorrow?
And so on.
And I think that what's happening is that people are seeing the things they used to care deeply about become commodity.
And so they all of a sudden are saying, well, therefore, I don't need a platform anymore.
But actually what they're what they're feeling and what they're seeing is that that platform is rising.
And if they and they are feeling that they can't unhook from where it sits, where their current platform sits and rise with it.
So they're throwing it out and saying.
I don't need it.
When actually, if they built their platform in such a way that the APIs, the inputs to it or ingresses to it were about the jobs that needed to be done, the ability to deploy an application, the ability to test it with users, the ability to scale it when necessary, the ability to get a test environment, these things that are in that story you're telling me still present, then all of a sudden they could have moved up the stack from saying, I have these really handcrafted infrastructure as code solutions to behind that API, I've just thrown an AI with really smart, like an agent with really smart context and clear boundaries and clear least privileged permissions.
And that's now the thing that does that job to be done for me.
So I think platforms are in that story.
I just think people are not yet working at a collaborative scale.
where they're realizing that these things are across.
And so we're working with, I've been talking to many people through my work at the CNCF as well as customers.
And we're helping people do things like manage that agent experience on their infrastructure and within their organizations consistently across teams.
And that is their platform now, the harness.
So are agents just faster consumers or are they a completely different kind of user?
I think they're faster consumers.
I think, well, So I think that that is what they become is they become really, in some ways, really smart and in some ways, really silly, faster consumers.
So probably a bit like your puppy, to be fair.
So they're a bit like Mongo.
They're like, I can go do everything for myself and I will go find a way around whatever barrier you think you've put in the way of me and that food or that ball or that thing that I want.
And I think that's the thing about AI is that humans can learn.
Humans can have empathy.
Humans can have relationships.
Humans can have emotions.
And that has good and bad aspects when you're collaborating and working together.
But AI doesn't.
So if AI hits into a roadblock, it's just going to go off and do its own thing somehow, right?
It's not going to accept the fact that, oh, that's probably there for a reason.
Maybe I should go call up my friend and see why that's there and make sure I'm not doing any harm if I go around it.
That's not going to happen.
So faster consumers with...
out the human emotion associated with it that often paper over some of those challenges.
So one of the quotes I saw attributed to you, and first off, let me know if it's wrong, but that you said more users means more edge cases.
What should our listeners watch for?
I mean, what breaks first when you have an order of magnitude more users or consumers?
So I think the first thing that breaks is any sort of maintenance that you have.
So the first thing that breaks is if you do not have a clear, easy way to maintain software in a faster, more efficient way than the creation of that software, you're in trouble.
So what I mean by that, because people often go, well, I have a really efficient way.
I know how to run this script and it creates tickets on everyone's backlogs to do the upgrade.
I'm done.
And I'm like, cool, but now you have not created a high leverage change agent.
Your tooling, your platform, your whatever can only scale with the number of consumers because all of them have to be involved in all changes to the platform.
And that is not efficient.
So that's the first thing that I think breaks is any sort of management, any sort of upgrade, any sort of update, anything in that way.
I think the second thing that breaks is any sort of...
uncertainty or confusion about a contract.
So this is where, you know, more users make more edge cases.
There's the law where, you know, if it's possible, it will be done by someone.
So having a think about how to start with the minimum most API and contract that you can because you want to expand as and when needed, but thinking about how much...
Yagni or you ain't going to need it is going to have an impact on your platform if all of a sudden people go and find this edge thing that you thought might be useful for someone one day and now is being used at scale.
Is your coaching then, because I mean there was a statistic, you know, again 98% of all statistics are made up on the spot, but there was some statistic that, you know, some huge percentage of features in Microsoft Word were never used.
Or we're used by three people or kind of thing.
So do you account for the edge case?
Do you educate for it?
Do you take each one as it comes?
You know, because I don't think you want to add systematic knowledge for every edge case.
I think this is when you talk to another one of our former ex-colleagues that I respect, Kat Morris, and just be like, product.
How do I do product?
Because so I think the thing that I care deeply about is that.
platforms are products and that platforms should, and that their domain space is the things that are unique to the business, but common to the teams.
So something that you can't buy off the shelf, because if you could, you should.
It's non-differentiating.
But once you start building it or customizing or dealing with it, By doing so, you've created a high leverage activity.
And so not just one or two teams is using it, but many teams.
Because if only one or two teams need something, that's the perfect domain for DevOps.
And that's going to be true in every organization.
Every organization is going to have some sort of an innovation arm, some sort of a really old legacy item, some sort of something that is doing things very different from everyone else.
And that's okay.
Platforms need to focus on the majority case, get those running fast, and then figure out.
And then make sure that the things that are not majority case are correctly not majority case.
There's a reason for them to be not majority.
So yeah, so if that's a domain for your platform, then what you have to be doing is curating and identifying what is that thing that is unique to your organization, but common to your teams that you can make high leverage.
And so, yeah.
But different organizations have different personalities and cultures.
And so they will operate differently.
But as long as they think within that rule set, I think they can be quite effective product managers inside of them.
Yeah, I love that framing.
Everything is a product.
So I always close with one question.
But with you, I'm going to close with two.
The first one, and I'll tell you what they both are so you can chomp on them a little bit.
The first one, only because this is such a complex topic and people have 40 different definitions for platform, et cetera, is what have I not asked you that I should have, that the listeners should know?
And then the other one, and you can take them in order, is these podcasts published towards the end of a week.
Monday morning, what should the listeners do?
Oh, that the...
You're putting me on the spot.
I haven't job interviewed in a very long time.
I feel like I'm out of practice and I'm like, I don't have any questions.
I'm good.
No, I let's.
So Monday morning, I think I actually can answer that one a lot quicker because I just had a conversation with an awesome company who's working on this.
And I literally answered that for them because they asked that question.
And I feel really good about it is that it's it boils down to the you can't change what you can't measure side of things.
And.
Getting an idea of that business impact of supporting the builders in your organization.
So if people are trying to build value in your organization through software, what is slowing them down?
How long does it take for them to get the tools they depend on to do that building?
And as an organization, how much of your organization is towards the BAU lights on versus towards the innovation?
So how long and how much challenge is it for you to measure?
an upgrade or an update to the resources inside your organization when a security patch comes in.
If you can measure those two sides of the coin, those are the business metrics that are associated with a platform.
How do people consume it?
How do people maintain it?
And once you get a measurement on that, you can then determine if you are in a position that needs work or you're happy and content with those numbers.
So Monday morning, go figure out.
A few key use cases, how long does it take for people to get them and how long does it take for you to maintain them?
As for something that you haven't asked me, I guess one of the things that people often like to talk to me about is the consumer interfaces.
So is it, should I be doing a portal?
Should I be doing MCP everything?
Should I be doing CLI everything?
And I will point towards a talk I gave with the fabulous Whitney Lee back in Paris, KubeCon.
And now it's, you know, it's a couple of years old, but some of these ideas are a bit evergreen.
And it goes into the fact that interfaces are a human's connection to software or an agent's connection to software, but a consumer's connection to it.
And at different points in time and different points in experience and different points in...
need, they will need different things.
So there is no one interface.
And that if you have an API that can serve the right details and access, then you can have any interface you want.
So I guess the question that I get asked a lot, and maybe we haven't touched on, is what is the right way to consume a platform?
And my answer is there isn't a right way.
It is...
The platform should offer an API, and the reality is you're going to need to automate that API.
So you're probably going to need CLI tools and just API calls, raw API calls.
It's also probably going to need to get explored.
You're probably going to need a GUI of some sort to make exploration easier.
It's also probably going to need to be used by agents.
So MCP is probably going to be a high-value interface.
Those things, I can't tell you one interface.
And all I can tell you is just like you shouldn't codify business logic inside your Android app because you're going to have to duplicate it for your iOS app.
And the same thing goes.
Don't put your business logic of your platform into any one of those interfaces.
Build your APIs, invest in those, and then you'll get to have the interfaces you need.
Perfect.
So thank you very much for your time.
I always appreciate it.
Anything else you'd like to say?
No, just thank you for your time.
This has been a fabulous chat.
All right.
Have a good night.
Have a good night.