Skip to content
CTP is part of HPE Pointnext Services.   Explore our new services here →
  • The Doppler Report
Cloud TP Logo
  • Thought Leadership
  • Clients
  • Services
  • Careers
  • Contact Us

Cloud Technology Partners

CLOUD SERVICES

  • The Cloud Adoption Program
  • Application Migration
  • Software Development
  • Infrastructure Modernization
  • DevOps & Continuous Delivery
  • Cloud Security & Governance
  • Cloud Strategy Consulting

TECH DOMAIN

  • Amazon Web Services
  • Google Cloud Platform

ABOUT US

  • Company Overview
  • Leadership Team
  • Partners
  • News & Recognition
  • Announcements
  • Weekly Cloud Report
  • Client Case Studies
  • Events

CAREERS

  • Join Us
  • Job Opportunities
 Cloud Technology Partners
  • Doppler Home
  • Client Case Studies
  • Podcasts
  • Videos
  • White Papers
  • Quarterly
  • Events
  • Subscribe

Are Full Stack Teams an IT Utopia?

There have been numerous articles about full stack development and full stack engineers. Is a full stack team what every organization should strive to achieve?
Alexey Gerasimov VP, Global Cloud Delivery
August 8, 2018September 11, 2018 THE DOPPLER
Share this 
doppler_mail1

For more content like this, Get THE DOPPLER
email every Friday.
 
Subscribe here  chevron_right

Over the years, there have been numerous articles about full stack development and full stack engineers. The conversation has been relevant primarily to soft­ware development activities (specifically web development), and less so to other efforts. Opinions on this topic range wildly between the need for deep specializa­tion in a specific area or two, versus taking responsibility for the entire product development process and its outcome. We suppose it is somewhat similar to the question of whether it is better to be an expert in one area, or a “jack of all trades and master of none.” But we do not believe it has to be one or the other. Your approach should depend on the operating model you, as a company, implement.

The Concept of a Full Stack Developer

First, let us review the terminology and the concepts. Historically, IT personnel were organized by functional roles and responsibilities. There were “front end” folks, who took care of the UI, “back end” folks, who developed the heavy code, and database administrators, who then dealt with the data. Obviously there were additional roles in the organization, but let us keep this simple for now. The front-end, the back-end, and the database people all did their tasks and coordinated with each other at their respective touch points. They may have been really good at their jobs, but their responsibilities did not reach beyond their domains. That might have been okay for a while, but in many organizations it eventually created silo issues, which slowed down both new feature releases and bug fixes.

In comes the concept of the full stack developer. The thinking was that if a devel­oper can be good at both the front end and the back end, he or she can effectively remove the inherent silos, streamline the development process, and produce higher quality software in a shorter period of time. This means a full stack devel­oper has to be pretty good at all aspects of software development and familiar with the entire stack – front end UI, coding, networking, databases, etc. Making a developer responsible for the entire stack helps prevent challenges that can occur during handoff stages but, more importantly, it changes the accountability para­digm, as the developer is now on the hook for the whole product. The saying goes: “if everyone is responsible, no one is responsible.” When things go wrong and a number of groups are involved, finger-pointing begins. With a full stack developer, there is only one place to point the finger.

By the way, using a full stack developer does not automatically guarantee that the code produced will be better than that produced by a team of specialists, and chances are, it may not. However, full stack developers are certainly incentivized to do their best, since the responsibility rests solely on their shoulders.

So here is what the full stack developer concept can look like: full accountability for end-to-end results, reduced silos, removed friction points, faster delivery of value and shorter feedback loop. Wait. Is this DevOps, or at least something that closely resembles what DevOps is trying to achieve? It certainly is. That is why you often see full stack developer roles in progressive, DevOps-minded software organizations which value short release cycles and speed to market. But it does not mean that this concept is right for every organization, nor that you cannot deliver value quickly without full stack developers.

What this concept does reinforce is the need for an individual to: be aware of and understand areas of operation outside his or her silo; expand his or her horizon; be fully vested in and accountable for the end result; and work to remove all artificial barriers to delivering value faster. These things in them­selves create a significant value-add to any organization. If one full stack devel­oper can provide so much value, what if we have 10, 20 or 100 of them? And what if we put them together into full stack teams? But is that what a full stack team is, a team of full stack developers? NO. A full stack team is NOT a team of full stack developers.

As much as we believe everything in our lives is moving toward software, there are more areas than that which need to be addressed for a product to be released. These include: business analysis, testing, product management, stakeholder management, communications and more. What a full stack team borrows from the full stack development approach is the idea that it is operat­ing as a frictionless, self-sufficient, value-generating unit.

Here are the five characteristics of a true full stack team:

    1. Self-sufficient
    2. Empowered
    3. Agile
    4. Accountable
    5. Value generating
  1. Self-Sufficient

Similar to the full stack developer, the full stack team should be able to address all aspects of the project or engagement. This will most likely cover everything from business analysis to architectural design to the hands-on implementation of the solution at all levels — networking, database, software, testing, docu­mentation, knowledge transfer, etc. You might even have one or more full stack developers on the full stack team. The key point is that the team needs to be autonomous and should have the right skills and the right tools to deliver the needed outcome.

  1. Empowered

The full stack team must be empowered to make appropriate decisions, and the empowerment needs to come from the top. This is extremely important! Decisions the team will make vary from feature implementation to architec­tural design to how the product is released. The team has to have the power to prioritize what to work on, when and how. If it has to constantly go ask for approvals elsewhere, it is not an empowered team and the process is full of unnecessary roadblocks. Plus, if the team cannot make its own decisions, it cannot be held accountable for decisions others made for it.

  1. Agile

