Gregor Hohpe

Most of you guys work in large-scale IT and know pretty well that large-scale IT can be a bit of a drag, actually, to be honest. Sometimes it can be a little bit depressing, right? A lot of stuff to deal with.

So it's only natural that we always want to look forward to something that's on the horizon that will make our lives a little bit better and ease the pain a little bit, right? So depending on your favorite sci-fi movie franchise, we are looking for a Neo or what's called Lisan al-Gaib now in Dune, right? Like something that will come and make our lives better.

Now, right now there's two candidates for that. There's obviously gen AI, but I think the jury is a little bit out how much it's going to make our lives better or worse. And the other big candidate is platforms.

Platforms hold a lot of promise. I call it the panacea du jour, right? They're going to make developers more productive, reduce the cognitive load, assure compliance, hide all the complexity. It's going to do all these amazing things.

So what I want to look at today is a little bit, okay, how much of that is actually true? And what would it take to build such a platform that at least comes close to that promise?

So my name is Gregor. I've been building platforms, or things that I thought would be platforms, since about 2015 in very large financial institutions. Then I drove the internal developer strategy for the government of Singapore. And then I spent four and a half years at Amazon building base platforms, building cloud platforms, until actually just this week. So, a lot of time to think about what makes a platform, and I found out it's actually not so easy.

But first we should think about, okay, why are platforms so important? And the short answer is, well, the stuff we are building these days is nothing short of amazing, but it's also amazingly complex, right? We're building houses or cars of different technologies, and the colleagues from earlier, like Justin and the other guys, showed an amazing list of all the things we expect developers to be doing, right?

And then Simon had a great chart where the developer is sort of in the crosshair of just about everything, right? And to just underline this a little bit, it's like, hey, you want to build a Hello World application these days? If you're really lucky, you get away with these things. I call this the octopus architecture because it has at least eight dependencies into major open source projects, right?

So this stuff is not easy. It's amazing what it can do, but it's also amazingly complex.

And to make it worse, what we have done, we realized that our traditional software development life cycle, where we sort of do things in one long run with different teams, that it has handoffs and it has friction and all the other things that we don't like. It doesn't have the feedback cycles we want.

So we had a clever idea: what if we compress this all, shift left, right? And we put this all in the beginning in one team. Then we have feedback. We don't have all these handovers. We don't have this long waterfall kind of cycle. Sounds really, really good unless you're actually in this team, right?

Because now it means you are doing everything. And probably, yeah, you need to be a business analyst. You do operations. You build it. You run it, right? You basically deal with everything and your head explodes.

So what we have done, in an interesting way, we push the technology not to the limit of the technology, but we have this bad habit of pushing the technology to our own limitations. Like, we push it as far until we can no longer deal with it. And I would say with modern development approaches, we are pretty near the limit, right?

And that's when I talk with customers, people always say, "Oh, all this stuff is awesome, but I don't have enough developers who are skilled in this, who are skilled in that." And that is exactly because we push things to our own human limit.

Now, this is not the first time that more complexity comes, right? We invent new stuff all the time. And there's sort of one fundamental model. I've worked in large-scale IT. Every IT strategy has a pyramid in it. I always tell people, "Careful, we stopped building pyramids 5,000 years ago." So it's a little suspicious that they're all over our modern IT architectures, right?

But pyramids, it's funny, the economics of building pyramids are very poor, actually, right? That's why we stopped building them. If you don't have very cheap labor, you're not going to build a pyramid, funnily enough.

We think the economics of a pyramid are actually very good, right? Because you need to build the base layer only once, and then sort of all the stuff on top becomes very, very easy.

There's one important, little bit suspicious assumption in here: that the stuff that's at the bottom is common, right? And it's not so differentiating. Everybody needs a database. Everybody needs storage. Everybody needs a VM. Okay, fair enough, right? And on top is the stuff that differentiates you.

The strongest assumption is that the stuff on top is somehow much simpler than the stuff on the bottom, right? Which may or may not be true. Most domains I know, in most business environments that we operate in, it is not actually that simple.

So with that, we come to the idea: all right, complexity everywhere. The pyramid always looks good on paper, but maybe not in reality. How can platforms actually help us?

And usually the story starts pretty gung-ho. You get statements like this. I know Dilbert has fallen a little bit out of favor, but normally we would call this buzzword bingo, right? We reduce cognitive load, speed up development, have compliance, right? All this kind of blah, blah, blah, until the reality sets in.

