The Feature Team Fallacy: Why LeSS Gets Team Design Wrong

I was facepalming out loud one day about an article on the Scaled Agile website that recommended organizing teams around complete features. During that conversation, someone pointed me to an article on Large Scale Scrum’s website that took intellectual dishonesty to a whole new level. When I asked around for clarification, it became clear that Large Scale Scrum (LeSS) agile consultants consider feature teams central to their framework.

I’m not an agile coach, and maybe that disqualifies me in some circles. But after decades of building products, platforms, and large-scale systems as a member of both feature and component teams, and after working to migrate a large organization from the former to the latter, I feel perfectly qualified to say this: the LeSS argument is wrong on both substance and experience.

Thanks for reading 5-Minute DevOps! Subscribe for free to receive new posts and support my work.

The Core Problem with LeSS’s Argument

Before diving into specifics, I need to name the pattern that runs through all of LeSS’s material. Once you see it, you can’t unsee it:

LeSS assumes extreme competence when describing feature teams and extreme incompetence when describing component teams.

If you reverse those assumptions — even slightly — their entire narrative collapses. Throughout this article, I’ll point out where this asymmetry appears. It’s the foundation of nearly every claim they make.

The second problem is methodological: LeSS asserts causal relationships between team structure and outcomes without explaining how one causes the other. Claims like “feature teams lead to better code quality” sound compelling until you ask: what’s the mechanism? LeSS never says. They simply assert and move on.

With those two patterns in mind, let’s examine the claims.

Defining Terms

The article defines a feature team this way:

https://less.works/less/structure/feature-teams

This sounds exactly like a long-lived project team — same structure, same goals — just without the disbanding phase at the end. Unsurprisingly, they later compare feature teams directly to project teams.

They never clearly define “component team,” but LeSS advocates I’ve spoken to agree with the same definition I use: a team responsible for a product sub-domain (a component of behavior) and not a layer in the tech stack (a DBA team).

I typically use the term “product team” or “product domain team” to describe this structure, but for clarity, in this article, we will stick to “component team.”

LeSS Claims

The article makes several claims without supporting evidence or explanations of why these claims have a causal relationship to team organization. However, I’ve worked in all of the structures described and have spent a fair number of years in the details of delivering software products better and helping others do that, so let’s pull back the curtains on these claims.

Component vs. Feature teams

https://less.works/less/structure/feature-teams

“Optimized for lines of code vs. maximum customer value”

LeSS claims component teams optimize for “lines of code” while feature teams maximize “customer value.”

This is a textbook false cause and false dichotomy. Team structure does not determine whether leadership incentivizes output or outcomes. I’ve seen feature teams used explicitly to maximize utilization by shuffling people around to satisfy output metrics. That misuse is easier with feature teams, but just as possible with component teams if leadership is dysfunctional.

This is actually a theme: most of LeSS’s criticisms of component teams are criticisms of bad management. Structure isn’t the causal factor.

“Focus on individual productivity vs. system productivity”

This also has nothing to do with team topology. It’s simply a reflection of how leadership measures work.

I’ve worked on feature teams that were task factories and feature teams that acted like real teams. I’ve been on component teams with strong collective ownership and others with leadership so dysfunctional that individual output was all that mattered. Again, structure isn’t the causal factor — management is.

LeSS repeatedly treats leadership incompetence as inherent to component teams and leadership excellence as inherent to feature teams. It’s magical thinking.

“Responsible for only part of a customer-centric feature vs. complete customer-centric feature”

This is finally a point worth debating — but LeSS still oversimplifies it.

Yes, a team responsible for something like tax calculation is only part of the checkout experience. But their job isn’t to implement checkout. Their job is to make it easy for every other team to build checkout, promotions, invoicing, or anything else requiring tax logic. Their customers are teams that need tax calculations to serve their customers.

They deliver value by:

• making the domain consistent
• making changes cheap
• supporting expansion into new markets
• ensuring accuracy and stability

A feature team has to re-orient on this domain, and every other component they touch to learn what other changes other teams have made since they last looked at them when a feature is added to the checkout process. That slows delivery, reduces quality, and increases the cost of change. It certainly doesn’t lend itself to supporting the business’s needs.

High-performing systems rely on deep domain expertise and sharp boundaries — not generalists wandering through unrelated domains in the hope of “forced learning,” as one LeSS consultant suggested.

“Traditional way of organizing teams — follows Conway’s law vs. ‘modern’ way of organizing teams — avoids Conway’s law”

This one is verifiable, objective nonsense.

The insight that Melvin Conway had was that system architecture and team structure are inseparable.

