Narrator: You're listening to the humans of DevOps podcast, a

podcast focused on advancing the humans of DevOps through skills,

knowledge, ideas, and learning, or the skil framework.

Luca Galante: So usually, it's already quite a hurdle to

convince the executive and all different internal stakeholders

to start and drive a platform initiative that can and should

last for years.

Eveline Oehrlich: Welcome to the humans of DevOps Podcast. I'm

Evelyn early Chief Research Officer at DevOps Institute.

Today we have with us drumroll, Luca Galanti is a product owner.

And our title of our podcast is a conversation with a thought

leader on platform engineering, I just talked to look at finding

out from where he is coming to to us, I will not give it away.

But he's in a very beautiful place. Hopefully, all of you

listening into us will be in a beautiful place, having a nice

cup of whatever in front of you enjoying our conversation. So

let me give you a little bit of background on Luca, he actually

routinely speaks to 10s of engineering teams every month,

tons of engineering teams, not 10s. But tons. Every month, he

summarizes his learnings and takeaways from looking at

hundreds of DevOps setups into very crisp and insightful reads

for everyone in the industry. And that from beginner ops to

cloud experts. So Luke, welcome to our podcast.

Luca Galante: Thank you. Thank you for having me. And hello to

everybody from Tenerife. A really nice place.

Eveline Oehrlich: Yeah, he gave it away, thank you give it away.

That is your choice of giving that away. I've been to tenerife

myself and it is a beautiful place. So enjoy it. Thank you

give us a little bit more background on your current

position and what you do Luca, totally

Luca Galante: happy to so I run product at humanI tech. But I

guess I'm more known in this pace as one of the core

contributors to the platform engineering community. I

moderate the slack there where we have almost 10,000 People

actually I think we're going across 10,000 Next week, I host

platform con which is the first ever platform engineering

conference, I write a newsletter that goes out to six or 7000

people. It's called Platform weekly, it goes out every week.

And yeah, so I talk a lot about platform engineering. And as you

mentioned in the intro, also kind of discuss what the

benefits can be with a lot of sort of like infrastructure,

DevOps, and so on teams

Eveline Oehrlich: all over the world. Fantastic. And I think

that's why of course, we are very interested in talking to

you. Just again, for your benefit Luca, our audience is

really wide spectrum from beginners, DevOps from more

advanced, we have practitioners, we've got site reliability

engineers, we probably got a few platform engineers on the call

on our on our podcasts listening in, we've got testers, we've got

system administrators, we've got leaders, we've got individual

contributors. So just so that you have a bit of a bit of a

background. Now, the term platform engineering has gained

steam, and to the tune of folks, manual players. And Matthew

Skelton who I both know, mentioned, actually this topic

in their book, in 2019. I did some research with a vendor

partner of the DevOps Institute, also in 2020, on site

reliability engineering, and we saw the term show up there, then

as well. So you've been, as you said, a core contributor to this

platform engineering community. And we'll have later on for all

the listeners a more details on where you can get involved. But

before we go any further, I always love to make sure that we

have a definition. So what is the definition of platform

engineering? Totally. So

Luca Galante: the way I think about it is platform engineering

is really the art because it's more of an art than a science,

in my opinion, of effectively taking all the tech and tools

that you have, especially in an enterprise engineer

organizations and binding them into a golden path that enables

developers cell service and in general reduces the cognitive

load for the individual contributor and the sum of This

golden path that are built by the platform engineering team

for the rest of the junior organizations is often referred

to as an intern developer, or IDP for short. And the focus of

an IDP is really that of improving developer experience,

by lowering cognitive load to developers, while also

streamlining the kind of like infrastructure and operational

setup, on the other side of things. And a sort of like key

principle that we advocate for in the community is platform as

a product. And so really have platform teams focus on building

and shipping a platform as any other product to the rest of the

G organizations, which is really their internal customers and the

developers. And so that's kind of how we define platform

engineering, in turn developer platform, which is the product

of platform engineering, and the two main actors in that

transaction, which is the platform team, on the one hand,

apart from engineers, and the developers, their internal

customers on the outer.

Eveline Oehrlich: So IDP, that's something for everybody to do

note down. And so typically, where does such a team sit? If I

think of the organization, today, reporting to application

development, infrastructure operations DevOps, and you

cannot say it depends on what's the typical. What's the typical

team these folks sit in, in terms of the organization?