So the test I like to apply is, we find this holy grail, this magical thing that can do all these things. I always ask, well, why didn't we find that five or 10 years ago, if this is so easy to do? Were we just dumber back then and suddenly we're enlightened and now we can do this? Or is it due to some pretty delicate nuances and mechanics? And that is much more likely. So we should think about and understand what makes these platforms work.

The first and most important thing is platforms are not the pyramid model. They don't follow the assumption that you just have to put the cherry on the cake if you did your homework correctly. The assumption of platforms is that, yes, it can hide the complexity underneath, but on top it wants to open up diversity. You're supposed to innovate on the platform. And it's assumed, yes, it hides a lot of complexity, but we are not just putting the cherry on the cake.

And that is the major flaw with the pyramid. The pyramid only works if you anticipated all use cases, right? I always say in the end, you get one method, it's called `doTheRightThing`, and it has a Boolean parameter. And if you're clever enough to set that to true, all your problems are solved, right?

But how do you build a platform like this? It's a fallacy, right? You would have to anticipate all use cases. And let's say you were clever enough to do that. The whole premise of innovation is that somebody has a use case that you did not anticipate, right? That's what's called innovation. So if you had built a pyramid, you would've killed innovation.

So if you want innovation, you need to realize that this is a double pyramid. People will do more things on top of the platform. And that is good this way because that's how your business is successful and that's how innovation functions.

So the first test I give platform teams is, has somebody built something that surprised you, something that you did not anticipate? That is a very good test for having built a platform.

Now, we have software people who are very clever to say, "Ooh, but if I know I'm going to be surprised, then I'm actually not surprised that they surprised me." Like, don't be that smart, right? You know what I mean, right? Something that you didn't intend to anticipate that they actually do. That is a good thing for a platform because that means people can innovate in ways on the platform that you did not anticipate. And that's what you actually want.

Now, another fallacy that we have as software people is we always believe we invented everything, right? Most of the time that is not quite true. And in platforms, this is also not quite true. We can learn a lot from automotive platforms, right? Folks like Volkswagen and BMW, Toyota, starting in the '70s, they started following a very strong platform model.

And the base idea was simple, but it leads to some very interesting insights. The base idea is, when you go to the dealer, right, you look at the nice shape of the car and the doors and the interior and the steering wheel and the gauges, all kinds of things. Yes, you want it to be safe and fuel efficient, but you don't take all that heavy engineering apart, right?

And cars have become more complex also, like anti-lock brakes, fuel management systems, emissions controls, right? All that kind of stuff costs a lot of money to build. So why not build the base once and then put many different models on top?

For Volkswagen, that was extremely successful, right? That's how we have a Golf and a Passat and an Audi A3 and an Audi A4 and a hatchback and a convertible, right? They have a gazillion models that are built on the same platform, to the point where on one of the platforms you can have an A4 and the Bentley on the same base platform, and the price point is probably like almost 10x, well, like 6 or 7x off, right?

And it sits on the base platform idea to have common things and differentiated things. Not that new. What's important to realize is that this approach led to more innovation in both layers.

So the idea wasn't that, "Oh, I know exactly what the base looks like and I do this once and never touch it again." No, no. The idea was, I have better economies of scale at the bottom. So if I want to make direct-shift gearboxes or something that has cost a lot of money to develop, I can now amortize that over more different models. So I have better economies of scale for the bottom half, but I have economies of speed, I have innovation on the top, because I can make more different models.

So the exercise, again, is not the pyramid, right? The idea is that both sides benefit and give you more innovation. And this is another one of these key properties where platforms shine. It has economies of scale underneath, but economies of speed on top.

And the cloud is the greatest example, right? Investing in cloud infrastructure, like data centers, undersea cables, is incredibly expensive. But as a user you don't need to sign up for the economies of scale, right? The cloud provider does that for you. The server still costs you 20 cents an hour. So you live in economies of speed. You pay per time. And if you use 10 servers, it costs 10 times more than using one server, right? You're not based on scale economy as a user, but the cloud provider is. And making that translation is part of the magic of how these platforms work. And the automotive industry is a great example of that.

Now, interestingly, the automotive industry also has shown the limitations of this. So there's a term called badge engineering. The idea was, well, if this works so well, can I just make the chassis bigger and bigger and put more in the common element? Economies of scale, right? The more I put in, the better off I am. And then I just stick a different badge on the trunk.

