Minimum Viable Platform: A Framework for Platform Engineering Success – The Platform Engineering Show EP4

Hi everyone. I'm Alan Shimo and you're watching the Platform Engineering Show. Let me introduce you to my co-host, where is Luca today, but Luca Gallente.

Luca, how are you? I'm good. And still in Sri Lanka.

So have a Move still in Sri Lanka, but a different background. Different background. Yeah.

It's a hotel room. I was hoping there was gonna be a table instead. I'm like in, in a, like closet holding the computer.

Okay. You know, it's, it doesn't, well, it's blurred, so you can't see, but, alright. Yeah, we won't make, we won't make you stand too long.

Hopefully. But where are you heading from? Shoot, we'll do a quickly, a little travel update.

A Little travel section. Yeah. We should have our own like travel segment every time.

Right. And then follow Luca. No, so Maldives Maldives for the next three days, and then Japan.

So the next, next time I think we're gonna speak is gonna be from Japan. Very cool. Yeah.

You, I would like to, I have, that's the place I haven't been to either is Japan. I was thinking about going for the cube con there in June. I just don't know.

I've got a lot of travel in May and June. I've got the RSA conference and then I'm doing a trip to Italy myself and we'll see. Anyway, let's talk platform engineering though, is what?

Yep. It, it's been, you know, we are hearing more and more and more about platform engineering, but what I, what I'm encouraged about is you used to just hear platform engineering, right? It was like this monolith, if you will.

It was, it like all encompassing. But now as we're starting, it's been maturing more, it's more widely accepted in the in market and people are understanding it. We're looking at the different aspects of platform engineering.

'cause it's not a monolith like anything else. When you get up close, you find out there's different pieces of it. Today we want to talk about MVP, not most valuable player, but, and not minimum viable product, but minimum viable platform.

Luca, educate us, what do we mean by that? Yeah. And, and I think your, your intro was, was spot on, right?

Because I think, um, the minimum viable pop, the minimum viable platform framework is a great example of, I think broadly the platform engineering space really maturing, especially in the last 18 to 24 months. Um, where, you know, we've spoken before about reference architectures and how those have been like a big game changers for the community and the space broadly in terms of really helping people visualize, okay, what does an enterprise grade internal developer platform actually looks like? And, but the issue with that was that then people were, had this kind of like target architecture that they wanted to build and it's like, okay, let's go build it.

And they wanted to build it all at once. Um, and that's where a lot of teams got stuck. In fact, I would say the majority of platform engineer initiatives that I've seen dying, um, was mostly because of a loss of momentum, right?

At the end of the day, as we said, right? Like platform engineering is very complex org transformation that touches all these different stakeholder groups. So you need to convince, you know, the app devs and the security teams and the architects and all these people, and you know, you go person A, B, C, D, by the time you got to person Z, person a forgot about you because it's been six months and you know, you, and that's how you lose momentum.

And so the medium viable platform framework was kind of developed, uh, from the community to, to help with that and to make sure that you follow this minimum viable product, you know, approach. Right? And this is also, I think, an interesting thing that, that we discussed previously, right?

This like idea of platform as a product, as one of the foundation concept, uh, foundational concepts of the, of the platform engineering space. And again, the moment you look at your platform as a product, as an internal product that you're developing, you automatically unlock all these, you know, product management best practices that we've all learned in the last couple of decades. And one of those is MVP or mini level product, which apply to the platform is just the MV mini level, TMV mine level puffer.

And the idea there is to look at this reference architectures, right? And instead of, um, trying to build everything at once, you really like focus on a subset of, of, um, of, of that reference architectures. And the idea is to, um, really iterate quickly on it and get the, and keep getting in, you know, more and more buy-in from the stakeholders.

So you don't have to focus on all the stakeholders at once. You don't have to focus on all the different sides of your infrastructure, uh, on all the different aspects of your applications. You just, you know, strategically select, uh, different parts of that and then show value there first and then iterate from there.

Excellent. Well, you know, the, the last thing here from, I remember from DevOps as well, when, when DevOps first came on, it was very rare that you'd have sort of an enterprise wide DevOps rollout. Mm-hmm.

I used to say DevOps. DevOps got done in bubbles. And, and if you've ever seen like soap bubbles or bubbles in the bathroom when you're a kid, maybe not when you're a kid, if you like bubble baths, but you know, you get a lot of little bubbles that when those bubbles come, you know, touch on each other, they become a little bigger.

And then, and then eventually you get those big bubbles, right. That you could catch. It's the same thing when you look at how DevOps spreads in an enterprise.

