Platform Engineering & Platform as a Product with Luca Galante

Hi everyone. My name is Patrick Ewing. If you're interested in platform, engineering, how to get stuff done and do it the right way as well as a little bit of devops controversy than this episode is for you. Joining me today is Luca guy ante. He does product at Humana Tech and he's one of the organizers of platform. Con aperol is links to socials in the description below. Check him out. And with that being said, enjoy the episode. How is I don't think I ever asked you this.

But how did you get into platform Engineering in the first place? Like what was your kind of Journey and where did you find it? Yeah so we you know when we started human attack basically we came together as a group of people we're not me but other otters you know like our CTO for instance build the platform. A Google and our CEO was also coming from experience building platforms at companies like MacKenzie.

Z, and I'm blanking on the name. It's the, the LinkedIn competitor Europe, but that the never really took off, but he was building this like black still like very larger than engineering organization, and he's building platforms there as well. And basically, they just realized we just realize like, hey, you know, and you know, we can get more into that later, but there is this concept of devops, which, in reality for her.

His company's means pretty painful day to day, but for dads and for jobs and infrastructure, people, and kind of leading engineering Innovations realized it already 10 15 years ago because they had to onboard, you know, hundreds maybe thousands of Engineers every year and they immediately realized, okay? This approach of trying to expect everyone to do everything, just doesn't scale and we need to build some sort

of platform layer. In between the operations by offering team and the rest of the engineer organization to make things more scalable. And so that's what they were building and we realize, hey, you know, Spotify is in the same are being abused in this game. And and so the idea behind you - like was to sort of, you know, build a product that could provide engineering teams, the core through configuration engine to build that platform in the Enterprise.

And and so we came up with this concept, which it was, you know, the internal developer platform and I mean, I want to make clear, we didn't invent anything, right? Like people had been building paw prints for them in good part of a decade, the but there was a lack of community. You know there was a lack of just share best practices, common terminology framework just to like think about these

things and talk about them. And And that's where we basically started hosting events for platform engineers. And it was in Berlin in co-operation in Berlin and we started doing a bunch of groups all over Europe and North America. Now, we have about 20, 28 groups, I think in over 10,000 members, so that that category crowd groans arts, and then we progressively start adding more bits and pieces to the community. So, we started adding a slack channel that known as Over 8,000

members really acting. That's really the Beating Heart of the community. If you will. Yeah, then there is pot fringing to org which is kind of the home where you can see all the upcoming events as a job board that there are, you know defining pieces around. What is popular engineer do stuff like that. And then we start and then we launch platform con last year, which I think was the highlight of the community. We had, you know, 7000 sign up, six thousand attendees just from

day one and people. We'll really really enjoyed it. And so we're going to double down on that this year as well. And and I think you know the platform engineering community

is really like, I find it really interesting because like on the one hand you know provides this sort of safe space for people to connect and share best practices and were stories about you know their platform failures or successes and I think that's that's great and that's what I think most deaf Community sort of provide normally yeah. I think the interesting thing about the platforming junior communities. It also provides this layer around identity on top of it,

right? And that's why, I think it resonated really well, especially in the early days with very, senior practitioners. Because again, those are the ones that had been building platforms are ready, they just need to know what it was cold. They didn't have like, you know, shared, you know, framework to think about this things and talk about them. And so I think it was like a big relief moment of like Ah that's what I've been doing, you know,

type of thing. And and that was really and so and then we can building on top of that. You know, I'm kind of okay, who is a platform engineer? What is a platform and you do, how is that different from a devops the necessary and so on and you know, how much does it bother me, or make stuff like that? And I think that's been really interesting for people.

And now we're seeing a second wave of I think less Your practitioners as well because you know they've heard about it's like, oh this is all new thing in town, proper engineering, I hear makes good money. Let me something sounds attractive in that way. Yeah, I like the kind of the notion of identifying yourself with something and it's interesting because for me, it

was really devops. Interestingly enough, because I came from the operation side coming out of University, I started in operations, then I missed kind of the software development side of things. So then I read online.

Line and I saw terms of devops like bringing both sides of that world together and I was like yeah this is really what I would like to do and that's where I then trended towards more so the software development side and we still have operational responsibilities but I can imagine that if you've been doing this kind of things and you've been labeled into something and it's really not a good fit or you've always been kind of an outlier in your role and then all of a sudden there's

a term on there and the roles and responsibilities are even the things that you're doing something. You've always Has been doing then. Yeah, that's a really powerful thing for someone, they can fully identify themselves with that. And then build on top of that right, share kind of their experience and perspective on that and then you create the community that you've been building which is, which is really powerful at the end of the day.

Totally. Yeah. Exactly. And you can really see it right? Like the created grows but it's it's also just really that, you know, the engagement The Passion of people joining in. Being there is, you can tell hit a nerve, you know, somehow. Yeah. What would you say?

