How to Set Up a Platform That Effectively Supports Your Development Teams
Matthias Patzak
ex-CTO | Author | AWS | Speaker | Advisor | ex-Scout24 | #noAFD | You can't light a fire without a spark
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
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:
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.
This LinkedIn article was originally published as a post on the AWS Enterprise Strategy blog .
Master Data Expert & Co-Founder
8 个月????
Head Customer Success | Canada Innovation Leader | Public Speaker
1 年Love this blog post. It makes me think of a McKinsey study on what set leaders of cloud adoption apart, the platform and operating model that delivers the developer experience were key differentiators: https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/leaders-and-laggards-in-enterprise-cloud-infrastructure-adoption
Enterprise Strategist at Amazon Web Services // Accelerating enterprise cloud migrations
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." Great insights, Matthias Patzak!
Enterprise Security Strategist at Amazon Web Services
1 年The security advantages of this should not be overlooked; from both efficiency and scaling perspectives. Great article, Matthias Patzak!
We help you build better products faster.
1 年Great article Matthias. Involving the intended users in development is generally a good idea, regardless of the product. For a developer experience platform, I would strongly advocate having future users on the team building that platform. Here are some EBM value metrics that come to my mind in addition to NPS: The time a team saves in delivering a new feature to their users using the platform (time-to-market), and the time a team saves in operating and maintaining their product (ability to innovate).