Technology Keys to Building a Disruptive Networked Business
The Balancing Act: Network Security and Connectivity
The Unexpected Virtues of Open Data
When Should I Consider Using Agile Methodology?
Zero-Code Application Development Lets CIO and COO Work Together Again
Mike Gundling, VP of Product Management and Marketing, TerraGo
DevOps - Modern Slogan or a Practical IT trend?
Vladimir Kuptsov, Sr. Director, Infrastructure, HMSHost
Thank you for Subscribing to CIO Applications Weekly Brief
Conway's Law in the Era of Agility
By Nick Caldwell, Former VP Engineering, Reddit, Inc
The simplest way to understand Conway’s Law is that your software architecture and product is going to be a reflection of your organizational chart.
Some managers misinterpret Conway’s Law as cautionary: don’t ship the org chart. The reason is that a product team which becomes too focused on a particular part of the software architecture will lose sight of the bigger picture. Software needs to have a purpose. We aren’t shipping technology and features in isolation, we are shipping a complete solution to some customer’s problem. Ideally, customers experience one consistent product vision rather than a collection of modules that feel glued together by different teams.
While that’s an important and humbling truth for product teams to remember, it isn’t what Conway’s Law is about. Conway was telling us that there is natural and unavoidable symmetry between an org chart and product. Since we are always shipping the org chart and we should continually make sure we have the right one to meet our customer’s needs.
The Inverse Conway Maneuver
If products reflect the org chart, then why not flip the script? The “Inverse Conway Maneuver” recommends evolving your team and organizational structure to promote your desired architecture.
Or put another way: start with the product you want to make, next define the teams necessary to construct it, and the right software architecture will necessarily emerge. It’s a particularly compelling idea in a world where software development is increasingly embracing DevOps and microservices.
Rather than shipping large monolithic codebases, modern products can be thought of as a web of smaller services connected by strong contracts. There may be many more dependencies to track but contracts and other DevOps standards allow services to be updated faster, deployed independently, and implemented without any internal constraints.
Taken to the extreme, there is no central architecture and what emerges is a star network of services that are organic, highly optimized, and able to rapidly evolve. Similarly, the teams owning and operating these services form a fluid network rather than a strict hierarchy. This leads me to my second favorite Conway quote
“[My idea] creates problems because…the design which occurs first is almost never the best possible, the prevailing system may need to change. Therefore, flexibility of organization is important to effective design”—Mel Conway
Conway points to the need for continual self-assessment and flexibility to address ever-changing business challenges. Engineering leaders are responsible for driving that growth and channeling it effectively. With the emergence of DevOps, microservices, and highly-networked teams we can achieve unprecedented levels of agility in both our product and organizational designs.
In the highly-networked and flexible teams of the future, the value of mission, culture, and relationships will dominate that of organization and architecture.