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 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:
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).
I think there’s a benefit to having at least some “specialized” full stack devs. I happen to be one. I do mostly backend, which is technically my job, but occasionally I will pick up a front end ticket or one that incorporates back and front end.
Being able to see and understand how all the pieces fit together can be really helpful. If your entire team is made up of specialized devs, they tend to solve problems only with the tools they know. In my limited experience this frequently materializes as too much business logic in the UI or improperly implemented database integrations.
But I think the real value that full stack devs bring to these situations is not so much in the code that they can write but in the insight they can offer during the planning phases by helping the BA or whoever’s writing the tickets, clarify who’s responsible for what and how something should be implemented if it may not be clear to the dev working ticket.
Thanks
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.
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 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.
Have you witnessed/experienced this in action?
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.
