Read on Twitter
Reasons why you may not want to build that UI only team.
A thread
https://abs.twimg.com/emoji/v2/... draggable="false" alt="🧵" title="Thread" aria-label="Emoji: Thread">
A thread
1) Defining ownership https://abs.twimg.com/emoji/v2/... draggable="false" alt="👩💻" title="Woman technologist" aria-label="Emoji: Woman technologist">
Who really owns a feature?
The team who built the APIs, or the team building the UI?
A frontend only team has a hard time really owning anything. They& #39;re just one step away from being contractors in your company.
Who really owns a feature?
The team who built the APIs, or the team building the UI?
A frontend only team has a hard time really owning anything. They& #39;re just one step away from being contractors in your company.
2) It gets hard to define their mission. https://abs.twimg.com/emoji/v2/... draggable="false" alt="🏹" title="Pfeil und Bogen" aria-label="Emoji: Pfeil und Bogen">
What really is the mission of a frontend only team with little ownership? Building shiny UIs?
What really is the mission of a frontend only team with little ownership? Building shiny UIs?
3) It can significantly limit career progression for the entire team https://abs.twimg.com/emoji/v2/... draggable="false" alt="💸" title="Geld mit Flügeln" aria-label="Emoji: Geld mit Flügeln">
What will you be evaluated on if you have a hard time defining your mission and ownership?
Even frontend KPIs will suffer if an upstream API is inefficient or buggy.
What will you be evaluated on if you have a hard time defining your mission and ownership?
Even frontend KPIs will suffer if an upstream API is inefficient or buggy.
4) Leads to excessive/unnecessary coordination https://abs.twimg.com/emoji/v2/... draggable="false" alt="🗺" title="Weltkarte" aria-label="Emoji: Weltkarte">
When was the last time your "backend team" got all APIs right?
"Meeting in the middle" APIs require significant upfront design and coordination.
Experiments take longer to run, prototypes require too much coordination.
When was the last time your "backend team" got all APIs right?
"Meeting in the middle" APIs require significant upfront design and coordination.
Experiments take longer to run, prototypes require too much coordination.
5) Hard to measure progress/KPIs https://abs.twimg.com/emoji/v2/... draggable="false" alt="📈" title="Tabelle mit Aufwärtstrend" aria-label="Emoji: Tabelle mit Aufwärtstrend">
Why would you even measure or be on the hook for any metric you don& #39;t fully control?
Who wants to be paged for upstream systems they don& #39;t control?
Because guess what, you now own the front door of your system.
Why would you even measure or be on the hook for any metric you don& #39;t fully control?
Who wants to be paged for upstream systems they don& #39;t control?
Because guess what, you now own the front door of your system.
6) Split brains https://abs.twimg.com/emoji/v2/... draggable="false" alt="🔪" title="Küchenmesser" aria-label="Emoji: Küchenmesser">https://abs.twimg.com/emoji/v2/... draggable="false" alt="🧠" title="Gehirn" aria-label="Emoji: Gehirn">
Another side effect of unclear ownership is the unnecessary coordination required by your product team.
Who really owns a feature? The PM defining the UX, or the PM defining the business rules for the feature?
Good luck with your split brain PM org.
Another side effect of unclear ownership is the unnecessary coordination required by your product team.
Who really owns a feature? The PM defining the UX, or the PM defining the business rules for the feature?
Good luck with your split brain PM org.
Of course there are benefits to specialization.
But would you prefer to orient your teams around specialization or around a mission that optimizes for customer impact?
But would you prefer to orient your teams around specialization or around a mission that optimizes for customer impact?
