Revolutionizing Developer Experience: Key Insights from a Successful Platform Team

Setting up a platform team to provide an excellent developer experience for other development teams can be challenging. In this article, I will share my experience and opinions based on my work in the Developer Experience Team at BRYTER.

We realized that crucial cross-team topics were being overlooked, such as CI pipelines, shared services, and dependency updates. However, we encountered challenges in determining what to work on first and how not to take on too much responsibility.

Through numerous iterations and learnings from resources like the Team Topologies book by Matthew Skelton and Manuel Pais, we have come to understand how to provide the most value for our company.

In this article, I will share some of the most important learnings I have gained over the past years, including avoiding doing work for other teams, not being the police, and keeping the platform small.

These insights can help you create an effective platform team that prioritizes developer experience and productivity.

This article is an updated version of the article "A platform team for next-level developer experience ", first published on the #UnblockedEngineering blog in February 2022.

Do not do the work for other teams?

This might sound surprising, but hear me out!

One of the most significant pitfalls is doing work for other teams. It is tempting to help other teams in a way that the platform team is doing services for other teams. If a team might need a change on their CI pipeline, just do it for them. Right? Wrong!

As a platform team, one of the highest goals is to get out of the way of other units. Instead of doing work for them, you should enable them to do their work themselves. And ideally, you make it as easy as possible. Instead of writing their pipeline descriptions for CI pipelines, you provide base job configurations for typical jobs so that they can extend those without reinventing the wheel.

Whenever you find yourself in a situation where you need to work for other teams, think about ways to enable the teams to do the job. It might sound like you are offloading work, but in reality, you help them own their product end-to-end.

Doing work for others makes them dependent on you and thus goes against the goal of enabling others.

Do not contribute to features?

As a platform team for developer experience, your highest goal is to provide an excellent, well, developer experience. This means: increasing developer productivity and helping developers to enjoy their work more. Find their most significant pain points and the areas where they waste most of their time and provide better solutions for those.

However,?platform?sounds like you would provide the essential services that other teams need. Mail services, blob storages, virus scanners, you name it. Suddenly, almost every fundamental part of some feature is a platform concern – A mistake I made at the beginning.

This leads to the attempt to satisfy two very different customer groups. On the one hand, you have the developers. On the other hand, you have external customers and try to provide essential parts of features that other teams will finish.

The latter is exceptionally unrewarding and puts the platform team under constant pressure to implement features. This leaves little to no time for the actual mission: developer experience.

Developers as your customers?

In such a platform team, you are not targeting external customers but your colleagues. You try to understand their needs, pain points, and what slows them down.

You will try to find solutions that bring the most value to many of them. Not only that, but you apply fundamental product management practices. You try to do the smallest thing possible to improve the developer experience and work in small increments. Ship often. Listen to developer feedback.

Furthermore, you shall not force teams to use your?product.

Do not be the police?

When building some fantastic tool or platform component that helps developers, it is tempting to force them to use it or to tell them how they need to do their job. There is a better approach.

A product company cannot force its customers to use its product and the features they build. It is the same with a platform team and developers.

You can provide a good set of linter rules and recommend a test framework. However, teams need to be free to choose something else instead. Only they know what helps them most. You can offer a solution, but teams can decide not to use it, knowing that you might not support them if they pick?another provider.

Furthermore, if you find that most teams are not using your solution, you need to ask yourself if you are building the right platform.

But also wait to jump to the conclusion of building the wrong platform too quickly.

Platform adoption is slow?

It will take much time (and marketing) until other teams adopt your solution. Whenever you ship a new tool or platform feature, only the most curious teams will jump on it right away. Others might take weeks or months until they are ready to use it.

Moreover, as a platform team, you usually do not have the luxury of having a dedicated marketing and sales team. You need to?sell?your solution yourself. Show developers the benefits of your solution and how to use it. Help them, i.e., in team programmings, to apply it to their use case.

Keep the platform small?

It is tempting to build over-engineered solutions with all kinds of bells and whistles. But as for any other product, the same is true for a platform: Build the smallest thing that could work. Of course, you could build a generator that automatically generates CI pipelines for other teams, depending on their requirements. But is documentation on how to define pipelines together with some sensible base jobs already enough?

Please do not underestimate the maintenance costs that complicated solutions will bring with them.

Where to go from here??

There is much more to share about developer experience. It is an exciting topic, as you have the privilege to work closely with your customers. Therefore, it can be super-rewarding as you see your impact directly. From my experience, it takes some time to see the positive effects, but the benefits are growing exponentially.

Initially, our team was called "Platform and Developer Experience". We renamed it later on to "Developer Experience". We learned that in our context, the "Platform" in the name is more confusing than helping. Furthermore, good developer experience needs both good tools and a good platform, and these two areas go hand-in-hand.

Summary?

At a specific company size, a platform team focussing on developer experience can have a substantial positive impact. When you have four or more teams with a very similar tech stack, shared UI components, or infrastructure, a platform team can leverage synergies, reduce cognitive load for these teams and help them to focus on creating customer value.

Such a platform team should…

• … not do work for teams but make their work easier and enable them.
• … see developer as their customers and the platform as a product.
• … therefore not act as police and not force teams to use their solutions.
• … not get caught up in feature development for external customers.
• … keep the platform small and most importantly,
• … be patient. Platform adoption takes time.

Do you have platform teams in your company? What are your experiences? Let me know here in the comments!

Are you looking to kickstart your platform team and significantly improve your developer experience? — Hire my team and me to quickly bring you up to speed and establish a highly effective platform team in your company in no time! — Write me a message, and I will share more details!