So, a platform engineer, I have a certain vision of it. But what would you say, like the roles and responsibilities are of platform Engineers, or more? So kind of that shared responsibility that you've defined. Yeah, so I think, you know, for me, so for look at like platform, engineering, broadly like I Define it as The art because it's more an art, I think, than a science of the designing. I mean, it's both but I'll become clear, why? It's not bad.

Designing, sort of, you know, and bringing together all the different Tack and tools that you have, especially, you know, in mid and large sized organizations, you know, Enterprise engineering, orbs, and bring all of them into a golden path. That basically does a number of things, it enables developers self-service and at the same time it reduces the cognitive load Ford individual contributor for do for the engineers. Yeah. And these golden paths are basically the superset of this

golden path. Is the internal developer platform or IDP in short and and and the IDP is then built by the possible range. Here, which is usually team writes, apart from engineering team, our platform team and the I think key principle is and also, I think what

differentiates platform teams and pot from Engineers from you no more traditional roles like a SRI or devops. Is this approach of platform as a product, which means you really want to treat your developers. The rest of the engineer organizations as As your internal customers and you are really shipping a product which means, you know, you are shipping features.

You have a p.m. usually and in fact, the product management channel in the platform engineering slack is probably one of the most active, you know, people always trying to figure out if you like a lot of open things because they're still, you know, there's still a lot of questions around like what are the best practices? How do you get?

Buy-in when you get executive buy-in how do you roll out you know oldest things that really like this this product questions and you know and it's a team you know in a lot of cases you have front and back in Q&A. So it's really like a product team. Okay. And this requires I think a really not just a different set of skills. But I think importantly also a mindset shift towards a, we're here to serve Serve our

customers. Who are the internal the, you know, the internal developers and you really need to, you know, think hard about how do you build that tide feedback loop between the developers and the, the platform team. So you can either eight and then you have rollout, strategies. You know, where do you start? Usually we see successful platform team starting from, you know, picking one Dev team because, you know, in an ideal scenario, you have a green field

setup. Where there's nothing platform, team decides, everything rolls it out, great. That is pretty much never decays. What we see is, you know, very complex, Brownfield Enterprise setups where you have, you know, tens of different teams and each one of them has their own preferences around. I use Jenkins, I use, you know, Jenkins, plus r go. I used Circle cycles that right and it's like, everyone has their own Spirit like delivery setup.

And so then the the goal of Of the platform team becomes to find that minimum common denominator. That's sold as many problems at the same time as possible for as many teams as possible. But then focus on usually, the more advanced teams within the org, there are the ones that are probably more comfortable. You know if the golden path is not perfect and they can go off path.

Meaning you know, they can mess around with the Hem charts or stuff like that and you know and then basically ones they nailed that Start rolling out, team by team and making sure that that minimum common denominator says, says through valuable for everybody. Yeah, it's interesting to me

that you say that the platform team is kind of a cross-functional team. So you have back in engineers and even front-end engineers in that because I thought it would just be people building that platform, right? There's no real fronting component in there. And then the challenge I would see is that you're building a product and that product is for internal Developers. So probably what you need to know out of more than anything. I'll maybe not more than anything.

I think it's a big component is developer experience, right? So what makes a developer experience really solid and really good? Like what does that even mean that you need to know as a platform team because otherwise, the product that you're building is for the wrong developers, right? Or you're solving the wrong

Solutions in that way. And I thought, then if you only have one, let's say competency within that team that's going to be harder because you're not going to have Developers that like build features and stuff like that, and ship that out to other customers or outside customers, I guess. But if you say it's a real cross-functional team, then that challenge becomes a little bit more manageable, I guess. Like how, how does a team like that structure itself?

It's cross-functional, you mentioned. Yeah, and I think it depends, you know, heavily also. So the way, the way I think about platform engineering and you know what we advocate for in the community Is a, you know, providing platform teams with a an opinionated toolbox.

Okay, basically, to build opinionated workflows was that mean that, you know, if you think about the key difference between, I guess like a predecessor of the IDP, which is a path of something like in a Roku four, people are familiar with that. Yeah. Um, you know what if past says is, hey, I have Looked at the market and I have formula or the product team behind the palace

as I've looked at the market. I found the minimum common denominator that I believe it's valuable for, you know, as many things as possible. And I have ingrained that in a framework, that is, you know, great to get started really quickly but it's really not very flexible, right? And so that work worked really well, like, right Heroku is Is really popular, but it kind of, I think, you know, slide and out at some point because people realize, it's great for you

know, Gregory Angels setups. Poor teams of a certain size we usually, as a rule of thumb, say, you know, below 30 50 Engineers like it passes, probably, grade solution. But if you go beyond that, you'll start having to be a lot more flexible in the golden pots that you need to build for your