If you want a system with a certain architecture, you must design the organization (communication paths, team boundaries, ownership) so that this architecture naturally emerges. This isn’t correct because Conway said it. It’s correct because it’s an observable, repeatable outcome. It’s so common that improving system architecture by aligning teams around the desired architecture is called “The Reverse Conway Maneuver.” I’ve personally planned, implemented, executed, and lived with the outcomes of doing this. It’s not a hypothesis. It’s real. The result of decoupling the teams to descale the application and enable continuous delivery was that lead times collapsed from months to hours.

Before 2015, I had never seen a real component-to-team alignment because most organizations were still stuck in project thinking. When we realigned teams by sub-domain to enable continuous delivery, it worked exactly as described in the literature. Lead times collapsed from months to hours.

You do not “avoid” Conway’s Law. You have three options:

1. Ignore it → Get spaghetti architecture.
2. Fight it with review boards, governance teams, and handoffs → More overhead, less delivery.
3. Leverage it to create cohesive teams and decoupled architecture.

Feature teams don’t avoid Conway’s Law — they just create a massive, amorphous “everyone owns everything” team with poor communication patterns.

LeSS assumes feature teams magically coordinate without introducing coupling. Reality says otherwise.

As Martin Fowler says, “Accepting Conway’s Law is superior to ignoring it…”

“Leads to ‘invented’ work and a forever-growing organization vs. customer focus, visibility, and smaller organizations”

We’re back to “our leadership sucks” as an argument.

Kingdom-building, not component teams, causes forever-growing organizations.

Any development team needs to be limited in size to be effective. If they grow too large, then collaboration becomes increasingly difficult. A component team should not be assigned so much of a system that it exceeds their cognitive capacity. There is a natural limit to how much a team can absorb.

“Invented work” is a failure of product management, not team topology.

If leadership incentivizes busywork, you get busywork — regardless of structure.

It’s less likely that a feature team will invent a new feature, but only because they lack product ownership and are simply pulling tasks from the shared backlog. That is not the same thing as “staying lean.”

Component teams own long-lived capabilities. When they lack product discipline, they can generate unnecessary improvements. But the root cause is still the same: misaligned incentives, not organizational structure.

Again: LeSS assumes PM excellence for feature teams and PM incompetence for component teams.

“Feature teams minimize dependencies between teams to increase flexibility”

No. They distribute them.

If multiple feature teams are all modifying the same component, they’re effectively one giant team pretending to be many. The dependencies do not go away — they become invisible until they blow up in integration.

Meanwhile, properly aligned component teams create true decoupling:

• stable APIs
• predictable contracts
• domain expertise
• independent deployment
• reduced blast radius

This isn’t theoretical. I’ve done it. It works.

Our goal should be small, highly cohesive, loosely coupled, cross-functional teams. A feature team may be cross-functional, but it fails at everything else.

• It is loosely cohesive because other developers outside the team’s control are also making changes to the code with no communication.
• It is tightly coupled to other teams because their code changes directly impact each other.

Feature teams only reduce dependencies if you assume every team is an expert in every domain and every domain is perfectly stable. That is LeSS’s recurring theme: feature teams assume superhuman competence; component teams assume none.

“Feature teams can focus on multiple specializations instead of just one”

So, a component team is an expert at their sub-domain, and a feature team needs to learn all the sub-domains that their feature touches? I’m struggling to understand why domain expertise is a bad thing. The article states it clearly.

…when requirements do not map to the skills of the teams, learning is ‘forced,’ breaking the overspecialization constraint.
Feature teams balance specialization and flexibility.

This “advantage” that feature teams have harms timelines, cost, and quality. That’s one way to impact the Iron Triangle.

LeSS confuses “learning” with “unnecessary context switching.”

Real learning is understanding:

• How your product helps users
• How downstream consumers use your capabilities
• How to improve quality with less effort
• How your domain behaves in production

Re-learning how some other team modified the code since you touched it last is not “learning.” It’s churn.

Feature teams increase accidental complexity, not knowledge.

“Individual/team code ownership vs. shared product code ownership”

No individual should “own” any part of the system, so that’s another strawman argument.

As for teams’ code ownership vs shared product ownership:

Feature teams do not have shared product ownership.

They have shared code change access with no enforceable ownership boundaries.

No team can enforce quality or architectural discipline across other feature teams. Every quality decision becomes a top-down mandate or a committee meeting. In addition, if the teams have operational responsibility, they will mostly be feeling the pain of another team’s mistakes instead of their own. This incentivizes the wrong behaviors. None of that is good for quality or, frankly, morale.

Component teams own both implementation and outcome. That’s real ownership.

LeSS again relies on the assumption that feature teams will coordinate perfectly and component teams won’t collaborate at all.

“Individual responsibilities vs. shared team responsibilities”

I see. We are back to “making up fake comparisons.” Both of these can exist in every development team structure. It’s an outcome of mismanagement, not structure. Every team should be focused on delivering as a team.

“Results in ‘waterfall’ development vs. supports iterative development”

