Great read, thank you for your perspective on this. I especially liked how you've made it tangible with a real-world example. Is there a typo in the Cake org vs Kebab orgs you have experience with in the last paragraph? I do not understand how both can have higher engineer/manager ratio when the numbers provided are 12, and 0,5.
I have to say, I don't quite buy this reasoning. Putting everyone into 1 big team clearly solves alignment issues and problems with user journey handovers; however, I see a number of what I consider insurmountable weaknesses here, namely:
- The cake is immediately heavily constrained in how much they can scale their org structure - as complexity grows, either adding more layers or more sub-teams will quickly result in a spaghetti of dependencies. The Web Platform will need something from Payments, a new UX Customization team will need something from Content, etc. It will become increasingly difficult to keep slicing the complexity cake in a clean way.
- I see the cake structure as undermining ownership rather than encouraging it. The Reader Experience team doesn't own their solutions end-to-end. To ship a feature (e.g. AI voice can now read you the articles while you cook!), they will often wait for (in this example) the Web Platform team and the Content API team. They have a strong dependency on the services provided by those teams, however, the engineers are loosely coupled - this is a recipe for frustration and many other toxic outcomes.
I would say that there are different ways to do “Kebab” - and I would agree that the example presented here is problematic. However, it’s possible to build Kebab teams around a MISSION rather than a FEATURE. This mission should be something more durable from the business domain than a feature - for example, instead of making a team around Front Page, make a team around Exploration with a specific KPI (e.g. “user stickiness”). I would argue that such a team, with a shared understanding and end-to-end ownership of the tech needed to fulfill their mission, with a mandate and full capability to deliver value is better set up to perform than a “Cake” structure.
Great read, thank you for your perspective on this. I especially liked how you've made it tangible with a real-world example. Is there a typo in the Cake org vs Kebab orgs you have experience with in the last paragraph? I do not understand how both can have higher engineer/manager ratio when the numbers provided are 12, and 0,5.
One is engineer to manager ratio; the other is the reverse.
Update: I think you have a point. It was a confusing sentence. Rewrote it. Thanks for the feedback.
I have to say, I don't quite buy this reasoning. Putting everyone into 1 big team clearly solves alignment issues and problems with user journey handovers; however, I see a number of what I consider insurmountable weaknesses here, namely:
- The cake is immediately heavily constrained in how much they can scale their org structure - as complexity grows, either adding more layers or more sub-teams will quickly result in a spaghetti of dependencies. The Web Platform will need something from Payments, a new UX Customization team will need something from Content, etc. It will become increasingly difficult to keep slicing the complexity cake in a clean way.
- I see the cake structure as undermining ownership rather than encouraging it. The Reader Experience team doesn't own their solutions end-to-end. To ship a feature (e.g. AI voice can now read you the articles while you cook!), they will often wait for (in this example) the Web Platform team and the Content API team. They have a strong dependency on the services provided by those teams, however, the engineers are loosely coupled - this is a recipe for frustration and many other toxic outcomes.
I would say that there are different ways to do “Kebab” - and I would agree that the example presented here is problematic. However, it’s possible to build Kebab teams around a MISSION rather than a FEATURE. This mission should be something more durable from the business domain than a feature - for example, instead of making a team around Front Page, make a team around Exploration with a specific KPI (e.g. “user stickiness”). I would argue that such a team, with a shared understanding and end-to-end ownership of the tech needed to fulfill their mission, with a mandate and full capability to deliver value is better set up to perform than a “Cake” structure.