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

Rate this content
Bookmark

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. In this session I’ll go through, supported by an actual study case in the industry, Conway’s Law and the importance of teams’ landscape and interactions, and how well-designed teams charts can improve independence, autonomy, motivation of the teams, leading to a faster and better rate and quality of delivery.

17 min
09 Mar, 2023

AI Generated Video Summary

The Talk discusses the importance of organizational layout and Teams interactions in software development. It explores the challenges of organizational shards and the need for problem thinking to optimize team communication. The concepts of loose coupling, high cohesion, and clear domains of responsibility are explained. The Talk also emphasizes the three essential team interaction modes: working closely together, X as a service, and facilitation. Furthermore, it highlights the significance of understanding domains, boundaries, and domain-driven design for efficient work and fast delivery.

1. Teams Interactions and Organizational Layout

Short description:

In this part, we discuss the importance of organizational layout and Teams interactions, as well as the impact of communication structure on software design. We explore the challenges of organizational shards and the need for problem thinking to optimize team communication. The goal is to fit teams to the desired software architecture, improve team structure and interactions, and promote autonomy, mastery, and purpose. The concepts of loose coupling, high cohesion, and clear domains of responsibility are explained. Finally, the Team Topology book introduces Fundamental Topologies and Interaction Modes as ways to rethink organizational shards.

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.

2. Team Alignment and Interaction Modes

Short description:

We have stream-aligned teams, enabling teams, complicated subsystem teams, and platform teams. Communication and interactions between teams are critical, and three essential team interaction modes are discussed: working closely together, X as a service, and facilitation. These concepts promote loosely coupled and high cohesive teams in a proper flow of change.

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.

3. Domains, Boundaries, and Domain-Driven Design

Short description:

All these concepts, fundamental topologies, and interaction modes are essential for loosely coupled and high cohesive teams. Eric Evans highlights the challenges of flow when teams rely on complex interactions. The solution lies in exploring and validating boundaries of responsibility, prioritizing the team's needs. Tightly coupled architectures hinder autonomous teams, while unclear boundaries and high coupling lead to delivery issues. To support efficient work, understanding the required software architecture is crucial before organizing teams. Domains and their boundaries play a key role in minimizing cognitive load and enabling domain-driven design. This approach aligns with strategic planning, fosters a common language, and promotes team ownership and fast delivery.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
React Day Berlin 2022React Day Berlin 2022
29 min
Fighting Technical Debt With Continuous Refactoring
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt. In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.
React Summit 2023React Summit 2023
26 min
Principles for Scaling Frontend Application Development
After spending over a decade at Google, and now as the CTO of Vercel, Malte Ubl is no stranger to being responsible for a team’s software infrastructure. However, being in charge of defining how people write software, and in turn, building the infrastructure that they’re using to write said software, presents significant challenges. This presentation by Malte Ubl will uncover the guiding principles to leading a large software infrastructure.
React Advanced Conference 2022React Advanced Conference 2022
22 min
Monolith to Micro-Frontends
Many companies worldwide are considering adopting Micro-Frontends to improve business agility and scale, however, there are many unknowns when it comes to what the migration path looks like in practice. In this talk, I will discuss the steps required to successfully migrate a monolithic React Application into a more modular decoupled frontend architecture.
React Day Berlin 2022React Day Berlin 2022
25 min
Building High-Performing Cross-Cultural Teams
Everything we do, from the way in which we write our emails, to the method in which we provide negative feedback and evaluate performance, governs the performance of our teams. And understanding how culture impacts our efficacy as a team can drastically improve our day-to-day collaboration. In this session you'll learn: How different cultures communicate, How different cultures evaluate performance and give constructive criticism, How different cultures make decisions, How different cultures trust, How different cultures perceive time.

Workshops on related topic

React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
WorkshopFree
Shopify merchants have a diverse set of needs, and developers have a unique opportunity to meet those needs building apps. Building an app can be tough work but Shopify has created a set of tools and resources to help you build out a seamless app experience as quickly as possible. Get hands on experience building an embedded Shopify app using the Shopify App CLI, Polaris and Shopify App Bridge.We’ll show you how to create an app that accesses information from a development store and can run in your local environment.
JSNation 2022JSNation 2022
41 min
Build a chat room with Appwrite and React
WorkshopFree
API's/Backends are difficult and we need websockets. You will be using VS Code as your editor, Parcel.js, Chakra-ui, React, React Icons, and Appwrite. By the end of this workshop, you will have the knowledge to build a real-time app using Appwrite and zero API development. Follow along and you'll have an awesome chat app to show off!
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Hard GraphQL Problems at Shopify
WorkshopFree
At Shopify scale, we solve some pretty hard problems. In this workshop, five different speakers will outline some of the challenges we’ve faced, and how we’ve overcome them.

Table of contents:
1 - The infamous "N+1" problem: Jonathan Baker - Let's talk about what it is, why it is a problem, and how Shopify handles it at scale across several GraphQL APIs.
2 - Contextualizing GraphQL APIs: Alex Ackerman - How and why we decided to use directives. I’ll share what directives are, which directives are available out of the box, and how to create custom directives.
3 - Faster GraphQL queries for mobile clients: Theo Ben Hassen - As your mobile app grows, so will your GraphQL queries. In this talk, I will go over diverse strategies to make your queries faster and more effective.
4 - Building tomorrow’s product today: Greg MacWilliam - How Shopify adopts future features in today’s code.
5 - Managing large APIs effectively: Rebecca Friedman - We have thousands of developers at Shopify. Let’s take a look at how we’re ensuring the quality and consistency of our GraphQL APIs with so many contributors.
JSNation 2023JSNation 2023
57 min
0 To Auth In An Hour For Your JavaScript App
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.js backend + Vanilla JS frontend) to authenticate users with One Time Passwords (email) and OAuth, including:
- User authentication – Managing user interactions, returning session / refresh JWTs- Session management and validation – Storing the session securely for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
JSNation 2023JSNation 2023
87 min
Build a Collaborative Notion-Like Product in 2H
WorkshopFree
You have been tasked with creating a collaborative text editing feature within your company’s product. Something along the lines of Notion or Google Docs.
CK 5 is a feature-rich framework and ecosystem of ready-to-use features targeting a wide range of use cases. It offers a cloud infrastructure to support the real-time collaboration system needs. During this workshop, you will learn how to set up and integrate CK 5. We will go over the very basics of embedding the editor on a page, through configuration, to enabling real-time collaboration features. Key learnings: How to embed, set up, and configure CK 5 to best fit a document editing system supporting real-time collaboration.
Table of contents:- Introduction to the CK 5 ecosystem.- Introduction to a “Notion-like” project template.- Embedding CK 5 on a page.- Basic CK 5 configuration.- Tuning up CK 5 for a specific use case.- Enabling real-time editing features.