Get a unique snapshot view of platform engineering today

If you — like me — are involved in platform engineering, we need to pick your brain. There are a few preconceived notions out there that I want to validate with you. 

With your help, and the help of many other data folk out there, we can get a better view of what people think, and companies do. We get a useful benchmark or snapshot about platform engineering today.

I have a survey where I quickly want to test four hypotheses. I know: “Another survey!?”. Yes, but this one you can learn a lot from — and it takes less than 5 minutes.. 

The four hypotheses are as follows: 

• Most Internal Developer Platforms are built on top of Kubernetes and Cloud Native

• The perceived benefits of a platform differ compared to who we ask

• Platform failures have two distinct patterns

• Platform teams struggle with breadth vs. depth

Let us find out how true they are. This is what you can do:

1. Read more about the hypotheses below

2. Think about what your experience tells you

3. Take the quick survey

4. Find out if the hypotheses are true when we share what the platform engineering community says  

When you are ready, here is the link to the survey. Why not do it right away, so you don’t forget? The survey closes on Friday, October 14 2022, so: 

Take the survey now

Why we are doing this

I’m currently helping TV 2 Denmark and their newly created platform team build an internal developer platform. Martin, Staff Engineer on the team, and I discussed how we could get the best possible head start. 

We asked ourselves: “How have others done this, and what can we learn from them?”

So we have talked with peers in organizations further ahead on their platform journey. We went to conferences like KubeCon and PlatformCon for inspiration and networking. We have read an enormous amount of blog posts, experience reports, etc.

From the ton of great information and guidance we received, I managed to build the below four hypotheses. Now we just need to validate them. For that, we need data from many people across different organizations. 

For that, we need you!

Let’s together find out if the hypotheses are true. You will, of course, find out what the results are through various forms of content that I will produce and share. 

Ready? These are the hypotheses:

Hypothesis 1: The majority of Internal Developer Platforms are built on top of Kubernetes and Cloud Native

Does anyone build their IDPs on anything but Kubernetes? It would be unthinkable to many, but let’s find out if they are out there.

How many are there, and what are their characteristics? Are they among Big Tech, with enough resources to build something tailored to their specific needs? In other organizations, is Kubernetes maybe seen as too big of a beast, so they prefer to custom-build something for a specific use case? Or maybe unicorns and startups just consider Serverless = Platformless.

Although the survey may not be able to answer these specific questions, with enough data, maybe we can connect satisfaction with organizational size, and platform team capacity with the presence of, for example, Kubernetes.

It’s also interesting to see if there are more organizations that use Kubernetes to abstract away multi-cloud and hybrid environments than those building on top of a single infrastructure provider (e.g., AWS or on-premise).

And to elaborate: 

• Is Kubernetes really a vital part to get the traits of a good platform, such as increased self-service, productivity, and happiness?
• Is Kubernetes adoption dependent on the infrastructural foundation?

Hypothesis 2: The perceived benefits of a platform depends on who we ask

If you are on a platform team, it’s natural to think that the platform will have a positive all-around impact on delivery teams. But you are a little biased.

Developers on delivery teams may not be as satisfied with the level of self-service or the support and documentation provided by the platform team. Or they experience that the platform team solves all the wrong problems.

I know it’s not a revolutionary hypothesis. But still: How many teams actively reach out and ask their users frequently whether they are happy with the platform and if it is solving their problems?

We’re also asking those considering building an internal developer platform about their prospects. We want to compare their expectations with the satisfaction level of those who already have one.

Hypothesis 3: Platform failures have two distinct patterns

In an ideal scenario:

The platform team continuously seeks to understand their developers’ needs and pains. The team builds a minimal viable platform from the start. And the platform is treated as a product by the team, its consumers, and sponsors. The team works relentlessly to satisfy the developer and is not afraid to pivot when needed. 

The developers see themselves as customers of the platform, provide feedback, and express their goals. 

The sponsors fund the platform based on the value it provides for the teams. 

Let’s just call this ideal scenario “The pivoting product”.

But things are rarely ideal in life. So in this hypothesis we look at two common failure modes — when the platform doesn’t meet expectations. We call them the “legacy trap” and the “false starts”.

The legacy trap

The entire organization has high expectations of the platform, and the initial level of satisfaction reflects this. But, once the hype is over, the platform team struggles to provide a platform that meets these expectations.

There are many explanations here. Perhaps the domain is too large or complex for a single team to cover. Maybe team members are still swamped with support on legacy systems they’re still responsible for.

They never get to build anything resembling a platform, so satisfaction steadily drops over time, both externally and within the platform team.

The false starts

Here we see anti-patterns like platform as a project, with temporary platform teams with part-time members. They can only focus on the short-term, solving ad-hoc local problems or problems that are theirs alone.

In this scenario, initial expectations of the platform are low and only decrease until it eventually gets sunsetted.

To build a platform engineering organization, you need buy-in from upper management. Without active support from the higher-ups, there’s a high risk of uncertainty avoidance and half-hearted false investments. 

So, our principle of treating the platform as a product is not solely about how the platform team interacts with its customers. We’re also addressing the funding model of the platform. It should be funded as a product based on the value it provides, not as a project.

Hypothesis 4: Platform teams struggle with breadth vs. depth

Platform teams should support delivery teams’ capability to build, ship, and run their applications. But in a way that doesn’t remove delivery teams’ ultimate responsibility for their software in terms of, for example, reliability and performance.

But where should the platform team start? Can one team provide good solutions in all of the categories above? And if you cover them all, what do you need to sacrifice in terms of depth or lack of capacity?

This is why we in the survey ask: “To which degree does the platform help delivery teams build, ship, and run their applications?”.