What is a platform engineering team, and why do we need them?
Definition of ‘platform team’
What is meant by the term ‘platform team’ in a tech company? Let’s step back a bit: Platforms used to mean a complete software development environment and underlying subsystems with a programming language(s), runtime, components, and all associated libraries and services. Windows is a Platform, iOS is one, Android is as well. WordPress and other popular CMS are platforms. In fact, everything that serves as a foundation to build software is a platform. And it is extendable by plug-ins, customizable by configuration, and re-usable in a broad set of use cases.
In the last 10 years with the rise of more and more technology-driven startups, platforms became mainstream and are captured in many books and articles describing team topologies and organizational patterns for tech-driven companies.
Companies started to create their own platforms making it easier to build new features and products for a variety of user segments at scale. The term platform within a company means any core capability that you can build upon. A platform team is responsible for creating and evolving these core capabilities, understanding the needs of their internal customers, and supporting the organization to leverage features that were built to serve one use case by creating abstractions around such features to make these available to many other teams.
In a nutshell, a platform team is a team that creates the foundational layers and core building blocks of a company’s products.
More concretely a platform can be at different levels of granularity:
- Infrastructure that runs your stuff
- Development environment and tools that help write/test/run code
- System architecture/security
- Key technology choices
- Core abstractions (data model, business modeling) API/SDKs
The bigger a company grows the more it will / should invest into creating higher-level building blocks enabling the business to diversify its customers, products, and market segments:
- The Frontend components and design system
- Payment and Checkout
- Messaging (eMails, App Notifications)
- Personalization
- Event tracking
- API Handling etc.
Platforms are business-critical
A platform is the collection of the most important features behind the company’s products.
The quality of platform investments will influence the health of the company’s product offerings and team performance: scalability, speed, quality, flexibility. Platform investments reduce existing organizations’ debts (both technical and architectural) to allow teams to create disruptive features for customers and thus leading to increased innovation and motivation in teams. And there is an aspect that is easy to forget but hard to ignore: Having a cutting-edge platform is probably the most important retention tool for your engineers. Not because it is cool, but productivity and stress-free coding are essential for creating amazing tech products.
Build a platform roadmap
Product engineering organizations invest in 3 buckets: Platform, Features, and Experiments. Platform development enables feature development and feature development enables experimentation. The way you want or need to do experiments informs the way you need to build your features. And the features your users want and the way you need to build these inform your approach to building platform capabilities. The distribution of these investments depends on the product and the maturity of the market.
This feedback loop between investment types is critical: Feature and experiments inform the platform roadmap, and inversely platform provides leverage to build more features/experiments. If this is not balanced well or the loop is broken, teams might end up building things that nobody really needs, adding complexity instead of reducing it. In fact, companies can burn a ton of money with wasted platform work, and the bigger and more complex the company gets the more of a trap it can become. Platform teams need to make sure to really understand each of their client's strategies, the features they build, plan to build, and think about building in a few years.
Whatever the teams do, it needs to be extracted from existing products, features, and experiments. If a feature team builds a new user experience, the platform team should never start with creating a platform because someone else might need this too. But as soon as it is clear that the feature might be a good baseline for other use cases, the platform team can enable this development by extracting a platform out of the feature and delivering it so that other teams can replicate or customize the feature for their specific use case. This requires cultural change: Teams need to adopt domain, or problem ownership instead of tool or system ownership otherwise this assimilate and adapt approach won’t be successful.
If two teams are building a similar or even the same feature, this does not necessarily indicate the need for building a platform capability. Replication and duplication are always better than the wrong abstraction. Speed and value creation beat avoiding redundancies and perfectionism. The ultimate goal is the speed of delivery of customer value. If a platform team can increase either the speed of delivery or enable the company to leverage value creation, it is a good indication that they should feel responsible and add work to their roadmaps. Speed includes how efficient developers can use platform capabilities: If they need to study fragmented documentation for a few days first or need more than half a day for setting up their dev and test environment, something seems to be not right. This is a tax on every new developer that joins the company.
Platforms need to see daylight
The platform supports your most important product features. So you need to capture detailed data about speed, scale, uptime, and everything that informs about the health and performance of the platform itself and the features that are running on it.
Experiments can be built in days and results come in immediately. Features can be built and the success can be seen within a few days or weeks. Agile is all about building features and experiments in short iterations to learn quickly and adapt fast. Platform work in general has longer timelines. But it should not mean that you don’t need to create signals indicating if everything is on the right path. Let platform work see daylight regularly so that you can celebrate progress and learn & adapt along the way. Platform teams should have short iterations and milestones deployed ideally in prod, and only rarely wait for it to ship fully.
Platforms are products
As a platform team, you’re not creating just a system but a product and the customers of that product are the engineers and product managers building features and experiments for your end-users. Everything a platform team creates needs to start with having both the user and internal stakeholders/consumers in mind. This means establishing empathy with internal clients and collaborating with them on the design and implementation of solutions. Platform product managers together with their engineering counterparts need to understand the longer-term strategies of each of their client teams and establish a high level of empathy with their ways of working. This will then be the foundation to create roadmaps and ensure the platform delivers value to the business and enhances the developer experience. Good product management is all about building products that customers love. So, start earning this love by providing a better developer experience for the engineering and product community in your company.
References
https://www.thoughtworks.com/insights/blog/adopting-digital-platform-strategy-iterative-approach
