"The idea of the ‘full-stack developer’ is rather quaint, a throwback to the late 1990s when the ‘full stack’ meant a single development framework like Delphi 5 or VB6. However, in the modern world, the ‘full stack’ is way larger than any one person can comprehend. Even an entire team of eight people will struggle to deal with the ‘full stack’ and indeed, why should they?"
Matthew Skelton, director of Conflux and coauthor of Team Topologies, hits the nail on its head: When the software stack is seven layers thick, it’s impossible to truly be a full-stack developer.
In software the desire to ‘shift left’ has put more and more pressure on developers to cover more and more bases, but being a Jill or Jack of all trades isn’t necessarily desirable. “When you have a problem, your problem is specific. When you have a toothache, you want something to relieve your specific type of anguish. It's the same way when you have a backache or arthritis pain,” writes Liz Ryan, founder of Human Workplace. She emphasises lack of specialisation makes for the “worst personal brand ever” as it suggests that you don’t know what you want to do—and you expect your boss to just figure it out.
Or, it means that when companies advertise for these bucket roles they are asking for too much. Putting that level of responsibility on one person becomes a single point of failure. Remember, we need well-rounded teams, not burnt-out individuals.
In this piece, we explore modern product management and autonomous teams—with a lovely side of pedantic semantics—to figure out what full stack even means and how to go about pursuing it the right way.
T-shaped job security
A T-shaped developer dives deep into a specialisation—either a concept like security, reliability or testing, or a vertical like financial services or retail—and then has a wide range of basic skills and experiences, which aren’t just tied to technology, but business and collaboration too.
As Coralogix’s developer advocate Chris Cooney reminds us, developers have to grow their skills beyond coding in order to become “more rounded value creators.” His example of a T-shaped software engineer is someone who is great at Java, but knows some databases and ReactJS.
"T-shaped individuals deliver expertise in their chosen discipline, but they deliver value across a huge spectrum of skills. It's painful to get rid of these people,” he writes. “T-shape your value generation. Make yourself indispensable. And if you still find yourself facing layoffs, you're going to find that you stand out from the crowd in the technology market.”
As tech budgets get tighter, these core and especially visibly cross-functional skill sets are key to job security. Typically, these skills have you working outside the boundaries of your team and, often, across departments or even silos. They allow you to work out loud and prove yourself to more people across an organisation.
Full Stack or ‘Just Enough’ Stack?
Just like you don’t want to put too much pressure on one individual, you don’t want to lay too much on one team. The impetus of the move over the last 20 years toward autonomous, loosely coupled teams is to give these ‘two pizza teams’ (don’t get me started on how five to nine people would only eat two pizzas) just enough that they can build fast, get feedback faster, iterate and go again—without having to wait for anyone’s approval. Part of this is achieved by putting technical guardrails in, like bowling with the sides up, so you can’t veer out of the quality and governance lanes. Pursuing a full-stack team likely has too much responsibility, but you may get the same benefits without going too many layers deep.
“With well-designed boundaries and the use of what Team Topologies calls ‘platforms’—essentially things that improve flow and reduce cognitive load—there is no need to aim for ‘full stack’ at all. Instead, teams can aim for something like ‘enough stack’—just enough of the stack to be able to own services end-to-end,” Skeleton told WTF. Part of the goal of Team Topologies is to ensure that team structure and communication pathways evolve alongside the organisation and technology.
Each individual kind of team designated by Team Topologies works on a curated experience for users, and they collectively work towards optimal flow and collaboration:
- Stream-aligned team: a typical cross-functional, product team that’s reliant on rapid feedback and the other three teams helping them.
- Enabling team: experts in an area to bridge knowledge gaps, like test automation, build engineering, and architecture. Emphasis on collaboration, making everything works ‘as a service’.
- Complicated subsystem team: the facilitators of flow, these are deep domain experts who are responsible for an important subsystem, but then interfacing with its users.
- Platform team: they focus on creating reliable, usable and fit-for-purpose developer experiences for internal developers, not top-down mandatory tool use.
The first rule of Team Topologies is that any platform should not increase the team’s cognitive load. With this in mind, a team’s platform should include clear service boundaries, complexity of abstractions, and continuous alignment to business goals. From there, you aim for the ‘thinnest viable platform’, or the smallest set of APIs, documentation and/or tools needed to help a specific team release more simply and quickly. This could be as simple as a wiki page and as complex as a developer portal.
Who is on a T-shaped team?
A good stream-aligned team or T-shaped team doesn’t have an army of one, but a group of individuals who balance each other out. “Good product development needs a lot of roles,” Andy Domeier, senior director of technology at SPS Commerce, said at December’s DevOps Enterprise Summit.
He says these T-shaped or autonomous teams typically include:
- Engineering
- Product manager or product owner
- Launch management
- Developer relations
- Customer success
- Scrum master
“Functions don’t have to be job titles right away,” Domeier continued, as you don’t always have the budget available to increase headcount, including in tighter economies. It’s always cheaper, he contends, to retain, train and upskill teammates, “productising undifferentiated engineering” as a team. Some stopgaps he mentioned are managers playing product owners and on-call engineers working in customer success.
Just make sure, he reminds, to set reasonable expectations, so you aren’t, again, adding to team cognitive load.
Job processes for better team-building
This also means creating job descriptions that engineers will actually apply for. Now, this isn’t just an insurmountable list of five-plus years’ experience with a dozen different languages, databases and frameworks. You are looking for someone to solve your problem. This may be a specific piece of technology, but the benefit of embracing Cloud Native is you shouldn’t have to be locked into specific vendors. It’s better to hire a teammate with certain aptitudes that you have or need, than to hire someone because they check off a technical skill.
Your grocery list of nice-to-haves presented as demands also hurts your team’s diversity—and, by extension, proven access to innovation—as those under-represented in their fields, including women and neurodivergent people, are less likely to apply to a job where they don’t meet 100% of the criteria.
“Employers have pain. That’s why they hire people,” Ryan aptly observed in the same Forbes piece. It’s just, by the time you get that job ad up, there’s been so much bureaucracy and so many layers added to the job process that you lose focus on your team’s immediate need. It either becomes several interviews dedicated to the overarching company mission and vision, or else you are so desperate to fix that pain point that you rush to hire someone without finding team fit.
One way to do this is to empower the team to run much of the early interview process. This can be as simple as candidates joining team coffees or lunches, stand-ups or retrospectives, or by doing pair or mob programming. You’ll know better than any HR psychological reviews or painful whiteboard interviews if that person is a good fit for your team’s particular needs. And usually you will save both your team’s and the candidate’s time.
A full-stack team is still technologically nascent
Ovais Tariq, CEO of Tigris Data, argues that the concept of a full-stack or T-shaped team that we’ve presented in this piece thus far is only really available to enterprises, where “the company has enough resources to have a separate front end and back end.” Then it makes sense to have them separate, he says.
When we talk about autonomous teams that can release code even multiple times a day, we are still only reflecting the composability of the back end. This autonomous way of working relies on breaking up larger, monolithic applications into smaller services in order to release and test quickly. This is how back-end teams often function, Tariq told WTF, but “the front end, in most cases, has still been monolithic.”
Only now is the front end being broken up into smaller pieces or “micro-front-ends.” He gave the example of an eCommerce site, which currently has contained within its front end many events, including the customer profile page, the cart, and the shown inventory. If that was broken up into micro-front-ends, then you could have a team that does all the front and back end for one function and business logic, like payments. That becomes a full-stack application that is completely separate and autonomously built, released and maintained by one or more dedicated full-stack teams.
This is where it makes sense to have full-stack developers managing that application, he says, and “I see a trend in an increasing number of these profiles.”
In addition, he sees the rise of programming tools that enable these full-stack developers, like those that use JavaScript to write the front end and then NodeJS to write the server-side. Microsoft’s JavaScript-compilable TypeScript, widely adopted by JavaScript frameworks, also enables this behaviour, and, as we explore on our Hacking the Org podcast, this was part of the approach taken by the team at Cinch when they migrated from Kubernetes, C# and .NET Core to a new stack on top of AWS Lambda. NextJS is another full-stack framework that he says has grown rapidly over the last two years because it also allows for this team or individual behaviour.
“Programming language is a big barrier to the same developer doing both. When you have languages enabling that, that’s when we see more and more people going in the same direction” of being fully full stack, Tariq explained.
He’s also seen this with his own data solution Tigris Data, where more than half of new users self-identify as full-stack developers who are looking to learn more about the database side of things. “You need to understand database principles as back-end engineers,” he says, “but front-end engineers are learning they need to know something of it, too.”
The next step toward enabling these truly full-stack teams? He says infrastructure tools have to evolve to be more accessible to developers. “Application developers as a whole do not have the knowledge to be able to use databases the right way.” He’s not saying they necessarily need to be fluent in relational theory; instead, databases need to become simpler to use. Pointing to popular tools like HashiCorp and Terraform, he said, “All of these automation tools are for SREs and DevOps to make it easier for infrastructure engineers, but they aren’t built with the developer in mind. That’s why we have these skill gaps. These tools are not written for someone who has an application developer mindset.”
As this demand will only continue to grow—especially as, sadly, tech companies downsize—we will have to see if 2023 brings broader adoption of these tools to empower the full-stack, T-shaped, autonomous team. Because, Tariq says, developers shouldn’t have to increase their cognitive load. “As much as we can abstract that [complexity] away and build tools with the end users in mind—the developers—the better it will be.”
Previous article
