Welcome back to the DevOps.com series, ‘Enterprise DevOps Q&A.’ I have a backlog of Q&A in store, but don’t let that stop you sending in more! If I can’t answer them myself, I will try to find someone who can.
For this post, I was recently asked about the challenge that large enterprises are facing over whether to use generalists or specialists to drive their DevOps transformation…
Q. Does a DevOps environment prefer generalists or specialists to succeed?
This question has ricocheted for a while. Google CIO Ben Fried – who spent 14 years in IT at a large enterprise (Morgan Stanley) – spoke as long ago as 2011 about how ‘Generalists, Not Specialists, Will Scale the Web.’ Some webscale businesses like Netflix even espouse a singular ‘NoOps‘ skillset, although they continued to have separate specialists … and maybe still do.
However, in large enterprises, I have seen DevOps work well with both specialists and generalists.
The Case for Generalists
A generalist who can take on more duties from design to deployment is especially productive when application alignment moves to a local or vertical approach, as I have discussed before. Such generalists can move code through the SDLC faster, with greater integrity and fewer opportunities to drop the ball. In such structures, there are fewer handoffs from ideation to production, so there is less chance something will slip through the cracks.
Local and vertical organizational structures tend to be less complex, with fewer products, fewer services, fewer applications, and fewer technologies involved, so such teams can better emulate smaller startup-sized organizations. DevOps generalists in these structures, for example, will not have to learn the vagaries of 5 different provisioning tools, because they all use just one tool. Generalists will often do better in such structures.
The Case for Specialists
On the other hand, in a large enterprise you might have not only 5 different provisioning tools, but also 4 test automation tools, 3 middleware systems, 5 databases, and much more – housed in a dozen different departments! It is perhaps impossible then for a generalist to have the expertise required to be proficient in all of these processes and technologies. As anecdotal evidence, look at any web site or mobile app ‘designed’ by a developer – a good proportion of them are almost unusable.
In the enterprise even specialists like DBAs or security admins need to specialize within their field. An Oracle DBA, for example, has specialized knowledge that a Hadoop DBA does not. Big enterprises adopting big DevOps need specialists who know specific differences between DB2, Oracle, MySQL, and Hadoop. And as I have posted before, it would be nice to standardize on one, but such a dogmatic approach is simply unrealistic.
The Case for ‘T-Shaped’ People
That said, as with many conventions in Enterprise DevOps, a best practice seems to be in finding balance. Build up leaders who can truly collaborate across disciplines with experts in other areas, while still retaining a depth of skills and expertise in their specific field. This is the idea of ‘T-shaped’ people – aka ‘Generalizing Specialists’ or ‘Master Generalists’.
This seeming oxymorons are actually useful archetypes to apply to DevOps staffing, especially when supported by expertise from specialists from the PMO, architecture, development, DBA, security, testing, QA, pre-prod, and operations teams. This is the best of both words – generalists when you want them; specialists when you need them.
The Case for Pragmatism
Perhaps more importantly though, as Donald Rumsfeld once famously noted, “You go to war with the Army you have … not the Army you might want.” In a large enterprise the staff you have will likely be specialists, regardless of the staff you might want, so this will be your starting point.
Fortunately, building a collaborative cross-functional team from separate groups of specialists, rather than a single DevOps department, is as much of a DevOps best practice as seems to exist. Take for example a large enterprise like National Australia Bank, which has have taken a DevOps approach that started with specialists but ultimately resulted in a ‘DevOps Team.’ On the other hand, organizations like DirecTV and Union Bank started their DevOps journeys by helping dev, test, and QA to streamline within their specialization, as much as they looked to streamline the collaboration between teams of specialists.
The Case for Another Case?
Did you handle your DevOps staffing differently? Is there another way to reconcile the differences between generalists and specialists? Please feel free to add to the discussion in the comments, I would love to hear more about your approach to enterprise DevOps staffing.
And as always, if you have questions you’d like to address about Enterprise DevOps, let me know. Leave them in the comments below; hit me up on Twitter at @AndiMann; or send me an e-mail to me at andi.mann@ca.com.
