How to Set Up a Platform That Effectively Supports Your Development Teams

Many of my conversations with AWS customers are about their attempts to build developer experience platforms that simplify software development and operations, automate deployments, improve software quality, reduce costs, and ensure security and compliance.

Unfortunately, not all platforms live up to their expectations. The most frequently cited problem is development teams rejecting the platform that is supposed to support them. Other problems include a lack of collaboration between the platform teams and the development teams and complex platform requirements.

In this blog post, I will give you an overview of how you can set up a platform to effectively support your development teams.

The Purpose of Platforms

The main purpose of IT platforms is to provide delivery teams with simple, efficient, and stress-free toolchains to build and run software so that they can focus on solving business problems faster.

A platform team is an enabling organizational unit

1. that provides tooling-as-a-service to other IT teams, mostly software and data engineering teams;
2. that helps to onboard, support, and advise these teams on the platform’s tools and services;
3. that facilitates alignment between the users of the platform on the scope, roadmap, and priority of the platform’s tools and services; and
4. that is accountable for ensuring product development teams adhere to defined global guidelines regarding security, compliance, and financial aspects

Platform Scope

Developer experience platforms can offer a wide range of tools and services designed to support the development and operations of transactional and analytical applications. Typical products include tools and services for software development and testing, CI/CD pipelines, monitoring and logging, containerization and orchestration, service and data discovery, analytics, security, collaboration, and billing and backup services. In some organizations, platforms provide hosting services for deploying and running applications.

Platform Size

As a rule of thumb, 10% to 20% of a company’s product development should consist of platforms. This may vary over time and depends on the scope of the platform. Resources may be greater at the beginning of platform development and scaled down as the functionality becomes sufficient and the platform scope experiences fewer changes.

Characteristics of a Platform Team

Platform teams are product teams for internally used products. They are small, diverse, cross-functional, and self-organizing. They include every role required to design, build, and operate platform products. Effective teams include 6–10 people, with some leeway. The roles required depend on your organization’s current operating model and maturity. Typical roles include product owners, software developers, and sometimes quality assurance (QA) engineers and IT administrators.

Platform product owners should understand the socio-technical domain of developer tooling (probably as former users of the platform’s products) and have ideation, communication, facilitation, and delivery management skills. Organizations sometimes underestimate the role of the product owner—this is a mistake. The product owner plays a key role in the success of a platform. Successful platform teams work backward from user needs.

It is important to have team members with both operational and development backgrounds. Developers should be able to work across the technology stack of their team’s responsibility with expertise in a specific area (these are called T- or V-shaped developers).

In some organizations, developers are also responsible for testing their products. Other organizations add the role of a dedicated QA engineer, a software developer focused on test automation. I recommend empowering and training developers to quality assure their own products. The fewer roles there are on a team, the more flexible and effective it is. If the QA engineer is a dedicated role, they should be part of the platform team instead of a separate QA team. This allows them to take responsibility for a specific part of the platform over an extended period and run their services independently.

How Do You Know If Your Platform Is Good?

It is difficult to measure whether a platform is achieving its goal, which makes it important to gather the right data and anecdotes. A good indicator is the net promoter score (NPS), a metric based on asking platform users if they would recommend the service to a new member.

Another indicator is the adoption rate of nonmandatory services in delivery teams. These two metrics are general indicators, but you can get very specific metrics about a new version of a platform service by deploying it in an A/B test. In this method, some delivery teams use the new service while a control group doesn’t. You can measure and compare certain capabilities like cycle time, throughput, release frequency, or duration for both groups.

How to Get Platform Adopted

I have successfully used three strategies to overcome problems in getting platform services adopted:

1. Involve product team representatives in making decisions for the platform’s development—but don’t treat them as just a sounding board; grant them decision authority regarding the scope and prioritization of the platform’s products.
2. Rotate engineers between the user teams and platform teams. This way, the engineers who will use the platform are actively involved in building it and can ensure that it is designed to meet their needs. Conversely, the platform engineers have to eat their own dog food while working on the consuming engineering teams. A reasonable rotation length is a few weeks but no longer than a quarter.
3. Avoid speculative design and gold plating at all costs. Don’t generalize too soon. Only build a product when other consuming teams have committed to using it. It is even better to prototype platform products for a single team (perhaps with additional capacity from the platform teams) to learn and use in one context. Only move the product to platform ownership and generalize it when two other teams commit to using it.

Conclusion

Platforms are an important part of larger product development organizations. Among other benefits, they can implement centralized and automated that policies improve your compliance and security. When set up correctly, they can improve the quality, cycle time, throughput, and motivation of your delivery teams. The principles I’ve given here should help you get the most of your platform and the team that creates and manages it.

What are your experiences with developer experience platforms? I would be interested in hearing about some of them.