Hey there,
Platform engineering is still in its phase of competing definitions, and emerging best practices. There is one thing however, that we need to get clear sooner rather than later.
I’ve just returned from Las Vegas where I had several fascinating conversations with fellow Platform Engineers. At this point thank you to our friends at GCP for inviting us and giving Platform Engineering such as stage, you rock!
There were several recurring themes but one stood out to me particularly: lots of folks think Platform Engineering equals Developer Experience. Or even that Developer Experience is at the center of Platform Engineering. Or that developers are the only customers we need to care about. None of that is true. And while this might get you into the room, it will not let you stay there. Platform Engineers are serving, let me be very clear, the organization that pays them - and nobody else. If you are not able to generate a positive return on investment of the platform engineering initiative within the first 12 months of your existence - the initiative does not deserve to survive. It’s really important to say this as firmly as possible because sure, I could sugarcoat this… but reality is often too harsh for a sugar coating.
So let’s get a few things straight: as a platform engineer you don’t have one user group, you have many. Here are the most common ones: application developers, infrastructure and operations, security, product managers, executives. In some situations we might want to get even more granular and distinguish frontend, backend, maybe data-engineers.
Our platform needs to serve all of these users and we have to have them top of mind all the time. This starts with user research. If you just ask your developers you will get an entirely skewed picture. Maybe it doesn’t matter to them that they can just create a ticket or send a Slack if there’s a problem in their deployment. But it absolutely matters to the poor operations person that has to work through 100 tickets that are all more or less the same every day. In other words: what doesn’t matter to the individual can matter to the group a lot!
Don’t get me wrong, DevEx is important. Because if you cannot get your developers to adopt your platform you’re done too. No usage, no volume, no ROI. But so does InfraEx (if that’s a term at all). If your platform is a Backstage setup that creates hundreds of resources every time a developer thinks it makes sense - but the resources have to be picked up by infra teams, these teams will revolt sooner or later.
Chris Stephenson, the clever guy, is often saying: you cannot remove complexity, you can only shift it. Keep that in mind if you design your platforms. Doing A can go at the expense of B and nobody wins.
So, key learning: you have many users, you need to think about their experience holistically and all of them need/want golden paths.
So, while we’re at it there are a ton of interesting events coming up:
- I’ll be chatting with Kelsey Hightower soon around Platform Engineering. Have questions that we should discuss? Just respond to this mail.
- PlatformCon is coming up - are you signed up yet?
- We’ll be in London in two weeks - meet us at AWS Summit London!
- Don’t miss tomorrow's roundtable on How enterprises drive successful platform engineering initiatives
Cheers from Temnitztal
Kaspar
