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!
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?
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!
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?
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.