May 2020

DevOps Institute
DevOps Journey SKILbook

Process & Functions:

DevOps Roles, Titles,
and Topologies, Oh My!
DevOps Success Requires
Topologies, Roles, and Titles

By Eveline Oehrlich, DevOps Institute,

with Matthew Skelton, Head of Consulting at Conflux
and Karen Skiles, DevOps Institute

Eveline Oehrlich Matthew Skelton

 Executive Summary
IT leaders and individual contributors are learning that
taking the next step to transform their organizations to
embody modern application delivery practices means
jettying rigid processes inherited from previous devel-
opment and deployment methods. It also requires the
change of culture, opening new and/or different com-
munication channels, building new team structures,
and organizing teams differently. This report helps
understand the dimensions of the change across titles,
roles, and team structures.
DevOps Journeys
Start at Different Places

The challenge is that there is not one specific DevOps model which fits every organiza-
tion as starting points, goals, leadership, existing cultures, architectures, systems, and
tools vary. Each organization starts from its own unique state and has its own unique
challenges. One goal which all DevOps journeys should have in common is improving the
customer and employee experience. Before embarking on a DevOps journey, consider
the following key topics.

Definition of a vision must be your first step. Because

DevOps is, by its nature, already an innovative process rath-
er than a single innovative solution, the starting point is to
consider the holistic concept of DevOps. For this you should
understand two major components: The complementary in-
puts, that is the products and additional processes needed to
implement it, and the vested interest, that is what is in place
and needs either to be integrated or replaced when moving to
DevOps. These two criteria provide the basic framework of
the DevOps process as implemented in a specific case. From
this point, it is imperative to justify the process by evaluat-
ing the technical advantages, such as speed and quality, and
the economic advantages by understanding all the costs vs.
benefits of moving from the existing state to a full DevOps
implementation (see DevOps Vision Playbook report).

Defining a starting point of a DevOps project needs a team

with a common goal. DevOps adoption varies between enter-
prise and project adoption. While 42% of survey respondents
have indicated that their company has adopted enterprise
across one or many projects, enterprise adoption is at 22%
globally1. No matter, if you are embarking on an enterprise or
project DevOps journey, all journeys must start with a team
which has common goals and objectives.

1
 The makeup of the team is determined by the goal, at first.
There are many types of DevOps projects which start by ad-
dressing a specific challenge. Some projects start by focus-
ing on improving release cadence, others start by improving
how incidents are resolved and other projects are focused
on how developers can improve how to initiate changes to
existing software. No matter, the team members which are
a part of the DevOps team should reflect the value chain
involved in addressing the problem, at first.

The value chain team members form a DevOps transforma-

tion team. Once a goal is determined and a team is assem-
bled, the team owns the next steps of the DevOps journey.
Key principles such as how to shape the culture, how to
adopt automation, lean, the leverage of measurement, and
sharing should be applied to continue the journey.

Understanding Which Topology Aids

or Hinders What Makes a Difference

One of the most persistent problems in software delivery today is that responsibili-
ty boundaries are unclear or misplaced. Poorly-chosen responsibility boundaries lead
to blocked flow, inter-team antagonisms, and wasted effort building the wrong thing.
DevOps Topology patterns help to promote greater organizational effectiveness by
highlighting the pros and cons of different ways of working between teams2. The multiple
viewpoints help organizations to reason about responsibility boundaries and collabora-
tion efforts on an ongoing basis. The following are key things to consider.

2
 Anti-type topologies work against you. One of the dangers
of multi-team working is the creation of skill silos that work
against fast flow. In fact, the whole DevOps movement was
originally driven in part by a desire for a fast flow of changes
to software systems. Sadly, many organizations have missed
the early lessons from the DevOps movement and created
new silos around tooling and infrastructure that cause bottle-
necks and cross-team friction. This could be avoided by de-
termining a vision for the DevOps journey. Anti-type topology
models include Dev vs. Ops, DevOps silo, No Ops needed,
tools teams, SysAdmin, embedded ops, and Dev vs. DBA. The
DevOps silo is still the predominant topology in use today (see
Figure 1).

Figure 1:
Topologies in Use Today

Container-Driven Collaboration 1%
Other
(Please Specify) 2%
SRE Team
4%

Q
(Google Model)
What topologies are leveraged
as the primary model within
Ops as an Infrastructure-as-a-Service Team
(Platform)
5% your organization today?

None of the Above 6%

DevOps within Dev
(Organization Assumes Operations is No Longer Needed) 7%
Devs Silos and Ops Silos
(Legacy Model) 8%
DevOps-as-a-Service
(External Service Provider Support Some or All Aspects) 8%
DevOps within Ops
(Re-Branded SysAdmins) 10%
DevOps Tool Team
(DevOps Team is Responsible for Tooling Required) 13%
DevOps Collaboration
(DevOps is Everyone’s Job) 18%
DevOps Team Silo or DevOps Advocacy
(Seperate DevOps Team Between Dev and Ops) 19%

