It works, but not better than having each team member specialized in one subject. It just works, but it has it's own pros and cons:

Pros:

• For management, it reduces the "cost" of a team member quit, because the rest of the team can quickly and easily cover up his tasks.
• For management, it's easy to assign a feature, they can peek anybody.
• It makes developers to understand how the different parts of the projects communicate which each other, their impact and how they work.
• Works better for startups where projects and teams are small and agile and usually the projects are MVP.

Cons:

• Developers who specialize (or really like to specialize) in a specific subject, naturally won't last in this team more than 1-2 years (guaranteed).
• Features quality and velocity, at the beginning, slightly drops, a bit more bugs occur. Overtime it will be better depends on the team members learning curve.
• You won't have someone that masters a specific subject if you'll need one.
• Doesn't work good on enterprise, where there are lots of huge projects, and the product is stable and full (not only MVP).

So I've worked places where a user story is the only kind of story and one developer is responsible for every part of the stack for a given story. It didn't work as well as dividing responsibility between front end and back end specialists. I think full stack is a leadership role to figure out the API and integration, but I'm not sure that's even necessary given good communication.

Does it work? Sure.

My experience? I have rarely had a completely healthy team with good leadership and good developers. My experience has not been as good on full stack - it primarily creates different silos so you still don't have interchangeable developers. But I can't say with the right team firing on all cylinders wouldn't succeed.

Team size? Everywhere from 5 to about 20 with full stack being the case at the biggest and smallest. The biggest team was basically segregated by application so each app was siloed to a developer or small group. That was the absolute worst, though I guess the devs were largely happy because there was essentially no code review or supervision.

Quality and team cohesion were so variable I would hesitate to attribute that to full stack devs. Product cohesion was the absolute worst on the larger team of full stack because everyone solved every problem in a unique way and often differently between different apps due to better developer knowledge or different original developer and tech debt. But that was a poorly managed team altogether to be honest. It feels true but all I have is anecdotes.

So overall I'm not convinced it's a good idea, but I'm curious to see the other replies.

Think of a T. This is the breadth and depth desirable on a team. Everyone has familiarity with every technology involved. However, only a few people have deep understanding of different aspects. Helps with the 80/20 of a lot of projects. The deep tech folks prep for the broad tech. Works great!

Is that "full stack"? Close enough for marketing speak. ;)

deleted by creator

It's fine for the usual straightforward and easy problems -- problems that common developer tools and paradigms have solved. Like a product that reduces to CRUD with a few boolean expressions, joins, and simple algebra mixed in. But I think it's inefficient maybe even unworkable for harder problems. And hard can be scale, like moving up two orders of magnitude in throughput or entities, or down in latency. Or hard can be algorithmic stuff.

I highly agree with what others have said here, that a culture of "fungible engineers" can alienate those who want to go deep. Some folks enjoy being subject matter experts or are drawn to a craftsmanship aesthetic. And, IMHO, a healthy org culture should work for all kinds of people -- specialists and generalists. I think you should aim for and encourage people to grow to be T shaped rather than fungible cogs.

Think about the alternatives - either you divide the stack into separate teams or you have non-overlapping experts in the same team. Both are horribly worse.

With the multi-team architecture, no one can deliver anything on their own. They all have to hand off their work to someone else and receive handoffs from someone else. Rework becomes huge as downstream teams with expertise not present upstream identify flaws and send work product back for revision.

With non-overlapping experts, you have a team of N with N bus factors of 1. No one can get sick or take vacation. If someone quits, dies, or wins the lottery, the whole team shuts down while they try to find a replacement. You can fix this by hiring 2 or even 3 experts per area. So now your team is full of redundant experts that fight for expert recognition. The handoff problem remains but is somewhat lessened.

A full-stack team is not a team of pure generalists. A full stack team is a cross-functional team that owns the entire value stream (design to production) and cross-trains internally. Hiring people with specialized knowledge is predicated on their willingness to learn all other areas and teach their area. Only T-shaped professionals (depth in one area, breadth across the stack) inhabit the team and only people with the humility to learn need apply.

Over time, a full stack team outperforms every other team. The team is internally redundant on all tech, so bus factors are lowest when new people are added and bus factors continuously get larger over time as people cross-train. New hires have built in training because the team is always training. New tech can be added regularly because everyone is always training and learning.

Full stack teams are the best form of software team hands down.