Cross-Functional Generalizing Specialists¶
Definition¶
Instead of organizing teams around discipline-based silos (requirements, design, development, QA, operations), DAD advocates cross-functional teams made up of generalizing specialists: people who are deeply skilled in one primary discipline (e.g., backend development, user experience design) but have working knowledge of multiple other disciplines and are willing to move fluidly across them as work demands. A generalizing specialist in testing might help with requirements gathering; a developer might contribute to UX design. This breaks down formal handoffs, reduces documentation waste, and builds shared understanding across the team.
In the Book¶
Chapter 1 introduces the philosophy grounded in Alistair Cockburn's observation that "people are non-linear, first-order components" in software development—people and their collaboration are the primary determinant of success, not processes. Chapter 4 details the DAD roles and emphasizes what they are not: there is no separate "tester" role, no separate "business analyst" role. Instead, a generic team member should be capable of doing multiple things. Chapter 5 discusses team formation strategies and the move away from specialized roles.
The book contrasts two models:
Specialist Model (Traditional): Requirements analyst → Requirements document → Developer → Code → QA Tester → Test report → Production. Each handoff loses tacit knowledge; each person is optimized for their narrow skill, not the team's overall effectiveness. Knowledge is trapped in documents that quickly become stale.
Generalizing Specialist Model (Agile): A team with shared ownership explores requirements together; developers write tests; testers help with requirements; business analysts understand the technical constraints. Documentation is minimal and collaborative; knowledge lives in the team's ongoing conversation and code.
The book acknowledges that deep specialists still exist and have a role—a team building a complex database might bring in a specialized database administrator for a week to help with configuration—but the team itself should cover the full spectrum of skills needed. Importantly, the book distinguishes between "specialist in one area" and "siloed specialist": the former contributes depth to the team; the latter becomes a bottleneck.
The book also addresses the reality that not everyone is a generalizing specialist. Some people are happiest and most effective staying in one discipline. The DAD team structure accommodates this: the team as a whole must be cross-functional, but that doesn't require every individual to be equally skilled in all areas.
Why It Matters¶
Cross-functional generalizing specialists address one of the deepest sources of waste in traditional development: handoffs between specialized roles. Each handoff requires documentation (often incomplete), review (often overlooked), and rework (inevitable when assumptions differ). By breaking down role barriers, teams accelerate feedback, reduce rework, and build shared understanding that prevents misalignment. The generalizing specialist model also makes teams more resilient—if one person is out, others can step in rather than blocking on a missing specialist. For enterprises, this is a cultural shift: moving from "people as specialized resources allocated to projects" to "people as team members with diverse skills." This shift unlocks the agility that agile methods promise.