Simplification Through Modularization
Simplification Through Modularization
Leading a Change With Slowification, Simplification and Amplification, part 3
For engineering leaders, leading change isn't a one-time event but an ongoing initiative. As I've discussed in my previous two articles, we must continually strive to improve and compound the outcomes of our work.
This is the third in a series of five articles, where I explore three critical aspects of the transformation process:
Slowification: Making the problem-solving process easier.
Simplification: Making the problems themselves easier.
Amplification: Highlighting problems loud and clear.
These concepts were introduced in the book, "Wiring Winning Organizations," which I recommend as a comprehensive source of knowledge. Here, I’ll provide a concise overview, supplemented with examples from my own experiences.
In this article, I'll focus on the process of Simplification through Modularization and its underlying principles.
Here, you can find a PDF cheat sheet summarizing this article.
Links to the other articles in the series
Simplification through Modularization (this article)
Amplification (coming soon)
Dunbar's Number
Dunbar's number, a concept proposed by anthropologist Robin Dunbar, suggests that humans can maintain stable relationships with a limited number of people—typically around 150. Beyond this threshold, managing relationships becomes challenging, and group cohesion often deteriorates.
There is some criticism of Dunbar's number, such as:
Depending on various factors such as cultural differences and technological advancements, the number can be higher or lower than 150.
In the age of social media, we can maintain contact with hundreds or even thousands of individuals (but with different quality and depth).
The concept of a "stable relationship" is open to interpretation, and it may be difficult to define precisely what constitutes a meaningful connection.
Despite these criticisms, the core idea behind Dunbar's Number—that there are cognitive limits to the number of meaningful relationships one can maintain—remains relevant in team dynamics. With that in mind, we should build our organizations in a way that simplifies teams configurations and communication between individuals.
For example, Amazon’s famous "Two-Pizza Team" rule enabled the company to maintain agility and foster innovation despite its massive scale. Structuring teams, with Dunbar’s layers in mind, facilitates better communication, increases accountability, and strengthens bonds among members.
Here are the mentioned layers:
Support Clique: The innermost circle, usually consisting of about five individuals. These are the people you turn to in times of crisis.
Sympathy Group: Includes around 15 people, comprising close friends and family members with whom you maintain regular contact and share emotional support.
Active Network: This layer encompasses around 50 people, consisting of friends and colleagues with whom you interact frequently, though with less emotional intimacy than those in your sympathy group.
Even though we operate in a specific, work-related environment, it’s not hard to observe certain characteristics of each of these layers, depending on the team size. Just look around in your company.
Personal side note: When I was promoted from a team lead role (Engineering Manager) to a broader role (Engineering Director / Head of Engineering), the relationship with my existing teammates shifted from a Support/Sympathy group to something closer to an Active Network, and our initial emotional intimacy diminished (as I mentioned in my older blog post: You are you, but they don’t see you this way anymore).
Three Layers and Dunbar's Number
In previous articles, I mentioned the three layers of focus in engineering transformation:
Layer 1: Technical Objects: Focuses on the actual artifacts being worked on, such as code, libraries, algorithms, APIs, interfaces, data structures, UI components, and more.
Layer 2: Tools and Instrumentation: Involves the tools and systems used to manage, develop, and monitor the technical objects from Layer 1 (IDEs, CI/CD, observability & monitoring platforms, and more).
Layer 3: Social Circuitry: The processes, standards, and communication patterns that guide how people work together (organizational culture, team dynamics, leadership practices, etc.).
Changes to Layer 3, rather than Layers 1 or 2, can be the primary driver of engineers' productivity. Combined with Dunbar's Number concept, you can see that Simplification Through Modularization isn't just about splitting your code into microservices or modules—it's about organizing engineering teams into support cliques or sympathy groups and the distributed architecture derivative of that approach.
Simplification Through Modularization
In the previous article, we explored the concept of Simplification through Incrementalization, which involves separating the novel (untested and new) from the known (validated and stable).
Simplification Through Modularization approaches the problem from a different angle. It involves breaking down large, complex systems into smaller, self-contained modules. These modules interact with each other through well-defined interfaces, allowing each module to be developed, tested, and maintained independently. This approach not only reduces complexity but also enhances scalability, maintainability, and team autonomy.
Amazon's Two-Pizza teams, as mentioned earlier, embody this approach. Their famous mandate stated:
1 - All teams will henceforth expose their data and functionality through service interfaces.
2 - Teams must communicate with each other through these interfaces.
3 - There will be no other form of interprocess communication allowed.
…
6 - Anyone who doesn’t do this will be fired.
This strict enforcement of modularization allowed Amazon to scale massively while maintaining the agility of smaller teams. Each team could innovate and evolve their services independently, without being bottlenecked by other parts of the system.
This is an example of how modularization can transform an organization's ability to scale and innovate.
Modularization in Practice
The technical implementation of modularization takes many forms in software engineering. Microservices Architecture, Micro Frontends, Plug-In Architecture (e.g., IDEs like Visual Studio Code are highly customizable through plug-ins), or Modular Monoliths (check out
’s writings on Shopify's approach) are just a few examples.Here, rather than diving into technical details, I want to focus on structuring your decomposition efforts.
Domain-Driven Design
Modularization isn't just about breaking things down—it's about doing so in a way that maintains coherence and allows for seamless integration. One of the most effective frameworks for modularizing complex systems is Domain-Driven Design (DDD), introduced by Eric Evans.
DDD focuses on breaking down a system into distinct modules based on the business domains they represent. Here’s how you can leverage DDD to implement modularization effectively:
1. Identify Bounded Contexts
In DDD, a "Bounded Context" refers to a specific boundary within which a particular model is defined and applicable. Each bounded context should encapsulate a specific domain or subdomain, representing a coherent module that can be developed independently.
Example: In a large e-commerce platform, you might identify bounded contexts such as "Order Management," "Inventory," "Customer Support," and "Payment Processing." Each of these contexts represents a separate module, with clear boundaries defining what each module is responsible for.
2. Define Clear Interfaces Using Domain Models
Within each bounded context, create a domain model that accurately represents the business logic and data specific to that context. Define clear interfaces through which different modules can interact, ensuring that the domain logic within each context remains isolated and coherent.
Example: The "Order Management" context might have an interface that exposes methods for creating, updating, and tracking orders. Other contexts, like "Inventory" or "Payment Processing," would interact with this module via its defined interface, without needing to know its internal workings.
3. Encourage Independent Development with Domain Experts
In DDD, collaboration between developers and domain experts is key. By modularizing your system according to bounded contexts, you allow teams to work closely with domain experts to deeply understand and model the business logic relevant to their specific context.
Example: A team responsible for the "Customer Support" module collaborates closely with customer service managers to model the workflows and data structures that best reflect how support tickets are handled. This ensures that the module is both technically sound and aligned with business needs.
4. Handle Integration with Anti-Corruption Layers
When integrating modules that span multiple bounded contexts, use anti-corruption layers to translate between the models of different contexts. This prevents one context from corrupting the domain model of another and maintains the integrity of each module.
Example: If the "Payment Processing" module needs to interact with a third-party payment gateway, an anti-corruption layer could be used to translate between the external API and the internal domain model, ensuring that the external service does not introduce inconsistencies into the payment domain.
These are just a few examples of Domain-Driven Design practices, which I hope will inspire you to further exploration. For a deeper dive into DDD, there’s no better source than Eric Evans' book, Domain-Driven Design.
And for more abstract cases of domain separation, here’s a perfect quote from the book, "Wiring Winning Organizations":
"Consider the electrical outlets in your home. In this case, the modules are your home and the power company providing electrical power to you, and the interfaces are all of the electrical outlets. The Layer 3 implication is that you have independence of action (i.e., the ability to plug and unplug appliances without needing to coordinate with your power provider). Conversely, the power provider also has independence of action. They could switch from fossil fuels to renewable energy without having to coordinate with you."
— Kim, Gene; Spear, Steven J. Wiring the Winning Organization
Modularization as a Leadership Strategy
Modularization is more than just a technical decision—it is a management tool that enables a shift from top-down to center-out leadership. By modularizing your systems, you create an environment where teams can operate with greater autonomy, make informed decisions, and collaborate effectively, all within a framework that aligns with the organization’s overall goals.
This approach not only simplifies complex systems but also fosters a culture of innovation, engagement, and continuous learning.
Why is This Important?
In a top-down leadership model, decisions regarding system architecture, module design, and implementation details are typically made by senior leaders or architects. Teams are then tasked with executing these directives, often leading to bottlenecks, reduced autonomy, and slower innovation. This approach can be effective in crisis situations or when rapid, uniform decisions are needed, but it risks disengaging teams and stifling creativity.
On the other hand, center-out leadership distributes decision-making authority, allowing teams to make decisions within a framework of well-defined expectations and standards (read more about standardization and alignment in further sections).
Modularization is a key enabler of this approach. By breaking down complex systems into smaller, independent modules with clear interfaces, teams are empowered to take ownership of specific areas of the system, innovate within their domain, and make decisions that best fit their unique context.
Top-down managers act as rulers, but in fast-paced environments, they also face cognitive overload, constant urgency, and the need for a highly detailed understanding of their landscape.
Center-out managers focus on communication, facilitation, and knowledge sharing. If you wish to work in this manner, you must build mutual trust and delegate effectively. This doesn't mean working less (delegate and forget) but working smarter.
For more on how to effectively implement center-out leadership, I recommend reading my article Top-down vs. Center-out Leadership.
Modularization and Company Culture
Similar to Incrementalization, Modularization isn't just about the code—it's about how teams work together. It's about creating a culture where teams are empowered to take ownership of their modules, innovate independently, and collaborate effectively across the organization.
In companies where modularization is part of the culture, teams are more agile and can respond to changes faster. They can experiment with new ideas without waiting for approval from other teams or worrying about breaking the entire system. This autonomy drives innovation and speeds up development cycles.
In a modularized environment, your team's long-term plan isn't about building monolithic structures that last for years. It's about creating adaptable, scalable modules that can evolve with your business needs. This shift in mindset can be challenging, but it's essential for building resilient systems.
But for modularization to become part of your company culture, it needs to be embraced by everyone—from leadership down to individual contributors. This requires clear communication of the benefits, training to ensure everyone understands how to implement it, and tools that make modularization easy to manage.
In my personal experience, leading towards modularization always started with changing the way things are built in the organization, such as:
Introducing a continuous delivery process,
Measuring how each feature of the product is being used through product analytics,
Monitoring the technical stack behind the product through observability practices (monitoring, alerting, tracing, etc.),
Controlling how changes are released to customers (feature flags, early access).
On top of these SDLC practices, teams selected the appropriate architecture (e.g., mobile apps modularization, or Micro Frontends solutions).
If you want to explore these topics in detail, I recommend checking out the first part of my series: The Role of Engineering in Product Model Transformation.
Modularization Needs Alignment
Modularization aims to create independence of action for small teams focused on self-contained modules (e.g., product features). Such autonomy requires one critical thing—alignment.
It's essential to build an environment where people are free to choose their actions and ways of working but also contribute to aligned goals and adhere to commonly accepted standards. This may seem contradictory, so finding a good balance between freedom and unification often becomes an art of leadership.
There are many angles to building alignment. Here are some of my writings that shed light on this subject from different perspectives:
Non-Functional Requirements - NFRs are crucial for ensuring your software meets its functional goals while adhering to standards for performance, usability, reliability, and other quality attributes. This article provides examples and good practices for defining NFRs.
Principles - Guidelines for Your Team - Rather than dictating what people should do, promote principled leadership, which serves as a framework for decision-making and pursuing the company's strategy.
Engineering Strategy Framework - By creating a long-term plan, you provide your team with a North Star—what they are supposed to achieve. Such a strategy helps them pick the right actions when doing their job here and now.
How to Lead a Team of Senior Engineers—This blog post aggregates different techniques for leading senior engineers. The main assumption is to stop telling people what to do and instead give them expectations, problems to solve, or a purpose.
How to Build Collective Intelligence and Empower Decision-Making - A blog post that aggregates different approaches to building collective intelligence in a distributed organization.
End Words
Modularization is a key strategy for tackling complexity in software engineering. By breaking down systems into smaller, self-contained modules, leaders can empower their teams to work with greater autonomy, leading to faster innovation and more scalable solutions.
In this article, I delved into Modularization, showing how it not only simplifies architecture but also enhances team dynamics and leadership effectiveness.
In future articles, I'll explore the remaining aspects of Simplification—Linearization and look closer at the last main theme of transformation - Amplification.
Thanks for reading, and I look forward to hearing your insights on today’s topic.