Source: 2020 Upskilling: Enterprise DevOps Skills Report

3
Leverage DevOps topologies which accelerate success.
There is no single “best” DevOps topology that will guaran-
tee success. Some patterns work best in certain situations
while other patterns work better in other situations. For
example, when two teams need to work together to discov-
er new technologies or new ways of working, Type 1 (Dev
and Ops Collaboration) works well. However, this collabora-
tion can be difficult to sustain for long periods of time, and
typically does not scale to more than a few teams simultane-
ously. At scale, the pattern that seems to work well is Type 3
(Ops as Platform) where the Ops team provides only the un-
derlying infrastructure and has no runtime responsibility for
the applications running on the platform. The Dev team has
runtime responsibility for the applications. Other DevOps
topologies can work in more specific scenarios.

Ensuring team ownership and trust boundaries. Modern

software delivery is a sociotechnical practice, combining
social aspects like teams and larger groups with technical as-
pects like code, infrastructure, and so on. Organizations are
increasingly looking to tackle the challenges of organization-
al dynamics as part of their approach to effective software
delivery. This means things like limiting the size of software
to the cognitive capacity of the team, what is called Team
Cognitive Load in the Team Topologies book3. This rightsiz-
ing of software helps to improve team ownership and flow,
making the software delivery approach more sustainable
over months and years. Organizations are also beginning to
understand the implications of so-called Dunbar´s Number
as these relate to groups of people within the organization4.
Anthropologist Robin Dunbar has characterised a series of
human trust boundaries that relate to the size of groups,-
Dunbar’s Number, and how these relate to a sense of “us
and them”. It’s important to acknowledge these trust bound-
aries and design organizations to take advantage of the
different levels of trust within these groupings.

4
Job Titles and Job Roles are
Important to Facilitate Structures

While team topologies influence the success of DevOps journeys, the job roles, habits,
and capabilities in people and the workforce are just as important to facilitate these
structures. While job titles speak to certain abilities and typical tasks based on training
and experience, they also define the level of the job within the organization, consider an
Assistant Professor versus a Professor, and sometimes determine the pay grade. Whereas
a job role is the application of talents and abilities specific to a situation. A person holding
a job title can have different roles in different situations.

DevOps Engineer or Manager is the most popular title. As

mentioned, job titles describe a certain ability or typical
tasks performed by an individual. Our research indicates
that DevOps Engineer wins the number one title spot in our
survey. The popularity of the DevOps Engineer or Manager
title has grown significantly since 2019 (see Figure 2). Howev-
er, the role will require knowledge, experience, abilities, and
skills across a key set of topics applicable to the organiza-
tion seeking a DevOps Engineer or Manager. According to
Robert Half Technology, today’s salary for DevOps startup
positions starts at $90,000 and can go up to 180,000 for
experienced DevOps individuals5.

The DevOps Engineers are generalists and specialists.

While it is still essential to have specialists, such as network
administrators, storage administrators, and so forth, within
an integrated product team, a department with over-spe-
cialized individuals within a DevOps project no longer
exists. While the number of technologies within organiza-
tions are continuing to increase, it is encouraged to foster
DevOps engineers to have a variety of general skills with
specialized knowledge and achieved mastery in the tech-
nology areas needed. The key functional must-have skills
for a DevOps Engineer are IT operations, security, infra-
structure, application development, and design (see Figure 3).

5
 Figure 2:
DevOps Engineer is the Most Dominant Job Title in 2020

Q
For which job title(s) have you recently
hired (or are you planning on hiring)?
Select all that apply.

Product Value Stream Lead

3%
System Administrator 15%
(or similar title to reflect value stream management)

15%
4%
Other Roles You Have, Automation Architect
or are Planning to Recruit for

None of the Above 7%

Test Engineer 16%

Scrum Master 16%

Don’t Know
9%

Site Reliability Engineer 17%

Platform Engineer
11%

DevOps Coach 11%

Infrastructure Engineer
(cloud, environment, etc) 18%

Product Manager or Product Owner 11%

CI/CD Engineer 24%

Release Engineer / Manager 11%

DevOps Consultant 26%

Agile Coach 14%

Software Engineer 28%

DevOps Engineer / Manager 51%

Source: 2020 Upskilling: Enterprise DevOps Skills Report

6
Figure 3:
Functional skills, IT Ops, Security and Infrastructure Skills ​
are Just as Important as Application Development

Q
How would you rate the importance
of the following functional skills for
your DevOps team members?

