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.

This talk has been presented at TechLead Conference 2023, check out the latest edition of this Tech Conference.

FAQ

Organizational layout and Teams interactions are critical because they significantly affect the design and efficiency of any system. According to Conway's law, the communication structure of an organization will mirror the structure of the system it produces, impacting how software is built, especially when adopting micro-services and domain-driven design. Effective communication within and between teams is key to efficient problem-solving and operational success.

Conway's law states that the design of a system is influenced by the communication structure of the organization that created it. This means that the interface structure of a software system will reflect the social structure of the organization. The law highlights the importance of effective communication and organizational structure in creating efficient and scalable software systems.

Organizations can solve problems related to organizational shards by adopting a holistic approach known as problem thinking. This involves constantly optimizing the overall flow of work, identifying and removing bottlenecks, and ensuring efficient communication patterns that aren't limited to up-and-down reporting lines. The goal is to support teams in getting their work done autonomously from design to deployment.

The three key motivators for improving team structure and interactions are autonomy, mastery, and purpose. When teams have these motivators within strong bounded responsibilities, it leads to higher quality and increased speed of delivery. Autonomous teams are more focused, have clearer responsibilities, and can adapt better to changes.

The four fundamental team topologies suggested by the Team Topology book are: 1) Stream-aligned teams, which align to a flow of work from a segment of a large business domain, 2) Enabling teams, which help stream-aligned teams overcome obstacles and detect missing capabilities, 3) Complicated subsystem teams, which require significant expertise in mathematics, calculations, or technical fields, and 4) Platform teams, which group other team types to provide internal products that accelerate delivery by stream-aligned teams.

The three essential team interaction modes are: 1) Collaboration, where teams work closely together to drive innovation and rapid discovery, 2) X as a Service, where teams consume or provide something with minimal collaboration, maintaining clear responsibilities and predictable deliveries, and 3) Facilitation, where one team helps another to clear impediments and reduce capability gaps, benefiting from active assistance or coaching.

It is important to understand the required software architecture before organizing teams because the communication paths and incentives within the organization will dictate the software architecture if not planned properly. Having a clear vision of the software architecture helps in fitting teams as autonomous entities, reducing communication overhead, and improving overall efficiency.

Cognitive load refers to the amount of information a person or team can hold in their brains at a given moment. It's important in team interactions because high cognitive load can lead to inefficiencies and errors. Teams with appropriate cognitive load limits can focus better, have clearer responsibilities, and deliver higher quality work.

Domain-driven design (DDD) helps in improving team structure and interactions by providing techniques for strategic planning and technical design that align with business goals. It fosters a ubiquitous language, clear complexity evaluation, and well-defined boundaries of responsibility, enabling teams to have full ownership, engagement, and a fast flow of delivery.

Moving away from a monolithic architecture in OLX's motors customer unit led to enhanced independence and efficiency. It reduced high coupling and diffused boundaries, which previously slowed down delivery and quality due to constant inter-team dependencies. The transition enabled autonomous work, defined responsibilities, low communication overhead, and faster decision-making and delivery.

Vânia Santos
Vânia Santos
17 min
09 Mar, 2023

Comments

Sign in or register to post your comment.
Video Summary and Transcription
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.

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