Generally it starts as little bubbles. There's a little project here, little project there, but it's the same thing with minimal minimum viable platform. An important part of it is momentum, right?

No one wants to go with a loser, everybody wants to be with the winner. So if you could build some small wins, you get some wins that people could point to and say, Hey, look, it works. Hey, look, it, it helped us do that.

It made that go faster. It made this more secure. People want to do, give me some of that.

I want some of that good stuff, right? More I want that more. Yeah.

Right. Or more of it. And, and that, that's how you get buy-in across an enterprise.

That's how you get those bubbles. Yeah. Right.

Exactly. Creating bigger bubbles. Yeah.

And, and I think it's very important also to, you know, figure out what, you know, what is it that people want, right? Um, because like, um, again, if you're trying to make everybody happy, that's really hard, right? So you should really just focus, okay, what are the one or two stakeholder groups that are really crucial for this initial phase to prove value?

And then understand, okay, what did, what do they want? Um, because you know, if I go to developers and talk about like, oh, we're gonna cut time to market with this MVP, they don't care. Um, it's not something that they necessarily think about, right?

But, you know, executives care about that. Um, application developers might care about reducing waiting times, right? And so you just need to understand, okay, what are those two initial like ones and desires that I'm gonna target with this MVP?

Um, and then to your point, create those first bubbles, right? And then go back to them and be like, look at these bubbles. They're great, they're shiny, right?

And then they're like, all right, I want more of those. And that's when you start like adding more and more and more. Um, and that is why, I mean, so just taking a step back, right?

Like the MVP framework is a framework because it has like very specific sort of, um, uh, different phases of it, right? Particularly, there's like four phases. There's like a discovery phase.

And this is why I think, um, this discovery phase is so important. And it is exactly to do what we just said, right? To like really map out what are the desires of people, like what are the challenges that I wanna solve?

And again, you know, I think like a lot of people, like a lot of platform teams get stuck in, um, you know, trying to have this like very quantitative, measurable type of things that they want to improve on. I think especially in the MVP phase, it can really be qualitative, right? We've talked about before, you know, of like, hey, it can literally be like, Hey, you know, person X is spending, you know, 20% of their time on, you know, uh, fielding ticket ops or, you know, uh, we are approximately, it approximately takes us like, you know, a couple weeks anyway, this like waiting time is just, is really long.

It sucks, right? And, and, and so like that can be the starting point. And then you just go back to the same stakeholder and, and look, look, now you don't have to wait weeks.

You can, you know, it's in instant or you just need to wait like a few minutes or a few hours, right? Like that's already like insane improvement. And then from there, you build on top of that and you professionalize it and you get, you know, more, um, you know, more secure in everything.

And so this is why that first discovery phase is really, really important. Um, then the second phase is, you know, what, so it's discovery then integration, which is really, you know, basically, you know, hooking in all the different parts, um, that of, of, of the subpart of your reference architectures that you decided to target with your, with your, um, MVP if you, you know, for people that are familiar with that. Otherwise, we can also link it somewhere in the show notes.

Um, you know, the, the reference architectures have five different planes, right? A developer control plane, which is effectively the front end of your platform, an integration delivery plane, which is the backend. Then you have a resources plane, which is, you know, all the infrastructure that your platform sits on top of.

And then you have a security plan and observability plan in most mvp successful MVPs that I've seen people mostly focused on the first three, right? You need some front end, you need some backend, and you need some resources. You should keep all those things to a minimum.

You probably don't really need, you know, security or observability in the first phase. You can ob you obviously need to design with that in mind, but, you know, a first MVP doesn't need to show, you know, ultra secure anything, right? Because it's just an MVP, it's working in dev, like there's no production workloads on it and so on.

So, um, and so that's, that's really like the integration phase is about integrating those different pieces that you've kind of like singled out. Then you start deploying your first applications, right? And, and, and, and you, and, and that's where you see, okay, everything is working.

And then number four is the sort of like demo time, right? Um, which is also very, very important because it connects back to phase one where you first went to people and like, Hey, what do you want? Then you need to now go back to them and it's like, Hey, you know, I actually did what you wanted, right?

Uh, or close to it. And that's where the loop, you know, starts the flywheel starts going the infinity. Yeah.

The magic happens. Yeah. So, you know, when I hear you describe this Luca, to me, I think one of the most important things, and you know what, it's a lesson I've learned over and over and over again in 35 years of doing back work, the finding success is important.

Yeah. And a lot of engineers, I guess it's the way their brain is wired. They define success exactly the way you said, right?

