Product Team Members Report To The Team Leader
A Product Team should be collaborative, but communication/psychology/flow is simpler if there's a single "leader" who the members report to.
- Hand-offs between specialist teams create delays and mis-communication and/or overhead.
- Countless product decisions can be made more complicated/expensive than their value warrants.
- Refining ideas as group with shared sense of "cost" vs "benefit" accelerates finding sweet-spot of small-batch delivery.
- Even in a consultative organization, having a well-defined leader tends to improve FlowState.
- A (software) Product Team should be a sticky, outcome/(OKR)-driven, product-focused (not technology-stack-focused/), cross-functional Two-Pizza Team. Probably 5 devs + 1 QA + 1 UX/UI Designer + Team Leader.
- All its members should report directly to the Team Leader. Not to their Functional Management. They should have a supportive functional Community of Practice, but "standards" etc need to be sold to Team Leaders.
- The Team Leader should probably be a Product Manager. This may be a syllogism. Conceptual Integrity via Auteur Theory.
- the "key factor" of success for a team might be technical/engineering excellence, in which case maybe the team leader should be an engineer. Contrarily: being a product team, tech excellence has to be in service of the customer's needs.
- alternatively, might be completely about the specific team and discipline-lead individuals within it, as to which is a better leader of the team? Does this imply it's better not to even "name" a leader? I think the key anti-pattern is having team members report to someone outside the team, but could a self-organizing system work? (2015-11-22) Dignan Picking Self-Organization Model
- But since the majority of the team will probably be developers, the Team Leader should have enough development experience to have deep dialogue/collaboration with the devs about finding the sweet-spot of benefit-vs-cost in defining each initiative.
- Hiring: leader of the team they'll be joining is final decision-maker, should obviously involve devs from team, plus dev-leads in other teams.
- Promotions: if engineers aren't managing engineers, then promotion tends to be about "level" (hardness of problems they are good at solving, and compensation). Yeah, "standards" and a committee....