organ from the different teams. And so having a solution like a process, becomes you Hard. And so the idea is hey, here is a tool box set of principles design principles, you know, best practices and so on to go and build your IDP and the key thing about an IDP is that the platform team will depending on,

you know, what is the context of their engineering innovations that they're working and shipping for is, you know, they'll take the right path, sir. The right level of abstraction. And I think that's really important because, you know, you'll have different types of users. So you'll have the Junior front end, maybe that doesn't care whether the application is running on GK e on E KS. What is running kubernetes at all? Yeah doesn't matter.

Like I just want to say just want to you know deploy it a simple change to their app and see and see the result and contestant and some environment that's it. But then you also have you know your senior back and maybe the really laws messing around and llamo filed and help chards and For free. So the question is, what do you do, right? And that's where he becomes really hard to take this, like, pass approach of like Boop. Like here's the solution for all your problems.

It's unlikely to work and skill at an Enterprise size.

And so instead is how can you, you know, build a product team that really has this tight feedback loop with the different other product, enjoy the different Dev teams and And and really, you know, builds his pads and all spots, option options for for for everyone to kind of use and and, you know, their feet, their few, sorry, their few kind of like key principle that we do. You talk about when we talk about platform, engineering, one is, you know, Platformers

product. The other one that I mentioned earlier is you want to focus on this like common problems but then The other, I think the other things that are really important. Are you know this this concept of being the glue is really valuable, right? Like you really Fought For Engineers need to you know make sure that they did the tie together, all these different, you know Tech and tools. In one golden path that really makes sense and that optimizes for reduction of cognitive load.

And and you know, frustration honestly, right because what you see in a lot of you know lot of I think engineering orgs today is you have a double up steam and you have the rest of the developers and as the, you know, with with this converging trends of cloud native kubernetes. I see get-ups, you know, and all of it together and it's like crazy CN CF landscape was like, huh? Is a thousand different tools

then. Now, you know, in a lot of situations if I'm a developer and I just want to, you know, deploy simple change to a Dev environment and test something or I want to spin up a preview environment to do that. You know, I've seen many Enterprise organizations where that can take you like one or two weeks just to get an environment just to get it in a database provision and so on.

And so that creates all sorts of waiting times for stration foreign developers side and the on the operation side. You're basically you become a glorified help desk.

That is just trying to put out fires and you know fighting kick it off constantly and and so the DEA deal of having this glue of building, this golden imbalance is is really to provide this layer on the one hand for developers to just self-serve, what they need to run their apps and services, you know, in independently and then operations can focus on on I think batter. More interesting problems. Let's say then provision is saying pause for a sequel for

the tenth time. Yeah. Interesting. One of the things that you

mentioned still kind of lingers in my mind in that but if you start out on a Green Field like if you start on a Brownfield, you can kind of find your common denominators because you already know what people are using. You might want to standardize some things here and there and then it makes sense to like have a platform team specifically that Taylor stores your internal. Purrs.

But when you said on a Green Field side of things, it would be better if a platform engineer already starts with that. That for me is hard because for me, it's like a chicken and an egg problem, right? You first need to figure out what your developers actually use, and what they need or because they have to figure that out when the product with the

product they're building. So if you don't have that, then how can you make a platform that already like is going to make the developer experience better if the developers don't even know what they're going to use at the end of the day, right? If you're in a really fast mode, you might choose some databases initially. And then later on figure out that other databases are more apt for the product that you're

building. But if you from the start already have a platform team, then they're going to have to provision different things or their golden path is going to be very flexible or malleable especially at the early on stage, but you still think starting with a platform team, kind of in a green field. Setting is a good step in that way. What have you seen? So I think that's a really good point.

I think, you know, from the platform team perspective that is the dream, you know, because it feels easier, but I think you bring up a really good point which is you, you then are missing a initial starting point that tells you already what the preferences of your developers are. And and so I still believe it can be more ideal if you have Those conversations those lines of communication with a different Dev teams in place, right?

But yeah, communication is everything and I think that is one of the things that I think Trends in the, you know, like hopping to the right, like going from the serve like ancients is admin that was living in a basement trying to figure out servers like and then to the devops and not depart from. Here. I think there is just like a correlation on increasing like you need better communication

skills. Yeah. And you really need to make sure that you can, you know, listen to developers but not just developers that you're able to, you know, sell up to management Executives to get full, stakeholder buy-in and, and really think about all different stakeholders. There's also one thing that I've

seen in large organization, like, examples Salesforce, Is multiple platform teams competing, okay? Right so, so then you add the extra layer of complexity where, you know, you're really in a race with the chatter and, you know, it's really which I think is healthy, it can be. Obviously there can be some like, you know, pros and cons

like in everything. But you know may the best win is is a good, you know, kind of like self-selection process and an end that You're interesting because then it you're really like not just a product but it company almost like you knew. You really need to think about your distribution and almost like your internal go to market versus the outer. But that's that, that's really just for very large. Organization was right? I can imagine.

