Product development pods
Located in: Product
Principles
- Products over projects - By focusing the team on a product (or area), you can expect them to think longer term and come up with iterative solutions.
- Complete - The pods are broken up so there is complete coverage of the product
- Autonomous - Each pod has the resources to create business value on it's own
- Independent - No pod is blocked by any other pod
- Shared responsibilities - There are going to be shared responsibilities (architecture, design system, etc), make sure they are clearly defined and understood.
- Clear Purpose - The pod should have a clear purpose and vision, as well as a way to measure their success.
- Limited overlap - There will be overlap, but the overlap should be minimal and follow agreed upon working agreements.
See https://docs.google.com/document/d/1SZTWG1RckbYvNBdnzpXMsdOfwFdhgmnwbugxRAMGINY/edit#heading=h.h0jntpk280fv for an interesting approach on pod principles
Types of Pods
Based on Team Topologies:
- Stream-aligned team - A classic product team. They generally own a segment of the business or product.
- Enabling team – Helps stream-aligned teams acquire capabilities they lack. This could be teams focused on proving out new technology or concepts.
- Complicated subsystem team – Owns a system that requires deep and specific expertise.
- Platform team – Provides an internal product. Stream-aligned teams use this product as a service to accelerate development.
How pods interact
Based on Team Topologies:
- Collaboration – Teams work together for a while. It can be to establish practices or new technologies or discovery.
- X-as-a-Service – One team provides a service to other teams. It’s treated as a regular product and consumed internally.
- Facilitation – One team works with another team until they build a certain capability.
Roles
As per Hiring Ratios, you can expect:
- 1 product manager
- 1 engineering manager and/or a tecnical lead (could be shared)
- 5-7 developers
- 1 designer
- 0.5-1 QE
