It works for us to some extent, but there are ultimately people who specialize in various areas. Nobody can be a true master of absolutely every area in a large system with enough knowledge queued up to be able to be an independent power player. And I think that’s reasonable to anybody who works in or near the trenches.

It should be expected that any member of a full stack team can figure out how to do any particular task, but it’s a waste of resources not to have people lean on teammates who have more recent deep experience in a particular area.

This goes for both technical areas as well as domains. If my teammate just spent a couple of weeks adding a feature that makes heavy use of, I dunno, database callbacks in the user authentication area, and I just picked up a task to fix a bug in that same area, I have two choices. I can consult with my teammate and get their take on what I’m doing and have them preemptively point out any areas of risk/hidden complexity. Or, I can just blunder into that area and spend my own couple of weeks getting properly ramped up so I can be confident I made the right change and didn’t introduce a subtle regression or performance issue.

As the number of tech and domain concerns increases, it becomes more and more important for people to collaborate intelligently.

My team oscillates between 4 and 6 developers and this has been our practice with pretty high success. Quality is high (when measuring our ability to deliver within our initial estimates and our bug count), morale is good, and everyone is still learning with minimal frustration.

I think the issue of team cohesion comes into play if people are all independent and also stop talking. If I take the couple of weeks in my previous example instead of talking to my teammate for some knowledge transfer, I’m disincentivized from leaving my personal bubble at all. I’m also less likely to stay within overall software patterns if I think I’m always trailblazing. The first time you write new code, you’ve established a pattern. The first time someone repeats what you did, they’ve cemented that pattern. That’s often a nasty double edged sword, but I generally lean toward consistency rather than one-off “brilliant” code.

Where this can start to break down is when people become pigeonholed in a certain role. “Oh, you’re the CSS guy, so why don’t you take this styling ticket?” and “Kevin, you do all the database migrations so here’s another one” are great ways to damage morale and increase risk if someone leaves.

Tl;dr: everyone should be able to pick up any task, and they should endeavor to keep their axe sharp in every conceivable area, but it needs to be carefully offset against wasting time by refusing to lean on other people.

As with most things, it’s usually a matter of personalities and not policies.

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.

As a full stack I feel capable of serving as an architect on a team. I am not sure if I could feel that way if I only honed in on one area.

So I think at least one full stack (architect) kind of person on a team is certainly beneficial.

As far as an entire team of full stacks? I’m sure that would be effective but it may cost a lot of money to have all that talent, where perhaps some tasks could have been done by a non-FS. Also there is the issue where specialization is needed in a certain area, and FS usually don’t offer that.

So I don’t think it would be a mistake, but it may not be as optimal as having a mixed bag where you have a handful of full stacks and then some dedicated FE and BE folks.

To answer your questions:

Do they work: yes

My experience: I’m biased, but I prefer working with full stacks because they get the “big picture” more often. This does translate to a smoother development flow most of the time.

Team size/xp: yes. I work with 2 other full stacks, and then we have some dedicated data engineers, a dedicated FE, and a dedicated data analyst.

Increase/decrease in quality: almost certainly there is a decrease on the FE side because full stacks are thinking about everything. Oftentimes the FE will get “good enough” and we’ll move on. I’ve seen dedicated FE people put a lot more care and attention than I would. However, for the BE I haven’t noticed any decrease in quality vs a dedicated BE.

Actually to address the FE quality issue we’ve arrived at a process whereby the FS builds the full experience and gets it looking mostly good and completely functional, then we pass it off to our dedicated FE person to polish. The polish involves making things look better, responsive, accessible, and ensure legibility. These are things I could do as a FS, but I prefer to lean on the dedicated FE person so I can move onto other things. It’s a system that works really well tbh because the FE person doesn’t have to start from scratch or think about the programming as much, and the FS can still get the FE development done without time sinking the nitty gritty. It’s a win-win.

Increase/decrease in product cohesion: full stacks intrinsically keep the stack cohesive, and that to me is part of the main benefit (see earlier statement regarding the architect role). This translates to the product as features are developed. Often we get a more maintainable system than if a BE and FE got together to agree on an API interface, both may be making concessions to the other that a full stack could work through in their own head and sort out quickly and more effectively.

We recently started a project full-stack in Rust, with the web frontend compiled to WASM. So far, I have a much better feeling in this regard than with previous projects, which were using TypeScript in the frontend and JVM languages in the backend.

For one, the frontend technology stack is obviously more similar to the backend. You still need an idea of HTML, CSS and general UI paradigms, but you can skip the knowledge of the massive JavaScript ecosystem, which is where in the past, we usually felt like we had to pull in someone dedicated to frontend.

And we have a compile-time-shared model between frontend and backend, so not only does that prevent the two from drifting apart, you’re also forced to fix something on the other side more often, which helps to keep devs in the loop across the whole code-base.

Generally, I feel like you’ll always need technology specialists for architectural decisions. And I feel like projects naturally trend towards having people with more expertise in certain areas of the project.

But I also think, it’s very healthy when everyone has some level of confidence tweaking parts all over the codebase, at least for those that are adjacent to their area of expertise. If you have people that exclusively know ‘their’ side, that completely kills any overarching architecture decisions.

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. ;)

What is a “full stack”

My problem is that there are a lot of layers beyond just the “front end, web/REST, database” layers that most people refer to, that are involved with delivering an application.

Like, do you know Angular and also BGP?

Probably not. So, it’s impossible to truly be “full stack” so you’re going need to actually define what everyone is supposed to be responsible for knowing, and also recognize that there are going to be folks that are strong in some areas and other areas less so. Plan accordingly

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.