Full-stack: fiction or fact?
Let’s start with the bottom line — Yes, there are real full-stack engineers out there with the capabilities to handle challenges both from server-side and from the client-side. But (and it’s a big but…) finding a true full-stack engineer who can handle both sorts of challenges is so hard that some refer to them as unicorns.
One of the most important roles as an engineering leader is the ability to scale and build your team fast. Building such a team can be a hard task when trying to find rare unicorns (ask any recruiter you know).
But wait…. Why do I need my team to be a full-stack team? If those full-stack guys are so hard to find, why should I insist on building these cross-functional teams? And what is, in fact, a full-stack developer?
One of my favorite resources for backing a statement is Quora and one of the most popular discussions on what are the traits of full-stack developer quotes a never-ending list of technologies and frameworks you need to master to qualify as a true full-stack developer.
But technologies and frameworks are ever changing, especially in the world of web development. I remember a time in which to be a true full-stack developer all you needed to know was C# and a bit (and no more than a bit) of applicative database administration. By that — you could control all 3-tiers and the SOA world. Full-stack developers existed long before the term was coined, so I prefer a more generic definition: a full-stack developer is a developer who masters or at least controls a variety of skills that can be used to independently develop features or products that are mostly distributed in nature (meaning they have both frontend and backend components)
Now that we all agree on what this “unicorn” is — why do we need it? Why can’t we just settle for a backend developer (or a backend team) working with a frontend developer to bring a product to fruition?
After several years of building such teams, I’ve noticed multiple advantages to preferring full-stack developers over the classic backend/frontend teams.
Reducing bottlenecks
As developers, one of our primary objectives is to deliver fast and high quality products. This is why the agile methodology was evolved — the ability to respond and respond fast, and you need to build your team so it responds quickly to the product team’s needs. When building a team of engineers, you should measure efficiency by employing KPIs.
Cycle time , which is defined as the amount of time needed for a feature to be shipped and provide customer value, is a favorite of mine. Let’s not argue about when cycle time starts and when it ends, and agree that measuring cycle time forces us to address features in small batches and address capacity bottlenecks.
Our world of web development can be chaotic at times. In a specialization focused team (backend/front/QA team), or even specialization focused engineers in the same team, focus can change from backend requirements (“Hey, I’ve got demand from customer X to change API Y”) to frontend requirements (“API Y works great! Why don’t we build a dashboard?”) very quickly.
Not only do you need to plan the product roadmap according to your team’s specialization, but you also need to sync it with your recruitment plan (and probably more often than you would want to).
If you’re getting stuck at bottlenecks, it means your team structure isn’t scalable, which is a problem that can be solved by minimizing specialization and using resources that won’t limit capacity — AKA full-stack engineers.
Reducing relays in the relay race
Bringing business value as an engineering team is very much like a relay race. Taking a feature from an idea until the finish line (someone is using my feature! Yay!) is usually a team effort that involves product owners, developers, QA, DevOps and more.
This race needs to be synced and to do that, we use different practices. First, there are practices that include the agile methodology ceremonies like dailies, planning and retrospective which their main goal is to keep everyone synced. Second are technical practices like code reviews, tooling (version and test management system). Last but not least, there are cultural practices like recruiting engineers without egos and with the ability to collaborate, transfer knowledge and more. Each of these practices are meant to minimize syncing and handover activities — otherwise, a lot of effort is invested in managing and timing them.
But wouldn’t it be easier to reduce the number of relays in the race? A full-stack engineer can transform a relay race into a single race with no management effort. It’s the dream of every leader, a team member with all the abilities to take on full ownership.
Why not go for it?
It looks like any leader’s dream — to create an autonomous, bottleneckless (is that a word?) and easily manageable team. So why doesn’t everyone go for the “full-stack dev” solution?
A few reasons:
1. Master of none — It’s not just the name of a great tv show. In today’s world, it’s hard to keep up and master both the world of backend and frontend development and just by reading the post “How it feels to learn javascript in 2016,” which describes the ecosystem of JavaScript (which its evolvement in the latest years in frontend frameworks allowing building web applications and in the backend side allowed developers build an end-to-end web and mobile solution while mastering one language) I understood how fast this ecosystem changes. And this was only in 2016!
That said, you don’t always need to draw a perfect horse. Sometimes it’s enough just to paint an ear or the horse’s tail. In other words, you just need to know basic backend well enough to write a simple endpoint in an existing service or have enough knowledge in React to create a button invoking the amazing microservice you created. Put simply, it’s ok for a full-stack developer to have a tendency for a specific domain — here is no need to strive for a 50–50 domain knowledge. Depending on the product, you need to have just enough knowledge to draw the horse’s tail.
2. Recruitment challenges — Finding top-performers in today’s community is challenging, and trying to find them in a community that requires more knowledge and expertise makes it even harder to build your dream team.
One of the difficulties in finding a good full-stack developer is assessing the expertise of such an engineer. Moreover, defining the type of engineer you need on your team becomes much more challenging in a full-stack ecosystem.
There are various ways of dealing with such a challenge. But you should view it as an opportunity. Building such a team requires people who are collaborative (to transfer knowledge and for mentoring), innovative (tech-wise and as a result more and more product innovative) and willing to learn. Therefore, usually these teams are more productive and successful due to the characteristics of their members — A-players will form an A-team.
The passion to learn and evolve should be a strong indicator in the recruitment process, even trumping knowledge and experience.
One more opportunity is that by removing the technical knowledge barriers in the team there are more options for personal growth of its members which in turn leads to more satisfied team members which leads to a more engaged team. I call this state of mind — “drop the walls” culture.
Cracking the challenge
How do we overcome these challenges and still enjoy benefits like removing bottlenecks and getting a more independent team? My way of tackling this was to move the focus from full-stack developer to a full-stack team.
What’s the difference?
Instead of working hard to find those unicorn full-stack developers, create a team made of developers that complement each other’s abilities and build a full-stack capable team. The focus then shifts from the individual to the team’s ability to deliver a product or a feature, giving you, the leader more flexibility with whom you hire and when. No more looking for the perfect all-in-one developer and instead focusing on the perfect all-in-one team. HR funnels usually need to work harder in creating this cross-functional team — every new team member needs to have capabilities that will balance the tech needs of the team. It’s ok to have a senior backend developer in the team without frontend/DevOps/data abilities as long as they balance the full-stack abilities of the team. Pay attention that this can be done not only by recruitment but also by personal growth and knowledge transfer processes.
A side note, this kind of team needs to be “closer” in more than one sense. Physically, the team has to sit in proximity to each other for collaboration. Culturally, the team has to embrace ego less people to allow mentoring and working together approach, and methodologically, meaning — all the practices that can support this approach.
Last words to conclude, Balancing the team and focusing on creating a full stack team isn’t enough and it can become a great cross-functional team that can be independent but will be challenged by resources according to road map focus. To keep the team independent and autonomous, you always need to encourage the “drop the walls” culture in which everyone in the team knows that they can conquer areas and techs even outside their expertise and knowledge with the right mentorship and practices ( pair programming, pull request process, code convention and more)
Go create the perfect team!