Luca Galante: It's gonna be hard without the independence, about

answer. So, you know, the reality is, we see very

different kind of, sort of, like organizational designs,

depending on really the size. More importantly, right. So

you'll have teams of 100 200, engineers, where they report

directly to the CTO, you have, you know, come massive companies

that we work with 1000s of engineers, and obviously, the

platform team does not report directly to the seat to but to

some VP level, probably responsible on developer

experience, or cloud infrastructure, or cloud ops.

You know, you have your kind of, like, Director of dev x had a

plot firm, those are the type of like titles that usually lead

these initiatives.

Eveline Oehrlich: So to some extent, I have also seen them as

a shared services group, of course, that name is not really

Vogue, right? Who wants to be a shared services group, but I've

seen them as a as a as an added value to, to that team, it kind

of depends on as you said, so I said, it depends. I didn't tell

myself, I was not supposed to say that. So but thank you, that

was really, really good. Now, again, the goals of this team,

you alluded to it a little bit already, but give us what are

their goals?

Luca Galante: Totally. So the the main goal of the platform

team really is that of figuring out what the what is the minimum

common denominator, across their entire engineer organizations

have problems that the developers have, right? So you

really want to start from not Oh, hey, let me through, like

build a platform with the latest shiny new tech, because I've

heard somewhere that it's cool. And I should, I should take a

look at that. But really take a look at you know, the complexity

and the reality of your brownfield enterprise setup,

where you usually have, you know, many different development

teams with very different stacks and delivery setups, you know,

you have the ones that prefer using your circle CI applies

aren't go, the ones that are on Jenkins, the other ones are

using something again. And so you kind of want to take a look

at all of that and get an understanding, alright, what is

the minimum common denominator that souls the attacks, the

largest possible problem surface, and that's really the

starting point of a platform team, together with pinning down

precisely a mission and a role for the platform team that gets

marketed internally to the rest of the organization, because

that's really important. In order to make sure that your

platform initiative is successful, is to make clear

that everybody makes sure that everybody understands, hey, you

know, this is not another infrastructure SRE team. This is

a product team. And so this reconnects to what I was

mentioning in the beginning, which is really the core tenet

of platform engineering and what clearly differentiates a

platform team from a DevOps infrastruc Archer essary team is

this product mindset, right? So is the idea that you need to

build a very tight feedback loop with the rest of the engineer

organizations, which again, are your your customers, and make

sure that you iterate on top of this minimum common denominator

are problems that you identified at the beginning. And keep

shipping teachers and keep improving the platform by

building different is different types of golden paths that we

mentioned different in the definition. And this is really,

the I think the make or break for a successful platform team

is the ability of listening and communicating clearly,

internally, internally to the organization. And understanding

what are the best golden paths that I can design for different

types of users across different types of teams. Right. So as an

example, you'll have, you know, your senior backend engineer

that really enjoys handling their Helm charts and icy

modules and some weird Yamo files and scripts that they've

put together. If you, you know, build a platform that is very

you, hi, Avi, and completely abstracts all of that away from

them, they'll fill, you know, they have no context, and

they'll push back on your path from initiatives and that

platform initiative will probably fail. On the flip side

of that you might have, you know, a junior front end

engineer, that doesn't care whether you're running on

Kubernetes, or somewhere else, they just want to deploy their

code, see, you know, test some changes, and if you go and so

for them, it might make sense to have a much higher level of

structuring, whether it's through UI, or usually what we

find, on average is still you want to do something code base,

because developers don't like to be abstracted away into UI. But

that clearly shows you meet two different types of golden paths,

and two different levels of contexts that you provide to

people. And, and so the key ability of a platform

engineering team, is that of is that of? Sorry, is that a

listening and, you know, being able to put together this

different golden paths for for different apps to users?

Eveline Oehrlich: You know, what it makes me think of a Rubik's

Cube when you were talking about these examples, right? We have

very different types of paths as you sit for these different

types of teams. So that's quite a challenge for for such a team

or that gets me to another question, or I'm assuming that

multiple platform teams are there?

Luca Galante: That's a great question. It depends, if I can

use that, sure, you know, so usually, in the vast majority of

cases, no, actually, you know, it's, it's already quite a

hurdle to get over to convince, you know, to get the executive

and all different internal stakeholders buy in, to start

and drive a platform initiative that can and should last for

years. So usually, in the vast majority organization, we

actually see one team, but obviously, the ideal scenario is

