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
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.
That is definitely my opinion. Wasn’t my call.
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.
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
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. ;)
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.
Have you witnessed/experienced this in action?
You mean people taking ages to release because the work is divided between multiple teams and each one is creating a slightly different feature?
Yes, I have seen that.
Or if you mean a team of generalists with an specialist here and there not suffering from this problem?
I have seen that too.
I have also seen people solve the specialization problem by making their own layer more general than it would technically need to be, and become about as productive as a full stack team. The interesting part is that I have only seen that done by generalists, so I really doubt a set of specialists-only teams can be really productive.
In your experience, is success dependent on each member (or most members) being T shaped?
It’s dependent on many members being T shaped. Not all, and I don’t know if “most”. But you need enough to handle the basic flow of the system and interact with all of the specialists.
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.