It has to be some metric, some KPI that I measure, right? And it's like I improved, you know, mean time to remediate by 38% or whatever. Yeah.

But sometimes success is, success is a feeling as much as it's a number, right? So sometimes it's a success is just, Hey, I'm getting more done, I feel like, or my, I've got a better life balance. I've got, you know, there's a lot of ways of defining success.

The important thing is that everybody agrees on what the definition of success is, right? Right. And then when you get to, to stage four and loop back, you can say, okay, this is what we said success was gonna be.

Here's, here's the reality. Right? And do they, do they match up?

Um, yeah. And, and, and this is why I think apart from engineering is so challenging for, for that kind of profile of engineer, right? Is is because mm-hmm.

Really, you know, much more of a cultural challenge than a technical challenge. And the problem is that a lot of times it gets approached as, you know, a 98% technical challenge and maybe like 2% of culture thing like sprinkled on top. And it's really almost the other way around.

Like, I've never seen platform engineer or broadly this type of org transformation, um, you know, fail because of a technical, uh, you know, choice of like this technology over desired technology. It's always because you didn't convince the right people, you didn't get developer. It Wasn't a meaning of the minds on what's success.

Yeah. And, and, and, you know, to, to define it. I think another big problem though, and I'm interested in your take on it, Luca, is the m the minimum part.

Yeah. Right? It's like a Goldilocks, sometimes it's too minimum, sometimes it, that minimum is like a maximum, right?

I think it's important to really, it's gotta be meaningful, right? It can't be trivial, it's gotta be meaningful, but it, it's not supposed to be the whole enchilada. You, you know what I mean?

It, it's minimum. How do you, how do you, you know, balance that? Yeah.

So I think, um, you know, again, if you follow the framework, the idea is that, you know, this, the, the, the MVP needs to be representative, right? And, uh, sort of like repeatable as well, like to your point of the bubbles, right? Mm-hmm.

Um, but you know, it also doesn't have to be a bunch of different things, right? It doesn't have to work for high compliance scenarios. It doesn't have to cover any advanced architecture.

It doesn't have to do any sort of like advanced research configurations, right? And the problem to your point is that, you know, platform teams and engineers have this standards of like, slip things into it, you know, because that, because it's cool because you never know, you know, and mm-hmm. And at end of the day, I think it's just like, uh, I've seen, you know, successful platform teams really going through this person almost, you know, the summer I've sword, uh, folding thing, right?

Where it's just every time you cut it off again, you know, and you just ask like 10 times, like, are you, you know, are we, do we really need this? You know, do we really need, you know, two different databases for this to be a representative? Do we really need, you know, um, all these different, you know, uh, different policies as code, not, you know, and every time, and it's amazing because even teams that I think like consider themselves like quite frugal in terms of like, you know, picking this like minimum set, um, um, you know, end up like cutting another 50% of fat basically, um, I I, by just asking it enough times.

And so I think, I think that's, that's where it's important to either have somebody external, um, as you're going through that have, you know, has experienced doing this or, um, have like a really strong product platform product manager internally that really, you know, keeps asking the same questions over and, and is not, you know, afraid of asking the same question over and over again, even if it's through like very experienced engineers. And it's like, no, but are you really sure? Right?

And then like, really pushing the, the envelope internally. Absolutely. Um, wanted to ask you about a, a another thing here.

When we talk about minimum, you know, MVP, what, what is the team behind it? You know, like we're, I think we're all familiar with the Amazon two pizza concept, right? If more than two pizzas, it's too big.

Um, Spotify has sort of the squad or whatever it was called, remember what, what's the right size team for a minimum viable platform engagement? Or is it just red, you know, really varies the Right, you mean team? The, the the parking team?

Yeah. Yeah. So I, you know, it definitely varies.

I think on the, depending on the scope. I think for me what's important is not necessarily the size, but that there are different roles, uh, or at least different functions clearly represented within the team, right? So as an example, right?

Um, um, and I can, I, I, we can, we can also throw up this, this, um, sort of like, um, really nice, um, bubble, actually bubble like visualization of, of platform teams and the, the different stakeholders around it. But in general, you have, um, you know, four key functions like the head of platform, the platform product manager, and then what we call, and it's funny because they're, they're really like emerging now as like very defined roles by, uh, by Gartner, for example. Um, they are job ads.

They already, um, having this title, which are infrastructure platform engineer and developer experience, or dev X platform engineer. And the point is, you don't, you don't need, you know, four different people with those four titles. A lot of times, you know, the had platform is doing the product role or the auto or vice versa.

