Recently we’ve been working on team models across our engienering team. How do we get the balance right in product delivery. What’s the gold standard we are aiming for in size of team, composition or roles and supporting roles. What we have found in going through this exercise is that being aligned on the underlying principles leads to a better discussion when talking about implementation details with stakeholders. How we have used this is as a starting artifact to align on. Once we are comfortable everyone is in agreement, the discussion around implementation becomes easier.
So with that in mind, here are the underlying principles we came up with for our current team model…
- People managers cannot effectively manage more than 5-7 people
- Reduce cognitive load by establishing clear domain boundaries along value streams
- It takes longer to find and hire leadership than it takes to find and hire individual contributors
- Optimising for delivery consistency, ie. flow of work
- We value discovery work so that we build the right thing (understanding before execution)
- The minimum delivery unit is the product delivery team
- We value practice leadership in order to build a high quality product
- Product delivery teams have a balance of skills (software engineering, analysis, design, etc.)
- Product delivery teams need appropriate support (architecture, tech writers, etc.)
As a result of these underlying principles, we ended up with the following implementation details…
- Stabilise existing teams ahead of hiring new teams
- Forward hire leadership when growing rapidly, but don’t hire too far in advance because the plan can change
- Stream leadership is formed before forming delivery teams
- Optimal value stream size 3 to 4 product delivery teams, as soon as we go over that size things get hard for the PM
- Team size is optimised for supporting running software in production while moving forward on product delivery
- For roles like Architects & Principal Engineers there is a cognitive load on the size of the domain they cover (they can’t be effective if they need to cover too big an area)
- For roles like Architect’s the constraint is the number of value streams they work across
- For roles like Principal the constraint is the number of product delivery teams and value streams they need to cover.
- For roles like SEM’s & EM’s the constraint is often the number of people management responsibilities
- For roles like PM’s & PA’s the constraint is the number of product delivery teams
- For roles like PD’s the constraint is the number of value streams that have front end capabilities
- For research roles the constraint is the number of markets they need to cover
