Comparison
Code ownershipvsCognitive load
Code ownership
you opened a pull request against another team's repository and it sat there for eleven days.
Who is accountable for a piece of code: reviewing changes, running it, and being paged when it breaks. Strong ownership makes quality and on-call clear and makes cross-team change slow; collective ownership makes change fast and quality diffuse. Neither is right in general, and the failure to state which one is in force is what produces both the eleven-day review and the directory nobody maintains.
Full entry →Cognitive load
the team owns nine services and can explain four of them.
The total amount a team must hold in its head to do its work — domains, systems, tools, on-call surface. Treating it as a budget is the most useful team-sizing idea of the last decade, because it explains why adding one more service to a team can halve its throughput. It is also the strongest argument available against a proposed split or acquisition of ownership: not that the work is too much, but that the understanding required is.
Full entry →