Why every engineering team should have a Full Stack developer
Engineering bandwidth is expensive and good developers are hard to find. As a result, most engineering teams consistently face a bandwidth crunch.
Lately, I’ve been trying to answer a question along these lines:
What is the optimal ratio of mobile, backend and web developers in any engineering team in order to seamlessly execute the product roadmap for at least the short — medium term?
The crux of the problem lies in the word optimal. If engineering bandwidth were cheap or you had a huge corpus of money, the answer would’ve simply been — hire as many as you need! (exactly what big tech did prior to the 2022 funding winter). But, we do not live in an ideal world — engineering bandwidth is expensive and (eventually) EBITDA matters.
If you’re just starting up or even lead an engineering team in one of the big tech giants, planning optimal engineering bandwidth holds relevance in every engineering team of any shape and size. Understaff, and you would not be able to seamlessly execute on your roadmap. Overstaff, and we all saw the mass firings in tech in 2022–2023.
While working out a solution, instead of stumbling upon a golden ratio or the number 42, I found an answer in full stack developers. So let’s try to solve the problem step by step.
Org structures
Irrespective of your team size, your engineering org structure should broadly resemble one of these structures:
- Smaller teams going through their 0–1 journey would essentially have basic server and client teams (or individuals) trying to ship out their MVP.
- Teams growing through the 1–10 journey would have added devs across each team and optionally would have incorporated additional teams (e.g. new client apps).
- Finally, when engineering teams get larger, they’re split into smaller sub-teams or pods (courtesy the Ringelmann Effect).
- And repeat.
Bandwidth disparity
While the argument scales well for any number of teams, for simplicity let us only consider 2 teams — server and client.
As a result of any of the org structures above, depending on the number of developers at each layer, you would get your team’s effective bandwidth in one of the following ratios:
So all we need to sort out our bandwidth problems is to understand the product roadmap, estimate each task and hire accordingly. That’s easy, problem solved?
Well, no.
Let’s add the following facts to the equation:
- Developers are human and will take holidays throughout the year. Some planned and some unplanned.
- As per this report, the average developer attrition stood at 13.2% in 2022.
- It is not possible to consistently define tasks that require engineering bandwidths in the same ratios. Some Sprints will have back-end heavy tasks and some will be client-heavy.
- With the ever changing market realities, it is almost impossible to accurately predict the medium — long term roadmap for any product (unless of course you are hell bent on shipping a certain set of features without being flexible to the dynamic market realities).
Therefore, we have changing variables on both sides of the equation.
- Available Bandwidth: It is impossible to maintain a consistent bandwidth ratio across your engineering teams all year round.
- Required Bandwidth: Is it not possible to consistently define tasks that require engineering bandwidths in the same ratios.
The Solution
As I’ve discussed above, understaffing at the expense of your product roadmap or overstaffing at the expense of your profitability margins are perhaps not the optimal solutions for such a problem.
Enter, full stack developers.
Full stack developers are developers that are proficient in more than one tech stack. They can contribute towards multiple codebases within a single Sprint cycle.
Full stack developers offer engineering teams with enough leverage and flexibility to consistently balance the changing dynamics of available bandwidth and required bandwidth.
- A release requires excessive backend bandwidth? Allocate your full stack dev there.
- A release requires equal bandwidth across server and client? Let your full stack dev deliver a feature end-end.
Should all devs on your team then be full stack?
My personal opinion — no. Consider the t-shaped skills of a normal dev who has spent multiple years learning and working on the same tech stack vs a full stack dev who has learnt and worked on at least two tech stacks.
In my opinion, the dev who has worked on a single tech stack will almost always have a greater depth in that particular tech stack. Therefore playing a pivotal part in your team in terms of architecting your overall application, maintaining code health and staying up to date with changes in the tech landscape around that stack.
Therefore, a hybrid team consisting of both would be an ideal solution.
Should your first hires be full stack?
Again, no. Similar to the answer above, the first developers to setup the codebase and its structure make decisions that would impact your codebase for a long time. Therefore, the more depth they have around that particular tech stack, the more informed the decision making in the beginning.
Should the choice of tech stack matter?
If you plan on having full stack developers on your team, should you select the tech stack at client and server layers in order to make it easier for devs to work on both of them? Probably, but not a must have. Many organisations tend to use JavaScript based frameworks at client and server layers (e.g. MERN or MEAN stacks) or multi-platform technologies such as KMM. This helps the engineering team switch between the codebases since the underlying programming language does not change.
However, I believe that it is quite easy for any good modern developer to learn any new language and start working on it. In most cases, only the syntax changes, keeping the fundamental concepts like looping, conditionals etc unchanged. It might be better to select the tech stack around other factors such as your use case, infra budgets and market realities.
How many full stack devs must be there in each team?
With any team building exercise, there is no golden formula. However, we can learn the quirks of any solution and tailor them according to our realities.
For a smaller team, even a single full stack dev should suffice. However, with a growing team size, you may want to plan for backups and have at least two on your team.
