In a previous article, "Why Feature Teams Beat Siloed Development: Lessons from a Cloud Migration," I discussed moving away from functional silos toward cross-functional units. Today, let's dive deeper into a more fundamental, architectural reason for organizing as feature teams—one that directly shapes the software you build.
The simple truth is this: success in software development is directly related to how individuals coalesce into a true team. Assigning names to a group and giving them tasks doesn’t magically create one.
What Makes a Team, Anyway?
A team is:
- A group that has matured enough to be effective.
- A collection of people who share goals and interact consistently to perform tasks.
If your "team" is constantly in conflict, operates with distrust, or doesn't feel united, it's not a team. If members rarely interact or pursue different—or hidden—agendas, they aren't even a group.
Effective software teams balance design, technical, and business knowledge. Location is secondary; regular, meaningful interaction toward common goals is what matters. Remote and hybrid teams can thrive, but they often require intentional facilitation to reach the maturity needed for intense collaboration. And size is a factor—most high-performing teams range from 4 to 8 members. Beyond that, you need to divide and conquer.
The Hidden Force That Shapes Your Code
But why structure teams around features or products in the first place? The answer lies in a principle that quietly governs how organizations build software.
In 1964, architect Christopher Alexander—whose work inspired software design patterns—argued that stable systems should be split into components with high internal cohesion and low external coupling. The human tendency, however, is to organize around familiar labels rather than optimal structure.
Then, in 1968, Mel Conway made a pivotal observation, later popularized by Fred Brooks as Conway’s Law:
“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”
In practice, this means developers often structure software to mirror their org chart, not architectural best practices. If you have a "security team," an "engine team," and a "UI team," you’ll likely end up with a security module, an engine module, and a UI module—whether or not that creates a secure, stable, or well-designed system.
Turning Conway’s Law to Your Advantage: The Inverse Conway Maneuver
Here's where it gets powerful. Instead of letting your organization accidentally dictate your architecture, you can flip the script. This is called the Inverse Conway Maneuver.
You deliberately design your team structure to produce the software architecture you want.
Organize teams around the components and boundaries you desire in your system. Give them names that reflect what those components actually do. Want a clean, well-defined interface between two services? Put them under separate, autonomous teams. Building a platform with a plugin architecture? Create a core platform team and dedicated teams for each major plugin.
By aligning your team topology with your target architecture, you guide the system toward better cohesion, cleaner separation of concerns, and more sustainable design.
Feature Teams as an Architectural Strategy
So when we advocate for feature teams, we’re not just talking about efficiency or morale—we’re talking about software design. A well-structured feature team, aligned to a clear product area or customer journey, naturally builds software with strong internal cohesion and intentional boundaries to other domains.
This is the intrinsic, architectural reason to move beyond silos. It’s not just about working better together—it’s about building better systems, intentionally.
Your org chart isn't just a list of names and titles. It's the blueprint of your software's future architecture. Design it wisely.
Have you seen Conway’s Law play out in your organization? How have you structured teams to shape better software? Share your story in the comments.
Good post, Paulo. I'll add that if you want good docs to go with clean feature separation then feature teams sitting in different rooms (or remote) do a better job because they don't want to walk down the hall or schedule more meetings so they write and share more docs.
ReplyDeleteThat indeed happens in practice (having to produce documentation) but there is a better way called Consumer-Driven Contract (CDC) testing, which is a collaborative process where the consumer drives the contract's definition.
ReplyDeleteFirst, the consuming team writes tests that codify their requirements for an interface and publishes them. The providing team then uses these published tests as a development guide, implementing their API to satisfy the tests. A passing test suite signals that the provider has implemented everything the consumer needs. There are tools specifically built for this purpose, like Pact: https://github.com/realestate-com-au/pact. I encourage you to check it out. Thank you for your comment!