Platform Teams with Ganesh Srinivasan, Chief Product & Engineering Officer at Confluent
Getting the timing of platform teams right, funding them, and the platform team mindset.
👋 Hi, this is Gergely with a 🔒 subscriber-only issue 🔒 of the Pragmatic Engineer Newsletter. In every issue, I cover challenges at Big Tech and startups through the lens of engineering managers and senior engineers.
I don’t think anyone has platform teams fully figured out. We know they are especially important when scaling up fast-growing organizations, and they are key building blocks for all large tech companies. But how do you decide when to start your first platform team? How do you convince the C-level decision-makers to fund these? And what percentage of your engineers do you allocate to platform efforts?
I sat down with Ganesh Srinivasan, someone who has built several platform organizations, and has tackled all of these questions. We talked about:
About Ganesh
What are platform teams?
Platform teams coming into play
The timing of putting platform teams in place
Stages of growth and platform teams
Getting support from the business
The percentage of investment in platform teams
The platform team mindset
Platform leaders: hire externally or lean on internal expertise?
The recurring challenge with platform teams
Related to this issue is the one with Adam Rogal, Dir. Developer Platform at DoorDash on developer productivity. Adam who eventually took over the Mobile Platform team at Uber from Ganesh.
1. About Ganesh
Ganesh managed the mobile engineering group at LinkedIn and has been VP of Engineering at Uber, building up the mobile platform organizations from scratch, among other achievements. He is currently Chief Product & Engineering Officer at Confluent, building an event-streaming platform that handles real-time data at a massive scale.
The first time we met, both of us worked at Uber. I had recently joined the Payments team, and we were in the middle of rewriting Uber’s rider app. Ganesh and his team were heading up this effort, with several platform teams in this organization heavily involved.
As part of the rewrite, the Mobile Platform team built a RIBs mobile architecture that all teams utilized when rewriting the app, and which Uber later open-sourced. The mobile CI and CD teams were working furiously on improving build performance and CI output, while having close to 200 mobile engineers committing code multiple times a day, to the same monorepo.
2. What are platform teams?
Platform teams are the building blocks that product teams use to ship business-facing functionality. Products are built on top of platforms, which platforms enable product teams to move faster. Platforms teams share the following characteristics:
Focused on a technical mission. Platforms are focused on technical goals like scaling a key area, achieving performance or availability goals, or building an easy to extend and maintain architecture that serves multiple teams and areas.
Customers are usually internal engineering teams. Most customers for a platform team are engineers of other product teams or, in rare cases, people from the business side also using the platform.
Consumed by multiple verticals. Each platform typically has multiple customers - products or other platforms.
Read more on how platform teams differ from product teams in this article.
Now on to the discussion with Ganesh. For the rest of the article, my questions are in italic font, and the answers from Ganesh are with normal font.
3. Platform teams coming into play
What is the point in a company’s growth at which platforms come into play?
Platforms become important when you reach a certain “breaking point” with the number of engineers relative to the codebase. This ratio depends on the platform – native mobile, web, backend and so on – the maturity of the platform, and the complexity of the codebase.
At Uber, this bottleneck came when the mobile team got to about five engineers in 2014. There was an engineer who used to review every single code change, keeping the quality high, and they were the one person who kept the full architecture in their head. The build system ran on another engineer’s laptop, and this all worked fine at the time.
However, we knew this setup would not scale as we kept growing. With 40-50 mobile engineers we needed a different approach. The same pattern of the “breaking point” repeats itself in all organizations. At LinkedIn, I saw a similar thing happen with a backend team scaling a Node.js codebase.
If you don’t create platform teams in time, you fail to stay ahead of the growth curve. When you don’t create any platform teams, the incentive for the product engineering teams is to build the next product feature. Companies are there to solve problems for their customers, so this is what product engineering teams focus deeply on. For example, on the Billing team, the product managers will be thinking deeply about how they can launch the next bill payment feature that improves the customer’s experience.
These product teams are not coming at things from the wrong perspective, they are simply listening to customers. And your customers are always front-and-center.
Compare this with the importance of platform teams. If you don’t put a platform team in place, you’ll have a hard time scaling up from the Nth engineer. This problem is something that usually doesn’t register as urgently as solving a customer problem does.
An engineering leader’s job becomes tricky when balancing shipping with staying ahead of the curve. They keep hearing the product manager wanting to ship things. At the same time, they need to think ahead to how they’ll balance growing the team, without dropping their productivity.
A good way to relate to platforms is thinking about Site Reliability Engineers (SREs). SREs are thinking about capacity management for the future, as SRE teams are effectively a reliability platform. SREs will ask the question, “what do we need to do to scale, to handle 3x the current load?” Platforms answer similar questions, but do so for a variety of other characteristics.
4. The timing of putting platform teams in place
Many platform teams at Uber were founded early. What does good timing look like for the first teams?