actually having multiple teams competing with each other. And

so we, I can, I can link in the show notes there. I've spoken a

couple of times with Arne Erickson is a also really key

contributor of the platform engineering community and other

platform engineer.org blog, and he has a rolled out the what was

the successful platform initiative of Salesforce about

five to eight years ago. And in our conversation, he tells a

story of how they work internally with I believe three

or four outer different platform teams. And this you know,

highlights again, what I was talking about earlier, which is

the importance of you know, communication and internal

marketing skills, which really positions the the platform

engineer to have a different skill set and your kind of like

usual infrastructure SRE that is more focus on you know,

reliability, scalability, maintenance, and so on. Because

really, you again, you are shipping a product and a key

part of shipping a product for everybody that has done so well

know, is distribution, right, and building that relationship

to your customers. And so nowhere is that Sure. And then

in larger organizations where you're actually competing and so

you're basically building a almost a go to market motion.

within your law firm design,

Narrator: you want to get ahead in your career and we can help.

DevOps Institute certifications will validate your knowledge and

give you the skills you need to succeed in a key area of DevOps.

With our certifications, you'll be able to prove your subject

matter expertise, and enhance your professional credibility.

advance your career today with DevOps Institute certifications,

get started by visiting DevOps institute.com.

Eveline Oehrlich: So you mentioned already a variety of

benefits of platform engineering team, let's not dwell further on

that one. Because I think there is plenty of good things you

already said. But challenges and your when you mentioned one

already, which is the actual making sure that executive

spying? So two prong question first, what are some other

challenges besides making sure that you market that? And then

how and what is the best way to actually market that if I'm the

CIO of company X, and you are now coming to me? How would you

market that?

Luca Galante: To me? Yeah, that's a great question. So I

think the you know, there are two basically set of challenges.

One is a, you know, set of technical challenges. And again,

I think the, the best sort of like starting point is looking

at the current reality of your engineer organizations and find

that lowest common tech denominator that can be used

across all different teams and start from there. And that by

the way, just as a quick tangent, is something that we

see a lot of people miss, as a as an idea. Because I feel like

the fallacy is a lot of people think, hey, if I could only

start Greenfield, right, and so I'm a new platform teams and

your platform initiative, let's start from scratch, right. But

by starting from scratch, and kind of dreaming up of your

ideal bathroom stack, you are missing out on a key piece of

the puzzle, which is listening and, and effectively building on

top of the information that you already have available. And so

actually, almost paradoxically, we've see the most successful

part from initiatives really are in very complex enterprise

setups, there are very, that are very sort of nuanced, and the in

the different stacks that people use, and then learn and build on

top of that, and then and then from their, from their they get

started. The other set of challenges is what we mentioned,

which is basically internal marketing. And then there there

are, there are two, I think different levels. One is the

first one that you mentioned, which is basically you know,

your your kind of like executive buy in. And I think the main

line of argumentation there is one around ROI. And especially

in you know, times like now and the macro situations that we're

living through is paramount, I think for engineering management

to understand the impact that a platform can have. And the

impact is not only on your kind of Dora metrics, right? So

obviously your lead time deployment frequency, what is it

change failure rate and MTTR? They all improve? Right?

Massively, you have a crazy drop in OPS overhead in ticket what

we call ticket ops, right? So basically, operations team

constantly being stuck. And then on the other side of the fence,

developers having to wait so you know, waiting times drop ups,

overhead drops, you also have your kind of slo metrics,

improving like security, stability, reliability, all

improved because you get a much better audit of who deploys

what, where you can easily do dis rollbacks between

deployments. And so your entire delivery setup gets extremely

more efficient. But I think the other thing that sometimes can

be a little bit, maybe harder, like it's a little bit less

quantitative, potentially, but it's the, you know, crazy drop

in frustration across the engineer organization, right?

Because in a lot of in a lot of teams right now, the reality of

DevOps is developers being completely overwhelmed by

increasingly complex cloud native tool chains that adults

fully understand and in fact shouldn't because it's not their

job. And so when they just want to, you know, spin up a pre

environment to test a little changed is now all of a sudden

need to touch 1015 different tools and three or four

different scripts and completely, are completely

overwhelmed by what we call, you know, this cognitive overload.

And, and on the flip side of that, so what happens is then

they basically either ping their most senior colleague, that

senior backend engineer we mentioned earlier that likes,

