Why the Full Stack Engineer Is Problematic

Excerpt from the DevOps Enterprise Forum Paper Full Stack Teams, Not Engineers, by Jason Cox, Christian Posta, Cornelia Davis, Dominica Degrandis, Jim Stoneham, and Thomas A. Limoncelli.

Can you possibly be good at everything? In the digital era, the sheer quantity of tools, frameworks, programming languages, and methods/models overwhelms the brain. Technologies come and go, and learning a new technology often involves intense effort. Learning a new environment and domain knowledge takes time. When asking engineers how long it takes for a new hire to get up to speed, a common response is six to twelve months.

It takes years of hard work to become a master of anything, and DevOps skills are no different. Kubernetes, for example, is famous for its complexity and relative ease for junior developers to botch up in unpredictable ways. If you are drinking through the firehose while learning new domain knowledge, you might also be deep into learning a new language like Clojure, utilizing new cloud APIs, applying the Big-O notation to new algorithms, and mastering machine learning and server-less functions. And that just scratches the surface of technology that continues to accelerate and expand. How do you intend to keep up with the growing stack?

Mastering one skill by default means you will intentionally ignore other skills to focus on the one you want to master. The brain can only hold so much. Our human working memory is vulnerable to overload, which occurs as we study increasingly complex subjects and perform increasingly complex tasks.

One prime complaint from engineers is the consistent interruptions that prevent individuals from completing work during the day. If you can’t do your most important work during business hours, when do you get your work done? The pressure to work during the wee hours of the night on top of one’s regular day job is strong.

Working long hours may come with trendy bragging rights, implying strength and power, but as The Wall Street Journal health writer Melinda Beck says, “Genuine ‘short sleepers’ only need four hours of sleep per night, but they comprise only 1% to 3% of the total population.” So for the 97% to 99% of us who aren’t short sleepers, working the wee hours brings sleep deprivation and mistakes—both are contributors to burnout.

Burnout is more than feeling blue. It is a chronic state of being out of sync at work, and it can be a significant problem in your life, including the following impacts:

• Loss of energy: The burned-out individual feels overwhelmed, stressed, and exhausted. 
• Loss of enthusiasm: Passion for the job has faded; the job “rubs you the wrong way;” it feels like a burden or a chore.
• Loss of confidence: Without energy and active involvement in one’s work, it is hard to keep motivated.

Risk of burnout from information overload is real and leads to serious health issues:

Expecting individuals, including ourselves, to be skilled in the “full stack” adds to the ongoing cognitive load that must be carried to get the job done. This can lead to burnout and even, in some cases, more serious health issues. But we need to be able to support the entire stack to help our businesses stay relevant and keep moving forward. What can we do? In the next section, we will look at some options to help support the entire stack while providing a healthy and humane work environment for our teams and ourselves.

What’s a Real Path Forward?

The full-stack developer or engineer is extremely difficult to find, develop, and sustain. In cases where individuals are able to fulfill these roles, they place themselves at risk of cognitive overload and the related health risks. Additionally, the acceleration and evolution of the technology stack means that mastery is a moving target, demanding continual learning investment in multiple domains. However, our businesses need full-stack functionality to stay relevant, efficient, and nimble in the market. How do we meet that demand without overloading individuals?

A full-stack team has the combined skills across its members to effectively design, build, deploy, and operate software throughout all development cycles of their deliverables. Moving to full-stack teams helps us deliver the full-stack advantage to our organizations without the challenges of recruiting, developing, and sustaining full-stack developers or engineers.

Here are some recommended practices to help build full-stack teams:

• T-Shaped Team Members: Everyone’s an expert in one or a few skills (the vertical bar of the T) but there’s a basic understanding and empathy for many or all other skills needed to build and run the product (the horizontal bar). Consider rotating team members through different specializations to help create more T-shaped team members. Rotate/reshuffle team members and/or teach others on the team to ensure that experts can take a vacation and reduce risk in the event that someone leaves the company.
• Everyone Teaches: By teaching, you better understand the subject yourself while also building empathy for others. One VP of Engineering we talked to said the measure of a Senior Engineer is how much they teach, not how much they code.
• Growth Mindset: Hire for growth mindsets as you staff your teams, so those members are open to growth. It’s okay to be curious and take on additional roles to move forward using rotation.10
• Communities of Practice: Build communities of practices so your team members can develop deeper skills and learn best practices from others.
• No New Silos: Don’t create new functional silos required to ship value. The intent is to create high-performing teams of specialists with high degrees of communication, empathy, and knowledge-sharing. Creating silos can severely inhibit speed, communication, empathy, and knowledge sharing.

To download the full guidance paper Full Stack Teams, Not Engineers, please sign up here.