Um, um, and you know, in some cases you just have a platform team of like two or three people. And so like, everybody's like, kind of like covering old bases in some cases. You know, you have like, uh, apart from team, there are like a hundred people, and then it's not even that you have four different people.

You have like four different, you know, or like, you have like many different teams and product teams, and each team has like those roles represented one way or the other. So regardless of the scale, the important thing is that there is this, um, I think, um, uh, the, you know, the dysfunctions that interface themselves with the, with the different stakeholders. So, you know, the had platform is really responsible for selling this thing internally, ultimately, right?

And so, uh, getting the executive is keep selling up, down, or both. Yeah. Uh, mostly up, I would say, right?

Mm-hmm. And so really like to, to, um, but also across to like legal and compliant, like architects to an extent. Um, and then you have, and, and I do think that the, the line between the, the, the handle platform and the platform product manager is quite blurry, right?

But then you have the platform product manager that is, I think, the most important role, right? 'cause it's really about mediating all the different, um, inbound requests slash vested interests of all these different stakeholder groups, right? So you need to, you know, balance all this stuff.

Um, and it's, it's really, I think the, the most critical one and also the, the most in demand role and the hardest to find, um, I think right now in the market. Um, and then you have this like devex and, and infrastructure platform engineer. And I think the, the, the differentiation there is really important to have, again, not necessarily as a title, but at least as an area of focus for different people, um, or even for the same person.

But it needs to be like a very conscious, like, okay, I need to cover both of these things. Why? Because I think a lot of platform teams have this tendency to over optimize, over index on devex, because ultimately the, the end user of the platform is that application developer.

And so, okay, you know, that's the whole point of the platform. But if you don't connect the, your platform engineer initiative to the, um, you know, to the overall infrastructure and, and you don't sell it to your infrastructure and operations teams, it's, um, doomed, I think, or, um, very, very quickly, right? Um, and, and so that's where it's very important that you have yes, the devex platform engineer that maybe comes from that background to really build a tight feedback loop with developers and, you know, find the right level of obstruction, the right level of con context, the right interface to the platform for developers.

But then it's very, very important that somebody's building, um, together with the infrastructure operations team, the connection of the platform to the, the, the underlying, uh, infrastructure stack, right? Um, and, and, and also that is selling effectively the platform to them, to the INO teams as a way of effectively, hey, this is a vending machine layer, basically, right? For you to provide your infrastructure to the rest of the organization in a much more productive way where, you know, you don't have to fill ticket ops and getting annoyed and everything is like standardized and automated by design, yada, yada, right?

So you, whether you have, you know, different people, 200 people or or two, the important thing is that you're, you know, consciously thinking about those different, You have those roles. Yeah. It's important that those roles, you know, those are kind of indispensable roles.

Let me ask you a question, Luke, and when you say, you know, dev X or in working with developers, it's in today's world, it's not just the guy who's maybe coding, but is, is like for instance, the QA person, the test person. Mm-hmm. Right?

They have a real stake in this too. 'cause they, they've gotta test all this stuff and hopefully before they deploy it, but, um, you know, but on the platform, nevertheless, so would the, would the dev person also work with like, for instance, QA or security testing or, you know, other people along that CICD journey, if you will, who are involved in the pipeline? Yeah.

Or in the factory, right? These are all factor, you know, if you think of software as a factory Yeah. These are all the people working in the factory.

Yeah, absolutely. And I think right now, you know, we're still in the phase where I think software, most of the times, like we spoke about in the first episode is create, is, is, is produced as this, as if you were in this like, um, you know, craftman type of, of, of, of like boutique, you know, uh, thing. And, um, and, and so I do think as we're getting more industrialized as a, as an industry, then, um, you will, you will lose, uh, touch points.

Um, or, or rather, or rather the touch points. You know, we had this like really interesting conversation with, um, with Kelsey at Platform Call 24, where he was, you know, talking about this, like, you know, sellers are a good thing and all these people got mad. Um, uh, but the important thing is that you have like a platform layer in between the silos that facilitates that communication whenever it's needed.

But the point is, it's not needed all the time, right? Um, and so, and I think that's ultimately what then increases, to your point, the developer experience and frankly, everyone's experience, right? Because you don't have to, you just remove all this friction from the system, right?

You can, you can like focus on what you do best, what you wanna do, like you want to code, you don't wanna necessarily, you know, spend 30% of your time configuring stuff. Um, and, and, and so then you can do that. And then when you need, you know, educates or whatever, then you know, you have like off path options, uh, beyond whatever the, the platform normally mediates.

