What is your opinion about full-stack teams? I'm referring to teams where the desire is for every member to competently contribute at every point in the stack.
- Do they work?
- What has been your experience?
- Does team size and/or experience level inform your opinion?
- Do you notice an increase/decrease in quality?
- Do you notice an increase/decrease in team and product cohesion?
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:
my experience
In my specific experience, when you talk about "full-stack" I don't only think about one "FE-BE-DB" project, but also another projects which are part of the company products (i.e. embedded products, testing infrastructure, cloud engineering...).
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.
The idea that a single developer delivers an entire story is where your problem was situated. Stories aren't assigned, they are owned, and they aren't executed, they are delivered. One story can be worked on by 4 devs, all with different skills, but the story owner is the one who makes sure it gets the right people on it and is the one who makes sure the product owner sees the delivery.
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.
Yes, I have built both types - specialist first and it was a fiasco. Cross-functional was consistently the best
I'm a little surprised specialist was bad. Unless bad egos were involved.
Specialist is too thin. The specialists only know what they know and they don't want to learn new things outside their speciality. So I had to hire a new person everytime we found a speciality gap because the specialists were like "not my job, I am an X specialist, go hire a Y specialist". Then, they held their work tightly, no cross training, so the specialists all became their own brand of bottleneck. Different work speeds and different levels of quality meant that ego came to defend against performance complaints, and I as a manager couldn't add more people to the problem areas because they weren't trained in that area and the specialist could do it faster than they could train others to help.
That being said, all my full-stack team members had specialities. That's what T-shaped means. I had frontend specialists who could work the whole stack, backend specialists who could work the whole stack. Dev tools specialists who could work the whole stack. Architects who could work the whole stack. Everyone we hired had something they were best at, and an alignment to learn the whole stack. Within a year they were able to work on all tech in the stack and anyone could bring in a new tech to solve a problem and everyone would learn it.