Yeah, most companies it's it's hard to even get one often teamwork. So but I mean it's for me it's the ideal situation, right? And you might, you might think it's strange because obviously if there's multiple platform teams, why just not join them together? Weather and make one Uber platform. Like, I've heard a lot of stakeholders say that shouldn't be joined forces and do that, but at the end of the day, like

bunching up a bunch more people. If you have a really big team is going to have so much overhead in communication and sharing a mental model of what. The thing is, we're actually building or what problems were solving in that, if you separate that, then obviously there's going to be at some point. You can see some teams going faster or having better results than other teams and then even with the teams that are not going as fast, there's the Things there, right?

So if you then centralized that, then you can build the best solution in there. Except that's going to have a lot of people, a lot of resources and time and money in that way. So then it doesn't sound as efficient. But if you're looking at the end product, the end result. Yes, I think at the end of the day that will be better just by virtue of that which is

protocol. So, in large organizations, I do see value in that for me, I'm really looking into kind of a start-up phase in a more so project oriented thing because that's kind of the team setting that I am. In now with the project that we're doing and we envision multiple teams working on this product that we're building in different teams and cross-functional teams and a future platform team, but, right now, the future is not there

yet. So we have platform Engineers but they're in the kind of cross-functional teams that deliver the product at the end of the day and they're very close to whatever needs to be done, right? And if that's if they have to build software they'll build software but more. So when there's a platform component, they already start figuring things out. When it comes to In that and rolling that out and making that

easier for the future also. But I have seen that there needs to be a balance in there because if you read leverage or really focus on making it easy to roll out and making a configurable and stuff like that and then the development team decides all this is actually not like good for our use case anymore or were shifting or pivoting because of new learnings then.

Yeah that kind of feels wasted. So I do feel like there needs to be a balance in there, but the best way to figure that out, it's the half the platform Engineers than beer. Really close to the development team. That's how I would start out. You need that feedback loop and

and also you need I think frankly. But you know, platform team that doesn't fall in love with their own product, right? Where it's like, no I built. This thing is the perfect thing. Shut up, use that. It's like it. And you keep either rating because, as you said like, the needs will really change, right? You have in some cases, you know, maybe like the Earth. Beginnings, usually, and this is where I feel like I'm platform

is almost not needed, right? If you're like 20, engineers and you're old, you know, see our Engineers, your old comfortable, handing, your Hound charts, and your icy modules, and so on so forth, then I mean you don't really need a pot from like that would be an overhead at that point over Kaiba. Like as you start scaling that becomes less and less true. And then, you know, you have this like more Junior, people, people that I've never used kubernetes before people that I

know. Ever used to reform before and then you need to like, make that me on common denominator like broader and broader and then you get to a point where, like, all right now we really need this like, you know, high level golden pots where, you know, for, for the senior back end. That's been here for three years.

It's still like they can still mess around with with the files but maybe we have some like bother plate templates that you know, we control as a platform team and then for the more Junior folks, you have just like it affect, you like it, click off cui, you know, To to do things that obviously, like is more restricted, feels more like a past, but that's fine for that use case, right? And so you need to keep it

really flexible. Yeah, it's interesting to me, is what have you or have you seen in the community?

People going more towards managed Solutions as well, or managed Cloud Solutions. Like I get the Heroku example and kind of a possible solution. A lot of cloud offerings are now more so managed in the fact that you give it a configuration and it scales up things automatically where people maybe even choose less S4 kubernetes or even a more so managed version then the operational overhead because it's managed

becomes lesser, right? So then I think also the strain on the platform team is becomes lesser because of that but then their role and responsibilities more.

So I think that's maybe my vision becomes more so configuring that to the best way it can be right for the use case and so on so forth and then the development team, doesn't really have to figure out how to do that or what the best way is because that's kind of a, it's kind of a different ballgame, that's a Playing field in that way to optimize for what you're doing. You need the knowledge to do so in the first place. Yeah, absolutely, exactly like that. Java platform team is really to

take this tool box. So that was talking about and then, you know, and then there's different types of tool boxes, right? Let's get a kind of like Get live, only one doubts platform which I think, you know, is still a bit tremendous missing entire that were they? Yeah, of of it. Past really, if you're being in for being honest, you know what we see in the vast, majority of cases for like that your mid-sized to large sized Enterprise is homegrown open source tools like past together

basically. And you know so you have your like your terraform your are go you know some people put it like a backstage on top type of thing and and and that that that's great like that works for Of folks, what we see though, especially, you know, for a lot of those like mid-sized, also, to large-sized teams, that just don't have a lot of the satellite platform engineering capabilities in-house. Yet is you are Reinventing the wheel, right?

Because, yes, there's a tongues of Open Source, which is out there, and it's great. But the challenge is, you know, to figure out which tools work best with the chatter, you know. No and there's really a lack of reference architectures and

