Why Scaling Bottom-up? How Teams’ Interactions Should Impact the Organizational Structure

Hi all, I'm happy to be here talking about Teams interactions and the important role they play on proper scaling and reorienting processes. In the next 20 minutes, I'll talk a bit about Teams as means of delivery, Teams interactions, and the importance of DDD for Fast Flow. Let's start!

So the first question is, why? Why is the organizational layout and Teams interactions important? Well, Mr. Mel Conway observed a behavioral pattern that would end up levelling up to a law. Conway's law is the observation that the design of any system is significantly affected by the communication structure of the organization that developed it, and is a consequence of the fact that two software modules A and B cannot interface correctly with each other unless the designer and implementer of A communicates with the designer and implementer of B. Thus, the interface structure of a software system necessarily will show a congruence with the social structure of the organization that produced it.

This has significant impacts on how software is built, especially if micro-services and more domain-driven design are adopted, and this is directly related to the organizational shards that companies usually have. The problem with org shards is they provide a team single view, with the relation between teams and lines of reporting, but usually the communication patterns are not up and down the reporting line, they are parallel and throughout the shard, which makes communication efficiency the key to effective teams. We'll go to wherever we need to solve our problems, and this creativity and problem solving method needs to be turned in the benefit of the organization, not restricted to up and down lines of reporting.

So how can we solve the org shard problems? Problem thinking is a holistic approach process that is always repeating itself, always trying to optimize for the whole, considering the overall flow of work, identifying bottlenecks and removing them. And now back to our initial point of communication. Common organizational bottlenecks are busy team structures, poor communication and slow delivery pace, and I think that we all have been through, if not all, some of them. The overall goal is for the architecture to support the ability of teams to get their work done from design to deployment, without requiring high bandwidth communication between teams. And I guess that this is the nirvana of the organization, right? This means each organization needs to understand which software architecture is needed before, and big capital letters here, before organizing the teams. Otherwise, the communication packs and incentives in the organization will end up dictating the software architecture, which is something that we don't want. And here we are going back to the communication topic. The more we fit teams for the desired architecture, and not the other way around, the more contained and improved communication will be, improving the efficiency of team designs by taking out the communication chaos overhead. Rearguing or scaling a company, based on this assumption, however obvious, is challenging to the top-down, as it's intrinsically related to the team's needs of collaboration and interactions, their ability to be flexible and adapt to change, and team's domains and cognitive load boundaries. Cognitive load is the limit of how much information a person, or in this case a team by joining all the members, can hold in their brains at a given moment.

So what is the goal here with this manoeuvre, how can we improve the team's structure and interactions? To start, we need to think of teams as living organisms within the ecosystem, with individualities that respond to increasing motivators. These motivators are usually a three-element reference, and they are autonomy, mastery and purpose, which when enabled within strong bounded responsibilities, allows quality and increased speed of lavour. Why? I do this question a lot. Well, when teams are loosely coupled and highly cohesive, it means that they are autonomous in the context they work, context which is restricted in responsibilities and adapted to their cognitive load, limiting the switching efforts, thus increasing focus and quality. You may have heard these terms before and they apply the same. So the loose coupling is when components do not hold strong dependencies on other companies, and high cohesion is when components have clearly bounded responsibilities and their internal elements are strongly related. So these concepts apply on all scenarios the same. Also, the clear set of domains of responsibility pushes back the jack-of-all-trades master-of-none mindset, avoid forcing teams to juggle requests and priorities from multiple sources. In summary, proper team landscapes that put teams first positively influence responsibility boundaries, speed of delivery, quality of work, and autonomy, which consequently directly impacts the software the teams produce. Built on top of Conway's law, Team Topology book mentions two core concepts that help to use team landscapes to rethink the company's organizational shards, and the concepts are 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.

We have a stream-aligned team, which is aligned to a flow of work from usually a segment of a large business domain. We have the enabling teams that help stream-aligned teams to overcome obstacles, and they also detect missing capabilities. We also have complicated subsystem teams, where significant mathematics, calculation, or technical expertise is needed. And last but not least, we have the platform team, which is 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 aspects of organizational and strategic thinking, to allow these team topologies to interact properly, some interaction modes are suggested as presented in the next slide. And again, going back to the communication problems where we started, how can effective teams collaborate and communicate? Dependencies will exist, the loser, the better, but they exist and we will not be able to make them go away. How can we simplify our lives? How can we communicate to build upon a good team structure?

In the book, again, the three essential team interaction modes go as follows: meaning working closely together with another team, which is the driver of innovation and rapid discovery, but tends to blur the boundaries. It's a really good communication mode for rapid discovery of new things that avoids costly handing-offs between teams. We also have the mode of X as a service, meaning consuming or providing something with minimal collaboration, which 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 a shared component that can be provided as a service. And last but not least, facilitation, meaning helping or being helped by another team to clear impediments which senses and reduces gaps in capabilities. It's good when one or more teams benefit from the active help of another team facilitating or even coaching some aspect of their work. Bottom line is, all these concepts, both fundamental topologies and interaction modes, end up being a rule of thumb when it comes to think about loosely coupled and high cohesive teams working together in a proper flow of change.

Bottom line is, all these concepts, both fundamental topologies and interaction modes, end up being a rule of thumb when it comes to think about loosely coupled and high cohesive teams working together in a proper flow of change. At this point, we have been through the importance of having a clear vision for the design software architecture to then fit the teams as organisms that are as effective as the boundaries they are given and communication strategies they apply. We have also discussed interaction modes that improve communication, but what about the cognitive load? What about the team's boundaries and responsibilities? Well, Eric Evans, which is a widely known software architect and author of Domain Driven Design book, aligns with the observation that flow is difficult to achieve when each team depends on a complicated web of interactions with many other teams. When the responsibility boundaries assigned to the teams is not viable or well-defined, it results in lack of ownership, disengagement and slow delivery rate. Is there a solution? Yes! Exploring and validating boundaries of responsibility, taking into consideration the team first, is what we will discuss next. Research by Accelerate found that the tightly coupled architectures negatively influence the capacity of having autonomous teams with clear responsibilities. 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 that 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 until development, 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 do we consider the teams' needs? How do we account for their angle? We think about domains, by applying a well-known strategy that enables teams' full ownership. We explore and discuss domain-driven design, and then assess how the teams will fit on those. This means, again, it feels like I'm repeating myself, but this is really important, that the organization needs to understand what software architecture is required before organizing the teams. Otherwise, as already mentioned, the communication paths and incentives in the organization will end up dictating the software architecture. But first, taking a step back, what is a domain? We know that good boundaries minimize cognitive load, right? But what are these boundaries? Boundaries are conceptual lines that wrap around domains, and domains are larger applicable concepts than software sites, helping us to think across the board and use common heuristics. The fact they provide a vision on the problem being solved makes it also easier to assign complexity to a domain, which in turn makes it easier to assign to the teams according to their available cognitive load. This enables domain-driven design, providing some software development techniques that address both strategic planning and strategic and technical design, keeping the alignment with the business, fostering ubiquitous language and a proper complexity evaluation, which in the end provides clear benefits, team ownerships, engagement and fast flow of delivery.