Why your team should work like an open source project
What Conway’s Law Means for Your Organization
Your Product follows your organizational structure
In the late 1960s, Melvin Conway postulated, that organizations design systems that mirror their own communication structure.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
What does this mean? I came across a great graphic on this by Manu Cornet, who once recorded this fact — quite apt, I think.
Once we look at how Google is structured, we see absolute similarities to their products: There is further interlocking and overlapping, quite unlike Apple. Here, everything is focused on one central system (the hardware) and everything is aligned with it.
Zach Holman is one of GitHub’s early engineers and has spoken in the past about GitHub’s decentralized and asynchronous structure. Ryan Tomayko wrote a blog post about this type of structure: Your team should work like an open source project.
By far the most important part of the talk — and what I hope people experiment with in their own organizations — is the idea of adopting the natural constraints of open source software development when designing internal processes and communications.
GitHub is structured in many ways like a set of open source projects, simply because it’s a necessity: typically for an open source project, we’re not all in the same room, nor do we work at the same hours. There is usually no top-down hierarchical management. This explains why GitHub does not focus on the centralized tools or reports. Something managers often want as a means to control employees. GitHub as a product focuses more on the needs of developers than on the needs of managers.
Now I wanted to know more
After I could really identify with Conway’s law based on my experience, I did some more research and came across some other interesting “laws” from sociologists, economists, and systems scientists:
- Brooks’s Law
Brooks’ Law describes that if you subsequently allocate resources to an already late (software) project, you only further delay the project. - Hackmans’s Law
Hackman’s Law states that the larger a group is, the more difficult it becomes for its members to work together. Worse, the group’s vulnerability to trouble increases sharply as it grows. - Goodhart’s Law
Goodhart’s Law states that when measuring becomes a goal, it is no longer a good measure. This means that if you only work according to the measurement of a goal achievement, you have lost sight of the real goal (a good product, service, etc.). - Larman’s Law
Larman’s Law states that organizations are implicitly optimized not to change the status quo of middle and top management, “specialists” and its power structures. - Parkinson’s Law
Parkinson’s Law states that a job always takes as long as the time I have to do it.
Yes, what can I say? I can put a tick behind each of these laws…and you?