That was a miserable failure. It actually has a name. It's called the Cadillac Cimarron Effect. Nobody remembers the car because it was horrible, except for the effect. And basically what they did, they took a Chevy Cavalier, put all the options in it, right, easy to do, and then said, "This is a Cadillac." Now nobody wanted to pay a Cadillac price for a Chevy Cavalier.

So what was the failure here? They shrunk the platform back into the pyramid, right? They made the part on top of the platform so small that this thing looked again like a pyramid. They didn't take advantage of the innovation on top.

So what we learned: both halves are important, right? You want the diversity. You want the innovation on top. It's not the cherry on the cake. It's not the tip of the pyramid. And luckily the automotive manufacturers already tried for us and showed us how this does not actually work.

One more thing to get our head around platforms: they can do amazing things, but platforms enable. So they create value indirectly. Like the chassis, the half car, nobody buys, right? That direct-shift gearbox, nobody buys, right? It's an enabler to make more models that in the end generate more revenue. So it's an indirect revenue generator.

So it doesn't do things for you. It makes it easier for your other teams to do things. And when we talk about platform teams and platform team economics, that's very important to understand, right? You make other people faster. So by signing them up on your platform, that's how you generate benefit. Your platform itself is not something that you are selling that is generating the revenue.

Now, I made a little bit of fun that now we consider platforms like this big panacea that's going to solve all the problems. And not all of that is true, but some of it is.

Because when we look at progress, the way we progress is by being able to do things that we didn't used to be able to do. And Eliyahu Goldratt, right, the Goldratt theory of constraints, used to be a very clever guy. He said that is actually how technology brings benefit. It diminishes a limitation. Something that was limited before is now no longer limited. You can do things that you couldn't do before.

And that's where platforms do have some magical properties. Because I said in the beginning, life in IT can be a little bit depressing. The reason it is so depressing is because we have these seemingly opposing forces.

Talk to any IT leader and say, "What are you supposed to do?" They will tell you immediately, "I'm supposed to standardize, harmonize, drive complexity down, because that's what my boss tells me." And then the business comes like, "Oh, we need to be agile. Shorter cycles, more products." Boom, between a rock and a hard place, right?

Same on any project. "Oh, we want to squeeze the schedule, but we can't compromise quality." Boom, right? And the problem with this is, as long as you live in the worldview that it's one or the other, there is no happy place, right? You will always be unhappy. You can be unhappy here, you can be unhappy in the middle, you can be unhappy on the left.

So the maneuver is not finding out where on this spectrum you should be, like how much quality do I compromise? Like how many corners do I cut to move faster? That is the wrong mental model because that makes you just more unhappy.

The key exercise is to realize that you can have both, right? We call this dimensionality in the systems thinking folks, that this is not one dimension. It's not left or right, but it's two dimensions, right?

And the way to do this, we have all examples for this. Quality and speed, that's automation, right? Shift left a little bit also, right? But yeah, automated tests allow you to be faster at higher quality. Prototyping, scalability. I've worked on serverless, right? You can build stuff very quickly, and it will also scale. So they can be overcome.

People used to think that you cannot sell anything that's open. Well, we have a lot of open source IPOs, right? So we have found vehicles and mechanisms to make these two things work.

And platforms are right at the top one, right? It's the subtitle of my book, right? It's innovation through harmonization. And the reason that is interesting is, you know, A, the pain goes away, right? Because we can have both. But the reason it's interesting is because traditionally standards are considered to be at odds with innovation, right?

We think like, "Oh, if I standardize something, I take people's choice away so they can't be as innovative as they could be." And if you, like me, used to be a head of enterprise architecture who was in charge of standards, you learn that the hard way. Because pretty soon I found out that the most hated person in the whole organization is the standards guy.

It's like, "Oh, we want to use this database."

"No, standard says you can only have that database."

"Oh, but we need to have this." And we all know how that story continues, right?

So there's this association that the standards are things that make innovation not possible. But there's nice counterexamples, right?

One is the International Standards Organization. One of the older standards we have is the metric screw thread, right? The M3 screw. It makes sure that two pieces fit actually together.

And the fire hydrants, my favorite story from learning from the past, 1904 Baltimore fire, right? The city of Baltimore more or less burned down. Fire codes were not exactly what they are today. So the fire people from all the surrounding cities came to help.

