In November, I co-presented a talk on Scaling Babylon's Workflow platform. While you can watch the recording in the link above to understand how we transitioned and what adjustments we made on our path to becoming a platform team, I want to focus this post on the key reasons you should consider a similar journey.
What is a Platform as a Product?
"Platform" is an often abused term in technology. If you quickly google it, you will find: "A platform is a group of technologies that are used as a base upon which other applications, processes or technologies are developed". For example, when we started Now TV, a single platform team provided APIs to all different client-facing teams (iOS, Android, Web, Xbox, Roku...). When I worked at NewsUK, the Digital Platform department provided services to the different brands operated by NewsUK. However, at times platform teams don't perceive what they do as a product but as the backend of a client-facing product, and they don't perceive other teams as their customers. In every place I worked that had this misconception, the platform DX was poor and ultimately was causing slow progress and less value delivered.
In 2018 I started consulting at NewsUK Digital Platform Department after working closely with customer-facing teams for a long time. The differences compared to a customer-facing team were quite substantials but the one that concerned me the most was the lack of feedback loop that measured how their work impacted "client" teams.
With the other leaders, we started including product techniques and treating the API we were building as a product. Back then, the idea was interesting but a bit unconventional. Fortunately, a lot has happened since then and, especially thanks to Matthew Skelton and Manuel Pais (and their book, Team Topologies), some of the concepts we introduced at NewsUK now are common practices in the industry.
Back to the original question, a Platform as a Product is, as the name entails, an approach that treats the teams using the platform as your customers. An even better definition is "a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced co-ordination." (Evan Bottcher). This simple change in perspective entails that the way you measure success and figure out what to build next has to adapt. I'll go into the details of those two aspects in future posts, but you can hear more about it in my talk on Scaling Babylon's Workflow platform.
Why does a Platform help when your organisation scale?
In the presentation linked above, I mention that the need to transform our team into a Platform team was driven by working in a fast-growing organisation (like Babylon) where finding solutions that double team capacity tend to be short-lived. I think this is oversimplistic.
In truth, we could have held a bit longer without structuring ourselves as a platform team if that was the only reason:
- we could have made the team bigger. At the time, there were only three engineers, so certainly we could have increased team capacity as a first step;
- we could have further scaled by having multiple teams working on the same codebases, with each team taking care of different subdomains
- or, as mentioned in the talk, we could have allowed the delivery teams to make changes in a shared codebase and have our team orchestrate releases (inner-sourcing)
We felt all the above approaches were suboptimal because none of them allowed delivery teams to release their changes independently. This point is quite important because one of the main drags to delivering value when you have a product built by multiple teams is dependencies between them. While a lot can be done to "manage" those dependencies ideally, you want to remove them and enable teams to self-serve.
To summarise, if your organisation is growing is key to keep an eye on:
- Dependencies between teams and how those affect the delivery of value to the end customer
- Consider organisational changes that are NOT ONLY marginally better than the previous one
- Pay close attention to the DX of the services and tools that you are building in-house for other teams to use
Building a Product as a Platform team is expensive, and it makes sense only at a particular stage of your product and organisation. However, not building a platform at the right time and in the right way will be way more expensive because it will slow down your overall organisation.
Watch this space for additional content on the journey to build an effective platform team.