Full-Stack Engineer For DevOps: Fact Or Fiction - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

IT Leadership // IT Strategy
10:54 AM
Eric Reed
Eric Reed

Full-Stack Engineer For DevOps: Fact Or Fiction

DevOps requires multifaceted IT pros to help deliver results at market speed. But do these beasts exist in the wild?

The first two questions: What are full-stack engineers? And why do you need them?

I can best describe what I mean by “full-stack engineer” using the analogy of a new product introduction (NPI). When I was an engineer working in NPI, we would assemble a team comprising members with different skills to form a (usually) small, efficient project crew focused on delivering a product to the market. To be successful on an NPI team, you had to have skills in several disciplines because the nature of the project required you to “wear multiple hats.” In my case, I was a hardware engineer, but I also had experience with manufacturing and occasionally helped with bootstrap/initiation code, mechanical design, and packaging.

I view the “full-stack engineer” in a similar light. Like the transformation a business needs to go through to handle a successful NPI, the rules are changing in our IT organizations as we move from traditional IT and software development roles to DevOps. By definition, in a DevOps world, the lines blur between IT roles (developers, infrastructure, and support). At GE Capital, we have taken the approach that we need these “full-stack” engineers to enable us to make the transition from being a traditional IT shop to one that is DevOps based. (Note that we have branded DevOps “ArchOps” within GE Capital, because it is such an important initiative within IT.)

Living in a DevOps world
Our experience on this journey to date has been that the small, self-directed teams required in a DevOps world require an amalgamation of skills spanning everything from IT security to database design and application architecture, plus everything in between. While each individual on the team has a particular strength (say, application design and coding), each one also needs to have working knowledge in other areas (maybe UX or network design). That’s because, whether we’re developing the patterns and blueprints for the platform service, or utilizing a continuous delivery methodology, this knowledge is necessary in order to be successful at the speed of DevOps. Scrum cycles are designed to get us to a minimum viable product (MVP) in as short a time as possible, which means teams have to be as self-sufficient as possible. If you have to track down outside expertise every ten minutes, in no way can you deliver at those speeds.

If 'DevOps' is just another way of saying 'multistack' then this is a key to hiring in the future, according to the InformationWeek DevOps Survey.
If "DevOps" is just another way of saying "multistack" then this is a key to hiring in the future, according to the InformationWeek DevOps Survey.

People who can function on these teams are “full-stack engineers.” This also answers the second question I posed above. How many “full-stack engineers” do you need? In my experience, as many as you can find.

If you buy into the idea that to be successful at DevOps you need full-stack engineers, the first thing you have to do is find them. This leads us to a third, equally important, question: Where do I find one -- or more than one?

We are fortunate to have a handful of these people in our organization today. But a handful is not enough, especially in an organization with a global nature such as ours. 

The answer is to build them yourselves, which has been our approach. We have been working to grow people into these roles. We hold boot camps where we teach them the basic skills of the automation and continuous delivery tool chains we currently use. We allow teams to self-organize, better to leverage their skills and expertise. We focus on workforce planning as we move forward, to ensure that we build a pipeline of people with the aptitude to grow into this role -- a supply chain that is sustainable into the future.

Not every developer or infrastructure IT pro needs to be a “full-stack engineer.” Just as NPI teams still need manufacturing and R&D and marketing skills, we still need people who are experts in one aspect of development, such as compute/storage experts and great application developers. It is our current thinking that for our own IT teams to be successful, they need to be seeded with resources that have multiple skills.

A great byproduct of this approach to bringing this new generation of “full-stack engineers” into IT teams is that it also provides another career path. Good technical people are always looking for ways to expand their skills, and this provides them with that opportunity. It also helps us navigate our way to the expanding and fast-moving world of DevOps.

Eric is currently the Chief Technology Officer for GE Capital, a position he has held since mid-2011.  Prior to this role he held a number of roles in IT in both GE Capital and the Consumer & Industrial businesses in GE.  Prior to joining IT, he started his GE ... View Full Bio

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
5/13/2014 | 12:06:58 PM
Finding Full-Stack talent
When I was working as Head of Technology at a NY startup we really needed these types of developers, and I found they were really difficult to track down.

Full-stack developers (we were calling them "generalists" at the time, which probably added to our difficulty in sourcing them) are vital to small engineering teams where resources are limited and you need to move fast.  You just can't afford to have a handfull of specialists sitting on the bench, blocked by a bottleneck elsewhere on the team.  Adaptable engineers are game changers in this scenario--if your dedicated front-end man can chip in to help out on infrastructure tasks when things get backed up it makes the process much more fluid.

After going through the struggle of trying to source these engineers, I felt there had to be a better way to find these types of candidates, so I started HeapSort.  By isolating full-stack engineers and providing tools to showcase the breadth of their experience we provide a very effective way to source this type of talent when an organization needs it.
User Rank: Apprentice
5/8/2014 | 2:09:48 AM
Hiring for the Team, not just DevOps
What I see in the article is hiring for a team, not just DevOps/Full Stack.   I also see hiring for DevOps is hiring for those focused on the flow, no matter what dept/org it goes thru.  It's a value-chain that you want to focus on, and if that's full stack, great, but don't over-narrow the scope by just thinking Full Stack.

There are places for experts, and there are also places for people with broader experience.
The key to me is balance of speed and focus.

It's not to hire every 'full stack' you can find, it's hiring the right balance of people.  
I do think it's likely many companies are a short those who can cross the group silos (dev and ops being typical) and breakdown barriers/blocks/sacred cows to meet value goals (faster deploy, higher visibility, lower mttr, higher availability, fewer regressions, etc).

For speed, hire for DevOps with a set of skills in the pipeline you are focusing in (deploy, metrics, response, tools, etc).  The person with deploy experience may not fulfill all the needs of your visibility goals.  Put together a team which spans the needs with appropriate overlaps in coverage to avoid those resource SPF.

Hire the expert to crack tough questions that those in the flow won't have time to focus on.

Beware thinking everyone doing everything is the goal.  
DevOps Full Stack Engineer in that sense is a fiction.


Drew Conry-Murray
Drew Conry-Murray,
User Rank: Ninja
5/5/2014 | 4:52:44 PM
Grow From Within
Internal training sounds like a good idea. Can you share how long it takes to train someone up to a "full-stack" engineer, or at least to get them started on a project?
The Best Way to Get Started with Data Analytics
John Edwards, Technology Journalist & Author,  7/8/2020
10 Cyberattacks on the Rise During the Pandemic
Cynthia Harvey, Freelance Journalist, InformationWeek,  6/24/2020
IT Trade Shows Go Virtual: Your 2020 List of Events
Jessica Davis, Senior Editor, Enterprise Apps,  5/29/2020
White Papers
Register for InformationWeek Newsletters
Current Issue
Key to Cloud Success: The Right Management
This IT Trend highlights some of the steps IT teams can take to keep their cloud environments running in a safe, efficient manner.
Flash Poll