This is another non-sequitur with no causal mechanism.

Component teams can and do deliver continuously. In fact, they are much easier to optimize for that. They can also deliver in large, dangerous batches.

Feature teams can, and do, deliver in large batches. You can also deliver more often, though it’s more difficult than with component teams due to the change management issues.

Waterfall is a process issue, not a team topology issue.

LeSS again conflates symptoms of bad management with properties of component teams.

“Exploits existing expertise; lower level of learning new skills vs. exploits flexibility; continuous and broad learning”

I wasn’t aware that expertise was a liability. By that logic, the ideal team is a group of boot-camp grads constantly “learning” because no one knows anything. Apparently, deep domain expertise is bad, but perpetual reorientation is good.

Let’s be clear: relearning domains you don’t own because another team changed them is not learning — it’s churn. It delays delivery, increases frustration, and burns time without adding value. Yes, we want engineers with a learning mindset. No, we should not manufacture learning by forcing people to rediscover the same domain every sprint.

Real learning is understanding:

• How to improve outcomes for users
• How your domain behaves in production
• How consumers use your APIs and capabilities
• How to reduce the cost of change

Feature teams don’t enable that. They just spread accidental complexity around and call it “flexibility.” LeSS again assumes extreme competence in feature teams (“everyone can learn every domain instantly”) and extreme incompetence in component teams (“nobody can learn anything unless forced”). Reality leans in the opposite direction.

“Works with sloppy engineering practices vs. requires skilled engineering practices”

“Works with sloppy engineering practices” is an extraordinary claim, and the author provides zero evidence. This is a classic causal fallacy: asserting that aligning teams to features somehow improves engineering discipline. There is no mechanism for that. It’s just marketing-speak dressed up as insight.

We took the opposite approach: we aligned teams to product domains and asked a simple question — Why can’t we deliver today’s work to production today? That drove better engineering practices, faster feedback, better domain expertise, and higher quality. Aligning architecture and teams around sub-domains makes engineering excellence easier, not harder.

Instead of inventing imaginary causal relationships to sell a framework, start by solving the actual problem.

“Contrary to belief, often leads to low-quality code in component vs. provides a motivation to make code easy to maintain and test”

How, exactly? What is the causal mechanism?

When my team owns our code, we continuously improve it. We simplify designs. We strengthen tests. We reduce complexity because we live in that domain every day and carry the operational responsibility.

Feature teams break this completely. When other teams change code we own, without context or accountability, we spend our time chasing regressions, correcting architectural mistakes, and undoing well-intentioned but uninformed changes. It’s demoralizing and destroys incentives for improvement. Worse, it cultivates a blame culture because ownership is diluted across teams.

LeSS again assumes feature teams operate with flawless discipline and assumes component teams operate with none. It’s backwards.

“Seemingly easy to implement vs. seemingly difficult to implement”

This was probably added to say, “If it’s hard, it’s worth doing,” and make the reader feel challenged.

If you think component teams are “difficult to implement,” then you’ve never redesigned teams around product architecture. Putting a group of people together and assigning them a feature is the easiest thing in the world — that’s why the industry ran on that model for decades.

Designing durable team boundaries around domains and architecture takes actual work. It requires understanding purpose, coupling, cohesion, and flow. Feature teams take the lazy approach and call it “modern.” Component teams take the engineering approach.

Feature Team vs. Project Team

I know this post is too long, but I promised I’d cover this.

https://less.works/less/structure/feature-teams

This comparison is on-brand with the rest of the LeSS material: superficial, unsupported, and confused.

The first row is true.

Everything else is wishful thinking. None of the claims are causally linked to whether the team is long-lived or short-lived, or whether they work on features or on product domains. They are simply attributes of good (or bad) leadership.

A feature team has all the hallmarks of a project team, except that it does not disband at the end of the project. It hops from project to project without ever owning anything from birth to death. I’ve lived that. It’s miserable.

LeSS Effective

I often criticize SAFe because I’ve lived through its failures, but LeSS stretches credulity to the limit. The material isn’t just biased — it’s full of confident assertions with no evidence and no explanation of causal mechanisms. SAFe at least tries to justify its claims. LeSS assumes them.

Worse, the entire feature-team argument requires assuming:

• All feature teams operate with world-class competence, and
• All component teams operate with organizational dysfunction bordering on self-sabotage

If you give both structures equal competence — or even realistic competence — the LeSS argument collapses instantly.

Feature teams might work for two or three teams. At scale, they collapse under coordination overhead, lack of ownership, architectural decay, and dependency hell.

A good job-interview litmus test:

Ask them what they think of feature teams.

If they start evangelizing them, thank them for their time and walk away. You’ll save yourself years of pain.

Thanks for reading 5-Minute DevOps! Subscribe for free to receive new posts and support my work.