Thank you for taking the time to write this wonderful resource - I'm moving from a product engineering team to a platform engineering one at my current company soon and have been searching for online resources to prepare myself mentally for my new role. This article is such a timely and insightful read!
Thanks for the feedback! I don't think there is a "one size fits all" setup for platforms/products, but I hope there are points that will emphasize.
Also, I've found platforms to not be *very* different across companies... and pain points are similar. I'll be covering more on this topic, as I find platforms (and platform strategy) becomes important for fast-moving companies to scale.
A lot of the platform issues resonated, especially the ones around finding good ways to measure impact, the pull to working on things the platform believe are most important (at the expense of customers), and then adoption and migration constraints.
It sounds like you have some follow-ups in mind but I'd love to know more about good ways you've seen teams get themselves out of these traps. For me, I think we've benefited from periodically rotating (especially leadership people) from program teams into platforms to bring a degree of empathy, and a constant reminder for people to speak to your customer and deeply understand their problems (its super hard though).
I think one of the most interesting sources of tension is the creativity and innovation driven by platform teams that then need the program (or, within our org, product teams) to change behaviour.
Anyways, I'm a new subscriber but really enjoyed reading your article.
Good write up and a lot of useful tidbits about platform teams. However I had a couple of questions/thoughts:
1. The problems that existed with previous project teams sound like a resourcing issue. Won't that exist with a product/platform team split also? You would still have problems implementing cross domain projects without the resources.
2. How do teams decide what is owned by program vs platform teams? Does it happen after a product is delivered and then the orh decides a particular part of it needs to be scaled and can be shared and owned by platform teams?
3. What is the point of a program platform team? Isn't the point of a platform team to be cross domain? Does this mean the program platform team just works on issues of scale security etc without being interrupted by customer needs?
1. For a feature / set of features that is offered in both mobile (at least Android and iOS) and web, do you recommend one product team for each (Android / iOS / web) or a single product team for all?
2. What is the current team size across all the product and platform teams at Uber? Do you have any insights on how much this model can scale?
3. For an org with mobile and web products, do you have any recommendations wrt to the architecture that can support hundreds or maybe over one thousand developers? Similar to the microservices approach on backend and microfrontends on web, what is your experience on mobile, how did you do this at scale?
1. I am a big believer at a team owning a full feature. Meaning a team with a mix of iOS, Android and web engineers. This is what can help the feature become the best. This is a classical "Product" (or, as Uber called it, "Platform") team.
However... there might be other considerations at play. For example, in my group at Uber, we had very few web engineers. We decided to start a web team initially with all these people, who would build up all features initially. The plan was to have the team get expertise, and then engineers would "split" and join teams where they owned the features.
The danger of separate teams is silos growing. It's how the web, iOS and Android features all become separate. At Uber, e.g. iOS and Android people on the same team would plan together, and even review each others' code sometimes!
2. As a rule of thumb for team size: at least 5 people (bare minimum for an oncall rotation) and no more than 12 (the limit for a manager to work with: though 8-10 was a more common practical limit). This also matches e.g. the suggestion from Will Larson, who is a bit more strict in team sizing and sets it at 8: https://lethain.com/sizing-engineering-teams/ We both worked at Uber, though barely overlapped.
3. Hundreds or thousands of developers... yeah, we did this at Uber with hundreds of mobile engineers. A few things:
a) You NEED to invest in platform teams for this scale (developer experience, but also architecture). At Uber, the Mobile Platform group came up with a new architecture that we prototyped, then rolled out to the whole org, RIBs: https://github.com/uber/RIBs I also did a talk on this, as did other Uber engineers: https://vimeo.com/267250296
For frontend, we saw far fewer engineers, and I don't have a similar "goto" approach. Microfrontends seem to be gaining ground. However, the web codebase is almost always not as coupled as the mobile one: it's often separate products, domains etc. A web platform team is definitely a smart idea to start. Many larger web companies also have shared web UI teams for components.
I'll have to pull in some expertise on the web platforms state of the world though, as mine is more on the mobile (and somewhat the backend) side. If anyone has thoughts here, please, feel free to chime in!
Thank you for taking the time to write this wonderful resource - I'm moving from a product engineering team to a platform engineering one at my current company soon and have been searching for online resources to prepare myself mentally for my new role. This article is such a timely and insightful read!
Thanks for the feedback! I don't think there is a "one size fits all" setup for platforms/products, but I hope there are points that will emphasize.
Also, I've found platforms to not be *very* different across companies... and pain points are similar. I'll be covering more on this topic, as I find platforms (and platform strategy) becomes important for fast-moving companies to scale.
Really great article, thanks for sharing.
A lot of the platform issues resonated, especially the ones around finding good ways to measure impact, the pull to working on things the platform believe are most important (at the expense of customers), and then adoption and migration constraints.
It sounds like you have some follow-ups in mind but I'd love to know more about good ways you've seen teams get themselves out of these traps. For me, I think we've benefited from periodically rotating (especially leadership people) from program teams into platforms to bring a degree of empathy, and a constant reminder for people to speak to your customer and deeply understand their problems (its super hard though).
I think one of the most interesting sources of tension is the creativity and innovation driven by platform teams that then need the program (or, within our org, product teams) to change behaviour.
Anyways, I'm a new subscriber but really enjoyed reading your article.
Good write up and a lot of useful tidbits about platform teams. However I had a couple of questions/thoughts:
1. The problems that existed with previous project teams sound like a resourcing issue. Won't that exist with a product/platform team split also? You would still have problems implementing cross domain projects without the resources.
2. How do teams decide what is owned by program vs platform teams? Does it happen after a product is delivered and then the orh decides a particular part of it needs to be scaled and can be shared and owned by platform teams?
3. What is the point of a program platform team? Isn't the point of a platform team to be cross domain? Does this mean the program platform team just works on issues of scale security etc without being interrupted by customer needs?
Also did Uber create program and platform program teams and did some of these platform program teams become cross domain eventually?
Thanks for all the details, Gergely, very useful!
I have a few questions:
1. For a feature / set of features that is offered in both mobile (at least Android and iOS) and web, do you recommend one product team for each (Android / iOS / web) or a single product team for all?
2. What is the current team size across all the product and platform teams at Uber? Do you have any insights on how much this model can scale?
3. For an org with mobile and web products, do you have any recommendations wrt to the architecture that can support hundreds or maybe over one thousand developers? Similar to the microservices approach on backend and microfrontends on web, what is your experience on mobile, how did you do this at scale?
Thanks again, appreciate it.
Hey Ovidiu,
1. I am a big believer at a team owning a full feature. Meaning a team with a mix of iOS, Android and web engineers. This is what can help the feature become the best. This is a classical "Product" (or, as Uber called it, "Platform") team.
However... there might be other considerations at play. For example, in my group at Uber, we had very few web engineers. We decided to start a web team initially with all these people, who would build up all features initially. The plan was to have the team get expertise, and then engineers would "split" and join teams where they owned the features.
The danger of separate teams is silos growing. It's how the web, iOS and Android features all become separate. At Uber, e.g. iOS and Android people on the same team would plan together, and even review each others' code sometimes!
2. As a rule of thumb for team size: at least 5 people (bare minimum for an oncall rotation) and no more than 12 (the limit for a manager to work with: though 8-10 was a more common practical limit). This also matches e.g. the suggestion from Will Larson, who is a bit more strict in team sizing and sets it at 8: https://lethain.com/sizing-engineering-teams/ We both worked at Uber, though barely overlapped.
3. Hundreds or thousands of developers... yeah, we did this at Uber with hundreds of mobile engineers. A few things:
a) You NEED to invest in platform teams for this scale (developer experience, but also architecture). At Uber, the Mobile Platform group came up with a new architecture that we prototyped, then rolled out to the whole org, RIBs: https://github.com/uber/RIBs I also did a talk on this, as did other Uber engineers: https://vimeo.com/267250296
For frontend, we saw far fewer engineers, and I don't have a similar "goto" approach. Microfrontends seem to be gaining ground. However, the web codebase is almost always not as coupled as the mobile one: it's often separate products, domains etc. A web platform team is definitely a smart idea to start. Many larger web companies also have shared web UI teams for components.
I'll have to pull in some expertise on the web platforms state of the world though, as mine is more on the mobile (and somewhat the backend) side. If anyone has thoughts here, please, feel free to chime in!