• IT REVOLUTION
  • Newsletter
  • About
  • Contact
  • My Resources
  • Books
  • Resources
  • Courses
  • Podcast
  • Videos
  • Conference
  • Blog
  • IT REVOLUTION
  • Newsletter
  • About
  • Contact
  • My Resources

IT Revolution

Helping technology leaders achieve their goals through publishing, events & research.

  • IT REVOLUTION
  • Newsletter
  • About
  • Contact
  • My Resources
  • Books
  • Resources
  • Courses
  • Podcast
  • Videos
  • Conference
  • Blog

Why the Full Stack Engineer Is Problematic

April 2, 2020 by IT Revolution 6 Comments

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.

Cognitive overload can result in lower quality, heroics, burnout and health problems.

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:

Too much information puts our brain’s health in danger, resulting in an information overload. Over time, exposure to multiple sources of data leads to the overstimulation of the brain. Neurons get overloaded with data, numbers, deadlines, targets to be met, and projects to be completed, and all this unnecessary information can ultimately destroy them. Consequently, a stressed and overloaded brain is at high risk of dementia and other neurodegenerative disorders (Parkinson’s and Alzheimer’s diseases).

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.

Most Recent Articles

  • Model Life-Cycle Management at Continental Tires
  • Flow Engineering
  • Value Stream Management and Organizing Around Value

Filed Under: DevOps Enterprise Forum Guidance Papers, Research Tagged With: christian posta, cornelia davis, devops, devops enterprise forum, dominica degrandis, full stack, full stack engineer, full stack team, jason cox, jim stonham, software, software delivery, teams, thomas limoncelli

Comments

  1. avantika says

    April 6, 2020 at 1:21 pm

    This gives one an interesting aspect on full stack development. Thanks for sharing.

    Reply
  2. Market Research says

    March 31, 2021 at 3:37 pm

    Fantastic. Great article very helpful. And a clear explanation about the problems in full stack development.

    Reply
  3. Zineb Maddi says

    April 24, 2021 at 2:13 pm

    This is really a great article. I would add the focus on embedding learning in the workflow of work.

    Zineb

    Reply
  4. KIS says

    June 20, 2022 at 10:17 am

    or you know just stop using shit technologies and crappy languages.

    Reply
  5. Sok Puppette says

    June 20, 2022 at 1:14 pm

    > Too much information puts our brain’s health in danger, resulting in an information overload. Over time, exposure to multiple sources of data leads to the overstimulation of the brain. Neurons get overloaded with data, numbers, deadlines, targets to be met, and projects to be completed, and all this unnecessary information can ultimately destroy them. Consequently, a stressed and overloaded brain is at high risk of dementia and other neurodegenerative disorders (Parkinson’s and Alzheimer’s diseases).

    This is idiotic babble bearing no resemblance to any realistic model of how brains work.

    Reply
  6. Khalil Gharbaoui says

    June 20, 2022 at 3:42 pm

    I do not agree with all of it.

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

newsletter sign up

Topics

Tags

agile agile conversations better value sooner safer happier business business agility business leadership case study cloud continuous delivery devops DevOps Advice Series devops case study devops enterprise forum DevOps Enterprise Summit devops handbook digital transformation dominica degrandis douglas squirrel enterprise Gene Kim incident management information technology IT jeffrey fredrick jez humble John Willis Jonathan Smart leadership lean making work visible manuel pais mark schwartz matthew skelton nicole forsgren operations Project to Product project to product tranformation seven domains of transformtion software software delivery Sooner Safer Happier teams team topologies the idealcast WaysofWorkingSeries

Recent Posts

  • Model Life-Cycle Management at Continental Tires
  • Flow Engineering
  • Value Stream Management and Organizing Around Value
  • Don’t Just Survive Your Audit, Thrive In It
  • Exclusive Excerpt from The Value Flywheel Effect

Privacy Policy

Featured Book

Featured Book Image

Events

  • DevOps Enterprise Summit Virtual - Europe
    Virtual · 10 - 12 May 2022
  • DevOps Enterprise Summit US Flagship Event
    Las Vegas · October 18 - 20, 2022
  • DevOps Enterprise Summit Virtual - US
    Virtual · December 6 - 8, 2022
  • Facebook
  • LinkedIn
  • Twitter
  • YouTube
Copyright © 2022 IT Revolution. All rights reserved.
Site by Objectiv.