This is about speed, speed and more speed. Full stack teams should design fea­tures, test concepts, try and fail (if necessary), address issues and release the product quickly. Hence, full stack teams need great communication, very short feedback cycles and a penchant for action. They do not have to be located physically together to have all this – virtual is fine. The key to velocity is to cre­ate an empowered team that can make a decision, see it through, evaluate the results and quickly course correct if necessary.

  1. Accountable

When a full stack team has the power to make decisions, it can be held account­able for the outcomes. In other words, the buck stops here. There is no more “it worked in the Dev environment” type attitude. The team should be account­able for the end result from all perspectives — product quality, customer need, meeting expectations, matching the required Service Level Agreements and so on. Full accountability means the team must understand the full benefits and impacts of the product on the end customer / consumer / buyer, and be on the hook for all of it, to ensure a successful outcome.

  1. Value Generating

A full stack team is able to: remove waste; automate where necessary; do what really matters versus what is easy; deliver value. The last two goals are crucial. They sound obvious, but how often do you see developers gold-plating fea­tures, or teams working on something super cool that provides value only to a small subset of end users, or perhaps not at all. On the business side, how often do meetings take place just for the sake of having a meeting? Full stack teams can focus on the areas that provide value and remove unnecessary waste from the process of delivering that value. It is another example of the 80-20 rule. The full stack team should commit 80% of its efforts to the 20% of the project that matters most.

Is a Full Stack Team What Your Organization Needs?

So, is the full stack team an IT utopia? And more importantly, is a full stack team what every organization should strive to achieve? The answer to both questions is: it depends. Your organization might not be a cloud unicorn or operate in the brave new DevOps world. You might not have the need for teams that are agile and self-sufficient, although every team should still be empow­ered, held accountable for the results of its work and focus on producing value.

At Cloud Technology Partners we certainly believe in the value of full stack teams to solve the complex public cloud challenges our clients give us. Putting together a cross-functional and empowered full stack team of experts has proven to be the best way to quickly deliver the value clients expect.

Share this


Related articles

 

6 Reasons Why Your Cloud Strategy Must Include a Plan for Change

By Joey Jablonski

 

Pioneering Cloud in the Financial Services Industry

By Alexey Gerasimov

 

Navigating the Cloud's Most Challenging Blocker: Your People

By Paul Barnhill

Related tags

Agile   Change Management   DevOps

Alexey Gerasimov

Alexey is the Vice President of Global Cloud Delivery for Cloud Technology Partners. Alexey’s role at CTP is to provide leadership and guidance to his team responsible for delivering Advisory and Professional Services engagements to large enterprises.

Full bio and recent posts »



Find what you're looking for.

Visit The Doppler topic pages through the links below.

PLATFORMS

AWS
CTP
Docker
Google
IBM
Kubernetes
Microsoft Azure
OpenStack
Oracle
Rackspace

BEST PRACTICES

App Dev
App Migration
Disaster Recovery
Change Management
Cloud Adoption
Cloud Economics
Cloud Strategy
Containers
Data Integration
DevOps
Digital Innovation
Hybrid Cloud
Managed Services
Security & Governance

SUBJECTS

Big Data
Blockchain
Cloud Careers
CloudOps
Drones
HPC
IoT
Machine Learning
Market Trends
Mobile
Predictive Maintenance
Private Cloud
Serverless Computing
Sustainable Computing
TCO / ROI
Technical "How To" Vendor Lock-In

INDUSTRIES

Agriculture
Energy & Utilities
Financial Services
Government
Healthcare
Manufacturing
Media & Publishing
Software & Technology
Telecom

EVENTS

CES
DockerCon
Google NEXT
Jenkins
re:Invent


 

Get The Doppler

Join 5,000+ IT professionals who get The Doppler for cloud computing news and best practices every week.

Subscribe here


Services

Cloud Adoption
Application Migration
Digital Innovation
Compliance
Cost Control
DevOps
IoT

Company

Overview
Leadership
Why CTP?
News
Events
Careers
Contact Us

The Doppler

Top Posts
White Papers
Podcasts
Videos
Case Studies
Quarterly
Subscribe

Connect

LinkedIn
Twitter
Google +
Facebook
Sound Cloud

CTP is hiring.

Cloud Technology Partners, a Hewlett Packard Enterprise company, is the premier cloud services and software company for enterprises moving to AWS, Google, Microsoft and other leading cloud platforms. We are hiring in sales, engineering, delivery and more. Visit our careers page to learn more.

CWC-blue-01

© 2010 - 2019 Cloud Technology Partners, Inc., a Hewlett Packard Enterprise company. All rights reserved. Here is our privacy policy CTP, CloudTP and Cloud with Confidence are registered trademarks of Cloud Technology Partners, Inc., or its subsidiaries in the United States and elsewhere.

Do Not Sell My Personal Information

  • Home
  • Cloud Adoption
  • Digital Innovation
  • Managed Cloud Controls
  • The Doppler Report
  • Clients
  • Partners
  • About CTP
  • Careers
  • Contact Us
  • Most Recent Posts
  • All Topics
  • Podcasts
  • Case Studies
  • Videos
  • Contact
Our privacy statement has been changed to provide you with additional information on how we use personal data and ensure compliance with new privacy and data protection laws.  
Please take time to read our new Privacy Statement.
Continue