What did they end up doing? Standing there watching the city burn down. Why? Because the hoses did not fit on Baltimore's fire hydrants. There was no standard.

So in this case, a standard is a big enabler for a maybe unforeseen use case, right? That somebody from another town comes and wants to help put the fire out. Since then there is in fact a Baltimore standard for fire hydrants in the U.S.

And quick side comment: they didn't standardize on a single size. Look, the hydrant has two different-size connectors, right? I always say they look like little Martians. They have two on the side and the face in the front.

So standardization doesn't mean everything has to be one, like one database. It means understanding your architecture. And in this case, the reason is because the big connector goes to the pump car and the small connectors go to the fire hoses. And making this the same size would be stupid because it's either too small or too heavy.

So you need to understand your architecture to set good standards. But once you do that right, you enable new use cases.

Well, in IT we have a classic example, right? What's been the biggest sort of innovation-driving standard that we've seen in the last decades? HTTP, right? Any browser with any server, right? Without that standard we would not be talking about platforms and clouds and all the other stuff that we have today.

So classic example of this maneuver, right? How does harmonization open up new options? I call this options trading. You give up some options, right? You reduce some diversity. You lock some things down, but not because you're a bad person, right, like the head of enterprise architecture, but because in return you get more other options.

Simple example, everybody knows, right? You want to have different teams. They prefer to have different programming languages. Some have genuine need to use different programming languages because runtime performance, memory footprint, cold starts on the serverless, whatever it might be, right?

So you just realize, okay, we need this diversity. How do we get this done? We're architects, right? For us the answer's relatively straightforward. We put a common integration layer: HTTPS, OAuth, JSON, right? Whatever it might be.

So as long as people follow the standard, as long as they're willing to give up the options up there, in return you get options, you get diversity.

So on the scale of how much panacea are platforms really, this one they can do. They can drive innovation. They can drive diversity, not despite standardization but because of standardization. That is the key mechanism that is at place here, right?

In the end, cloud platforms are good examples. I come later on. Operating systems are great examples, right? How many operating systems do we use in the world? Probably like two or three in reality, or like a small handful. What do people build on top? Whatever they can imagine, right?

I always say, when operating systems were designed, the things that we build today on top of these operating systems didn't even exist. Like most of the AI stuff we're doing and most of the cloud stuff we're doing, right? When Unix came about, and Windows probably, right, that did not even exist.

So that's a sign of a great platform: highly standardized, but on top, the sky is the limit, basically. So that contradiction we are taking out of the equation, and that is really a big part of the magic of platforms.

Never short of a clever slogan. Yeah. One way, I need to translate this for my North American folks, A4 is the paper size that everybody else on the planet uses. So think like Letter, Letter for other people.

It's 210 by 297 millimeters in size. It's a very strict standard. But nobody has ever come to me and said, "You know, I can't do anything because the paper is 210 millimeters." So the next time your developers come and complain about your standards, be free to use this kind of example.

And quick side note, this standard has some magical properties because A3 is exactly double the size of A4, and then double of that, double of that, A0 is exactly one square meter because it's a square root of two of the sides.

So what you can do is A4 is one-sixteenth of a square meter. So if you use 80-gram paper and you're trying to figure out how much can I put in a letter, it's very easy: 80 gram divided by 16. So the sheet of paper weighs five gram.

Now try to do that without the standard, right? Somebody had some good ideas, and that's why the thing has so funny sizes, because there's a reason behind it. But it doesn't stifle creativity. It actually makes it easier because the envelopes fit and the mailboxes fit and everything else fits.

Diving in a little bit, right? So I'm zooming in here sort of through the layers. The challenge is a little bit that we've been building common layers for a long time, right?

So this picture on the left, where, hey, there's the applications and somehow these applications run on this infrastructure, and the infrastructure is common and shared and less differentiating, and the thing on top is more differentiating. That idea has been around for a long time, and it's served us kind of okay. It served us okay until the world became fast moving and technology became more complex.

So the problem we are having is, when you draw a platform, it looks the same. So people say like, "Oh, what's the big deal?" And I do see this mistake made where often the platform team originates out of the infrastructure operation teams. And that comes out of this logic, but it could not be possibly more different.

Like, a platform is 180 degrees the opposite of a common services and infrastructure operation team. It is exactly the opposite. The picture just doesn't allow you to see it because this model is not suitable. This is a static model. It's an organizational model. It doesn't show how people work.

