Create synergy in platform teams!

Kevin van Ingen
5 min readJul 2, 2021

Platform teams are commonly created to provide a single place for fixing common problems. An example could be: linking your cloud’s account to the organization’s single-sign-on environment. This solution creates efficiency, you will not spend money on the same task over and over again. In many companies, this is a common rationale behind funding a platform team. It’s really easy to get a business case together for this efficiency. However, we want to stress that we need to go the extra mile to not only move work to platform teams but create more synergy using platform teams.

A brief history of the rise of platform teams

To understand where we are today, we need to look at where we came from. Whether you are following agile methodologies like Scrum or SAFe, ITIL Service management, or you have an SRE way of working, all of these methods promote a team being composed of multiple disciplines. The ability to be able to deliver value as a team independently from other IT teams and the business is a crucial pillar. These same methodologies also aim at reasonably small teams (mostly smaller than ten persons). The combination of a small team with having multiple disciplines is that you will still end up with a desire for broadly skilled individuals. A team needs detailed knowledge of compilers, garbage collectors, serialization, transactions, the latest NPM packages, HTTP2, certificates, tracking cookies, GDPR legislation, state management in component-based frontends, pen-testing, and…… how to run a high-available Kafka cluster. :) It’s just a lot to fit in a handful of minds.

One way to deal with this is to hire the best of the best. However, this does not scale very well. Sometimes it can also feel like your organization is being taken hostage by your best and brightest engineers.

The other way to deal with this is to create platform teams. Teams that specialize in parts of your technology stack to serve other teams. This approach has gotten a lot of traction over the years. These platform teams have created efficiency! However, we would like to inspire platform teams and organizational leaders to look beyond efficiency to a new goal: synergy.

Create synergy in platform teams!

The basic concept of a platform team where core components are being built and delivered to feature teams is solid. However, far too often we noticed that the consumers of these components are still bothered with the details of these components.

Let’s consider an example. A platform team has been tasked to create a secure transport layer into the company’s cloud. Therefore they acquired an enterprise-grade firewall license and are building a web proxy service. After implementation, all incoming and outgoing traffic is supposed to be routed through this proxy. A common approach recognizable for a lot of us working in an enterprise-grade environment. We can observe that it is great that the platform team is taking care of the acquisition and implementation of this platform. That ticks the box for efficiency. However, now the application teams need to be aware that there is a layer of networking surrounding their application. They will have the burden of e.g. understanding the network consequences to them and the added configuration. There probably is a process in place to ask for a route/path to the outside world which they need to take. The observation here is that by solving a non-functional for many feature teams, we are also creating a burden for them. While this is one of the more complicated scenarios and one could argue that this situation involves inherent complexity, my argument would be that we should always strive to create the least amount of cognitive load for implementing teams for our services. This is not a new concept. We came across it in multiple DevOps conferences, and it’s also very well articulated in the book ‘Team Topologies’ by Skelton and Pais.

The reality is that it is more easily said than done. With an infinite backlog and scarce resources platform teams are under a lot of pressure to ‘get stuff out there’. So when facing a team’s service catalogue we can ask some important questions:

Does the implementing team need to go through training, video, or pages of documentation, and if so, how can we avoid that?

Does implementing this service require a one-time effort, or does using this service cause some amount of cognitive load, every day? Feature teams should experience the smallest amount of cognitive load from technology and platforms, freeing them from implementing important business value. For one-time efforts, a special exception can be made. Services that make every move of a feature team more difficult should be redesigned as soon as possible.

Freeing a team of mental burden

Let’s consider this example of a platform team: DevOpsAreUs. The platform team wanted to take the burden of secure practices away from the feature teams. Therefore the feature team has now no way of logging in to a production cloud environment. While securing the production environment sounds like a favor to the team, we make their life very difficult. If a team would be able to log in, it’s way easier to create a mental model of the environment than only based on a logging and monitoring solution. In times of trouble, there is an additional load placed on the team. Additionally, now the team is thinking about ways to navigate potential problems in every feature they are picking up, logging more than they should, just for when it might be needed. So a feature’s team’s everyday work is made more complicated as well.

To get this into the heart of our development practice we would propose an acceptance criterium for platform teams: ‘this feature should free up capacity in feature teams’.

Evaluating your platform team’s service level

So next time you are doing a retrospective with your feature team, ask yourself the question: ‘does interfacing with the platform team take a burden of complexity on our team’. The same question can be reversed if you are on the platform team yourself. Frequently evaluating your offered services is a key action to deliver high-quality services.

For more information about this subject, the symptoms, and the remedies click here.

--

--

Kevin van Ingen

Software delivery, DDD, Serverless and cloud-native enthousiast