blueprints right now, which is why, you know, we actually one of the one of the tracks of platform. Conditioner is cold pot from blueprints because I think we're in we're getting to a second stage of the platform. Engineering, you know, movement where at the beginning the last like year and a half two years. It was really just about like hammering, this ABO like hey, if you want real true, you build a,

you run it platform. Learning is a way of doing it and the Enterprise, especially, and, and now people are all right, I'm sold. Where do I go next? Like, where do I start? And there's very little, you know, when it comes to starting points and blueprints and just, you know, share architecture is that people can look at. And so that's something that we're focusing on community wise

this year. But, yeah, and so that's why I think, you know, that's kind of, you know, the value prop with With you money take is that is, you know, take this like or configuration engine and then go build your opinion and workflows on top of it for your org but don't try and reinvent.

The whole logic, you know, of configuration management and how, you know, resources are provisions and all that stuff because that's where we see a lot of teams just doing the same work over and over again because, you know, everybody is a special snowflake but actually, they're not really Get that I mean it's interesting right because when new tools come out step one is to figure out how to get this thing working out how to get things done with it or how to use it to

leverage whatever you want to do. And when you have a bunch of tools you do that, you get stuff done with that and at some point you're like okay maybe this is not the best way but this is our way and you talk to other people and you learn about what they've done and then all of a sudden you kind of have shared better practices until they become best practices and those might be within your organization but if you standardize that Then people that are new to that and there

are in kind of a starting phase. They don't have to reinvent the wheel, right? Because then those that already have done and figured out how to get stuff done, they can educate those on what they've done and then all of a sudden you're going to have a shared methodology of how to do the thing in the first place and how to do it, right? Because that's the most important part that makes it sustainable towards the future and flexible, probably.

Because the future is kind of unknown in that way as well. I like that notion of, like, figuring out your internal golden paths and then even may be standardized It's never going to be a silver bullet, right in, you're always going to have options but at least kind of defining a blueprint for other people to hold onto or to learn from. I think that's very valuable. Totally. Yeah. Yeah, exactly. And yeah, so that's what we're trying to do.

And I think like you mentioned, you know, being being like you know sustainable I think that's really that's really a key word.

where, You know, you really need to think hard. I think. So, you know, let's say your Google, of course, you need to like, build everything internally because your requirements are going to bestow specific and custom. And in fact, I mean, they have like, tens of different platforms, right? Because they're so huge. Yeah. But you know you really need to look at like the ROI of these

things and think about. Okay, you know, how much can I build Scratch, how much can I, you know, how much time can I put into this? Because the average sort of, like platform initiative that we see is a year to two years and the issue a lot of times and something that, you know, in the community we weren't people against is like, hey, it doesn't end there, right? Yes. People are like, yeah, build the popcorn.

Great. But you know, that's actually where the work starts is, then you're like Ida rating on this product and And that, you know, takes like ftes takes resources and so on so forth. And so, I think that that's one thing that also is this, I think Blueprints and Wilson another track that is an impact to track. It's more geared towards, you know, understanding the value of the ndr i-- of platforms for management and helping Engineers

sell internally. But also making sure that everybody oldest a Holder's internally all are aligned around this concept of, you know, what are the expectations of value creations and what are the costs because the costs are really not trivial. So, it's important to keep that in mind. Yeah, it's interesting because what you mentioned, like, I can see that from a product building

perspective and obviously that then holds true if your if your platform is your product. But looking at it, let's say I'm a software team and people are building things and we're working towards a goal. I've I've you have people that really thrive in that kind of early on stage, right? And then when your live as you mentioned, then you get more. So faster customer feedback. So then you can iterate and test your assumptions faster and move on to delivering more features

and more value in that way. But for some software Engineers that stage becomes then less interesting because they really like the early, the early start of things where they get to test and they're really good at that fast. Iterating testing what really feels good and what doesn't based on the use case that they have and more. So the But once they're live, that's not really their Forte because then they're building on top of what they already have.

Is that kind of the same for platform Engineers because I can imagine you build towards like releasing more value for your developers that developer experience in that way.

I don't know if it's the same or comparable to going live with certain features but I can imagine some are and then obviously, once you are live at, once you're happy with kind of 90% of your platform and that then becomes or then you move into kind of that iteration phase, I can imagine Even some platform engineers then that's really not their Forte as well, as that kind of comparable in that way. Yeah, absolutely. You know, you have to kind of

like the 021 people, right? And then the, the OnePlus. And, and so I think the same thing like, you'll have the people that, and especially I've seen a medic a couple of sort of like, senior consultants and people that have built a bunch of platforms. And they really enjoy this, you know, starting from scratch phase, where they enter into company to disaster. Whatever, you know. And, and then the the spend like, two three years and they built it and Equipment while to set up the team.

