Platform teams are by design a dependency for many other teams, it is how the organization can leverage implementations of common functionality and tooling.
But dependencies between teams are bad because they slow down the development process. Whenever one team is waiting on another team to be able to finish their work, it adds a delay to the overall delivery timeline. This can lead to missed opportunities, delayed delivery, and reduced overall quality of the project.
Which is why a top priority for a platform team is to focus on minimizing the impact of its products being a dependency. The only way teams can maintain their speed and independence while leveraging platforms is for the platforms to be as frictionless as possible to use.
There are different ways to achieve this, depending on what kind of platform it is and how the teams might use it:
- Service catalog. There can be a general service catalog for all platforms or one for each, whichever makes sense. The service catalog is some kind of interface (either a website, webservice, CLI or some other way to help teams fulfill their needs) that presents everything the platform can do. Any team can use this catalog in an automatic or manual way to use the services of platforms.
- Constant feedback. When teams use a platform for a purpose, their usage generates useful information which should be exposed back to the teams. This can provide important business metrics for the teams or simply information about what impact their usage has on the platform.
- Logging and observability. If everything goes well, then logging and observability is not needed. But we all know that sometimes, things don’t go as planned. In that case, teams using the platform need to be able to investigate (up to some extent) themselves into what happened. Having a platform engineer support every single situation that doesn’t go well is not feasible and it limits their customers independence, which is never good. So every platform should offer as many means as possible for their users to debug themselves what is going wrong.
- Onboarding. Getting started with a platform is a critical point. It could be a manual process that platform teams do in the beginning, to learn as much as possible from their users experience, but this should be at some point automated and part of the service catalog.
- Support. For the times when it is not possible for teams using a platform to help themselves, then the path for them getting help should be the most effective as possible. There should be no confusion where to reach out for help or in what way. This is connected to having clear boundaries for the platform.
- Documentation. As a poor-mans or temporary solution, documentation can help platform users to help themselves, but ideally the platform should be easy to use and self-explanatory and therefore making documentation pointless.
There are many kinds of platforms and many ways to make them be a desired dependency. In these 400 words I am just scratching the surface. The principle to have in mind is clear: minimize the impact of platforms as dependencies for other teams.