you know, messing around with their Yamo files, maybe. But

then what you end up having is your most senior and most

expensive resources, shall I say, being effectively blocked

and blocking outers and becoming a bottleneck. So that's another

point for your kind of like sea level conversation. Yeah. And

then on the flip, the alternative with that, again, as

you're like infrastructure and ops team completely stuck,

basically constantly fighting ticket ops and putting out

fires. And so there's really widespread frustration on both

sides of the aisle. And that's really what platform engineering

sets out to improve is really living and enabling true DevOps,

true, you build it, you run it, and not the kind of like half

baked version that we ended up with in the last decade,

effectively. And so that's really kind of like your pitch

to sea level. And obviously, you know, you can, you can take

smaller parts of that and go pitch to your developers and

operations team on the other. After that, I think what's

important there on the operations side of things is

that you make really clear again, that you you're

differentiating between sort of more traditional operation role,

right. So it's not like a platform team replaces an SRE

team, you still need to care about how your load out your

load balancing across all your production regions, and

clusters, and all that good stuff. But you need to spin up

this separate set of skill sets and roles that really focus on

shipping a product and you need to make sure that that is really

aligned the mission. And the vision of the platform

engineering org is aligned with the rest of the serve like

infrastructure teams to make sure that there are no friction,

there's no friction there. And then the third sort of group of

stakeholders, obviously, as developers, and we kind of

touched on this earlier, but the idea here is, you just need to

listen a lot and make sure that developers have a clear idea

that you are improving their day to day math and lead by enabling

them to self serve the tech and tools they need to run and

operate their operations in fulsome service completely

independently. But at the same time, you're not doing that by

providing them some past like, some class like tool that

abstracts them away from the underlying tech and tools. And

again, this will matter more or less, depending on the user. If

it's a more senior user that is, you know, used to handling low

code stuff then. Or just like low level configuration stuff,

they will be very sensitive to the type of golden path that you

design for them. And that's where it's really key that that

you know that that information flow is really optimized. And

then also, finally, I think there is a conversational roll

up strategy. Again, you can think of it as any sort of like

go to market, who are your early adopters, where you start. And I

think, you know, we've seen a lot of successful platform

initiatives starting by working with the more advanced

development teams that usually are the ones who are going to be

more comfortable with your cloud native stack, you know, they're

not afraid of Helm charts, or TerraForm, modules, and so on.

And so it will be easier to start by sort of like with them,

laying that foundation with something that is not so

abstracted, and then progressively move to maybe more

junior or less experienced teams or just teams that frankly,

don't need to be so deeply in touch with the underlying stack

of things. And for them build a potentially more abstracted,

simpler golden path. So those three groups,

Eveline Oehrlich: I can just hear your passion on this topic

is just phenomenal. Luca, you are phenomenal. I want to say

that one more time. You are phenomenal. Now I have two more

questions. One is related to the platform engineering and that

individual skills. And the last one is a fun question. So let's

do the hard work first. skills as you know, we hear the DevOps

Institute are really engaged in skill building upskilling and

all those wonderful topics and you mentioned one Skill already,

which was listening something I have to tell my husband, he

should become maybe a platform engineer, and then he would

improve his listening skills. But no, he has no chance. But

that was one skill. You said, what are some additional two,

maybe two other skills you want to highlight? If I want to turn

into a platform engineer, what should I have as a skill?

Luca Galante: Totally well, so I mean, from a technical

perspective, obviously, you want to have a solid understanding of

all your kind of, you know, infrastructure, especially cloud

native tool chain, right. So your Kubernetes I see

infrastructures code, see ICD workflows, good ops, you know,

throw your boss word of dude, you were, you know, obviously,

you wanna, you want to have those bases covered. But I think

the vast majority of people that will approach to platform

engineering, sort of topics coming from a, kind of like,

your infrastructure DevOps role will already be familiar with

that. I think, really, and I want to kind of de risk of

repeating myself, but I think that there are two main things

really, that I see. One is product mindset. And so that's

really the shift that maybe if you are coming, sort of like,

more green to this is, or, again, from building and

shipping products, that's not a big shift. But I think if you

aren't coming from your kind of more traditional infrastructure

and DevOps role, it might be a more important shift, mindset

wise that you need to make. And, and that's, I think, really key,

right? And, and so that's obviously like the part of the

listening and having this mindset and really starting to

think, Hey, your developers are your customers. And that's all