And then you have another team that basically takes over from there and, and off, you go, right? And that's great. I think that is the ideal scenario, to be honest. I think that the issue is a lot of times people don't think about face too, right? And it's like, oh, we have an issue pot from seems to be a potential solution. Let's explore. Let's build one. But without a Sorted initiative internally to keep driving this and understanding this is not a

one or two years project. This is probably a, you know, five ten years depending on the company. Yeah, interesting. Also based on what you were

saying, I wonder, let's say you have a bigger or medium sized organization, even a large one, and there's no platform team, right? So we have separate development teams, kind of doing their own thing even making their own Solutions or choosing their own stuff, resource wise. And what they need for production. At some point, I can see is, it would be good to standardize

that, right? And a platform team, will kind of build that solution towards that, but if there's no platform team, who's going to advocate for creating such a team in the first place, like, where have you seen that coming from an organization? Is that the engineering managers that a CTO? Is that the developers themselves? Like, where does that in cling? Or that idea usually come from? Yeah, that's really good question. So I've seen it coming from both

On both sides of the equation. So either the you know the engineer manager who's just really frustrated with her Engineers you know not being able to deploy or yeah. Just like her own day-to-day and like this sucks. Like why does it take so long and but I think honestly probably I would say 80% 70 to 80% of cases is actually the Ops item of the equation. Oh, come because they're either one say I think suffer, most in most cases.

So to give an example, if you are, so the Ops side of the equation will suffer in pretty much in in Old Company sizes. Yeah. Whereas the large company both the developers and the Ops are really frustrated because this problems the problems that platform engineering addresses get worse as the As the engineering org size grows, right? So you have you have a certain point where it's just so bad for everybody involved. That when you everybody's like, oh my God, yes, platforms.

Like let me sign now, but in a, if you think about maybe a case where you have, you know, a couple hundreds engineers and it's a more advanced engineering organization where you no more. Confident like handling certain certain things and then they really just need help with that like that. I actually like the final 20% of you know, deployments provisioning infrastructure stuff like that. Then from the point of view, as a bit of the site tragedy of the

commons, right? Because from the point of view of the company and the and the org engineering or get, it's still a net positive to implement a pot fur. But from the perspective of The Selfish perspective, Active of the developer. Now I go from I just slack my Ops Team and usually they get back, you know within a couple of hours problem solved, great too. Okay, now I need to learn this new, you know, platform thing. It may be interrupts my workflow, you know, type of

thing. And so from their perspective, it can be like a net neutral or maybe even a - right. And so that's Where those are the scenarios where we see, you know, the Ops / platform teams. I really Keen to push because, you know, they're their reality still is a lot of take adopts coming in, so it still sucks for them, but not so much for the developer. And that's where I think. Again, it's really important for the platform team and the developers to have a really scared Vision around.

How do we, you know, no create an on-ramp for platform for developers to, you know, access the, the platform and and make sure that it fits into existing workflow as best as possible. And that's really important, right? So, for instance, one learning that we made as been to, you know, most Engineers really enjoy, you know, they're really used to like a fully code-based. Kind of like workflow, we're going to deploy and everything is get bays and so on so forth

and so trying to impose a click hop cui type of thing where now a little bit further than you can jump out of there, you know, code based workflow into some UI and try and figure this thing out that they've never really seen and you know, it's not like oh I'm learning this new skill that probably means. I get it like a pay. Raise the next job, not even.

Right. It's It's like it's just kind of annoying now and that's where we see for instance platform initiatives fail when they really focus on this like dashboard like thing, why? Because a lot of times especially from the perspective of, you know, management or people that need to, you know, sign off on this like rollout

it's really great. The idea of having this like service catalogs of having this you know, beautiful one place one, you know, pane of glass to see everything but that's not where Are the issues are. Usually the issues are around my configuration management, infrastructure provisioning their level deeper and and and it's not.

And so it's not about just putting, you know, there's this, there's this guy Lee that build a platform where apple and he wrote an article on platform Regina or get that is called something like along the lines of if you put a, a pane of Glass on top of a pile of shit or you see shit?

Yeah. And And that is, you know, the idea of, you know, you really want to focus on what are the core issues that that block developers in the day-to-day and in our experience that's really around configurations and infrastructure provisioning. It's not about, you know, how do I template my service? You know, and then start from there and so it's really important for platform team Stooges. Figure out. How do I fit this into into the developer workflow in a way that

makes sense? And that's where we see code, fully code based interfaces, right? Like using yellow flies, and stuff like that, as the, as the best. Again, minimum common denominator across the board, interesting?

Yeah, I think the challenge with the biggest challenge, I see for a platform team is really just figuring out where the value is. And that puts, I mean, that responsibility lies with the product manager at the end of the day, right? And because they're building a product to people that are more technically oriented, right? Developers in the first place does, the product manager also need to have like a lot of