So the model I like to do is, we talk a lot at this event about feedback cycles, right? It's like, how does software actually get built? When it gets built, deployed, it runs. Maybe we either have technical feedback, it doesn't work or doesn't scale, or we get usage feedback, we get better ideas, right?

This is sort of our outer loop of software development. That's the thing we want to get to spin. And now you see, oh, the left side has these classic throwing over the wall and, "Oh, I don't know why the application doesn't work, so let me do a quick reboot and log a defect for the app team." That is not great.

So I always tell the platform teams, you are really the bearing on this thing. You are not in the cycle. You are making the machine that spins, and then you let it spin. You're not in the cycle.

When you get a ticket, that is an anti-pattern. I was told we don't like anti-patterns, but I don't care, right? That is an anti-pattern, right? When you get a ticket to do something as a platform team, bad news, because that is left model. That is not right model.

I'm painting a little bit black and white, right, but to make the case. You should not be in the loop. You should be making that the loop runs faster. You're grease on the axle, right?

And in the book, okay, I'm not going to go through all this, but if you don't believe that it's really 180 degrees the opposite, here's like 13, no, 12 dimensions of things where really it is exactly the opposite.

So taking your existing sort of infra ops and saying, "Hey, now we call this thing platform," bad idea. I call this, "We renamed all our teams and nothing has changed shockingly," right? So that is another trap we like to fall into.

So you're building this platform. You realize, okay, it can do some magical things. It can boost innovation through harmonization, right? It's not what infrastructures used to be.

So what is this level at which this platform plays? What's in this platform and what's not in this platform, right? We don't want to recreate a pyramid, but also we don't want the inverse pyramid where we have no commonality.

So the key thing there is that you want to abstract away complexity, right? Because that's how developers become more productive and compliant. But you want to be careful that you don't make this an illusion.

And the biggest fantasy I see people do, they look at the cloud services, right, from all the cloud providers, and they say, "Oh, they're great, but they're a little complicated. They have too many settings. Like DynamoDB has this many settings. Wow, developers, a bit overwhelmed. So let me set some defaults." Sounds plausible enough. Same defaults.

The problem is, if you take things away, if you have a thousand-piece puzzle and people seem a little overwhelmed, taking pieces away does not make their life easier. It actually makes their life harder. So just removing pieces alone doesn't reduce the cognitive load and is not a form of abstraction. It's an attempted simplification, but it's not an abstraction, right?

And try this with puzzle pieces. People will hate you, right? If they don't hate you for the standards already, right?

So again, the car gives us a great example. As engineers, we are very poor at finding good abstractions because we build all the pieces. We are very proud of all the pieces, right? So we want to name things after our pieces.

So I always say, if the engineers had named the car, right, it would be called the piston-crankshaft-gear-wheel assembly because that's all the fantastic stuff that's in there. Builder, singleton, right? So good abstractions, bad abstractions.

Cars actually have reasonably good abstractions, but they still leak. Our British colleagues have told us that this pedal is called the accelerator. But somewhere on the way over the pond that became the gas pedal. Gas pedal is not a good abstraction because what does the electric car have? Hopefully there's no gas in your batteries anywhere, right?

So very bad. The abstraction doesn't hold. Accelerator holds. So wording and nuances make a big difference whether it's an abstraction or not. So next time you go in the car, you depress the accelerator, please.

Coming back to operating systems. Operating systems are actually extremely successful platforms. They're highly standardized but give us huge amount of innovation on top. But they didn't do that by simplifying the API for block storage. They didn't default the drive letter on your block storage, right?

They give us things like file systems, hierarchical file systems. They give us streams and sockets, right? They give us a different model and a different vocabulary. It's not an easier way to read the disk sectors. It is streams and files and folders.

And that is a good hint on whether you have an abstraction or not. If you use a different vocabulary and people don't have to use the vocabulary underneath, like gas power, then the chances are you are doing better on the abstraction. Like, if you have the base vocabulary leaking through, then people need to know what's underneath. And by definition you didn't really abstract anything away.

So that DynamoDB with some defaults, right, probably not doing so well in this case.

Okay, quick shudder. All right, gen AI. So we're not allowed to have a talk without gen AI.

So one thought people are having is, so let's say I have something that's a little bit too complex, right? I have all these APIs, right? Will gen AI just solve their problem because it generates all the code for the developers?

