Organizational Design Pattern 2—Fluid Ownership
Fluid ownership refers to a lack of fixed ownership over specific technical components. Contrastingly, the second organizational model emphasizes empowering teams by giving them the autonomy to address customer needs directly, without any limitations on changing technical components.
This approach marks a significant shift from traditional, rigid structures to those that place customer value at the forefront of all activities. Under this paradigm, while teams enjoy the freedom to creatively address customer challenges in their own ways, there is also a strong focus on ensuring consistency in building and development approaches across the organization. Moving away from the rigid ownership of technical details toward a collective focus on customer outcomes fosters a more agile and responsive organization. Here, success is measured by the value delivered to customers rather than strict compliance with technical specifications.
Shifting toward simpler organizational structures without strict ownership policies can mitigate many of the negative consequences previously discussed. This approach removes the rigid boundaries that often compartmentalize teams and their work, fostering a more cohesive and collaborative environment. In such structures, the absence of formal ownership policies helps avoid issues like siloed knowledge and unnecessary complexity, as well as the associated inefficiencies.
In an environment where there is no designated ownership of specific technical components, team members naturally develop a sense of collective responsibility.
Peer Accountability: Without strict ownership, individuals feel a greater sense of accountability to their peers. This is not just about avoiding shame when others review their code or work; it's about contributing to a larger effort where everyone's work is interdependent. The desire to maintain respect and trust among peers becomes a powerful motivator for maintaining high standards.
Intrinsic Motivation: When team members know their work will be seen and potentially changed by other teams, there's an intrinsic motivation to produce work of high quality as they don’t want their team to feel shamed. It’s easier to feel shame for yourself than for others you intensively work with day-in-day-out. This is not just about avoiding negative outcomes but about taking pride in one's contributions to the collective output. The quality of work becomes a point of professional pride and a measure of one’s skills and reliability.
Group Pressure and Agreements: In simpler organizational setups, where formal policies and policing are minimized, the adherence to quality and standards often comes from internal group pressure. Teams that self-coordinate and distribute work are more likely to develop their own systems of accountability based on mutual agreements rather than enforced rules. These agreements, formed through consensus and collaborative discussions, ensure that everyone understands and upholds the team’s standards. Compliance is driven by a commitment to the group and its goals, rather than by top-down enforcement.
Direct Coordination and Alignment: Teams in these simpler structures coordinate their efforts directly and align their goals and methods without the need for intermediate layers of management. This direct coordination allows for quicker adjustments and real-time problem-solving, which can lead to more innovative and agile responses to challenges. Teams are better positioned to align their work with the overarching goals of the organization and immediate feedback loops, enhancing both the effectiveness and efficiency of the work.
Overall, removing rigid ownership and embracing simpler organizational structures encourages a culture of shared responsibility and peer-regulated quality. This environment not only boosts morale and enhances collaboration but also leads to higher technical quality as team members strive to meet the collective standards they have jointly established, instead of those forced on them by others.
When adopting this organizational design pattern, it's essential to consider several critical factors. Without careful consideration, you may find yourself in a situation that is even more overloaded and stressful than the organizational pattern previously discussed.
Myth: The Tragedy of the Commons
Ecologist Garret Hardin, published, in 1968, the article, “The Tragedy of the Commons”. It became incredibly popular. The popularity grew so much that many refer to it as a given, a law. As with Conway’s Law, there was no scientific basis to assume it was unavoidable. But what was the article about?
A research paper, exploring the concept of the tragedy of the commons by Charles Anukwonke, reflects upon the original article and its history, posing the following crucial questions:
-
Will shared resources always be misused and overused?
-
Is community ownership of land, forests and fisheries a guaranteed road to ecological disaster?
-
Is privatization the only way to protect the environment and third world poverty?
Many in the software product development world also refer to the original paper to answer the above questions. Instead of land, forests, and fisheries, we talk about software components and its ownership. The tragedy of the commons states that shared ownership will inevitably lead to a degradation in the quality of shared parts. Or, as is popularly stated: “If everybody is responsible, then nobody is responsible.” It became “common sense”.
As stated in the above-mentioned paper, Elinor Ostrom refuted this myth of the tragedy of the commons with her research and the book Governing the Commons: The Evolution of Institutions for Collective Action. She was the 2009 Nobel Prize winner for her work in this field.
In short, with the right set of conditions (as we explore in this book), teams will take responsibility for shared components, and quality will not degrade but improve.