Three years ago, I presented a talk on the skills pipeline myth at ShmooCon, denoting that our ability to overcome our staffing and skills shortage is to look more broadly at the available talent and development channels that currently exist to address our shortcomings. Three years later, as the rise of DevSecOps out of DevOps has taken hold, an alternative model has adjust how we need to view the talent and skills pipeline to ensure we don’t put ourselves into a bigger hole and create a larger problem.
My first talk equated the typical mentality of technology staffing efforts to focus on direct or specialty skills to address each niche of the need for various security roles, rather than look at the needs based on the design of the complete ecosystem. My term of “firefighter”, were those specialists brought in to do a singular focused task, who were difficult to find for the role and resulted in premium pay and tightly scoped expertise. These are individuals brought in, often after an event has occurred or the organization has been told they need these skills or competencies.
Conversely, addressing the problem in the design phase, would expand the possible pool of talent to address issues that may not be specialists in a sole topic, but may encompass a broader range of skillsets. In this case, preventing accidental ignition through the implementation of controls, such as “safety matches” or other prevention and mitigation techniques. In this case, while solving a narrowly scoped issue can be viewed and “attacked” as a solution from different points of view and available resources.
With the movement of DevOps to DevSecOps, the model for both is a shared skill AND responsibility model. It is a reversed mindset to where the title of a DevOps or DevSecOps engineer relies on being a generalist to be able to be plugged in nearly anywhere, but may swing this concept to the extreme the other direction. In this case, nobody is potentially really good at anything, and thus impacts quality, reliability and security by expecting these roles to service every need.
In this talk I plan to see how we can find the middle and work towards solving our skills pipeline issues, but also adapt a successful shared responsibility model that adequately addresses the needs of modern architectures and service use models.