Conclusion: Navigating Complexity of Cognitive Load through Organizational Design

In the world of software product development, managing cognitive load effectively is not just about reducing the amount of information developers must process; it involves strategic organizational design that aligns closely with broader business goals and enhances team dynamics. This book has explored two predominant strategies for managing cognitive load: focusing ownership on specific parts of the puzzle and striving for fluid ownership with high technical excellence across the development process.

Narrow versus Broad Ownership

The practice of assigning ownership, whether narrow or broad, fundamentally influences how teams interact with their work and each other. Narrow ownership tends to optimize for individual or small team comfort, allowing for deep expertise within a confined scope but often at the cost of greater cross-team dependencies and less flexibility. This can speed up developments within a small scope but doesn't necessarily translate to overall business agility or responsiveness to market demands.

On the other hand, broad ownership or even a lack of defined ownership extends the focus on specific technical tasks to encompass customer impacts and business outcomes. This approach not only facilitates a quicker validation of business hypotheses through direct customer feedback but also reduces unnecessary resource management and bureaucratic overhead. It fosters an environment in which learning and adaptability are at the forefront, encouraging teams to continuously evolve their skills and knowledge.

Technical Excellence and Continuous Learning

Focusing on technical excellence, this book highlights the importance of maintaining high standards in coding and architecture, which becomes especially crucial in systems where developers might frequently interact with each other's code. The incentive to maintain a clean and efficient codebase is not driven by external enforcement but by a collective standard of excellence that all team members adhere to as they know their work will directly impact their peers.

Moreover, in environments where ownership boundaries are fluid, the need for continuous learning and adaptability is paramount. Teams are encouraged to expand their technical and domain expertise, embracing new challenges and technologies as part of their routine, which in turn helps in reducing the cognitive load by making unfamiliar domains more accessible and less daunting.

Cultural Implications of Structural Choices

Ultimately, the choice between narrow ownership and broad technical excellence is deeply entwined with the culture of the organization. Larman's Laws of Organizational Behavior explain that the structure of an organization profoundly influences its culture. A structure that limits ownership may lead to a culture of silos and guarded domains, whereas a structure that promotes shared responsibilities and collective outcomes fosters a culture of openness, collaboration, and mutual accountability.

In conclusion, the strategies discussed in this book are not merely operational choices but foundational elements that shape the cognitive landscapes of development teams. By carefully choosing and integrating these strategies, organizations can craft a development environment that not only manages cognitive load effectively but also drives innovation, quality, and satisfaction among its members. The path forward lies in recognizing and implementing organizational designs that align with the desired outcomes, ensuring that teams are equipped not just to handle their current tasks but to thrive in an ever-evolving technological landscape.

For your convenience, here are the two organizational design patterns side by side:

Narrowing Scope to a Technical Piece of a Customer Solution This is about giving ownership to technical pieces of an entire customer solution. The narrower the scope, the more of the pros and cons will manifest; the broader the scope, the less they will manifest. High technical and domain expertise for what is owned. Motivated and proud of “ownership” (direct effect that does not require others outside the team). More autonomy in how things are being built but not in what features to build, and requires high collaboration or communication with others in the domain of business analysis, overall solution architecture, etc. Less ownership of the overall architecture of the solution (generally given to another unit in the organization, policing the others). Disconnect from real customer needs and problems (generating business outcomes). Reuse of internal software libraries and business logic mainly driven by external documentation and policies (must use platforms owned by others, policing, extra dependencies, etc.). Refactoring capabilities are bound to the ownership that is given. Faster to build the piece of the puzzle but slower to discover if what is built is truly useful for their customers and business. More complex organizational structure due to the separation of concerns (overall architecture, business value, customer happiness, integration, quality, coordinating on dependencies, etc.). Requires resource management practices to balance expertise with business needs.

Broadening Scope to Encompass Everything Needed to Own Customer Impact Collective code ownership: all teams have access to everything required to deliver a customer impact. Better understanding of customer needs and problems (generating business outcomes). Building technical and domain expertise regarding a piece of the puzzle highly depends on the duration of focus on that part. Motivated and proud of “customer impact” (delayed effect and requires teams to directly interact with customers). More autonomy in what features to build but not in how to build, and requires high collaboration across teams' growing features. Multiple teams work on the same outcome. (*) Alignment needed on how to build things across the entire solution (generally achieved by means of temporary communities creating policies and guidelines). Higher frequency of touching somebody else’s code, which becomes an incentive to develop proper code and architectures. Reuse of internal software libraries and business logic mainly driven by collaborative design workshops (refinements). Able to engage in significant structural refactoring of their solution. Able to use business trend metrics to evaluate their own contributions. Slower to build the different pieces of the puzzle (due to alignment needs) but faster to discover if what is built truly drives business forward. Requires the continuous learning of different, sometimes new, technology and domains (germane cognitive load).

(*) Take into account https://en.wikipedia.org/wiki/The_Mythical_Man-Month—there are no infinite possibilities here. From experience, 4-7 teams working on the same outcome at the same time is about as good as it gets. When operating with more than seven teams, it is wise to have other outcomes and focuses within different groups of teams. One could take inspiration from LeSS’s requirement areas; Scrum PLoP’s value areas, or similar patterns. Some of our clients have a fluid team of teams collaborating as one on a customer or business outcome of their choice. Re-teaming teams (not individuals) is frequently based on customer or business needs at that moment in time, a bit like a FaST collective would do, except that it’s not executed on a feature basis; it’s carried out on an outcome basis. Equally, it’s executed on a team basis, not on an individual basis.