Yep. Let me shift gears a little if we can, Luca. Okay, so let's say we follow the four steps and everyone says, great job, Bravo.

Let's, let's, now let's take it to the next level. What comes after MVP? Um, so the way, the way we, we think about it, um, uh, whether with our products or, or in the community is, is production readiness after that, right?

Because really, uh, the MVP is not meant to be production ready, ready, um, so it's really meant to like basically get everybody, you know, uh, rallied up, you know, and it's like, yes, this is great. We can totally see the benefit. Let's, you know, let's invest more time, let, let's invest more money.

But really more than anything, let's invest more time and resources, right? Because that's the hardest thing to get in enterprises is not necessarily the, you know, extra money. It's just like, you know, you can invest an extra like, you know, 200 k or whatever, but if you don't have the, the developers we're keying to actually keep working on this, it's not gonna go anywhere as an initiative, right?

So, so that's really the main thing. And so then the, the next phase is really, okay, how do we, and, and again, it's like a very structured kind of like production readiness, uh, checklist basically of like, okay, what are all the things that you now need to make this, uh, first minimum viable platform actually ready? And again, this is, is very important because here again, we're not talking about okay, bring your entire, you know, uh, software estate or cloud native setup, you know, to production redness.

It's, it's again, just like one subset, usually one or two applications with a, a subset of their normal dependencies, but they're now, you know, production, production grade, right? Um, and that's really where you start getting the traction of like, other teams looking at, ah, okay, they're, you know, that team is actually deploying all the way to production and you know, it's taking like 30, 40% less. And then that's where you go back to your bubbles of, you know, then you grow from there.

Um, and so then from there is, you know, the third phase will basically be production readiness to, you know, sort of like full, full rollout. Cool. org, right?

You could download them. org. You free to anyone there to download and, and ask questions from and stuff like that.

Speaking of people who have questions, does the community Slack? Yes. org?

I forget, is there a Discord server now too, or is it just Slack? No, slack. Just Slack.

Yeah. This is the way to go. Yeah, while we're at it, we, we were talking earlier about, um, CubeCon and, and some of the other events coming up.

Obviously Platform Con is next June, so we're still maybe six months, five months out of that. But, uh, for CubeCon for people who want to be involved in the community, you have your, uh, you guys have an event going on, you want to just let people know about it. com.

Um, you know, we, this reference architectures we launched the first time, the, the first talk about them was a platform 1 23 last year, a platform 1 24, already 20 plus percent of all the talks had this Revs architectures as a blueprint. So I'm expecting that to grow even further. org, a repository of all the talks slash articles slash you know, new community contributions of people that wanna share their reference architectures for their platform.

And so it's starting to grow and it's becoming a really interesting library. So I recommend people checking that out as well. com.

I don't think the, um, design, I think the design is gonna be updated by the time that people listen to this, which is a new, a new branding for the, for the event, which is really cool. Um, it's something that started as a joke, uh, in, in Valencia, um, The thing Dolphin do. Yeah.

'cause we just wanted to do like a better, a better, more fun party. Um, and it's basically grown to be this like unofficial opening party for Q Con. We're expecting over 4,000 registrations, uh, for, for the London one, and we've actually taken out like a proper, proper club.

And I can't say who it is, but we have actually, one of our frontend engineers is a very, very, it's a like, literally globally famous dj, um, that is a, yeah, he's a resident in one of the best Berlin clubs, um, you know, travels every week to like, you know, Mexico, India, whatever. Just plays like big shock. Um, and he's actually gonna headline, although not with his normal, um, DJ name because he can't use that.

Okay. Um, but he, He's gonna headline the event. Um, so, you know, we've, we've been basically saying about, Hey, this is like a techno party and then, you know, every time, because you know, it's still like a party attached to, to like a working conference.

So we always like, you know, like did it, but not all the way, this way, you know, this time it's longer. We're Doing it this year, we're Going all the way. It's like a proper warehouse, proper DJs.

It's gonna be fun. Very Cool. I'm giving time.

Cut. Yeah. Excellent.

All. Hey Luca, enjoy your last few days there in Sri Lanka. Enjoy the Thank Alan.

We'll catch you in Japan. Yeah, we'll be folding Summeri exactly. Steel Steve Island.

You'll catch We steel to make steel right. com or Apple Podcast, Spotify, wherever. We hope you enjoy it.

Subscribe to it. Until next time, this is Alan Shimel and Luca Ante. We're out.