What’s the best structure for software development teams? How should I structure my team? Should I use the Spotify Model? Which other options do I have?

The questions above and many others come to the minds of people who need to structure a new team or want to restructure an existing one. Most people in this situation believe that the simplest way to do that is to follow a recipe. That’s what we have been seeing currently in the market. For instance, the “Spotify Model” is often mentioned as a recipe for structuring a cross-functional team that works.

Although fantastic, the ideas contained in the approach shared by Henrik aren’t suitable for all cases. In order to achieve success, you’ll have to have the same ingredients – context – that Henrik had. Otherwise, you’ll have hard times implementing some of the ideas.

Read this – No, I didn’t invent the Spotify model – to understand what I’m talking about.

Some time ago I did reflect on how we usually structure cross-functional software development teams. I did the analysis based on two perspectives:

  1. Conway’s Law
  2. Flow of Value

Conway’s Law

Conway’s law says that “organizations which design systems are constrained to produce designs which are copies of the communication structure of these organizations”

According to Wikipedia:

The law is based on the reasoning that in order for a software module to function, multiple authors must communicate frequently with each other. Therefore, the software interface structure of a system will reflect the social boundaries of the organization(s) that produced it, across which communication is more difficult.

Learn more here:  Conway’s Law – Wikipedia

Flow of Value

I’ve heard a lot, and probably you as well, that Kanban is used as a tool to establish a flow and manage it. This flow isn’t about JIRA tickets. Instead, it is means flow of value, whatever your business definition of value is.

As a principle, everything we try to optimize should be favourable to improve the flow of value and not only favourable to speed or throughput. This means not all improvements are related to speed. Some might even slow down your current speed, but that’s totally acceptable if the flow of value will be improved. We know as well from Systems Thinking that local optimizations, such as focusing only on increasing throughput – are not the best way to optimize a system, especially a complex one.

There’s a fantastic book called Principles of Product Development Flow, which is not fun to read I have to say, that is super insightful and highly recommended for those who want to know more about what flow really means.

The Principle

The two ideas aforementioned helped me to formulate a principle to guide my analysis.

Cross-functional team’s structure should have Flow of Value as a principle and fight Conway’s law to avoid knowledge segmentation and enable the creation of a learning organisation. Click to tweet

The Question

Based on the principle above, I decided to explore the following question during this analysis:


How should cross-functional teams be structured to allow for a flow of value and to fight against Conway’s law?


I’ll continue the analysis in the next parts of this article. Sign-up below to know the answer and suggestions on how to improve your cross-functional team setup.