IT Operations Knowledge

52% 44% 4%

Security Practices

52% 45% 3%

IT Infrastructure Knowledge

50% 46% 4%

Application Development
and Design (SDLC)
45% 44% 11%
Must-Have Skills

Quality Assurance Knowledge Nice-to-Have Skills

32% 55% 13% Optional Skills
Business Continuity and/or
Disaster Recovery Knowledge
31% 52% 17%

Testing Knowledge

31% 59% 10%

Network Knowledge

28% 61% 11%

Governance, Risk and Audits

28% 55% 17%

DB Schemas and SQL Knowledge

25% 59% 16%

Enterprise and/or Business

Architecture Knowledge
24% 55% 21%

Source: 2020 Upskilling: Enterprise DevOps Skills Report

7
 Integrated product teams own the customer experience
on what they deliver. Integrated product teams are small,
focused, and multi-skilled teams which are responsible
across the entire value chain of their product with the ulti-
mate goal to deliver value to their customer. These teams
draw essential team skills from traditional functional areas
such as application development and design, IT operations,
security, quality assurance, customer experience, and archi-
tecture with product leadership provided by the business.
Over time, team members become more cross-skilled and
the team more self-sufficient.

What This Means

Leading Organizations Understand the
Importance of Topologies, Titles, and Roles

Fundamentally, until DevOps, we have simply perpetuated the initial development and
operations model that started over 50 years ago. It has been codified through many
methods and processes, but these usually simply added layers of bureaucracy over the
old model. DevOps is a complete transformation that gets rid of all the previous ossified
processes to answer today’s accelerated digitalization. The continuous drive towards
improvements around customer and employee experience fuels the desire to continually
evolve the digital business. Technology transformation is accelerating, existing architec-
ture silos within IT are transitioning to microservices, serverless, cloud, and Artificial In-
telligence is being leveraged to automate and replace some of the mundane tasks. Teams
will continue to exist. Due to continuous change, it is essential to continually adapt and
transform teams and individuals. To establish a successful DevOps team composed of key
members requires team members with key skills assembled into suitable archetypes.

8
References
1 https://devopsinstitute.com/upskilling-2020/
2 https://web.devopstopologies.com/
3 https://teamtopologies.com/?gclid=CjwKCAjw4871BRAjEiwAbxXi23T4EoV0hZP8_SVzqb3cIfbTp_NlAOz
T1wk5alJ5wI2YtU75Ji7DhRoC7JgQAvD_BwE
4 https://en.wikipedia.org/wiki/Dunbar%27s_number
5 https://dzone.com/articles/flow-metrics-software-delivery-metrics-for-busines

About the Authors

Matthew Skelton is Head of Consulting at Conflux (confluxdigital.net). Recognised by

TechBeacon in 2018 and 2019 as one of the top 100 people to follow in DevOps, Mat-
thew curates the well-known DevOps team topologies patterns at devopstopologies.com
and is co-author of the books Team Topologies (IT Revolution Press, 2019), Team Guide
to Software Operability (Skelton Thatcher Publications, 2016), and Continuous Delivery
with Windows and .NET (O’Reilly, 2016).

Conflux helps organisations to adopt and sustain proven, modern practices for delivering
software rapidly and safely using consulting, training, and our own range of books. We
specialise in applying Continuous Delivery, software operability, and team-first organ-
isation design using Team Topologies across organisations of all sizes, from startups to
multinational corporations. Learn more: confluxdigital.net

Eveline Oehrlich is Chief Research Director at DevOps Institute. She conducts research
on topics focusing on DevOps as well as Business and IT Automation. She held the po-
sition of VP and Research Director at Forrester Research, where she led and conducted
research around a variety of topics including DevOps, Digital Operational Excellence, IT
and Enterprise Service Management, Cognitive Intelligence, and Application Performance
Management for 13 years. She has advised leaders and teams across small and large
enterprises worldwide on challenges and possible changes to people, process, and tech-
nology. She is the author of many research papers, thought leadership pieces, and is a
well-known presenter and speaker within the IT industry. Eveline has more than 25 years
of experience in IT.
About DevOps Institute

DevOps Institute is dedicated to advancing the human elements of DevOps success. As a

global member-based association, DevOps Institute is the go-to learning hub connecting
IT practitioners, education partners, consultants, talent acquisition and business execu-
tives to help pave the way to support digital transformation and the New IT.

We help advance careers and support emerging practices within the DevOps community
based on a human-centered SKIL Framework, consisting of Skills, Knowledge, Ideas, and
Learning. All our work, including accreditations, research, events, and continuous learn-
ing programs, is focused on providing the “human know-how” to modernize IT and make
DevOps succeed.

Address and Other Details

Please contact
[email protected]
for questions about this report.