Does math apply to organizations?
The transitive property of mathematics tells us that if some value A is greater than some value B, and if B is greater than some value C, then A must be greater than C. This is a simple mathematical premise we can all agree on.
Conway’s Law tells us that any organization that produces a “system” will ultimately end up producing a system with a structure that reflects the communications structure of the organization. This is sometimes harder to identify, since the scale and behavior of software can be opaque, and software tends to have some of the inertia of previous organization structures.
So I posit:
If the communications between an organization’s software services are broken, that organization’s communications structure is also likely broken.
Let me clarify what I mean by software communications being broken. Any software system that cannot start up or serve basic requests is so obviously and immediately broken that it is not worth discussing what has led to that point. The problem is likely simple and uninteresting. I’m more interested in when complex systems, produced by integration of multiple processes and services, fail to be able to keep up with the demands of their business.
What I mean is when seemingly reasonable additions or clarifications of requirements introduces this seemingly electrical effect demand team after team, SME after SME, and escalations across all levels of management in order to move mountains to deliver. Typically phrases you’ll hear in these conversations will run along the lines of:
- The system was never designed to handle that kind of requirement
- That’s outside of my domain, go talk to… I don’t know who?
- I don’t have enough context on the problem to be helpful
- The customer expected this to be delivered months ago
Often, teams are siloed with a vague intention of producing some form of local efficiency by way of specialization. Specialization is all well and good, and I prefer teams of practitioners with honed focus on particular areas of their trade. But those teams should be heterogeneously composed, their members’ specialization not being built by who they talk to day-to-day, but rather by the learning they achieve from solving their day-to-day problems.
If a software engineering team delivering a feature misses the customer needs, or fails to deliver because of misalignment of behavior with dependent services, that team is often posed a question: what could have been done differently to meet that need and do it “on schedule”? The problem is probably along the lines of: the people on that team don’t know who the customers are, and they don’t talk to the people on the teams whose services on which they depend on a daily basis. And if that’s true, the chances of the people on the dependent teams talking to the customer are even smaller.
Proposed solutions during this retrospective will often lead to suggestions of: plan earlier, identify your project’s dependencies earlier, get your dependencies’ team’s to commit earlier, and capture clearer requirements earlier. But wouldn’t it be more realistic to compose a team made up of the people who are selling to the customer all the way through to the people ensuring the solution stays up and running after its delivered? It would make those doing the solutioning responsible for understanding the customer needs, and those doing the selling responsible for the feasibility and maintenance of the solutions.
