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