The truth is, and most developers don't like to hear
this, but when implementing platform engineering, we're kind
of stealing some of your autonomy.
The platform is built for software engineers.
If the platform is bad, it could be the case that the platform
team is building a platform for themselves, not for the software
engineers. Is this a common thing?
Sometimes I. Think it's even better to have
no platform at all than a bad platform.
How many developer hours have I saved by creating this coded
path? Don't build a cool platform.
Build a platform that developers want to use.
We'll use in the end if. You want to learn about platform
engineering, then this episode is for you.
I have two platform engineering enthusiasts joining me at the
table and the dynamic was just fantastic.
Atnan Al Shar and Yomer do Yom, so enjoy.
I saw this trend online and it was maybe a couple years ago.
It was DevOps is dead and platform engineering is the new
DevOps or it basically killed it.
A lot of people are like click baiting and engagement farming
specifically through that phase, but I'm curious what you think
about that. I think the platform engineering
as a discipline or as a practice that's coming up right now, it's
getting more mature every year. I understand why the title was
dev OPS is that I think they're trying to jump to the next
phase. And the idea here is that how
platform engineering is being pitched is try to counteract
kind of the DevOps movement of look, we understand you build
it, you run it, but we also want to make it better and remove all
of the negative connotations that happened with DevOps over
the past 10 years. So I think that makes the title
that I think that's why they said it.
I guess I don't. Know so do you agree?
Do you disagree? Yeah, I agree.
Yeah, yes, yeah. That's funny 'cause I disagree.
OK, tell me why. Yeah.
I, I don't think it's, I think that was that.
I think it just doesn't work in a current age of technology
anymore. That was, was of course created
or thought of in 2008. The world has changed quite a
lot since then, right? Containers were the thing,
Kubernetes wasn't there. So teams taking full autonomy of
their complete life cycle was possible back then move ahead to
10 years later. Communities, clouds,
infrastructure, codes, all these things were also put onto teams
had to maintain all of these things as well.
This is really where platform engineer stepped in and said,
hey, we tried to take small things that you're currently
doing and centralized them in the centralized team in this in
this platform so that you can just focus on writing codes and
being in flow. And we take care of all the
other underlying infrastructure that's needed.
So The thing is that I think it's OK.
It's that's like it was in 2008. I would agree with that for
sure, definitely. But in the current age of
technology, I think platform engineering makes DevOps work
again. OK, gotcha.
Yeah. I like it.
Yeah, yeah, yeah, I like the idea.
I think it's, it's evolution. It's that's what we're seeing.
I agree definitely on that. Just giving the chance for
social engineers or developers in general to go back to what
they do best and that's writing code that's that's talked about
from 2008 to now. The amount of stuff a software
engineer needs to maintain and work on and create and learn to
get their idea to production has grown rapidly, right.
You just mentioned how many AI tools are coming up every single
day or other tooling related to the software development life
cycle. A software engineer team to
maintain that and keep an eye on it while writing code, while
ensuring that code is secure, scale a bit, can be deployed to
production. All of these things it's it does
does not scale. And that's why platform
engineering is what I say, I think what we see as the
solution for this. But developers are also very
particular with regards to the tools they like, or with regards
to applications they like. Like if I, I put myself in a
position where I have a platform that is made for me to be more
productive, I really like the productivity side.
So that if you're talking about marketing, that's what hooks me
that I get buying for that. But then if I don't have that
experience, I get frustrated, right?
Because this is the platform that I'm on and I can't really
change anything because this is the choice of the organization
basically. So doing this I feel like is a
fine balancing act. Is that what you've noticed as
well? Yeah, it definitely is.
I would say to the developers, be on the lookout for if it's a
good platform or a bad platform. So it's a good platform can
actually help you get more productive rights, gives you the
right tools and a bad platform will have weird abstractions
that nobody wants to use, makes it even more complex to do your
work, which platform engineer was never set out to do right.
I think it's even better to have no platform at all than a bad
platform. And in the end, a good platform
will also have escape hatches. So the moment you a tool is not
supplied by the company or by the platform and you really need
it for a specific use case, you should be able to use the escape
hatch, get out of it and be able to use it to yourself.
It does mean however, especially in compliance or regulated
environments that you need to go to security yourself, get
affected. Make sure that it's set up
properly cause platform team will not do every small use case
that there is right. They will just support the main
tools that are needed within the company.
So yeah, developers should definitely be on the lookout for
a is the good platform or is it a bad platform?
Yeah. And if people are listening and
they say, OK, well, I have heard the term platform engineering.
I'm on a platform, but I don't think it's a good platform.
What can they do basically? In that sense, I guess you also
want to see how the platform team is engaging with software
developers. So in essence, in principle, the
platform is built for software engineers, right?
That's the main idea. If the platform is bad, it could
be the case that the platform team is building a platform for
themselves, not for the software engineers.
Is this a common thing? Sometimes, yeah, yeah, yeah,
yeah, yeah. Because building a platform is
fun for platform engineer engineers, right?
Definitely. I can say that.
And I do want to build it in this nice looking way and stuff.
But you're building a product, right?
And the product is for customers and you need to know what they
want. Otherwise there's no adoption.
It's very simple, right? So it could be the case that the
software engineers then need to address this with the platform
team and tell them to set this is our requirements.
This is what we want our like what what Kevin was talking
about like golden paths or so have to be able to work and be
productive. And that's the, that's the way
where you can get a bad platform to a good platform, have
feedback directly to the platform team and it's clear
what you want as an end user. You're the main customer here
for the product. So if you're able to do that, it
it should be able to get you to a better platform with time and
keep that feedback loop going with the platform team.
Because in the end, what feedback you're giving should
inform the road map for the product.
It's interesting, right? Because if I'm building a
product that is not for developers, in this case, I have
to do I have to put out the best product for those users?
Otherwise there's not going to be usage.
But I feel like with platform engineering, the role is
inverse. And you're saying if you're a
developer, you have to go to your platform team.
And I feel like they should come to me and ask me what the best
thing is. Yeah.
Of course, of course, of course, right.
But like most of the time, people in platform engineering
teams are very technical people, and I like to use new tools, use
technologies. So they focus on building these
do abstractions instead of actually solving what you need.
Yeah. So one of the tips I always give
teams is especially if they're a platform initiative starting in
your organization, try to be a early adopter, engage early and
show what kind of things you're running into, sell them
solutions. So but for example, say, hey,
it's getting something from ideation to production, takes me
3 weeks. Like I want to be able to be
able to quicker spin up services.
That's not solutions, it's an issue, right?
And then they can figure out, OK, how can we solve that with
the tools that we already have? Gotcha.
What is the best platform you've seen work in an organization
when it comes to I think your example from idea to production?
The best one, yeah, the I think the best one is the one that
will really help developers. So and it's it's very smooth.
So the interface, it can be a nice looking, nice looking
portal. But in this case, it was
actually AC light tool that they used.
And they could basically just create this C light tool, create
a YAML definition, send it to an to an to an API somewhere.
And this would spin up stuff in the Kubernetes cluster so that
they can run their their applications.
And that would be exactly the same as it's locally being done,
as in tests, as in excitation, as in production.
The environments were identical. So the things you were doing
locally, you could spin it up within seconds, would be exactly
the same as production. And I think from a developer
perspective, that is very cool, at least something that you
don't see very often. Yeah, exactly.
The environment and how you reproduce that locally compared
to all the other test and production environments that you
have. Also same with data
availability. If those are not in place
locally or on test and acceptance environments.
I've just been frustrated because you want to go to
production with confidence. You want to say I don't care
that it's Friday. I have the confidence in all the
safety net that we have to be able to do so There should not
be this mantra of it's Friday. We don't release if we have a
really good system that actually enables us to release whenever
we want. So yeah, I definitely get.
That and I think with the CLI tool part, that also brings it
closer to developers, right? They're also in their IDE, they
have the terminal, everything is in one place.
We can do what you want to do without the need to go to
different places and try open tickets with that operations or
whoever know you have everything you need in one place and your
productivity is much higher than going back and forth, right.
So yeah, that that makes. Sense and that's also that's a
very important part as well, right?
Because we are the truth is and most developers don't like to
hear this, but when implementing platform engineering we're kind
of stealing some of your autonomy.
Yeah, because now you don't get to decide how you do things
specifically we lay out this pad for you.
This called a pad like I've not explained before.
And the moment you do that, we need to also give you something
back, right? You cannot just always have to
come to us and be like, hey, can you do this for me or create a
ticket or use Slack. So we need to be able to deliver
all of these capabilities in a self-service manner that can be
can be done through a through a portal or through a CLI
interface, depending on what the developers want, right?
And a good platform engineering team will go to developers and
actually ask like, hey, what do you want?
But we don't see that happening that often.
So again, I would like to encourage developers just to go
to a platform team and say, hey, this is really something that
would help us a lot or this is the pain points that we have.
Yeah, you get that. What does a platform make sense,
right. Because if I start to start up
with you and I and you as well, the three of us start a start
up, we're not going to start with a platform.
I, I would assume. OK.
Thank you. Because that's my assumption.
That's a good, that's a good assumption.
But then at some point, I don't know if it's a scale or amount
of people or amount of applications or maybe even
domain, and some of the complexity that comes with that
defines when a platform does make sense.
I think we, I remember reading somewhere, it's like there's a
number of people, but that's very specific.
So we also need to look in words and see how it is.
I would say whenever you have a team that's growing and you see
that, let's say the productivity or the speed, velocity, whatever
is said the same, that's when you start considering what's
happening, right? So within a start up, you're
like 3-4 people, you work within each other.
There's no need for a platform, right?
When you start scanning a bit more and you see that, OK, we're
getting more productivity, we're getting more features shipped.
Perfect. As soon as you hit that, let's
say stagnation and and velocity, this is where you might consider
a platform and the reason behind it, I guess it's more people are
working on more tooling. There's not a lot of
standardization, which means some people are getting stuck
somewhere or there's this no consistency in in deployment and
then yeah, you have that issues. This is when the platform makes
sense, I would say. How do you then start from that
aspect? So you're saying velocity
stagnates or it even goes down based on just time progressing
and complexity building up? Does one person take ownership
of building a platform? Do you form a group that then
takes ownership or what is the next step?
If you are at that scale, I would say one person would be
enough. Really.
Yes, I would say so. Because then you don't want to
dedicate the whole platform team just yet.
Yeah, You want that one person who is very close to what's
happening with like in terms of the software development life
cycle again and start talking to the developers and understanding
what issues they're running into and then grabbing all of these
issues and stuff and start working towards let's say the
first golden path, right? This is where we want everyone
to follow kind of. And with that, you start having
a couple of people who are like you're evangelists, right?
The people you're going to start with, they are, they are trusted
people in the organization and they would be able to give you
their feedback. Once you create the golden path.
And with time you start obviously scaling that to the
rest of the organization and see how it's performing.
You need to measure it as well, right?
So it's not just creating it and that's it.
You need to measure it. And with the scaling that's
happening to the organization, you start adding more people to
the platform team to be able to support the the developers,
right. So I would say that's how I see
it at this deal. Nice.
Let's put a pin on on measurements because I think
that's interesting, but I want to learn from your perspective,
Yalmer, the people that are, let's say first movers or that
join a platform team, can that be anyone or what capabilities
do they need to have? Can it be a software engineer?
Does it need to be someone else? What have you seen?
That's a good question. I always like that the platform
team is a mix of people that are have been working in social
developments because then you know the pay points, right?
Yeah, you are the users. Yeah, indeed.
Which is kind of the best ideal situation, right?
But in the end, you also need to have the experience of, OK, I'm
not just building a application for end users, but I'm building
a platform that will be used by multiple different teams,
different kinds of requirements. So you also want the experience
of like more, well, system engineerish people.
And I think the combination of combining them together is
really when magic happens, then really the issues that are need
to be solved in companies are being solved and being done in a
matter that's easily repeatable, compliance and secure for an
organization. And again, that's really the
magic for platform engineering. Nice.
But then the looking back into that first mover, can that then
be either a system engineer or software engineer or what would
be your preference? Do you have a?
Preference. No, I don't.
I think it doesn't really matter what kind of skills they have.
I think it's where they will focus on.
I think if you want to become a success with your platform
initiative, it's not something that you should be like, OK,
we're going to build this in two years and then we're going to
release it like it's like horrible, right?
It should really be something like, OK, what is currently the
biggest bottleneck? OK.
And let's just see if we can fix that it.
Can be that simple? It can be that simple.
Platform engineering is this is the discipline of building
internal developer platforms, which sounds very scary, but we
also tried to enable flow within developers.
So just start there, figure out what's your biggest bottleneck,
waiting three weeks for a COP approval.
All right, let's talk to them. How can we improve this?
Is there a COP approval always needed?
Stuff like this is already platform engineering because
we're increasing developer flow, developer experience.
Maybe it's been my like kind of how I view the word platform
engineering. It's not so grand.
But if you're saying it's as simple as removing the biggest
bottleneck and trying to figure that out already means that
you're doing, you're thinking of or your platform engineering in
that way, that makes it a lot more simple, makes it a lot more
digestible. Yeah, yeah, yeah.
Especially if you these days you heard these big tools coming
around like backstage and platform orchestrations and all
very scary things. Golden paths, paved roads is
what I've heard is like the huge paths that are in my head, like
yearly ventures. Yeah, yeah.
It is. It takes like I think like one
of the best one I've seen. I have built it myself.
It took them like 7 years to get to the to the end state where
they currently are where everything is self servers and
done automatically to like a select bolt and stuff which is
incredible. Seven years.
Yeah, seven years. That's the way you start, right?
You start with small things, soften bottlenecks, increasing
flow for developers. Yeah, I was going to say, if
they did nothing and then released the seven years, they
must have had some serious business backing, some serious
belief that this is going to work.
Now they all start small, right? Every year a great story starts.
That's nice. And they need to showcase the,
the progress, right? You cannot say, OK, I'm going to
do this in two years. Then the idea is already done.
No one wants the platform anymore.
They're already past the, the whole problems that they're
they're into. And they're like, we're
frustrated enough. We're not going to wait for two
years. So getting that quick turn
around, trying it with people. I think with the first movers I
had a different also opinion on this.
I think if you are able to find who are, who is the team or the,
the, the people within the organiser are very excited and
are like looking forward to it. Use these people, yeah.
Yeah, use the energy. Go for them, yeah, because they
are the ones that are going to help you the most.
Most. Yeah, all the.
People that complain go fix it now.
Honestly, like that's feedback that's incredible.
Like one of the hardest things is, is getting good feedback
from from developers. How are they actually using the
platform? And developers that are very
angry about stuff within within an organization.
Amazing. Use them if you can onboard them
and make them a supporter. The rest is going to be smooth
sailing. Yeah, yeah.
I feel like the developers are very critical.
And the way for them to keep being critical is to actually do
something with the critique, right?
Make them feel heard and then implement it.
I've also seen companies or organizations or teams where
critique is labeled as negativity and then people kind
of shut down and they're like, well, if I said this, you would
just think I'm, I'm very negative.
You also have the those people that are very grumpy and
everything is just shit. But yeah, I feel like if
critique is very valid, something needs to be done with
it or you need to accommodate for it in some way, right?
We're focusing on this and this is then maybe next or This is
why this is not a concern at all.
So have you thought about XY and Z?
But there needs to be a two way, an equal level of dialogue.
Yeah, we mentioned that one of the success metrics is a
seamless developer experience. How do you measure that?
What does success look like for people that are building that
platform? OK, that's a big sign.
No, no, perfect, perfect. So multiple metrics obviously,
and multiple things you need to look at.
I really like them. So there are a couple of of
metrics that I'll talk about now.
It's first of all, it's the onboarding time.
OK, So I read this summer, I think Spotify did this, can't
remember. It could be.
And they measured the time from the first day you start working
at an organization until your 10th or request.
OK, the 10th, not the first till.
The 10th so they see how how much time it's taking you to be
familiar with your work, be familiar with what's the
landscape around you and how fast can you actually help and
and assisted to collaborate and and provide your value.
And that's why they tend. OK, so that's a really nice
metric. I really like.
I think another one is called service create time.
How much time it takes to create a service goes to production as
I'm not, by the way, correct me if I'm wrong.
So I'm just reciting my head. So that's also a very nice one.
Others could be obviously you can use also the space metrics,
daughter metrics are typical frameworks that you can also
have a nice one which is very small and can help is the NPS
not promoter score. OK.
And that's also to gauge the sentiment towards the platform,
which it's a very lightweight, it's very small form where you
can send it away like every month survey.
And yeah, it's a very small survey, like 3 questions that's
it. And then you can track it over
time, see how people are are feeling about the platform.
And then you can also correlate it with what features you've
released. So then you can have an idea of
am I right, Am I on the right path or not?
Yeah, I think freeze out some stuff.
No, I, I like it. I wish, I wish all companies
would do this. OK, right.
Because I think also the state-of-the-art platform
engineering reports came out and again, like I think it was like
60% of the companies under measuring that platform
engineering success, yes. Interesting, I saw that
yesterday I. Think, yeah, it's still crazy.
Like the number is also not, not not going up or go down.
So they're just basically just doing plus initiatives without
measuring if what they're doing is a success.
You know, plus engineering is all about flow and increasing
productivity, right? That's the promise.
So if we don't have a baseline like how do we know if we're
actually becoming a success with our initiative?
Also don't forget about business metrics, right?
So we talk about all of these things.
These are more platform engineering related to the team
itself. Also want to look at the return
on investment, right? Because you still want the buy
in and you still want the funding and you still want the
backing of the executive and the business.
You also need to check the return on investment for your
platform. How much money are we putting
in? How does that match up to how
much money we're getting out of it?
Right? So one I think measurement I
heard as well is how many developer hours have I saved by
creating this golden path for example.
Cool. Yeah, which is very nice.
But then you also, that's a hard one.
That's a hard one. But you need to measure before
your platform as well. So the idea of measuring is not
just after we're done, it's also before, right?
So before we start, what's happening and the reason behind
that, like memories and organizations are very short
term because if the platform is successful, they're like, oh,
life is amazing now, right? Five months ago we couldn't do
anything, but now everything is perfect.
So you need to also see what was happening before to justify how
good your platform is. Yeah, I feel like like a survey
is the easiest thing for me if I were to be in control, the
lowest hanging fruit that I could do.
The only thing is some people don't like surveys.
But in any case, I feel like if the survey is something we do
something with and people can see results, then that
incentivizes people to give their feedback.
That is 1 The other metrics I feel like are sometimes very
hard, right? There are frameworks for
measuring developer productivity, but they can also
be manipulated, right? If people know how they're
measured, especially on individual level, if it's
actually going to that scale, then people manipulate it,
right? I'm more productive.
Actually. I do many pull requests.
My 10th pull request was on the first day because I just changed
10 read bases. So yeah, I think it's
interesting to look at how metrics operate and then also
how an organization revolves around those metrics.
Now, the companies that don't do any metrics, that for me is very
interesting. And I have no clue how they then
indeed say, OK, this is successful, but it also how they
keep investing. Is investing always a
conversation? Because I feel like if you set
up a team, even if you start from from something, if you
start small, you need to have good backing, right, That this
is actually going to increase productivity.
And if you don't measure that, I don't know what people are
actually doing or how they can do this continuously.
That's a good question. Yeah, yeah, I, I also don't
know, like I think in the beginning you also ask like when
do we start the plus for engineering?
And I think for me, it should always start with measuring that
something's going wrong, like with the increased productivity,
decreased productivity, decreased experience, and then
you start the plus initiative. So the moment that they don't
measure anything and then they try to uphold this story of
being like, oh, we're going to increase productivity and
developers are going to have a bad experience.
It's all just fake because there's no numbers, just fluff.
Yeah, it's just fluff. They just need to believe that
it's it is and how. And then eventually, of course,
they will stop talking to developers and then they will
figure out that, oh, they are just building a platform because
they're like building a platform.
That's also probably why they're not measuring, because they're
not actually helping developers. They're just building and using
cool tools. So I think most of those
companies that are not measuring are probably scared to measure.
A lot of red. Flags.
Yeah, it's definitely a red flag.
Yeah, yeah, yeah. Yeah.
I would I would tell them to go shameless plug or read my blog.
OK, yeah. On the website platform
Engineering Matrix on xavia.com. Go check it out.
Interesting.
When we talked about developer productivity, right, that's the
smallest thing that you can do when you're already doing
platform engineering, it kind of triggered something in me
because nowadays, early 2026, organizations have an opinion on
productivity for software engineers specifically because
of AI tooling, right? If I have an agent that can do
something or I can vibe code something myself, why is it so
slow in my organization or what some leaders think?
And then it's like, yeah, you guys need to be more effective
or we need to modernize and we need to do that more quickly or
we need to save developer time. And people all of a sudden have
an opinion, which I think is very interesting.
I'm curious to hear what you've seen or how you also view that
people having opinions on developer productivity.
Oh. Yeah, I like that.
It's a good one. Yeah.
You know, there's a lot of in the report words coming out that
developers spend most of the time actually not developing.
So let's say it's 2030% of the time actually writing codes,
right? And the rest is just meetings
and getting stuff to production and creating ServiceNow tickets
and stuff like that. So if you then improve the way
in how fast they can write codes, you're only improving the
small increments of their work. It's 2030% if all the rest is
just in getting stuff for production, making progress, all
all all those kind of things. If you really want to improve
the federal productivity, you should not look at you should
also look at them helping AI right, But also how to get stuff
faster into production, how to make sure that we actually get
security on board faster. How these fast flows, these
golden pads, because that's really where most of the ball is
being dropped right now. That's the, yeah, basically the
resistance where the device gets stuck, and if you just improve
it in front of that, it gets stuck more and more and more.
Yeah, I like that a lot actually, that perspective.
Is that also If not. And I wanted to put you on the
spot quickly. Why not?
There's this statistics you always gave about, I think about
AI adoption and how executives look at it versus development.
Yeah, yeah. Because I feel like this is
very. Yeah, yeah, very relevant.
I think it's a new report from IBM and they say that 80% of the
executives see that they need AI to stay ahead of the game from
the competitors. And then 20% of the executives
say that their infrastructure is ready for AI.
So if we want this to work and we want to use AI to stay ahead,
we actually need to first look at our infrastructure and how
we're supplying tools and LLMS and models and APIs to our
developers instead of just looking at the developers being
a go fester with AI because your infrastructure, your platform is
not ready for AI. It's.
It's very revealing the statistic because then there's
this huge disconnect and what you mentioned, like now with the
advent of AI and how executives are looking at it, 2026
executives think this is the current landscape where it's
completely different. There's no connection
whatsoever. Part of it is metrics and what
we talked about. They have no idea what's
happening. They cannot see numbers.
This is what they love, right? They want to see numbers that
are very easily measurable and they can describe something for
them and they don't have that. So that's the disconnect.
I think it's with metrics with more knowledge going up top
about the current state school. And then also platform
engineering, again, having it ready for hosting your LLMS or
hosting your AI workloads, making sure that you're also
using AI within the company in a secure way and it's a compliant
way. Platform engineering also solves
this problem, so. You mentioned the OK, if
engineers are actually 30% doing hands on coding and 70% is
processes or meetings or just somewhere it's clogged
throughout the process. If I then as a platform team
focus on removing those bottlenecks, less meetings, more
focused time, is that also platform engineering?
Good question. I think a part of it, yes, of
course less meetings is not is not really platform engineering,
right. Well, if you're having meetings
about going to production and stuff and that gets automated,
then it's probably is platform engineering.
But I think it's on the the fence of just improving how you
work being being more lean as a as a company and the platform
engineering can also support that a little bit.
Gotcha. Yeah.
It's an extension of what what you're achieving is.
Then an extension of it is maybe less meetings, less processes,
less. Because it could be that all of
us are in a platform engineering team at a client somewhere and
then we see that meetings are actually the issue, right?
So we can build whatever tooling.
But yeah, we're going to optimize also that same 30% or a
little bit more because there's it's not just coding to go into
production. But if meetings are really the
issue, then that's a very interesting bit for me.
And that's kind of organizational behaviour that
needs to change, right. I saw that SML kicked out.
I don't know what the statistic was.
I think it was like 1600 people and almost all of them were
middle managers. And then I talked to some people
that work there and they were like, yeah, one of the reasons I
left was I was just getting dragged in meetings.
And the people that were organizing those meetings, they
didn't really have any influence.
And they were kind of in the middle and they're trying to
manage. But in the end, they just
clocked the system throughout. He said that's the reason I
left. So yeah, I think a lot of people
are going to be a lot more happier, a lot happier in the
end. While also ISML published kind
of record numbers. So it's kind of a disconnect
there. But I thought it was interesting
that is more behaviour and organizational change.
Because also throughout this conversation, I was wondering
why platform engineering is not just called developer
productivity, but all of those meetings and behavioral change
that also influences developer productivity in the end.
So yeah. Yeah, Maybe I'd speak a little
bit because the definition as well, right, Platform sharing is
the discipline of building an internal developer platform.
So that's really the the product and what we are trying to
achieve with the product is developed productivity.
But you can also do developer productivity in other ways
instead of having this centralized platform rights,
because you just look at processes and change that
instead of it would still fall on the platform engineering.
But again, platform engineering is a slippery slope that
everything can fall on the platform engineering these days.
Yeah. But in the end, it's still about
developer productivity, developer experience by having
this internal developer platform available for your developers,
but it doesn't have a start there.
Gotcha. Yeah.
If I then look at platform engineering, do AI tooling, does
that also fall under that? So whether an organization uses
cloud code or you mentioned Replit before the show and also
Microsoft Copilot specifically or GitHub Copilot even, does
that all fall under platform engineering in your perspective?
Yes. Yeah, yeah.
OK. I think it has this place there.
Yeah. So platform, the platform
especially if you have if you have like Kubernetes platform or
something, it's the perfect way for orchestration of
applications, but also large language models or other models
or maybe you need specific GP us to train specific models.
That's all something that the platform can orchestrate for
you. So it's definitely has its place
in order to enable AI within organizations.
Plus especially in the clouds of entity these days you can
actually have something running locally on sites offline ish in
your internal network instead of buying something from open AI or
or cloud for example. And then if you're setting up
your, your landscape in a way which follows our the principles
we talked about. And so your NLMS, your data,
everything related to your organization stays within your,
it's a environment because you are following the secure way of
provisioning infrastructure. It's scalable, it's consistent,
it's the same across from local up into production.
You don't have any fear of let's say having these LMS go outside
of the environment. Everything is compliant.
That's if you still follow that before transfer engineering
software, you build it to run it, and you have developers also
creating infrastructure and there's like 300 tools.
For one thing, you might find it very difficult to kind of clamp
down on what's happening and understand what's running in
your landscape with AI, with data being fed into the anonyms
with all of that. You can see where this is going
to go later on with like data breaches or problems within your
organization or these things we've already seen like people
use ChatGPT online and then upload company data, which is
also a huge problem as well. So if you're following the
principles, if you are providing these golden paths for
developers and you have a very consistent way of provisioning
infrastructure for developers, add on top of it AI.
And that's also very good for you because then it's secure,
it's compliant, and it's within your own environment.
So it's stood for as the principles of building
infrastructure that you already specified in the beginning.
What is your opinion on I love this term shadow IT because we
already mentioned, OK, if the platform is bad, then it's it's
worse than not having a platform at all.
And typically one of the symptoms that I see is that
people just get whatever tune and they don't tell anyone.
It's like very hush hush. And I know what I'm doing.
OK, no personal data, no, no coding.
But but yeah, I have this thing and it makes me more productive.
Yeah, I get it right. And from a platform engineering
perspective, it's it's horrible to to see shadow IT because it's
the side effect of basically having this incompetent
platform, right? I there's something that I
cannot do or you're not providing me the service.
All right, I'm going to my manager and he just puts his
credit card on his new AWS account and well, I have a non
compliant Awsifier, which is of course good for you, horrible
for the company because it's it's not secure, it's not
compliant, it's not regulated. Nobody's checking it.
What happens if this manager leaves?
Will the any of us account just closes?
Yeah, so I I get it. But I would really say to
developers, if you're on the brink of, of doing this, try to
go to the plus regime and be like, hey, I really need you
guys to either change step it up.
Otherwise I will go and do the shadow IT route.
Maybe that will be a wake up call for them.
I'd be like, OK, maybe we should really change something because
they are having actual issues we're not solving and they are
figuring out themselves. Yeah, interesting.
It's also the escape out, as you mentioned, right?
So being able to I'm also also like a huge amount of people
using the platform, but also taking their own path.
That's fine. And the idea here is that there
are still guard raids, of course, but you're also able to
explore your on your path on yourself by yourself, sorry.
And that's within the guard raids.
So we're still secure, we're still compliant given you're not
using the golden path, which is fine, but you also are on your
own path to discover or innovate or have a new idea in mind, but
within the card rates. So you're still within that area
of the platform team. And that's I think also
something that the platform team should be very clear on how
intuitive it is to use the escape patches as well, is that
it's very clear that you can go both ways.
We always prefer Golden Path, yeah, but you also can take your
own path if you need to. I think that a lot because I was
thinking if everyone needs to go to this platform engineering
team, right, Either for the escape hatch or for the golden
path or for new requests or for this is not smooth yet.
Can we fix XY and Z? They might also become a
bottleneck, right? If you get so much feedback,
then your throughput is kind of throttled and you have to shift
through. OK, where's the value and what
do we prioritize? But that also means you need to
manage expectations of the priorities.
You're not going to pick up yet or not going to do at all.
And you have to have kind of an equal level of dialogue and make
people feel heard. Otherwise you'd lose interest
completely. And the bigger our organization
skills, I feel like it is funneling towards this team that
is then responsible for platform engineering.
Have you seen something like that or how do you accommodate
for platform engineering or the team that is responsible not
being a bottleneck? I think you you start first of
all with whatever the platform or the the minimum viable
product is ready for the first team.
You don't announce that to the whole organization.
This is the first thing. It's not all in.
They need to set to the team and they would be, as I mentioned,
the evangelist. They would take you through and
you work very intimately with them, get their older feedback,
all of the bugs they're facing, making sure that the process is
iteratively improved, and then you start scaling slowly across
multiple teams with a full scale like organization.
If the platform is very well adopted, I'm assuming people
will help the platform team to get through a certain bottleneck
when like a lot of things are not happening.
If they are fully invested in the platform, then it comes to
like huge scale. I don't know to be honest.
Like maybe you know, I'm not sure.
I think the best way of making sure that the platform team does
not become a bottleneck is on to everything self-service.
So take it OPS, you should not need to create a ticket for
something standard, right? It should be self-service.
You should go to portal, use CLI, use an API, whatever you
should be able to request yourself.
That's one. Two ways have very good in the
sourcing. So the moment that you need
something, for example, you're very particular on the Ruby for
wheels, for example, you want that to be supported by the
platform. Sure, here's a repo go implement
it. We have an example for Java
Spring Boot or something. You can figure it, you can
figure it out. If you need some help, let us
know, right. Just implement it themselves and
then keep a little bit of control over it.
That's the best case because in that way you can have a platform
that supports build for use cases without having to skill
the platform team increasingly. Yeah, interesting.
That's nice. I was also wondering because
I've been in a lot of small organizations.
So then part of what I actually run in software, I need to be
aware of the environment. I need to be conscious of get
how much load can the team handle?
Do we go serverless? What what trade off do we make
for cost of ownership in the decisions that we make?
And I like those thoughts. And now I'm in bigger
organizations and in bigger organizations, it's kind of
smooth sailing because I don't have to think about that.
But that also kind of takes away from it.
So then looking at my personal skills, if I were to be at a
bigger organization and I don't think of that like that muscle
will kind of atrophy. And I'm wondering what your
perspective is on that because part of the developer ownership,
it's, it's huge, it's way too much on their plate.
I also say that the whole product sense is becoming more
and more important as well. So if you talk about tooling, if
you talk about creating software, if you talk about
knowing your customer, thinking from a business outcome
perspective, it's a lot that falls on the plate.
So I'm good with having some stuff fall away, but I'm, I'm
very aware that the right stuff needs to fall away.
And if I am in a bigger organization where things are
kind of accommodated for? Will I then feel pain or
experience kind of difficulties if I move into a smaller
organization and all of a sudden those responsibilities fall
again into the plate of the developer?
I think that's really the balance between a good and a bad
platform. So in the end if you go back to
before dev OPS, it was really separated by dev and OPS and OPS
would be gatekeeping of rights and and ownership of of servers
running and what kind of skill you need.
Then DevOps, it became completely the something for the
developers to take into account. And then you can say platform
engineering supports developers that you are still responsible.
We just help make it go faster. But you still need to think
about it. So we're not gatekeeping
anything. We're not trying to just trying
to make your life a little bit easier, but it's still on you.
You're still responsible for making sure that the there's the
right skill. And that's all those things
still on you. We just help make your life
easier. That's good, yeah.
What were your thoughts? Yeah, I think, yeah, makes
sense. I'm just trying to think of how
you would go from like a huge organization of just doing one
thing and then back. I can see the pain in it because
then it's a huge organization. Everything is very organised in
a way. There are processes for
everything and then you go back into like a small organiser,
say, OK, how did they used to do this before?
Yeah, that's a kind of a chaos. Might be why you leave.
Though yeah, it could be, definitely.
But yeah, definitely with a good bad platform part.
I think I still believe in the fact that developers should be
able to let go of all of the things that made their cognitive
load really high in the past years and make sure to focus on
writing code, very good quality code.
Yeah. And that's the main thing.
And then if they need to go back to it like a small organizations
where the roles are a bit murky and you need to take more wear
and more hearts, then yeah, I think you just need to exercise
that once again and help with like the platform team or all of
the learnings you had in the bigger organization, how things
are done so. Fair.
Yeah, there might not be a good answer there.
It's just a choice in the end. Yeah, exactly.
Yeah. I really enjoyed picking both of
your brains about platform engineering.
Is there anything that's missing that we haven't discussed yet
that you want to address before you round off?
I'm going to give you both the second.
This is the curveball I always throw, yeah.
I would say at least from my end, the thing that usually is
missing when we're talking about like tech or trends or stuff
like that is we talk a lot about the technicals part, but you
forget the business part a lot, which is like, and then these
are the people that are going to fund your initiative.
These are the people that have the money, these are the
decision makers, and these are the people you need to make
happy so that your initiative keeps going.
So I think that sometimes gets lost, but it's very good to
always focus on that part as well, I would say.
Gotcha. You know, don't lose your your
champions from the business. Side you need the money, yeah.
So yeah, and and don't don't build a cool platform.
The other platform that developers want to use and will
use in the end and for developers, help your platform
team build something that they want that you want to use.
Good stuff. I love it.
Thanks guys. Thank you so much for coming on.
This was a blast. Yeah, no worries.
Thank you. Cool.
We'll round off here. If you're still with us, let me
know in the comments section what you thought of this episode
and we'll see you on the next one.