technical knowledge in that way? I can imagine like a previous life of developer experience would help in that, but that might also bias them towards Solutions, which might be outdated. Like I feel like there needs to be a balance in technical information but not too much in

that way. Also. Absolutely. And that is why, you know, if you check out the product management channel on the slack space, like day is one of the most is were probably I Find some of the most interesting conversations and threats going on. Because, yeah, as you said it took a really fine line and really find that is that you

need to find. And then really think hard about where in in this site value chain the most value lies in terms of the problems that you can solve and one of the one of the issues not to bash you know service kind of like the next things. Like we actually work really closely with their with their team, they're really acting the community but like it, It's important to understand one of the, one of the fallacies that we see a lot of teams full into

is, and my battery is dying. So I'll call you in a second, but like is the idea of, you know, basically looking at the de workflow of developers and chronologically. And so they say, okay, we need to put fur and you know, we want improved of X and Bubba. They start like, you know, top down and Then they and then later. Okay, what's the first thing the developer does? Oh, you know, she creates a application as a service,

whatever. And so that's when they start thinking, okay, how do we optimize that step, right? And then it's like, oh service catalogs. You can see all the services that other teams are using blah, blah blah, and like that is okay in practice except that that step like, you know, changing that step, you know, maybe improves, you know, in your efficiency by one or two percent. Yeah. Instead of looking at light, where is the actual like hyper painful? Par you know of the developer

dream. She's usually actually handling the outer 10 tools that come after that, just to deploy something or provision something, right? And and and so that's where you know, you want to build a platform that takes all of that into consideration. But usually you want to start from where you can deliver more value not. We're people start horn logic. That's like one of the anti patterns, if you will then we see emerge sometimes the interesting, I've never had that

role. But obviously, with my kind of software engineering hat on or goggles on rather, I would sit next to software engineers and either pair up on a problem and see what they really face either in deploying their stuff, we're putting their stuff into production, right? Because that's kind of the end station of things, that's where

it ends for them. Once it's live, maybe even looking at like the information the game from that, but still, I think that experience will give you the most insights in the pain points, right? And if that is built on time or if that is kind of the tooling the other tooling that are using, then that should be kind of your number one priority

because that's going to deliver. The most value that's going to make their experience better or more efficient or it's going to make them more effective in the first place and I think as a team that is the responsibility. So starting with like it's similar to being as close to your customers as possible except your customers are developers in that way.

Yeah, yeah. And I think one of the issues that we see Is when it's top down, you know, and it's like, oh, we need to a, you know, CIO acts reads article. Why about, you know, that's apologies that and like, that's great. Like we need to roll it out and then we see a lot of people coming in and like, so we have been told we need to adopt this thing. What do we use it for? You know, and just try to figure out from there, which is, obviously not ideal.

And sometimes you just have this, you know, inefficiency is especially in larger in large organizations, where are, you know, platform teams, it's a, if you think about like a star up in the wild, if you know, if you were going to try and solve the 1% problem instead of the 80% problem, you would just fail, you wouldn't, you wouldn't build a sustainable business and the problem is because you don't have a lot of times in this large Orcs that that feedback in terms of like, you know, does

this team even make sense to exist then you just have you know initiatives that make Sense. Yeah that makes total sense to me.

One of the last thoughts I still have is kind of a controversy I saw online where I don't know exactly where it came from, but it was all over Twitter a few weeks back and was like that. Whoops is dying and platform, engineering is the way to go. What is your take on that? Do you see kind of a trend declining for devops and people moving more towards like building platforms as a product in that way? Or will it work better hand in hand? Like, what are your thoughts on that?

Yeah, so That was a really funny story. I think and, you know, we, it wasn't actually us now they're at the beginning, but we definitely saw it. It came out from actually an interview of our CTO with a YouTube YouTube channel. And then, you know, the recap was this like very catchy Delta's that long live Popham engineering and, you know, we thought.

Alright is brother, let's run with this and And that exploded to an extent that I never thought, you know, it would, but I honestly think it really trigger triggered. A lot of people but it also triggered a really help the conversation in the space that I think was really needed because look I think from my perspective, one doubts came up more than 10 years ago, the world was a very different place. We mainly developed monoliths, may be running on bare metal. We had, you know, incredibly

less complex infrastructure. There's no Cooper. At ease. No get-ups know, all the cloud native stuff they were talking about earlier and the initial idea behind that was a great idea which is remove the barriers between the vaginal and Ops and facilitate collaboration. That's great. But the reality of that is very different.

So many organizations don't pay, I think enough attention to the culture or challenges which is, you know, not the fault of that is not the fault of Ops or download sleep at all.

No, but they're just like, you know, with this increasing complexity of all the strands, you know, coming together and converging you the reality of devops is where we are describing earlier which is developers are blocked, they're afraid of messing something up. And then you have this role of the devops which in itself is a bit of a contradiction that that, you know, basically is doing oldest. Take it off sand. And trying to survive.

