This text was generated using AI and might contain mistakes. Found a mistake? Edit at GitHub
When most organizations face the challenge of growing engineering teams beyond the traditional Scrum recommendation of 5-9 people, the obvious solution seems to be splitting them into smaller units. However, Tsvetelina Plummer and Priscilla Gunawan from Nielsen IQ present a refreshingly different approach: intentional collaboration structures that maintain team cohesion while creating space for focused work.
The Context Matters
Working at Nielsen IQ, a 30,000-person market research company with about 2,500 person technology division, presents unique constraints. Unlike typical tech companies with primarily frontend and backend engineers, Nielsen IQ operates with highly specialized roles: data scientists, machine learning engineers, QA specialists, and SRE professionals. Many data scientists come from mathematics and statistics backgrounds, learning to code on the job. This diversity creates both opportunities and organizational challenges.
Beyond the Simple Split
When teams consist of 20-25 people, the traditional advice would be to divide them. But Plummer and Gunawan discovered that blindly splitting teams can cause suffering without solving underlying problems. Instead, they developed context-specific solutions based on three critical forces: product vision, system architecture, and team dynamics – treating people as equal stakeholders alongside technical and business concerns.
The Fluid Team Model
One innovative approach involves teams that reorganize themselves each sprint based on priority. Rather than fixed sub-teams, members dynamically reorganize based on which work is most critical. Through refinement sessions and daily standups, they sense which skills are needed and adjust accordingly. This maintains team unity while allowing deep focus.
Visualization as Foundation
A key discovery: visualization transforms abstract team dynamics into actionable insights. By mapping communication patterns – literally printing out avatars of the team members and drawing collaboration lines – teams can see exactly who interacts with whom and how often. Overlaying this communication map against architectural diagrams and stakeholder maps reveals whether a split makes sense or whether loose collaboration structures would work better.
The Selective Framework Approach
Rather than adopting complete frameworks like SAFe, the teams cherry-pick elements that fit their context. For one team struggling with painful sprint planning and retrospectives in a 20+ person group, they split ceremonies into “what” phases (done together) and “how” phases (done separately), while maintaining quarterly joint retrospectives. This lightweight adaptation, inspired by LeSS (Large-Scale Scrum), improved team satisfaction significantly.
Metrics as Conversation Starters
Developer experience surveys (based on DORA metrics) aren’t used as performance tools but as conversation catalysts. When data showed improved processes but decreased deep work, the team discovered an entirely different problem – increasing customer complaints – that was the real culprit. Metrics work best with trust and openness.
Conclusion
“Splitting without splitting” isn’t about rejecting the proven wisdom that smaller teams communicate more effectively. Rather, it acknowledges that organizational reality – specialized roles, enterprise constraints, product interdependencies – sometimes requires larger units. The solution isn’t predetermined structure but facilitated discovery: visualize your actual situation across product, architecture, and people dimensions, then let teams make informed decisions about how to organize themselves. One size definitively does not fit all, but intentional design beats accidental chaos every time.