Contents
Research tells us several things that make teams successful: continuity isn’t one of them. I encountered this idea from the clickbaity-titled article “Your Team is Killing Productivity”.
The question I’ve learned to ask about any apparent inefficiency is “What need is this actually serving?” and I wonder if the ubiquity of persistent teams stems from how well they fit within a hierarchical management structure, i.e. they make it really easy for executives to hold multiple layers of managers accountable over time (and those executives are presumably the ones who decide on team structure).
That’s certainly possible with task forces, just a bit messier. I think of things like SLOs, and how we might see them differently with task forces. Instead of a “Learn SLO” that the Learn squad owns, maybe we get more granular into “Lesson Loading SLO” and “Learn Page Search SLO” which the entire product team owns, and any task force working in one of those areas includes maintaining the SLO in their non-functional requirements while working in that area. Even then, there’s the question of “What about SLOs no one owns at the moment?” but maybe if one is suffering we convene a task force on it :think-about-it:
It reminds me of public vs. private and the idea (privatization) that the best way to manage resources (and avoid a Tragedy of the Commons) is to make them all owned by individuals, turning everything into a question of property rights. Isn’t that the basic idea behind persistent teams: having clear and stable lines of “ownership” over parts of a product? And does this article challenge that? Maybe yes, if the idea is shared ownership and transient “custodianship” over parts of a product. Or maybe no, if the idea is pushing ownership up the hierarchy and treating product people as mercenaries enlisted to achieve temporary objectives.