The code and artifacts belongs to the team, not any individual.
Collective ownership means any builder can check out and improve any module at anytime.
The key is to allow and encourage people to specialize, while at the same time balance that with having generalized knowledge. Team members should split their work between their specialty and other areas so they can help across the codebase.
When ownership is shared, knowledge spreads, and the team can make better decisions together.
With most projects teams I’ve worked with, I’ve seen the exact opposite setup. Modules are owned by individuals, which led to a lot of finger-pointing when progress was stalled, especially when the author was away.
Collective ownership prevents those dysfunctions by keeping the system understandable and changeable by the larger team.
Discussions for your team
- How often should team members switch and move onto different areas to help share and spread knowledge?
- Which modules which are complex and need more pairing time to help onboard others?
- Do we need more conventions and standards to ensure safe changes to a module by less familiar team members?
- How can we strengthen our position to handle situations when the original author is unavailable?