Adam Tornhill has some great little vignettes over at My Five Worst Bugs: Lessons Learned In System Design.
However, in his vignette “Virtually Correct” (which technically is about the hazards of using base classes in C++) he criticizes collective ownership of a code base:
I’ve come across collective code ownership several times in my career, and we currently employ that principle to parts of the CodeScene development. I also know some great developers who claim collective code ownership works well for their organizations. However, what all those success stories — including my own — have in common is that they occur in small, tight knit teams of 4-5 developers; I’m yet to see an example where collective code ownership works well at scale. My scepticism isn’t specific to software, but comes from my background in social psychology and group theory. As soon as we scale collective code ownership to a larger group, we open up for social biases like diffusion of responsibility and social loafing that I described in Software Design X-Rays. These biases are hard to keep in check.
That’s all well and good, but it belies a fundamental misunderstanding of the virtues of collective responsibility. Perhaps Uncle Bob Martin is the original culprit here? He of the “Single Responsibility Principle” infamy. But I’m not talking about code here, I’m writing about people and organizations. For code, it is a good heuristic to have functions assigned single responsibilities, it makes for less buggy and more maintainable code. The reality for people and organizations is different. A person is not much use if they have only one narrow single responsibility, and typically a person can cope well, and feel more self-esteem, if they are given a few important responsibilities within their capabilities. The reality is that collective responsibility can always work, and can always improve an organization’s overall performance if you use it right. To do so you should use the following principles of good collective responsibility, which I’ve gleaned from W. Edwards Deming:
- No single person should be punished for mistakes made that were not deliberate or malicious. Any honest assessment will usually conclude the system the person is working within is as much a cause of the problem as any one individual themselves. Incompetence of a worker is something a manager should never allow to happen, if they do then who is really incompetent? The worker or the manager who assigned someone a task which they did not have the skills to complete? It is very rare that fault or blame can justly be lumped on a single person.
- Any worker making mistakes non-maliciously or accidentally is not an isolated poorly performing individual, they are part of the whole, and the manager’s job is to help such workers overcome their errors and to provide support or continued training so that the organization as a whole improves.
- Any defects in products or processes can always be considered collective responsibility, but that means the organization collective has specialized workers whose job it is to assign responsibility to an individual or team to attend to the problems causing the defects.
- The consequence of the organizational lens in point 3., is that the stress and anxiety of fixing a problem is not focused on one poor person, but is recognized as a cooperative task to solve. To be effective this often means giving one person or a small team the task, but the responsibility is still distributed across the whole organization, since if the team does not perform well it is almost always the case that any different team of similar capability probably would also not perform well, and almost always the reason is a system fault, not an individual’s fault. Some bosses might demand, “Whose fault was it!?” failing to realize they are the ultimate cause of any faults. If an individual programmer lacked the knowledge or skill to fix a code bug, then maybe the manager assigning them the task should not have given them the task! In short: delegating responsibility should never be used to resolve oneself of responsibility. Absolving oneself of responsibility by delegation is a sure sign of a dysfunctional organization. You can always blame the poor line worker who made the proximate errors, but that is usually only hiding the deeper failures of management and your whole collective system.
- People should not be treated like pass/fail products. As bankers tend to learn from failed businesses who go bankrupt, they are usually the best folks to give future loans to, because they’ve learned from failure and tend to be more prudent than someone with a clean credit record. Thus, is is not rally a great idea to punish or fire incompetent workers, it is often less expensive and more efficient to provide more training and lesser responsibility that can be slowly built up, you are then investing in your workers.
These are reason why I think worker cooperatives have a very bright future ahead, and intensive coding tech start-ups would do well to adopt worker coop practices, and understand the above principles of who to enjoy collective responsibility without suffering diffusion of responsibility.
It is always a great idea to focus tasks and give small teams critical responsibilities, teams that are small but no smaller than necessary. But an organization can still enjoy collective responsibility, since when or if the team fails, you do not have to blame the team, and instead you can admit that there is almost always a broader system-wide cause of their failure, identifying that true cause is the way to enjoy collective responsibility.