(Re)Organizing Your Teams Using Domain-Driven Design

It is important for leaders to foster an Above the Line team culture to get the best individual performance from team members. (See my post titled Leading A (Distributed) Team? Foster "Above the Line" Behaviors for background info about this topic.) But to get the best team performance, leaders also have to organize their teams effectively.

Fifty-five years ago, Melvin Conway penned what has come to be known as Conway's Law :

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

So, the trick is to create an organization/communication structure that will produce system that best suited for the task and a way to alter that structure as the system evolves. To define product development org structures, I use a method analogous to Domain-Driven Design (DDD). In DDD, when planning how to deliver a desired overall solution, one first looks for how break it up into smaller domain models. I think of domain models as areas of boundable scope isolated from other domain models, where definable APIs/services can be used by external actors to access the underlying business logic.

Then, if leadership can identify what the domain models are at a high-level, we can then create an organizational structure that maps teams to the domain models they are responsible for. Another way to think about it is: If we know where the APIs/services need to be, we can then identify the teams who can take responsibility for delivering/operating/maintaining those APIs/services and the underlying business logic and data... and then let them have at it. This has the added benefit of reducing the amount and complexity of communication and coordination required between teams and providing a built-in structure for those interactions. This should automatically improve development velocity since dependencies on other teams dramatically reduces a team's productivity.

There are lots of online resource on DDD. But, remember, as the leader trying to create a workable org structure, you don't need to get into the deep details of DDD. You just want to get a sense of where the major boundaries of scope to map your org structure agains. Event storming is one quick-and-dirty method that you can adapt to work with stakeholders (including your and others' team members) to identify the intended software system's domain models at a high enough level to then map out a suitable org structure to match. It has the added benefit of instilling a common knowledge reference among the stakeholders about the system and underlying roles & responsibilities, so that changes to the overall system or the structure or relationship between individual domain models, and therefore to the teams responsible for them, can be handled gracefully.