Conway’s Law is a powerful underlying philosophy that informs how modern software organisations organise. Any system you build is actually a mirror of the system you use to build it.
Therefore, the corollary is that it’s possible to design an organisation that informs your target architecture.
This learning should be table-stakes for any software development organisation.
However, in the paper “How Do Committees Invent?“, Mel Conway states in his conclusion:
Ways must be found to reward design managers for keeping their organizations lean and flexible. There is need for a philosophy of system design management which is not based on the assumption that adding manpower simply adds to productivity. The development of such a philosophy promises to unearth basic questions about value of resources and techniques of communication which will need to be answered before our system-building technology can proceed with confidence.
Here is a (valid at the time) assumption that we need teams and we need managers in order to successfully build complex systems.
Deconstructing the Team
A lot has changed in the software world since 1967. Computing power has increased out of all comprehension, the number of programming languages has exploded and the advent of collaborative open-source software meant that effort in software engineering has received a force-multiplier. We now have frameworks and infrastructures on demand which enable even individuals or very small teams to acheive global reach.
Instagram was famously built with a tiny team and neither of the original co-founders had software engineering backgrounds. Their approach was to ensure that they didn’t overengineer solutions but focus totally on the customer.
“If it solves a problem and gets us closer to launch, let’s do it.”
Kevin Systrom and Mike Krieger, Instagram Founders
At the time of the Facebook acquisition, with 30 million users, Instagram had just six engineers.
Conway had already alluded to the power of people in his paper. He shows that individuals also choose what to build in a system and as the influence of the individual grows (through this technology force-multipler) the smaller the team needs to be. The silos tend to become people-sized.
Where is the Team?
So fundamentally, does there need to be a team? Can we shrink our ‘silo’ down to a single person and therefore our organisation to only a handful of people-sized teams?
As technology improves, the effort of a single person is amplified. It is come to a point now that a single, cross functional, ‘full stack’ engineer is able to assemble an effective solution themselves without relying on other teams or individuals to supply a solution for them.
Therefore, the necessary team size for creating an effective solution is effectively shrinking. It depends on the task complexity, it depends on the customer and it depends on the maturity of your engineering organisation. But ask yourself, when was the last time you wrote any serious software? Are you more of a plumber of DevOps pipelines than you are a software engineer?
Does the force-multiplication effect of decades of work from other software engineers already do a lot of your job for you?
There is a huge opportunity for software engineers to speak directly to customer problems through simplified, cloud-native architectures or (even better) integrating third party services. We just need to redefine what it means to be a software engineer.