In today’s digital economy, success is increasingly built on software. Whether you’re a startup shipping new features weekly or a large corporation overseeing enterprise-scale systems, how your software development teams are organized can make or break your product. Yet despite decades of trial and error, heated debates still swirl around the best way to structure software teams. Should you build around components or features? Should teams specialize narrowly or take ownership over broader areas? How much coordination is too much?
A new study forthcoming in Information Systems Research by NUS Computing’s Provost’s Chair Professor Jungpil Hahn with his current and former students, Zhou Junjie (DISA PhD student) and Vasilii Zorin (MComp Class of 2020), and long term collaborator Professor Gwanhoo Lee (Chair of the Department of Information Technology and Analytics at American University), brings clarity to this complex conversation. Using computer simulations and grounded in rigorous theory, the research tackles a deceptively simple question with profound implications: how should software teams be structured to perform best under different types of complexity? The findings challenge conventional wisdom and offer concrete guidance for engineering leaders, project managers, and digital transformation executives.
The Real-World Problem: The Hidden Cost of Team Misalignment
Software development rarely happens in a vacuum. Teams must navigate complex technical dependencies, shifting customer demands, and internal organizational constraints. Misalignments between team structure and product architecture can lead to communication bottlenecks, slower delivery, duplication of work, and mounting technical debt.
It’s not just a matter of getting work done; it’s about how efficiently and effectively value is delivered. For companies betting their future on digital innovation, understanding the science behind team organization is no longer optional.
This study goes beyond anecdotes and buzzwords by simulating thousands of real-world scenarios. It compares how different team structures – feature teams vs. component teams, broader vs. narrower scope – perform across varying levels of complexity and coordination. The result is a nuanced map of tradeoffs that development leaders can use to design smarter, more adaptable teams.
Feature Teams vs. Component Teams: A Core Tension
At the heart of the study is a tension familiar to most software organizations: Should teams be organized around end-to-end features or around technical components?
Feature teams are responsible for delivering complete user-facing functionality; think everything required for a “personalized playlist” in a music app, from UI to backend logic. These teams tend to be more autonomous and better aligned with business outcomes. They move fast but risk architectural drift if not carefully coordinated.
Component teams, on the other hand, focus on specific parts of the system architecture, like the recommendation engine or payment gateway. They bring deep expertise and ensure technical integrity but often require more cross-team communication to deliver user-facing features.
What’s the best approach? According to the research, it depends on the type of complexity your product faces and how well your teams coordinate.
Complexity Matters: Problem Space vs. Solution Space
One of the most powerful insights from the study is that complexity isn’t one-dimensional. It exists in two distinct domains:
- Problem Space Complexity refers to the intricacy of customer needs and how different features interconnect to deliver value.
- Solution Space Complexity refers to how technically interdependent the system components are.
If your customers need tightly interwoven features, like a social media platform with real-time messaging, content feeds, and integrated notifications, you face high problem space complexity. If your product’s architecture includes deeply nested services or complex data pipelines, you’re looking at high solution space complexity.
The research shows that feature teams are generally more resilient to solution space complexity than component teams are to problem space complexity. In other words, organizing around customer needs tends to be more robust than organizing solely around system architecture.
This finding is a strong argument in favor of feature teams in many situations, particularly where speed to customer impact is critical.
Mirroring and Its Limits
The concept of “mirroring”, where team structures are designed to reflect the structure of the product itself—has long been a pillar of software engineering theory. The idea is that minimizing inter-team dependencies reduces coordination costs and speeds up delivery.
The study affirms the value of mirroring but adds important caveats. Mirroring the problem space (via feature teams) generally leads to better outcomes than mirroring the solution space (via component teams). However, as complexity increases, the benefits of mirroring decline. That’s because in highly complex environments, no team structure perfectly contains all dependencies. Sooner or later, you’ll need to talk across teams.
This is where coordination comes into play.
The Power, and Perils, of Coordination
More coordination sounds like an obvious solution to cross-team dependencies. But the research reveals that it’s not so simple. While some level of coordination clearly helps, too much can be counterproductive.
Excessive coordination creates overhead, slows down progress, and reduces the team’s ability to independently explore alternative solutions. Interestingly, the simulations showed that moderate levels of coordination often led to better outcomes than either minimal or excessive coordination. This balance allows for alignment without stifling exploration.
For engineering managers, this finding underscores the importance of tailoring coordination practices. Use tools like shared documentation, sync meetings, or dependency boards judiciously. Focus on alignment where it matters most, and let teams run independently elsewhere.
Scope Matters Too: The Case for Underfitting
Another surprising insight from the study is the performance benefit of what the researchers call “underfitting” – i.e., assigning broader scopes to fewer teams. These teams take ownership of larger chunks of the product or architecture, allowing more decisions to be made internally.
In high-complexity environments where coordination is costly, underfitting helps internalize dependencies and reduces the need for constant cross-team communication. Conversely, in low-complexity settings with strong coordination infrastructure, more specialized teams (or “overfitting”) can work well by dividing labor more finely.
This gives team architects a valuable third axis of design: not just whether to use feature vs. component teams, but also how broadly to define team ownership.
Designing Teams for Performance and Agility
The findings have clear implications for how software organizations should think about structuring their teams and managing their work.
- There is no one-size-fits-all structure. Team design must be responsive to the complexity of the product and architecture. Periodic assessments of complexity—both customer-facing and technical—should inform structural choices.
- Favor feature teams when possible. Unless your product has unusually low problem space complexity and high architectural interdependencies, feature teams often deliver faster results with greater resilience.
- Use coordination strategically. Don’t assume more meetings or alignment rituals will always help. Balance is key. Tools like shared roadmaps, interface contracts, and asynchronous communication can help scale coordination without overloading teams.
- Expand team scope when coordination is limited. If your organization struggles to coordinate effectively across many teams—due to time zones, silos, or tooling—consider forming fewer teams with broader responsibilities to absorb dependencies internally.
- Design for exploration, not just execution. In fast-moving environments, the ability to explore multiple solution paths in parallel can be a strategic advantage. Team structures should support this kind of decentralized innovation.
Implications for the Future of Software Development
As the software industry continues to evolve, these insights have far-reaching consequences. In particular, they point toward more context-sensitive models of agile, moving beyond rigid frameworks toward more adaptive, principle-driven structures.
For example, in AI-driven product teams, where models, data pipelines, and customer interfaces are tightly coupled, feature teams might need embedded data scientists, ML engineers, and product managers all working together. Componentized teams might struggle to iterate quickly in such a setup.
In large enterprises pursuing digital transformation, success may hinge on building semi-autonomous “digital pods” that own entire customer journeys, rather than technical modules. In such cases, underfitting might be the right approach to internalize complexity and speed up delivery.
Even in open-source projects, understanding how to structure collaboration—across contributors, maintainers, and users—can benefit from these lessons. Structuring according to problem space might be the key to sustaining engagement and innovation over time.
From Frameworks to Fit
This research moves the conversation about team structure from rigid doctrine to adaptive strategy. The best team configuration is not one prescribed by any single methodology, but one tailored to your specific product, technical, and organizational context.
By embracing this complexity and using tools like mirroring, coordination tuning, and team scope management, engineering leaders can architect not just great software, but great teams.
In the high-stakes world of software innovation, that might just be the most valuable code you ever write.
Further Reading: Hahn, J., Zhou, J., Lee, G. and Zorin, V. (2025) “Organizing for Software Product Development: The Effects of Team Structure, Product Complexity, and Cross-Team Coordination,” Information Systems Research, DOI: 10.1287/isre.2023.0154