that matters. And so then obviously, there are oldest

topics that have emerged from there. The the kind of

fundamentals of product management, right, that we all

know, so user research product, roadmap, MVP being, how you

think about adoption, and that's just to mention a few, right? So

really just taking everything we've learned in the last few

decades around product management and applying it to

effectively infrastructure and gluing together your tool chain

into a product, a platform that makes sense for your end users.

And then the other one is communication broadly, and, you

know, obviously, part of vision is listening. But the other part

is speaking. And so the speaking part is again, like how do you

think about internal marketing? How do you think about

stakeholder buy in? And how do you make sure that you are

adapting to the different type of lingo to communicate

incentives clearly, right. So the way you communicate to sea

level, and you talk about ROI, and you talk about, you know,

your decrease time to market, you know, developers don't care

about that. Right. So then when you talk to developers, it's

really about, you know, their developer, velocity, I mean,

even velocity productivity or more stuff for sea level, it's

really about just getting them stuck and talking about, Hey,

your waiting times will drop. And, you know, this is how this

is how we can improve your day to day immediately. And I think

they're a key. A key part of the communication is how you plug

into their current workflow, we thought without interrupting.

And so that's, I think, is really important. But yeah,

those those two things, really product mindset and

communication skills are, I think, the major thing and if

you were to plot on a graph, your kind of evolution of that

buzzworthy sort of roles and titles from your SIS admin, to

your infrastructure to your doubts in the near future, apart

from engineer, you know, if you had time on the x axis and sort

of like communication on the y axis, then you know, they would

plot on to the right, and that's, that's, I think, kind of

how you want to think about it, right? Like platform engineer is

basically a DevOps engineer that listens and communicates better.

Eveline Oehrlich: Beautiful. Wow, that sounds like a really

exciting career choice to make if anybody out there wants to

know more, there is plenty more to get involved in. I just say

that there is a fantastic report and I think you will look about

the author of it. It's called the state of platform

engineering. So if anybody is interested in then just look for

Luca Galanti and type in state of platform engineering, because

there is all these different ways of getting involved in

Slack channels and communities and events. Super. This was

extremely insightful. I think. Now Now comes the fun part. So

besides doing these great thought leadership pieces, doing

your work, talking to people like me and platform

engineering, what do you do for fun Luca?

Luca Galante: Um, well, so as I mentioned at the beginning, I'm

currently on Tenerife. And so it's been really fun over here.

I've been living out of event actually, for the last couple of

weeks and surfing mostly, really early in the morning, because

we're one hour behind here. But that's, I think, one of the

things that I do for fun, you know, just just being in the

water being in nature, that's, that's really good times for me.

And the other one, frankly, as a good Italian is just eating and

drinking good wine. So, you know, simple, simple person

simple needs, but does go pretty far for me.

Eveline Oehrlich: Fantastic. We have to meet in person, I have a

van. I love Italian food. Oh, amazing. I cannot serve you with

so I do like the water. So maybe we get to meet one time

somewhere in a place. Maybe Jennifer, this has been

fantastic. Thank you. We've been talking to Luke. I like Galanti

product owner, product master, and really a great thought

leader on platform engineering. Luca, thank you again so much

for joining me today on humans of DevOps podcast.

Luca Galante: Thank you so much for having me. And if they can,

if I may, just because you mentioned the the events. If

people want to learn more about platform engineering, I would

encourage them to check out platform eg.org. And that's

really the home of the community and platform khan.com. That's

the event that's coming up in June this year. It's free,

anybody can sign up and we'll have the best of the best really

of DevOps and platform engineering thought leaders

there. So I invite everybody to join us over there.

Eveline Oehrlich: Great, thank you, humans. Yes, humans of

DevOps podcast is produced by DevOps Institute. Our audio

production team includes Julia pape, Daniel Newman, Schultz and

Brendon lay. Those are the three folks I want to have a shout out

to because they're wonderful. I am humans of DevOps podcast,

executive producer Evelyn earlyish. If you would like to

join us on a podcast, please contact us at humans have dev

ops podcast at DevOps institute.com. Do I sound like a

virtual agent? Maybe? Anyway, have a great day. I'm Emily,

talk to you soon.

Narrator: Thanks for listening to this episode of the humans of

DevOps podcast. Don't forget to join our global community to get

access to even more great resources like this. Until next

time, remember, you are part of something bigger than yourself.

You belong