Skip to main content

Skilling The Squad

Originally Published on the DevOps Institute Site

One of the most interesting trends in DevOps adoption is the evolution of the IT silo into the cross-skilled squad.

This is not just a semantical name change. Most IT teams today are comprised of like-skilled individuals such as a Scrum team of developers. The modern squad takes a slightly different approach, is more static than dynamic and is more product-focused than project based. Squads are built around T-shaped professionals –where each member has a specialty competency, but all members have a broad scope of skills across multiple disciplines.
A high performing squad essentially has all of the skills needed for the product or feature to which it is assigned and is not generally constrained by the availability of an individual resource. There is enough breadth of knowledge inside and outside the squad to shift more activities to the left so as to allow them to move more quickly and with more agility. While the squad model originated with Spotify, more and more enterprise organizations are starting to reorganize in favor of cross-functional squads.

The squad model is not only challenging the way that IT is organized, but it is also challenging the way we skill and certify IT professionals.

Historically most training and certification schemes were built as a hierarchy – starting with a basic “foundation” certification and eventually stepping up to a capstone designation such as an Expert or Master. Unfortunately, for most the journey starts and ends at the Foundation level. Statistically, only 10 to 20 percent of learners will actually be funded for or have the personnel need to achieve the capstone certification.
The other problem with generic certifications is that they do not clearly define what the recipient can actually do. While some certifications reflect documented roles such as Product Owners, Scrum Masters or Site Reliability Engineers, other designations are so ambiguous that a hiring manager or squad leader may not know exactly what skills they are hiring or how to use that resource. Would a sports organization build their squads around a group of people known as “Football Experts.” “Soccer Practitioners,” “Basketball Masters,” or “Baseball Professionals?” Of course not. Each member of a squad should be recruited based on the depth and breadth of their skillset and the competencies that that squad is lacking.
The DevOps Institute has responded to this challenge by creating a certification model that essentially “skills the squad.” The model is not hierarchical, it has inherent agility and is based on extensive research on the most critical and hireable skills needed for the modern T-shaped squad. At present, these include the best practices and principles around
As new skills emerge, we can adapt the model accordingly and help our Registered Education Partners deliver up-to-date content and certifications for a transforming market.
The hub of the DevOps Institute certification model is DevOps Foundation® – for which ITSM Academy is a proud lead author. This course offers the broadest and most comprehensive collection of current DevOps practices, principles and trends – many of which are not documented in a book and were born out of real-life enterprise innovation.
While skilling the squad with T-shaped competencies is an essential need for hiring and grooming the best talent, DevOps Institute also recognizes that organizational capabilities must evolve as well.  That is why we also offer a series of non-certification “DrillDown Courses” focusing on trending practices that have proven to be enablers of change and transformation. At present, these include
All of DevOps Institute’s content and certifications have been authored by some of the best and brightest thought leaders in their specific area.
Whether you call it a team or a squad, for now, one thing is clear – people are at the heart of every transformation. And upskilled, cross-skilled, talented people are the only way an organization is going to cross the digital divide. Skill the squad.
To learn more about ITSM Academy's DevOps and Agile Service Management classes:


Popular posts from this blog

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you. Roles and Responsibilities: Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance. Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables.  An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and th

The ITIL Maturity Model

Most organizations, especially service management organizations, strive to improve themselves. For those of us leveraging the ITIL® best practices, continual improvement is part of our DNA. We are constantly evaluating our organizations and looking for ways to improve. To aid in our improvement goals and underscore one of the major components of the ITIL Service Value System , Continual Improvement .   AXELOS has updated the ITIL Maturity Model and is offering new ITIL Assessment services. This will enable organizations to conduct evaluations and establish baselines to facilitate a continual improvement program. A while back I wrote an article on the importance of conducting an assessment . I explained the need to understand where you are before you can achieve your improvement goals. Understanding where you are deficient, how significant gaps are from your maturity objectives, and prioritizing which areas to focus on first are key to successfully improving. One method many organi

The Four Ps of Service Design - It’s not all about Technology

People ask me why I think that many designs and projects often fail. The most common answer is from a lack of preparation and management. Many IT organizations just think about the technology (product) implementation and fail to understand the risks of not planning for the effective and efficient use of the four Ps: People, Process, Products (services, technology and tools) and Partners (suppliers, manufacturers and vendors). A holistic approach should be adopted for all Service Design aspects and areas to ensure consistency and integration within all activities and processes across the entire IT environment, providing end to end business-related functionality and quality. (SD 2.4.2) People:   Have to have proper skills and possess the necessary competencies in order to get involved in the provision of IT services. The right skills, the right knowledge, the right level of experience must be kept current and aligned to the business needs. Products:   These are the technology managem