Reverse Engineering Conway’s Law
The lecture of Jacob Kaplan-Moss’ blog post, “Designing Engineering Organizations” triggered quite a few interesting conversations internally, and I would like to expose in a few lines our opinion about the subjects discussed therein. (If you haven’t read this article, please do, we’ll wait for you here.)
In a nutshell, and basing his reasoning on top of Conway’s Law, Jacob (former director of security at Heroku, and creator of the Django web framework) explains in detail a very simple definition for effective teams:
Summary: the most effective teams are stable, multi-disciplinary, aligned to product delivery.
Fifty years after Melvin Conway coined it, Conway’s Law is being “rediscovered” once again by teams all over the world. The rise of DevOps and in particular microservice architectures have been (in some cases, painful) demonstrations of its reality and its applicability.
In a world of fear, uncertainty and doubt, where software is eating the world, where every company is a software company, where all industries face the pressure of disruption, Conway’s Law got propulsed from an obscure computer science concept, to a cornerstone idea at the very root of modern business success.
The rules of business have changed. To succeed, we must reverse engineer Conway’s Law: we need to organize ourselves so that we can maximize the quality of our output, with constant, data-driven re-evaluation loops.
In VSHN we are undergoing such a major mutation, taking us towards that goal, albeit in a micro level: from technology-oriented to product-oriented teams. The objective is to stabilize our delivery cycles, and to align them to requirements through the interface of a single designed service or product manager.
This internal transformation is already showing positive results, and aligns our practices with what we believe is the best way to work with our customers.
In his article, Jacob also exposes the interrelationships required internally for such organizations to become more effective:
Larger organizations often end up needing a mix: a set of platform teams that build and maintain underlying infrastructure, shared libraries, and tooling; and a set of product teams that directly work on the product.
This is quite literally one of our core beliefs: we want to become the ideal platform team, to help our customers build and maintain the required underlying infrastructure, libraries and tooling for our customers to reach their own business goals.