Full Stream Developer

It seems increasingly common that the term “Full Stack Developer” has become synonymous with “Developer”, and that the scope of what is considered “Full Stack” is ever widening. In this post, I’ll describe why this term has always rubbed me the wrong way, and why I think you should try and be a Full Stream Developer rather than a Full Stack Developer.

Full Stack Developer

The term Full Stack Developer, or Full Stack Engineer if you prefer, is an advent of the Web era of software development where “Frontend Developers” provide expertise when dealing with client side technologies such as HTML, CSS, Javascript, etc and “Backend Developers” are typically writing server side code to persist information in a data store, implement APIs, and doing final validations on user inputs. A developer that is able to work on both Frontend and Backend development tasks is considered a “Full Stack Developer”.

Being a Full Stack Developer is supposed to be more glamorous because it implies that you have expertise in more of the skills required to build and deliver a modern web application. In practice it is rare to find people that are truly expert in both, and as is human nature many people have a bias towards one side or the other even if they have competency in both.

The proliferation of better libraries, frameworks, and tooling on both the client and server side has made being a Full Stack Developer more approachable than when the term hit the mainstream circa 2008. Also, due to the belief that having Full Stack Developers was more desirable, the market reacted by finding ways to produce more of them. You started to see people that may be experts in backend development start to claim the title of Full Stack Developer once they had even a small amount of front end developer experience.

Too Restrictive

Even though I’ve done enough frontend and backend development where I wouldn’t feel completely like a fish out of water if one were to label me a Full Stack Developer, the term still never sat right with me. Not because I don’t think people should split their focus between client and server concerns, but rather because it’s actually too restrictive. It locks a developer into a technology only mindset and I think that kind of mentality restricts career growth both in terms of depth and breadth.

Even in a more modern interpretation of Full Stack Developer where you include things we collectively call “DevOps” (e.g. infrastructure, instrumentation, and CI/CD) all you’ve really done is added more technical scope. Arguably more than any one engineer will be willing or able to truly excel at in equal measure.

Developers are by nature some of the most powerful problem solvers your organization will ever employ. We eat complex abstractions for breakfast. Why would any organization want to lock us into only dealing with technical problems? Have you ever worked in an organization where the only problems were technical? Sometimes, the hardest problems aren’t even the technical ones!

Full Stream Developer

There is a concept originating from Lean-Management practices called a Value-stream. Put simply, it is the set of activities that take place from the time a customer makes an initial request all the way through until the value required to fulfill that request is provided back to them. Examples in the context of software may be a customer reporting a defect, how that defect report flows through your support organization, software development team(s), testing, and then back out through the release process and eventually into the hands of the customer.

It’s out of scope for this post, but one day you really should sit down and go through a Value-stream Mapping exercise for your product. I think you’ll find it illuminating.

If you already understand your Value-stream, then you should be able to see pretty quickly that although developers provide a great deal of value creation, if they are only aware of the frontend and backend (and even DevOps) then they are only playing a role in a small part of the overall Value-stream.

I am advocating that we open the sandbox in which developers typically play and let them choose their own adventure.

If you’ve got a strong backend engineer who also has a knack for process management and is able to help your Customer Support organization streamline how they handle inbound defects, is that not adding value? If you’ve got a frontend developer that’s got a knack of upskilling others, would it not be of value for them to train your sales team so they can speak better about accessibility standards? Developers being aware of other things happening in the Value-stream results in them solving problems directly and indirectly.

Consider how a development team estimates their work.

Are they only including the client and server development effort in that estimate? Or are they including scope that would make sure the value they are creating has a successful path through the Go To Market portion of your Value-stream?

Clearly developers don’t want to create software with defects, but are they aware of the impact that a defect has on your customers and the resulting retention metrics? Are they including work in their planning and estimation sessions that would reduce the impact of defects if found in new work?

Are they pushing for roadmap space to do foundational work that reduces inbound defects? Pushing to create better tooling for Customer Success?

I would much rather praise and promote developers that are aware of the Value-stream and that take steps to positively impact it than constrain myself to only rewarding developers based on the accumulation of technical skill.

Nonlinear Career Progression

Think of your typical Career Ladder. They tend to be linear: Associate Engineer, Engineer, Senior Engineer, etc.

A good Career Ladder is going to tell you what kinds of things you need to demonstrate in order to move from one rung to the next, and there is value there. However, take a look at the resumés and work experiences of people that are sitting in the top spots of your organization. Go talk to them. I think you’ll find that very rarely have they had a linear progression through their career.

If you are an Independent Contributor in a technology role, you have to ask yourself where you want to be and then try and determine if a linear progress is really going to get you there.

I think many of you will find the answer is no, and that you need to find opportunities to swim in other parts of the Value-stream in order to get exposure to more critical areas of the business and potentially find something that captures your passions just as much as slinging code.

If you think that taking your focus away from pure technology is going to harm you, I promise that it won’t. I also recommend you go read the following books:

• Range by David Epstein.
• The New Kingmakers by Stephen O’Grady
• The Manager’s Path by Camille Fournier

As a manager of technical staff, you really only have two primary duties:

• Produce value for the business.
• Retain your staff.

If you don’t believe me, go look at your quarterly or yearly goals/objectives. You know, the things your boss and their boss are measuring you by. Chances are, it won’t be hard for you to interpret all of them as relating to one of the two duties above.

So then you have to ask yourself two questions.

1. How can I maximize value for the business if I am only able to influence the frontend, backend, and (maybe) DevOps?
2. How can I retain staff if all I can offer is a linear progression and they become disinterested in that?

Offering, and then coaching people through, a nonlinear career progression not only increases the value that managers and independent contributors provide to an organization but also keeps top talent in a company longer.

Think about it. How many posts on LinkedIn have you seen about people leaving a company for a new opportunity that wind up “trying something different”. That’s a lot of business and domain expertise walking out your front door because you’re keeping people in a box.

Summary

In short, there is no such thing as a pure technology company. When you take a step back and look at the Value-stream you’re going to realize that pretty quickly.

It’s a mistake to build a technology organization around people that want to be, or are arbitrarily being, restricted to technology only functions. One may think that the most valuable place for someone with technical skills is in engineering, but that’s not true. The mosts valuable place for anyone in an organization is where their abilities intersect with their passions. As people grow, so do their abilities and passions and that is what you want to be good at identifying in your hiring process and nurturing in your day-to-day management.

Everyone in a software company has the exact same job: deliver value to users. Being overly prescriptive of how each person contributes to that is detrimental to that singular objective.

So don’t obsess about finding Full Stack Developers or trying to be one. Find and coach people that understand and are willing to be Full Stream Developers, and aspire to view the entire Value-stream as your playground.