Are Full Stack Teams an IT Utopia?

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. 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.

2. 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.

3. 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.

4. 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.

5. 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.