Grow communities of practice across teams, so learning travels between groups
instead of being relearned in each one.
When an organization adopts LeSS, it moves people out of functional silos and into long-lived, cross-functional feature teams. That is the right move — but it raises a real question: if all the testers, or all the people who know a particular component, are now spread across many teams, how do they keep learning as a group? How does a new testing practice, or a hard-won lesson about a gnarly part of the system, reach everyone who needs it?
The answer LeSS gives is the Community of Practice (CoP) — a group of people who share a concern or a craft and deepen it by interacting over time. CoPs are how knowledge spreads sideways across the organization, peer to peer, rather than up and down a reporting line. Toyota calls this lateral spread of knowledge yokoten: whoever learns something is responsible for sharing it. A community of practice is how you make that happen at scale.
A CoP does not appear on the org chart, and you cannot decree one into existence the way you create a department or a project. Participation is voluntary: people join because they care about the topic. What an organization can do is promote and support them — with facilitators, infrastructure, time, and budget.
Each healthy CoP has an informal leader — a CoP coordinator — who emerges from the group out of genuine interest, not appointment. The coordinator organizes meetings and design workshops, keeps the conversation alive, and helps the community stay useful. A specific and powerful variant is the component mentor: a feature-team member who takes on extra stewardship for a part of the system — teaching how it works, watching its long-term health, organizing its community, and reviewing code as a teacher, not as a gate. They never approve commits; they cultivate understanding.
Crucially, a CoP is not a matrix in new clothes. A matrix multiplies reporting relationships; a community is built on collegial ones. Even the coordinator is a peer, not a boss. That distinction is what lets communities carry knowledge without re-creating the very hierarchy LeSS removes. The fuller treatment lives in the framework's Communities of Practice guide.
When specialists move into cross-functional teams, their craft doesn't fragment. A testers' or architects' community keeps a whole discipline learning together — the exact gap organizations hit when they abolish the matrix.
A better Definition of Done, a coordination habit, a way of handling a tricky component — found by one team, carried to the others through the community instead of waiting for a reorg or a mandate.
Knowledge held in a community survives people changing teams and consultants finishing their engagement. The organization holds it — not a handful of individuals who can walk out the door.
AI changes what teams build and how fast markets move. The organizations that turn that into an advantage are the ones that learn quickly together — and shared, lateral learning is exactly what communities of practice produce.
Communities are grown, not installed. A few things help, and a few things quietly destroy them:
An internal community complements your coaches and trainers — it doesn't replace them. It's how their work compounds across every team.
