Why should you scale bottom-up in your organization?
How teams’ interactions should impact the organizational structure.
We all have been through companies’ reorgs, probably more than once. If some are understandable and produce good outcomes, others aren’t — creating insecurities, lack of confidence in leadership, unnecessary changes, and even more complex paths of communication or decision-making. What is the difference, then? Is there a well-proven way of scaling or changing the current landscape of companies’ organizations? Yes, there is.
The Conway’s Law
Conway’s Law is a theory by Melvin Conway in 1967, stating that:
“organizations, who design systems, are constrained to produce designs which are copies of the communication structures of these organizations.”
This means that an organization’s output will be directly related to how it communicates internally - small distributed teams are most likely to produce modular service-oriented architectures. In contrast, large colocated teams are most likely to create monolithic architectures.
Reorging or scaling a company based on the above assumption, however obvious, is challenging to do top-down, as it’s intrinsically related to teams’ domains and cognitive loads* boundaries, needs of collaboration and interactions, and their ability to be flexible and adapt to change.
*cognitive load — refers to the amount of information the working memory can hold at any given time. Most people can handle a cognitive load of between 3 and 7 separate pieces of information.
The importance of Teams’ landscape
Built on top of Conway’s Law, “Team Topologies” mentions two core concepts that help to use the teams’ landscapes to rethink the company organizational chart: fundamental topologies and interaction modes.
In summary, what are the best topologies teams’ can work in? The authors suggest four fundamental topologies that go from business to platform-oriented teams:
- Stream-aligned team: aligned to a flow of work from (usually) a segment of the business domain;
- Enabling team: helps a Stream-aligned team to overcome obstacles. It also detects missing capabilities.
- Complicated Subsystem team: where significant mathematics/calculation/technical expertise is needed.
- Platform team: a grouping of other team types that provide a compelling internal product to accelerate delivery by Stream-aligned teams
As communication and interactions between the teams are the most critical aspect of organizational and strategic thinking, to allow these team’s topologies to interact appropriately, some interaction modes are suggested, as follows:
- Collaboration: working closely together with another team; this mode is the driver of innovation and rapid discovery (avoiding costly hand-offs between teams) but tends to blur the boundaries ;
- X-as-a-service: consuming or providing something with minimal collaboration; this mode keeps clear responsibilities with predictable delivery but needs good product management — it’s a great choice when there is a need for one or more teams to use shared components that can be provided “as a service.”
- Facilitating: helping (or being helped by) another team to clear impediments, which senses and reduces gaps in capabilities; it’s a suitable communication mode when one or more teams benefit from the active help of another team facilitating (or coaching) some aspect of their work.
These concepts together produce immediate structural outcomes, such as:
- Decoupled teams (long-lived teams that collaborate effectively), which balance safety and speed more effectively, with cognitive load adapted to the team’s capabilities and not the other way around;
- Strong bonds (keep together things with strong relationships) to allow teams to don’t hold strong dependencies on each other, fancying loose coupling, producing clear bounded responsibilities, with strong related internal elements, allowing high cohesion;
Moreover, teams are living organisms within the ecosystem, with individualities that respond to intrinsic motivators (such as autonomy, mastery, or purpose). These motivators enable quality and increase delivery speed when enabled within strongly bounded responsibilities. Loosely coupled and highly cohesive teams are autonomous in their work’s restricted and adapted context, thus limiting the context switching and increasing their focus and quality.
Also, the clear set of domains of responsibility pushes back the “jack of all trades, master of none” mindset, avoiding forcing teams to juggle requests and priorities from multiple sources.
In summary, proper team landscapes (that put the teams first!) positively influence responsibility boundaries, speed of delivery, quality of work, and autonomy, which consequently directly impact the software they produce.
Software Architecture and Team-First thinking
Research by Accelerate found that tightly coupled architectures negatively influence the capacity of autonomous teams with clear responsibilities.
“Architectural approaches that enable this strategy [of supporting team’s full ownership from design to deployment] include the use of bounded contexts and APIs as a way to decouple large domains into smaller, more loosely coupled units.” — Accelerate researchers
Many problems in delivering software come from unclear boundaries between teams and their responsibilities, which is often shadowed by a software architecture with high coupling between its different parts — something monolithic architectures indulge. The ultimate goal for every architecture is to support the ability of teams to get their work done with high throughput — from design through deployment — without requiring high bandwidth communication between teams, which by nature is harder to achieve in a monolithic architecture.
But in the process of moving away from monolithic software, how to consider the teams’ needs? How to account for their angle?
Well, we think about domains, boundaries, and cognitive loads, by applying a well know strategy that enables the team’s full ownership: to explore and discuss domain-driven design and then assess how the teams will fit in those. This means each organization needs to understand what software architecture is required before organizing the teams; otherwise, the communication paths and incentives in the organization will end up dictating the software architecture, which leads us back to the communication and interaction topic: the more “fitting teams in the desired architecture” (and not the other way around) thinking, the more contained and improved communication will be, improving the efficiency of the team designs by taking out the communication chaos overhead.
A Practical Example on OLX Group
Every company needs an organizational chart, especially big corporations acting in several different types of markets all over the world. The online classifieds business is no different, and in OLX Group, there is a specific Customer Unit to represent the car selling/buying market: Motors Customer Unit. This Unit represents individual buyers and professional sellers, aiming to match them to conduct business. As you can imagine, what started small is now a huge business, where people are empowered to make faster and better decisions and deliver better features quicker with low rates of problems for the users.
With more teams, markets, and competition, Motors’ software architecture is now at the point where the monolith that served and brought the Unit here no longer works. At this point, the monolith hinders our efficiency from being even faster and better. For example, high-coupling and diffuse boundaries constantly put our teams in each other’s way, forcing a strong alignment commitment at all times. The progress of business features is also affected, as every change triggers impacts in other teams, slowing down the delivery — and even the quality, as the impacts, often lead to small steps of delivery or even a compromise between the parts. The pace of delivery is also affected by the monolith, as every deployment has a high probability of stopping the pipeline due to the high number of changes, impacting everyone needing to deliver.
In an effort to enhance independence, the group of teams working to enable professional sellers’ business growth through vehicle acquisition, management, and sales (aka Professionals Tribe) decided to put in motion a plan to move away from the monolith by putting together a group of experts in DDD to help the teams’ getting a better insight of their responsibility boundaries and identify the needs to move to a decoupled architecture, allowing autonomy, independent work, and defined responsibilities.
But what are these boundaries? And why are they so important?
As already mentioned, good boundaries minimize cognitive load. Boundaries are conceptual lines that wrap around domains, and domains are larger applicable concepts than software size, helping us to think across the board and use common heuristics. As boundaries provide a vision of the problem being solved, it also makes it easier to assign complexity to a domain, which in turn makes it easier to assign to the teams according to their available cognitive load.
Identifying the boundaries is the groundwork needed to enable domain-driven design, providing sound software development techniques that address both strategic and tactical design.
Strategic design helps to understand what are the most important software investments to make, what existing software assets to leverage in order to get there fastest and safest, and who must be involved. This strategic design then involves reviewing current domains using event-storming sessions to define bounded contexts and context maps, using entities, aggregates, and domain events to redefine the current architecture, and aligning each domain’s responsibilities to the present cognitive load of teams’ resources.
Based on this DDD work, we expect to have solid grounds to review our current architecture aligned with the DDD building blocks and principles of modularity, high cohesion, low coupling, and abstraction/information hiding during next year — and in the end, reorg our Tribe chart according to teams’ domains and interaction modes, so that we achieve low overhead of communication and fast decision-making, fast and quality delivery, and allow our teams to have autonomy, sound mental health capacities, and expertise in the domains they are responsible for.
Thank you for reading!
