How to Build a Platform Team
by James Burns
Platform teams accelerate the speed of a business by making it easier for developers to release more features with less risk.
They do this by enabling developers to reason about their code in production, by reducing the burden to do common development tasks, and letting developers start new projects or change projects faster. Every investment in platform is an investment in making the rest of the development organization more efficient and effective.
But how do you get started building a platform team? Unsurprisingly they do not spring into being fully formed. It’s an incremental process that requires clarity of vision and objectives at all stages.
The Four Stages of Platform Teams: Seed, Growth, Adoption, and Mature.
The seed members of the platform team should be:
- Deeply Curious
- Ruthlessly Realistic
- Highly Empathetic
Often there are some developers who are just more curious about how things really work. They look more deeply at problems in production or in development environments. They figure things out and share them with their coworkers. This quality is critical to seed stage platform teams because initial adoption of a new platform is very much about generating excitement.
Software that ships is better than software that never ships. When starting to build a platform it’s necessary to be ruthlessly realistic. Yes, there are a hundred things you would like to do… eventually. What’s important is getting traction, finding the most important, the most impactful thing, with the resources you have right now and doing just that.
Of all of these though, the most important is empathy. Without that, platform teams can only build things to satisfy their own curiosity, not the needs of the developers they are empowering.
Ideally you’ll find at least one member of your new platform team from your current developers. Why? Because knowing exactly what challenges developers currently face by having faced them repeatedly is the best way to jump start empathy.
Some advice on how to vet platform candidates: When talking to candidates be cautious about people who talk about wanting to do it the right way this time. If they have specific ideas, vet them with others you trust. It’s far too easy to hire someone who, while experienced, has already decided to make all the opposite mistakes of where they were last, instead of listening and understanding the needs of your business. The technology of building an effective platform is rapidly becoming boring. The hard work is evolving the development process and the platform’s use of technology in parallel to accelerate the business.
Above all else, the goals of a seed stage platform need to be realistic. Why? Because it’s all too easy to overpromise and underdeliver, especially at the beginning of a project.
At this early stage, the most effective way to promote the platform team internally is through word of mouth, and sacrificing a positive experience by taking on too much scope will stamp out any possibility of this happening.
As for specific goals, a seed stage platform team should be to make a particular part of the developer experience should become much easier. That might be:
- Creating a New Service
- Deploying a Service in Production
- CI Completion Times
- Standardized observability
This easier experience will likely take away choices. For every choice that’s taken away, it needs to be clear to the developer how the change helps them focus on doing their work faster, and reduces the frustration when working with others who have made opposite choices in their project.
In the growth stage, the platform team moves from 1 to 3 people to 5 – 7 people. In seed stage, one person may be engineering manager, product manager, and team lead. In growth stage hiring someone to be specific product-focused often makes sense. While everyone needs to maintain empathy with the developer experience, having everyone in every meeting with every team becomes infeasible. Hiring engineers from a wider range of experience levels becomes easier. The fundamental characteristics necessary don’t change, but more often the work being done happens in a software development process. Engineers hired during this stage need to still be comfortable with changes in direction, even substantial ones.
Growth stage should lead to a platform that solves a critical developer workflow completely. This means business critical software is using it and seeing increased velocity and reduced incident impact. This is going to be hard. Often there are reasons why the problem wasn’t already solved by the developers working on it before. The focus continues to be making tradeoffs that simply workflows while increasing comprehensibility and operability.
The dangers at this point are many. In some cases there is pressure to turn this team into an operations team: they speed up developers but by doing the work for them, not through software. In other cases victory can be declared prematurely. If one part of the process has become substantially better it becomes easier to ignore software deployment issues or dependency update issues, or that even if all the new projects are, all the business critical software still isn’t using the platform.
Driving toward widespread adoption across the business, hiring increases substantially. At this stage, the value of the platform has been proven for a business critical system but now more investment is needed to smooth out the rough edges, bring more bespoke systems onto the platform, and make it even safer to develop and deploy quickly.
Often the platform team will become a group made up of 2 – 3 teams. Teams will focus on different parts of the development process or different types of development. A second product manager will be needed, as will dedicated engineering managers. It is critical to continue hiring for developer empathy, even though most work is regular software development. There are hundreds of development decisions a week that need to be informed by the developers’ needs without having to ask product management every time.
More than 90% of business critical software should be using the platform without any formal mandate at the end of the adoption stage. And all new projects should be done using the platform as well.
The benefits of enabling developers to switch projects and quickly be effective (or to write new services to replace old ones) is well known and understood. Even though the complexity of the business’ services have expanded, developers should have increased confidence in their ability to understand the behavior of software in production.
In the mature platform stage, hiring is driven primarily by business needs. 1 – 3 more teams will usually be added in the next couple years. Additional product management, architects, and directors are hired. New lines of business or new types of development workflows are recognized to need new platform development and support. Successful candidates to join the team will likely be excited about building products that have both technical challenges and clear business impact. They will still be motivated by making their coworkers lives easier. Regular conference talks about challenges overcome, scale seen, and velocity achieved help feed the hiring pipeline.
Methods for deploying software safely become more sophisticated with automated canaries, automated canary analysis, automated rollbacks. Shared software for observable applications includes standard instrumentation for third party dependencies like cloud APIs or cloud data stores. Developers routinely report that they feel they have a tight feedback loop for their software, and for their requests and questions to the platform group.
Building a platform team isn’t an exercise in magic or in spending piles of money for questionable results, it’s a process for iteratively building business value through investment. Platform teams enable developers to work more quickly and efficiently, but only when they’re closely aligned with and feel empathy for developers.
You can begin your platform journey today. Start having conversations with the deeply curious, with the ruthlessly realistic, with the highly empathy developers on your team now. Then make the decision to start empowering all your developers.