Yes, it will do. But what happens after it generates this code? Well, somebody needs to look at it. Somebody needs to maintain it. Somebody needs to debug it.

So yes, if your stuff underneath is a little bit smelly, the poop fairy will not come, and with gen AI, turn that into a fantastic developer experience. Cloud providers, listen up, right? This does not work.

I want to give you some more maybe fun and uplifting things, some metaphors that can help you think about how your platform is doing.

One is fruit salad versus fruit basket. Basically, how tightly integrated is your platform? Is it a collection of existing pieces? That's a fruit basket. Easy to put together, but it's not really a new product, right? You buy this fruit basket, you still have oranges and lemons, and if you have a watermelon, it'll be really heavy, right?

Versus a fruit salad is a new product. It opens up new use cases. You can take it to a picnic, including the watermelon, right? It does things for you. It has cohesion, right, what we like.

So I always encourage people, when you make a platform, a lot of people start with fruit basket. Here's some Jira, some CI/CD, some whatever, right? But ultimately you want to go more fruit salad, pre-made, tailor-made for the actual use.

The basket is built bottom up, right? We have the fruit, we put it in a basket. The salad is built top down. What kind of flavor do we want, right? What ingredients do we want for the salad? That makes a big difference.

The other metaphor I like to use is, so you're building a platform in-house, but the cloud providers are not sleeping. They're also building new things. But sometimes they also deprecate things, right? So the tide goes both ways, but mostly they're building new things. And they might build what you have built in your platform, like a CI/CD pipeline.

Right now, almost every cloud provider and GitHub, everybody has a CI/CD platform. Five, six, seven years ago, that was maybe something you would've built in your platform yourself. So you have a choice. I call this underwater. Your platform is now underwater because it does something that you could have from the cloud.

So you need to decide, are you staying where you are? That's okay. Nobody drowns. We have a submarine, right? So underwater, right? Or are you going to float on top? Which means shedding what you have built and replacing it with the cloud because better economics, and you build the next thing on top. That's the floating platform.

Like anything that goes underwater, you basically shed and you build more things on top. What I find is everybody wants to float because it's cooler to float. But then they realize, "Oh, we have all this sunk cost," and then they go to the submarine, right? So that's where the models help you get better decision discipline.

Last few pieces of advice. So when you're building an in-house platform, think about things that the cloud provider can fundamentally not build. And I give you some examples.

So obviously cloud providers have a lot of different databases, but here's one database that they cannot build for you: a database with customer information, or a database with PII. They give you all the settings and the bells and whistles to do that. But they don't know your industry, right? They don't know your country, your legislation, your internal processes, right? That is a service only you can do.

So having a database where you say, "Oh, it doesn't contain PII," and a database that does contain PII, or whatever your classifications are, that is a service. As simple as it sounds, that is a service that the cloud provider cannot build for you. That is something only you can build. And that's what makes an exciting platform.

Now, there's one requirement for that, and that is you need to understand this business technical domain. Like, what does it mean? What is your classification for data? Is this about PII? Is this about customer data? How does it vary?

You need to understand your own domain because that's what's going to define the platform. You're not looking to make a better or easier DynamoDB, right? The cloud providers have done that. You want to layer something that represents your business and expresses the way of working. So if you don't know that, don't build a platform, right? You need to understand your domain.

Last one is a little bit message to the cloud providers: platform teams are wholesale customers for the cloud providers, right? You build things en masse and basically resell them inside your organization.

So you will find that most cloud APIs are made for retail. They're like, "Oh, I want one queue," or "I want one Kubernetes cluster." What if you're a platform team and you have 200 Kubernetes clusters? There isn't so much support from the cloud provider.

So this is something you will need to deal with, and I encourage you to use this vocabulary. Say, "Dear cloud provider, I'm a wholesale customer, so allow me to manage a large collection of these services because I'm not buying one. I'm buying a hundred of these."

And very last advice I want to leave you with. Don't be this platform team that promised the developers they're going to have this golden path and this superhighway. Yeah, they're going to be some guardrails, but really, it's about going really fast. But what you deliver to them is a mud path with giant guardrails so they don't go left or right. They will not like you for that.

So don't be that platform team. I hope that was inspiring. I left some cards on the tables if you like this kind of stuff, the kind of books. In order to straighten out my brain, I tend to write things down. So you're welcome to get those or find me at the event. I'm here until tomorrow afternoon.

Thank you so much.