A Framework for Managing Technical Debt
TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Top Content
Today's Talk discusses the importance of managing technical debt through refactoring practices, prioritization, and planning. Successful refactoring requires establishing guidelines, maintaining an inventory, and implementing a process. Celebrating success and ensuring resilience are key to building a strong refactoring culture. Visibility, support, and transparent communication are crucial for addressing technical debt effectively. The team's responsibilities, operating style, and availability should be transparent to product managers.
Debugging JS
React Summit 2023React Summit 2023
24 min
Debugging JS
Top Content
Watch video: Debugging JS
Debugging JavaScript is a crucial skill that is often overlooked in the industry. It is important to understand the problem, reproduce the issue, and identify the root cause. Having a variety of debugging tools and techniques, such as console methods and graphical debuggers, is beneficial. Replay is a time-traveling debugger for JavaScript that allows users to record and inspect bugs. It works with Redux, plain React, and even minified code with the help of source maps.
Building a Voice-Enabled AI Assistant With Javascript
JSNation 2023JSNation 2023
21 min
Building a Voice-Enabled AI Assistant With Javascript
Top Content
This Talk discusses building a voice-activated AI assistant using web APIs and JavaScript. It covers using the Web Speech API for speech recognition and the speech synthesis API for text to speech. The speaker demonstrates how to communicate with the Open AI API and handle the response. The Talk also explores enabling speech recognition and addressing the user. The speaker concludes by mentioning the possibility of creating a product out of the project and using Tauri for native desktop-like experiences.
Principles for Scaling Frontend Application Development
React Summit 2023React Summit 2023
25 min
Principles for Scaling Frontend Application Development
Top Content
Watch video: Principles for Scaling Frontend Application Development
This Talk discusses scaling front-end applications through principles such as tearing down barriers, sharing code in a monorepo, and making it easy to delete code. It also emphasizes incremental migration, embracing lack of knowledge, and eliminating systematic complexity. The Talk highlights the use of automation in code migration and the importance of removing barriers to enable smoother code migration.
A Practical Guide for Migrating to Server Components
React Advanced 2023React Advanced 2023
28 min
A Practical Guide for Migrating to Server Components
Top Content
Watch video: A Practical Guide for Migrating to Server Components
React query version five is live and we'll be discussing the migration process to server components using Next.js and React Query. The process involves planning, preparing, and setting up server components, migrating pages, adding layouts, and moving components to the server. We'll also explore the benefits of server components such as reducing JavaScript shipping, enabling powerful caching, and leveraging the features of the app router. Additionally, we'll cover topics like handling authentication, rendering in server components, and the impact on server load and costs.
Fighting Technical Debt With Continuous Refactoring
React Day Berlin 2022React Day Berlin 2022
29 min
Fighting Technical Debt With Continuous Refactoring
Top Content
Watch video: Fighting Technical Debt With Continuous Refactoring
This Talk discusses the importance of refactoring in software development and engineering. It introduces a framework called the three pillars of refactoring: practices, inventory, and process. The Talk emphasizes the need for clear practices, understanding of technical debt, and a well-defined process for successful refactoring. It also highlights the importance of visibility, reward, and resilience in the refactoring process. The Talk concludes by discussing the role of ownership, management, and prioritization in managing technical debt and refactoring efforts.

Workshops on related topic

Build Modern Applications Using GraphQL and Javascript
Node Congress 2024Node Congress 2024
152 min
Build Modern Applications Using GraphQL and Javascript
Featured Workshop
Emanuel Scirlet
Miguel Henriques
2 authors
Come and learn how you can supercharge your modern and secure applications using GraphQL and Javascript. In this workshop we will build a GraphQL API and we will demonstrate the benefits of the query language for APIs and what use cases that are fit for it. Basic Javascript knowledge required.
Building a Shopify App with React & Node
React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
Top Content
WorkshopFree
Jennifer Gray
Hanna Chen
2 authors
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.
Build a chat room with Appwrite and React
JSNation 2022JSNation 2022
41 min
Build a chat room with Appwrite and React
WorkshopFree
Wess Cope
Wess Cope
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!
Hard GraphQL Problems at Shopify
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Hard GraphQL Problems at Shopify
WorkshopFree
Rebecca Friedman
Jonathan Baker
Alex Ackerman
Théo Ben Hassen
 Greg MacWilliam
5 authors
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.
0 To Auth In An Hour For Your JavaScript App
JSNation 2023JSNation 2023
57 min
0 To Auth In An Hour For Your JavaScript App
WorkshopFree
Asaf Shen
Asaf Shen
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.