EN 30: Turning the structure inside out

Lately, I’ve been thinking about a common pattern around how we tend to structure our codebase and teams: we favour organizing things around technical responsibilities or by function/skills. It might be a bit of a massive stretch, but in my mind there’s a thread connecting the two—technical responsibilities and split by function.

Let’s see this pattern in the codebase first with a few examples.

Once upon a time, there was a legacy codebase. Based on the folder names, it looked like it was referring to Domain-Driven Design concepts: aggregates, entities, services, repository… Inside, you could see things like OrderAggregate, OrderService, OrderRepository and all kinds of interfaces (IStuff). When I went to see an aggregate it was mostly empty, referring to some other code, and that code was mostly empty, referring to some other code. Travelling the maze of indirection, at the end, I finally saw something meaty. When it was time to extend the logic, it was necessary to unravel the maze, adding interfaces on top of interfaces. This is also a perfect example of an anemic domain model.

The worst part of the indirection maze was that, often, some paths were far from obvious, causing wasted time investigating how to go to the next step.

We’ve organized things by “technical concepts”, categories or by function.

Looking at the teams and the organization, a similar thing can happen. There are plenty of companies with separate front end and back end teams, or separate QA or design departments. Of course, we have the usual marketing and sales teams, or even the infamous DevOps team. We tend to structure the organization into functional silos, making departments by the skill or function they do. We create moats around the functions and limit the collaboration with other kingdoms via queues of work (email or Slack messages, tickets…).

The thing is, you could group front end and back end teams by their shared value streams, but it’s not apparent from the way they are structured that these groups have common outcomes. We can include in these streams the QA and Design team and any other that participates in the production of the product or part of the product.

Let me move to the realm of schools for a second. Based on my little understanding of how schools are organized in the UK, they have separate departments and functions such as attendance or self guarding. Functional silos again. Deep down, these silos share similar goals and should collaborate and communicate effectively to achieve those goals.

Organizing teams by function makes the value stream and shared outcomes hidden. Teams can work on their parts alone, but don’t have a sense of the whole and can’t act on the whole together. Collaboration is stagnant, communication doesn’t flow freely and transversally.

When I look at this, either the codebase or company structure, my mental image of the solution is to turn it inside out, to get what’s shared between the teams or the codebase out of obscurity and make it explicit.

For the codebase, what’s shared, or the umbrella that connects the technical concepts is what produces value, the business flows or, in the case of the UI, the components that the user sees.

For the teams, the umbrella that connects the functions is, again, what produces value, the value stream. Instead of having separate back-end, front-end, QA and design teams (and marketing, sales, etc.) we create a team around the value stream, that owns the outcomes and can act swiftly end to end. The incentives of the new team are aligned, they don’t compete for time or communicate via queues.

Interesting links

• The Siren Song of the ‘User’ Model. Read this article by Chelsea Troy yesterday, and knew I wanted to share it. She argues that the concept of a ‘user’ is extremely vague, not really useful for modelling, and we should avoid it as much as possible.

• Why Startups Fail and How You Can Avoid That. This episode of the Product Thinking Podcast has Melissa Perri speaking with Tom Eisenmann, Professor of Business Administration at Harvard Business School, about six ways startups fail.

• How modular can your monolith go? Chris Richardson, the author of Microservices Patterns—a book I’ve been reading and learning from for a while—is writing a fantastic series about modular monoliths. It shows us how to stretch the monolith to avoid prematurely doing microservices.