This article was written by Zack Scott, Transformational CIO and Lean Evangelist with more than 20 years successfully driving Agile transformations in start-ups, SMEs as well as in corporate organisations from the bottom up as technical leader and architect as well as from top down as senior manager and executive in Europe and Australia.

In this series, Zack will look at the evolution of organisational matrix structures and propose a 3^rd dimension to create '3D Lean' - a powerful model to support your Agile Lean Transformation.

In the first part of this series you could read how engineering evolved from a rather isolated - siloed - profession of alienated specialists to a more collaborative, cross-functional team effort of still mainly technical squads.

Of course, whilst working culture evolved and started to break down generations of silos, technological development also did not stand still and continued to advance further. Machines became both more powerful and cheaper, almost reaching a state of commodity, not only giving birth to a whole new breed of X-as-a-Service but also - utilising cloud native approaches - breathing new life into Constantine's principles of low coupling and high cohesion resulting in things like SOA, microservices, serverless, containers and more.

There we were, after decades of cultural and technological advances, a solution to an organisational problem (Michael Nygard) seemed within reach. But what was this organisational problem?

The challenge: how to successfully and sustainably scale an organisation and grow its delivery output, both in volume - more and richer products - and quality - responding to customer needs - but also in delivery speed, getting these products to their customers as fast as possible?

Microservices and other technological solutions allow smaller, cross-functional agile teams - squads - to work on different features independently. Ideally, these solutions are built around business capabilities (James Lewis and Martin Fowler), and squads started to be organised and scaled in tribes aligned with business domains to follow the Single Responsibility Principle - a principle about people (Robert C. Martin aka Uncle Bob).

This form of inter-organisational alignment and cooperation resulted in a shift how solutions and systems were to be designed. Where systems design had formerly been a technical engineering-only responsibility, people now started to talk about domain-driven design DDD and behaviour-driven development BDD to cope with growing solutions complexities by deeply connecting the implementation to an evolving model of the core business concepts (Eric Evans), bringing engineers and non-engineers even closer together.

They began to design systems and solutions in collaboration whilst starting to talk the same ubiquitous business language within bounded domain contexts and making functional silos truly a thing of the past.

The technical revolution of the last half-century is to Constantine's concepts what the cultural shift from siloed engineering specialists to domain aligned product teams is to Conway's law, a contemporary of Constantine (late 1960s):

Organizations which design systems are constrained
to produce designs which are copies
of the communication structures of these organizations.

Conway's law tells us two things: Firstly, systems will always be designed in alignment with the organisational (communication) structures. Therefore, try not to create a system ignorant of the organisational design. Instead, design solutions that embrace those organisational structures with the support, for example, of domain-driven design DDD methods.

Secondly, if your systems are dysfunctional, do not look for the problem only within these systems. Maybe it is the organisational (communication) structures that need to be improved - remember those old silos? Wardley as well as value stream mapping can help to identify organisational dysfunctions.

C&C - over 50 years ago, Constantine and Conway have already defined the fundamental laws how to effectively and sustainably scale squads and tribes to an organisation's benefit.

Stay tuned for the next article of this series!

The next article of this series will focus on how following this path will continue to erode traditional organisational silos and instead support the creation of inter-organisational, truly cross-functional product teams.