You are one use case away to start developing your internal platform

Become proactive in a constant ticket inflow by starting small

- X: I’m leading an infrastructure team, and we have the vision of becoming a platform engineering team, but I see multiple challenges. Our engineers do not know our developers pain, our leadership doesn’t support us, and I don’t see it happening. What do you recommend?

- Aleix: Do you use Jira for internal tickets to support teams?

- X: Yes.

- Aleix: They you already have a good starting point for your internal customers needs, AKA developers. Get the top 3 more repeated tickets, and automate that.

- X: But how we do get the buy-in from the leadership to do so?

- Aleix: That’s the neat part, you don’t. You don’t ask for permission, you just do your job taking into account the business needs, the amount of risk you can take, and be ready to ask for forgiveness.

- X: And how do I do for all the developers team to use the platform if I cannot communicate with them?

- Aleix: You also don’t do that. Before starting any platform initiative, you:

1. Identify the top 3 more repeated use cases, they are probably the ones blocking flow the most.

2. You let some people know that you want to to start automating some tickets as self-served, do not mention platform yet

3. Tell them that you’re looking for 2-3 teams to try it out. They will be the early adopters, the ones that will deal with all the bad stuff before the platform has as good user experience.

4. Involve them on the platform definition, make your infrastructure team be part of the conversation. Help them understand the user pains to build the thinest viable platform first with a good DevEx, and extend it later.

5. Release small, gain early adopters, they will be the ones sharing this with other people.

6. Before you realize, you have the first functional internal platform solving the top 3 developers pains/dependencies to you. You will achieve a faster flow of change, and you gained trust and a success case within the organization.

   1. Hopefully, by this time, you have been communicating with leadership, and they started to understand the impact of this approach.

7. At this point, you and the leadership might decide to make official the obvious, the infrastructure team became a platform team. 🎉

This is an adaptation of a real conversation I had at Platmosphere, where I spoke about Team Cognitive Load as a Metric to Measure Platform Impact. You can check the slides here.

First slide of my talk.

Platform Engineering teams are hard, in several aspects.

1. They need to help internal developers to deliver faster with less cognitive load. But who takes care of their cognitive load? 🫂

2. They are hard to fund, and are being challenged constantly if that investment could be better used somewhere else.

3. They are hard to manage to offer a compelling internal platform that solves the internal developer needs, making sure that it has a great DevEx, and they own the platform adoption, and distribution. Avoiding technology for the sake of technology.

But I believe we are falling into a fundamental mistake. We don’t always need to create an Internal Development Platform (IDP) on top of Kubernetes (reinventing AWS Fargate once again) to offer a great Platform Experience that solves our developer needs.

We can start smaller, and focus first on learning our organization, its needs, and the developers’ needs. Yes, I say developers’ needs a lot of times, because we kind of forget from time to time.

We (platform engineers) tend to believe that we know better what they need than themselves, and then we are surprised why nobody use our platform.

When you are in an organization that has an existing infrastructure team, that handles tickets reactively, and you find that all the flow value is slow, you’re considering a platform approach because you know all the benefits. You know it’s a great approach, but going from ticket handling to self-served platform isn’t trivial. Indeed, it is quite painful experience.

Instead, I suggest you to try something else first.

Thinnest-Viable Platform (TVP)

A TVP is a careful balance between keeping the platform small and ensuring that the platform is helping to accelerate and simplify software delivery for teams building on the platform. (p.101, Team Topologies)

Team Topologies shared this concept some time ago, and created a GitHub with a set of examples. You can see it here.

A TVP can be:

• A wiki with a set of guides and templates on how to achieve something.

• A Slack bot that triggers certain scripts.

• A GitHub template with the Terraform that can be configured with a script.

• You name it.

The important aspect is that you start with the use case that will impact the most to your developers, and it is achievable in a reasonable time. You do not want to expend 6-12 months developing something, you want to have a fast feedback loop.

That use case, you can find it via:

• Talking to people.
  The preferred method, but you need to have some product skills to do a good research, and not impose your own view. Partner with your product and design peers to make this process.

• Your ticket system, like Jira/Trello/Linear/GitHub projects.
  Those tickets that repeat a lot, those are the ones that you want to automate.

Meet your customers where they are

Sometimes we want to deploy a new technology, maybe adding a Backstage, or whatever you consider it is good, but we are used to their stuff. And maybe the best area to start offering your platform isn’t a new website but in Jira or Slack.

Potentially you need to configure a Webhook on a certain Jira ticket with a tag, or with a Slack bot with those use cases preconfigured.

Reduce the friction to start using your platform as much as you can. It is better that you adapt to them, than the other way around. You can educate them, as you release new versions in the future.

Be aware of the adoption curve

Reference

The adoption curve is a model that describes how new technologies or ideas spread through a population over time.

The chasm represents a significant gap between the Early Adopters and the Early Majority. It highlights the crucial transition point where many new technologies and products fail.

You cannot start pretending that everyone will use your platform. The only way to do so it is by a top-down decision, and people will find workarounds to keep doing what they did before, not leveraging the potential of the platform, and you losing extremely valuable feedback. A lose-lose for everyone.

Instead, start small. Find 2–3 teams, and 1–2 people within those teams to help you start the platform. Do product platform interviews to them, involve them on the platform design, and help them be early adopters. They will have more tolerance to the initial bad experience of your platform, and they will help you get into an OK state before releasing to other people.

If you do it good enough, those people will become your platform champions, spreading the good of it to others, and creating adoption momentum.

So, when people that are more demanding on the platform experience, they will find a good developer experience already.

Learning about your developers’ needs first, improve your TVP, then you build the Internal Developer Platform (IDP)

Don’t get me wrong, I’m not telling you to not build something on top of Kubernetes. What I’m saying is that you can focus on the thinnest platform first, focus on learning about your developers needs first, and then, from that super important context specific knowledge, build a great IDP.

Maybe, you find yourself with a good enough TVP that doesn’t require you to invest into a complete IDP, saving you a lot of time and effort, and a lot of money to the business.