Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Why you should hire DevOps enablers, not experts

public://pictures/manuelpais_2017_full_res-oreilly-292-medium-square.jpg
Manuel Pais IT Organizational Consultant, Independent
public://pictures/matthew-skelton-by-paula-brown-square-crop.jpg
Matthew Skelton Founder and Head of Consulting , Conflux
 

We are regularly asked if we know any DevOps or site reliability engineering (SRE) experts available for hire. Our answer is, invariably, "Not really." It's a tough market out there.

DevOps and SRE (for large-scale software, at least) are critical approaches for success in modern software delivery and operations, as widely demonstrated every year in the State of DevOps report or the array of presentations at the DevOps Enterprise Summit.

But if you think you can achieve DevOps by hiring "DevOps experts," you are missing some contextual awareness. What exactly are you trying to improve in the first place? If your software delivery is slow because of work you're handing off among multiple teams with diverse schedules and priorities, will a new hire really help?

We're not suggesting that you not hire people with diverse skills and backgrounds—that can be quite valuable to bring in new perspectives and approaches. But conventional hiring based on expertise alone is ineffective and prevents organizations from developing the "learning muscles" that can help teams traverse the latest trends (DevOps, SRE, etc.) to their benefit at the right time, and in the right context.

Hiring experts for every need is like engaging in palliative care for organizational health. Preventive care would be to incorporate the necessary team structures and interactions—as well as a focus on people growth and sufficient slack—to effectively take in process, technology, and business changes.

Learning organizations smoothly morph as they adapt to new challenges, and they unlearn existing ways of working when they become limitations rather than enablers.

Hire with alignment of purpose in mind

In his book Drive: The Surprising Truth About What Motivates UsDaniel Pink explains the three pillars of intrinsic motivation for knowledge workers:

  • Autonomy
  • Mastery
  • Purpose

When you acknowledge that a team is the fundamental, indivisible unit of delivery and operations for a product or service, then it follows that a high-performing team needs to fulfill those three intrinsic motivators for all of its members.

People generally understand how to apply autonomy and mastery to a team, especially within the context of agile, but the purpose of a team is less clear.

In our book, Team Topologies, we identify and characterize the purpose of four fundamental topologies. Besides clarifying what each team is trying to achieve, you also want to ensure that new team members' individual purposes are aligned with those of the team.

[ Special Coverage: DevOps Enterprise Summit Las Vegas 2019 ]

Four fundamental team types and purposes

There are four different team types and purposes:

  • Stream-aligned. These are cross-functional teams whose purpose is to deliver a product or service to external customers via end-to-end ownership of the lifecycle, from ideation to operations.

  • Platform. This type of team's purpose is to provide internal services to reduce the (cognitive) effort that would be required from stream-aligned teams to develop these underlying services. In other words, such a team delivers services to internal customers.

  • Enabling. These are teams of specialists in a given technical (or product) domain whose purpose is to help other teams grow new capabilities in that domain, reducing their learning curve when adopting new practices and technologies. They can be seen as internal consultants, and do not develop products or services.

  • Complicated subsystem. These are teams whose purpose is to build and maintain a highly complicated part of a system that depends heavily on specialist knowledge (think PhD-level specialists or niche technology), requiring full-time effort.

The last three team types work toward reducing the cognitive load of the stream-aligned teams, so the latter can focus on fully understanding and owning the products or services for which they are responsible without diversions such as, for example, setting up infrastructure and monitoring from scratch.

Failure to consider how a candidate fits in with your team's purpose can lead to a dysfunctional team, disengaged team members, and high turnover rates—especially for individuals hired based on their expertise in "hot' trends.

Alignment is key

A modern hiring process needs to consider alignment between individual goals and interests and the purpose of the team new hires are expected to join. For example:

  • A candidate who strives to be multi-skilled and always learning should be a good fit in a stream-aligned team, but only if that person enjoys frequent feedback and contact with (sometimes upset) customers.

  • A candidate who enjoys automating processes should fit in well in a platform team, but only if that person is genuinely interested in understanding the needs of other teams (as well as the organization), and in developing services based on feedback and fitness-for-purpose.

  • A candidate who thrives on a particular technical or product domain or practice and wants to continuously stay ahead of the curve might fit in well in an enabling team, but only if naturally inclined to communicate, pair, and share knowledge in a nonjudgmental way.

Hire with cognitive load in mind

There are three types of cognitive load that teams may face:

  • Intrinsic cognitive load, which relates to aspects of the task that are fundamental to the problem. Example: How are classes defined in Java?

  • Extraneous cognitive load, which relates to the environment in which the team is performing the task. Example: How do I deploy this app, again?

  • Germane cognitive load, which relates to aspects of the task that need special attention for learning or high performance. Example: How do bank transfers work?

Broadly speaking, you want to minimize intrinsic cognitive load and eliminate extraneous cognitive load (boring or superfluous tasks or commands that add little value). This will free working memory for germane cognitive load (which is where value-added thinking lies).

Learning approaches to consider

Keyword-driven hiring focuses on finding experts with low intrinsic cognitive load; they have internalized tasks in their domain of expertise, like driving a car without thinking about all the actions involved. 

But that only helps in the short term. An expert who cares more about the delivery mechanisms and technology, rather than how the actual products or services work and fit the needs of its users, will be increasing extraneous cognitive load and reducing space for business-focused germane cognitive load.

Also, there are plenty of approaches you can take to reduce intrinsic cognitive load by spreading knowledge within teams and organizations. These include pair and mob programming, mentoring, immersive dojos, communities of practice, brown bag lunches, more classical training, conferences, and books.

Pick what's easiest to start with and evolve over time. What is often missing, however, is the vision to invest the necessary time and patience to start harvesting the results of upskilled, empowered employees.

This means your organization should continuously look for ways to reduce extraneous cognitive load on its teams, rather than falling back to hiring experts as a palliative solution for an immediate need.

Hire with learning in mind

If hiring experts is the principal way you acquire expertise and skills (such as agile, DevOps, or site reliability engineering) in your organization, you will face a difficult challenge competing with many other organizations that are doing the same in a scarce labor market. And even if you successfully address that challenge, it will lead to atrophy of your organization's learning muscles. Learning organizations grow from the inside. They can detect when existing tools, practices, and processes are no longer effective for the challenges at hand and adapt continuously.

Bringing in people with new skills and points of view can help challenge assumptions and make progress, but it will not fundamentally transform a static, slow-changing organization into a fast-paced, adaptive one. Becoming a true learning organization requires not only setting up safe learning spaces and practices, but also adopting an integrated view of who you're hiring and why.

So rethink hiring as part of your larger strategy to become a learning organization. Your strategy should:

  • Take into account existing team structures and interactions and how they are expected to evolve
  • Empower knowledge-sharing activities, providing logistics and especially slack time 
  • Make it a priority to hire people who are a good fit for a team's purpose, expected behaviors, and interactions with others, above specific technology expertise 

Also consider what options you have to reduce the current cognitive load on your teams before hiring.

The Team Topologies approach provides a thousand-foot view of your organizational landscape, helping you see the forest (missing capabilities and blockers to learning) for the trees (specific skills and trends in need today).

Matthew Skelton and Manuel Pais, the co-authors of the book Team Topologies, run training courses and consulting based on their approach. For more about the different types of teams, their composition, and purpose, as well as heuristics on how to map your existing teams into the four fundamental team types described above, come to their presentation at DevOps Enterprise Summit in Las Vegas. The conference runs October 28-30, 2019.

Keep learning

Read more articles about: App Dev & TestingDevOps