And so, the idea of platform engineering, from my perspective, and from our perspective, thinking journey across the community is to enable true. You build it, you run, which is the core tenant at the heart of devops, right? And and what that means is now developers can actually self-serve tacking tools to deploy run and operate their applications.

And Aces and they can actually do that without depending on your Ops devops Team and your opt-outs team can actually focus on building a platform for developers or on essary maintenance, reliability, and, and just better challenges. Then, you know, setting up old is this like fighting take adopts constantly basically. And so, I think that conversation is a really healthy conversation to have especially because You know, I've so another thing that happened is

at as Humanity tag. We went to cube con Detroit and, you know, you have to submit your booth designs two months in advance. And this is when we had to like the whole like, you know, that which is that, I think, I literally just started, I was like, oh, this is great, like this is gonna get a lot of conversation. Sorry, that's it. And then this whole thing explodes, completely out of hand and then we're like.

All right now, Is our books. And but it was incredibly interesting because you had all these people that was Engineers that would walk up to the booth really angry so much that I'm right, because there were like what the fuck like adults engineer. I'm a lot. Like what are you talking about? And, and I kid, you not every single one of them, by the end of it was like, we hugged it out. They all walked out with our doubts, is that t-shirt, which is a sick design.

And, and they were like, thank you. This is actually really important conversation to be had in the community. And I think on the flip side of that, the people that were more protective are, you know, the people that sell devops there are, you know, within that like loud minority, you know, Twitter bubble which is also very much, you know, mirroring who are the sort of exhibitors, I keep Khan.

Yeah, and And I think are the people that have a interest, you know, in gating is Concepts and and and I think are straight up in some cases a little bit delusional because they live in this world where, like, oh no, devops is here to make a word about a place. Like, no, it's not.

It's a philosophy that started as something that is incredibly valuable, but the reality of people not working in selling doubts, but Actually living devops and their engineering organizations is quite different in a lot of cases. And so I think there's been this growing gap between, you know, the industry experts and the actual practitioners and they

don't really speak. And so that's what we are hoping to kind of address with the pot from engineering community has created a space for people to address these things and honesty. And you know, I think like most disciplines and trends like Eventually it morphs into something else and eventually you have a ingrained cast almost that protects it because they've just, there's so much invested interest in that, you know. So, very likely, it will happen.

The same thing. Probably for the apart from engineering at some point, but I think now we're hoping that it, it just freshens up the conversation because I think it's needed. Yeah, I think that's a, I mean,

It's a trigger and it's a marketing thing right there. Whoops is dead. But the people that come to you angry and want to start that conversation. Those are the most passionate people you're going to get because they care, right? If they didn't care, they wouldn't walk up to you. They wouldn't be like, what the hell is this? They care and they want to have that conversation and if you can bring the value to them and have that conversation a healthy way, I think that's just a win-win on

both ends, right? Because then you share experiences, you share perspectives and then their Horizon gets broader in in and of its own to the point where they get the Sure. And they love The Fray. I think that's really cool. Hey, that's a really key point that you bring up, which is having two healthy conversation.

And that's one thing that I've realized what we were a cube Khan, which was like, okay, it's great to have this in-person interaction where you can really take the time to explain what we mean. Right?

And then that trigger is really, you know a great top of funnel like drive into that conversation that you have the conversation, the issue with the online version of that was you know, because it got Not so viral the velocity of that message was just too high for the velocity of the conversation, to catch up to it. Which meant, I think, in a lot of cases, people got it without any context and and then I think

you can do more harm than good. Which is why we completely drop that and we're rephrasing it more towards, you know, you know, keep talking about the challenges that was burnout and like other ways of phrasing it but not necessarily that whoops is dead but it's funny. There are still It's funny to see six months later. Still all these articles popping up literally every week on? Like is that v dad my take and I'm Frank that can't see them anymore.

This is a yeah, that I mean it's super catchy and I yeah, that's it. That's how I got. Oh yeah, that's how I saw them as well. I want to know if I want to round it off here, Luca. Is there anything you'd still like to share with our audience that's listening in? Um, I mean, come check out the platform engineering community. So pot from engineering to or apart from con.com, those are kind of the main sites. And then from there you can join slack which as we said is go

over. 8,000 practitioners super-active. Pop link on 23 is coming up in June 8 and 9 is we recently just relaunched the website couple weeks ago is completely free is virtual so everybody can join and we're going to have you know probably 100. 5,200 amazing talks. And I think that's, that's really good place for people to start. If you want to, if they want to check out platform engineering. See what it's all about.

Yeah, sounds awesome. I'm going to put all those links in the description below as well as links to Luca social Luca diaunte. I hope I pronounced that correctly. It's Italian. So Allah put his social in description below. Check him out. Reach out to him. Let him know you came from her episode. And with that being said, thank you for listening. We'll see you on the next one.