As Committees May Think!

Earlier, I wrote about the way in which a roadmap represented a discretized set of fundable investments (link), some of which were "active" and others which were potential future investments.

From the famous “How Do Committees Invent?” Conway’s Law indicates that there’s always a relationship between the organizational design and the system design. But similarly, there’s a relationship between that and the way work is laid out - the system, the organization, and the work are all connected - and must be designed in an integrated fashion.

As new work gets prioritized (especially in a iterative, decentralized and evolutionary design organization), workers end up being split between “offensive formations” which are oriented around new initiatives (often working on new components of the system which don’t yet exist) and a “defensive formations” which correspond with already-developed aspects of a system.

Thinking further on the topic, it's interesting to me how many of the common visualizations end up being different representations of three fractal entities: an organization, a system and a collection of work (who, what, and when). Many of these visualizations are monads or dyads, but I've never seen a compelling triad - probably because two-dimensional projections of a three body system are necessarily reductive.

• An organizational chart: Shows people and their reporting relationships, often struggling to represent the inherently cross-functional nature of leaf-level working teams in a more matrixed EPD organization.
• A roadmap: Shows a sequential list of projects, generally ordered sequentially in a notional representation of logical time but disconnected from wallclock time.
• A gantt chart: Shows a piece of a roadmap arranged with high-level work items swimlanes with incremental milestones and lined up with absolute wallclock time.
• A kanban board: Shows low-level work items 
• A team planning chart: groups work items by person, showing their key priority (ideally using a quadratic layout to show decreasing fidelity (1 week, 1 week, 2 week, 1 month, 2 month for a full trimester view).
• An system architecture diagram: Shows the relationships between different components of a large technical system.
• Dataflow diagram: shows how data flows between different elements of a technical system.
• An information architecture diagram: Shows the relationship between different interface elements, often related to a site map but with more visual complexity.
• Concept diagram: shows the relationship between different concepts which show up across the UI + API in different components (both services and interface elements).
• A responsibility matrix: showing assignments of people to projects or system components, often with a role (responsible, accountable, consulted, informed, owner, DRI).
• A technology tree: shows a zoomed out version of a roadmap

Common hierarchies for each level include:

• Organization: Person, Team, Group, Business Unit
• Work: Initiative, Project / Epic, Story / Task / Issue
• System: Subcomponent, Component, Component Family?

But it's interesting, because there really isn't a dynamic way to see the state of these three in a unified way someplace. Just sorta fascinating to me, because it's not a complex system, but because it's fractal, human program / product / project managers + engineers + systems engineers + architects try to keep it all together.

It's also fascinating that while code compiles into build binaries, it does not compile into system or work diagrams, though obviously there is huge amounts of source code metadata which could be used to construct these.