Full-stack teams are a brilliant concept. They’re designed to have everything a team needs to solve problems in a given domain—front-end, back-end, database, security, you name it. When done right, these teams are little microcosms of outcome achievement, creativity, and autonomy. They blur skill boundaries, enabling faster delivery and real-time learning across disciplines. Sounds great, right?

But there’s a catch. Somewhere along the way, we started confusing “full-stack teams” with “teams of full-stack engineers.” When I say we, I mean it. I did this too. I was on the full-stack teams of full-stack engineers bandwagon. But that shift—over time—has cost us. By prioritizing generalists at the expense of specialists, we’ve inadvertently traded depth for breadth and innovation for adequacy. Let me explain.

The Original Idea: Diverse Expertise

When full-stack teams first gained traction, they weren’t groups of jacks-of-all-trades. These teams brought together specialists: a front-end specialist here, a security wonk there, maybe a backend aficionada and a product lead—all working alongside one or two versatile generalists to keep things fluid. Each member had their wheelhouse, but they operated as a team, united by their shared domain and goals.

This structure generally worked better than being segregated by specialty. Security didn’t fall through the cracks because the security specialist was on the team and working on the same problem with the rest of the team. Front-end performance wasn’t an afterthought because someone on the team cared deeply about it. And the generalists? They filled in gaps, made sure communication stayed smooth, and ensured the team wasn’t siloed.

The Rise of the Full-Stack Engineer

Fast forward a few years, and the industry’s obsession with versatility took over. Full-stack engineers became the default. Sure, they could work across the stack, but what we gained in adaptability, we lost in depth.

Take security as an example. A team with a dedicated security specialist has someone laser-focused on keeping systems safe. This isn’t just about catching vulnerabilities—it’s about innovation. Specialists stay on top of the latest exploits, tools, and techniques, often finding ways to harden systems that others wouldn’t consider. Without that expertise, teams staffed only by generalists are less likely to run meaningful experiments or proactively improve in critical areas like security.

The Dunning-Kruger Effect

There’s another side effect of relying too heavily on generalists: the Dunning-Kruger effect. This cognitive bias causes individuals with limited expertise to overestimate their competence while experts tend to underestimate theirs.

For example, a team of generalists might confidently design and deploy security protocols with improper encryption methods or inadequate protection against attacks, not realizing their limitations. Without a specialist, their overconfidence could lead to vulnerabilities that compromise the application’s integrity.

Specialization vs. Over-Segregation

Now, I get it. Too much specialization can be a problem. When specialists identify only with their niche, you get over-segregation—the kind of siloed thinking that full-stack teams were supposed to eliminate. Suddenly, your team is just a collection of mini-departments, passing work around like a relay race. That’s suboptimal.

The key is balance. Specialists should work within the team, not outside of it. They should share knowledge, contribute beyond their niche, and collaborate deeply with generalists. Techniques like pair programming or ensemble programming (my favorite) help here. Rotate the pairs regularly, and suddenly, everyone’s learning, sharing, and staying connected to the full stack. Specialists bring depth; generalists ensure that depth isn’t isolated.

Rebuilding the Full-Stack Team

So, how do we go from under-specialized to a good blend of specialization and generalization? Here’s my high-level take:

1. Embrace Specialization in Context

Let’s not be afraid to have someone specialize in front-end design, security, or database optimization. These aren’t roles to silo; they’re areas of focus that strengthen the team. Diverse skills and perspectives help solve hard problems.

2. Redefine Career Growth

Organizations need paths for engineers to grow in specialization without locking them into rigid roles. Instead of “front-end engineers,” have engineers with a “focus on front-end.” Create structures that recognize specialization but allow movement. For example, an engineer might be proficient in front-end, competent in security, and novice in back-end. Specializing for a few years? Great. Want to pivot later? Sweet. You’re still on the same career path.

3. Collaborate, Don’t Segregate

Build team practices that ensure specialists contribute to the whole and don’t become isolated experts. Use collaborative coding practices and collective code ownership. Encourage team members to focus on specific gaps within the team’s skill set while staying engaged with the broader codebase.

4. Create Connective Tissue

Create communities of practice where people with shared interests in focus areas can exchange knowledge and ideas. These communities help spread leading practices across teams and avoid disjointed user experiences caused by isolated decision-making.

5. Keep Autonomy Sacred

Full-stack teams thrive when they have the autonomy to experiment, learn, and deliver within their domain. That autonomy should include deciding the balance of specialization and generalization that works best for them.

Closing Thoughts

Full-stack teams are still one of the best ways to organize software delivery. But somewhere along the line, we veered off track by prioritizing generalists over specialists. The best teams—the ones that deliver, learn, and innovate—are those that balance the two. Let’s lean back into specialization, not as a step back, but as a way forward.

Related Behaviors

This discussion ties directly to several behaviors from the framework:

Know the Problem You Are Solving
Balancing generalists and specialists requires understanding domain challenges and structuring teams to address specific problems effectively.
Work Together
Collaborative coding practices like pairing and ensemble programming foster the kind of teamwork necessary for specialists and generalists to thrive.
Be Meticulous About Composition
Designing teams with a thoughtful balance of specialization and generalization aligns with the principle of intentional team composition.

Fixing Full-Stack Teams; Specialization Required