Why the sudden surge in operations related roles across product development disciplines? What is the connective tissue and where do they differ? What can they learn from each other? These are some of the questions we hope to answer in this article.

In this article, I'll be covering:

A bit of history

Although it has been suggested that the first explorations of operations as a concept date back to ancient civilizations, roughly 5000 B.C. in Sumeria, a more accepted theory is attributed to a period just before the industrial revolution.

Adam Smith wrote “The Wealth of Nations” in 1776. Smith’s work described how groups of people can be more efficient in building products and later influenced Henry Ford in the creation of his well-known production line.

But it was only with the industrial revolution and the rise of factories, machinery, and mass production that efficiency and reducing waste became vital. Frederick Winslow Taylor and Henry Ford were fundamental in the development of operational development. Taylor, with his more scientific approach based on data, and Ford in how he developed his mass production assembly lines, supply chains and delivery.

Post World War II, we saw new technology created and the rise of computers which truly revolutionized how we approached operations. With access to more data and sophisticated forms of tracking production and delivery, operations were able to improve its approach tenfold.

In the modern age, with the rise of digital products and a more global business landscape, we’ve seen an increase of not only the complexity of operations but the creation of operational roles within the teams that build digital products attached to specific disciplines or areas.

Ops everywhere! But why?

DevOps, ProductOps, DesignOps, ResearchOps, PeopleOps, DataOps… the list of ops roles seem to be endless, and as I’m writing this, I’m pretty sure that another two or three were created. Why do we see this sudden surge in ops-related roles?

The reasons may differ slightly between organizations, but generally, it’s because they have identified the need for their teams to focus more on the “what” and less on the “how”. This is where the operations teams play a fundamental part by having a group of people looking more at the operational side of the work.

More than that, we’ve seen organizations going from small two-man startups to hundreds or even thousands of employees in just a few years. Rapid growth is easy to sustain initially by adding more headcount, external contractors, and financing.

The problem arises when you reach the point that adding headcount stops having the significant effect we saw at earlier stages of the company. We also see that size, agility, and the capability to remain relevant become more of a challenge.

This is when ops roles become fundamental. All of a sudden, there is a need to have a person or team focused on the continuous improvement of practices, systems, infrastructures, and capabilities. Being efficient in the way we deliver, innovate or build capabilities becomes just as important as the work on the actual product.

However, for most organizations, there is still a lot of uncertainty on when, where, and how to add an ops role. Which ops role does the team need and what should the size be? In the next part, we’ll look at where the roles overlap.

So similar, yet so different

In my opinion, there are a set of underlying principles that drive ops roles. The baseline focus and work are about supporting the teams and people working on the product. In fact, in smaller organizations, the ops person or team may oversee various types of operations across various disciplines.

The important thing to keep in mind is that focus shifts from what we are building to the how:

  • How the team builds their knowledge and capabilities.
  • How the team builds the product and sets a strategy.
  • How the systems support the team and their needs.

Let’s look at what that means in more detail.

People

  • The composition and structure of the teams.
  • The training and development of the people on the team.
  • How the people relate within the team and with external people.

Practices

  • How the end-to-end process may be improved.
  • How new joiners are on-boarded.
  • Rituals and interactions.
  • How and when to work with other disciplines.
  • Define how the impact of the work is accessed and presented.

Systems

  • Connect all the work.
  • Easier access to resources and documentation.
  • Tooling that supports the work.

people, practice, systems - in product


The differences, however, become more apparent when we start going into details about how we may approach each of these pillars inside different teams or disciplines.

Different disciplines will have differing needs, the tools and frameworks they use, the type of training and development they require. Interestingly enough, when we consider processes, there should be overlaps, even if the different disciplines need different things to complete their tasks.

The impact of ops on the different disciplines and on the larger team can differ greatly and so understanding those benefits becomes important when trying to decide which you need to implement.

Understanding the impact of ops

The kind of ops that makes sense may vary depending on which stage of the process we look at or what level of the organisation is needing assistance.

Depending on the organization, some disciplines may have done a good enough job operationally that they may not need an ops-specific role, while other disciplines desperately need someone to give the time to focus on their operation needs.

The points below will help you understand the potential value of each, but you need to be clear on where that value is most needed or will create the most impact, before deciding on which to implement.

ProductOps

  1. Help how the product team looks at the product strategy, impact metrics and defining the OKR structure.
  2. Move towards being more customer-focused and less delivery focused.
  3. Help in the process of developing a strategy and then build a roadmap to support that strategy.

DevOps

  1. Developing continuous delivery solutions and workflows.
  2. Develop structured code and bug analysis solutions.
  3. Be more value-focused and less delivery focused.
  4. Defining the processes for reusable components.

DesignOps

  1. Be more user-centered and less solution-focused.
  2. Define process and structure for design system.
  3. Define how design is showcased to others.

ResearchOps

  1. Define research planning and execution.
  2. Defining knowledge library and process.
  3. Defining how to showcase research and insights to others.
  4. Ensuring a pipeline of customers to talk to.

Where and how can they work together?

Looking back at both where the different ops roles have similar activities and when they each diverge to discipline-specific activities, the question arises, how may they work together and where should they focus on their specific space.

On one end the different ops roles could easily fall in the mode of constant head butting with each other. Each one argues the importance and impact of their work and how each needs to be “owner” of the various parts.

On the opposite end, we could fall into a siloed approach, where each ops role focuses solely on their discipline. This approach, although it does present a certain level of autonomy, usually means that many activities never reach their full potential and often cause clashes when they do need to align with other ops roles. Why? Because each might have gone off in opposite directions and the two just aren’t compatible with each other.

Here are 4 simple tips to keep all the roles aligned:

  1. Define the scope of each role clearly and where they need to collaborate from the beginning.
  2. Have regular catch-ups and alignments, talk regularly about the work you’re doing and how you can support each other.
  3. Avoid adding ops roles to the organization unless really needed. If you only need a few things from an ops role, then adding it to the mix of various ops roles could be pointless.
  4. Define the owner(s) of the collaboration between the various ops roles. Without a clear owner, it can easily become a design by committee situation that never actually delivers. It also becomes complicated to drive the change or make decisions.

In terms of structure there are a few options and here are the 3 main ways we see ops roles being approached. Each has its advantages and disadvantages.

Minimum hierarchical structure

In this structure, we have a loose hierarchical structure based on the working model of most product teams.

Product ops management overlooks much of the infrastructure across the whole product org. This means they are connective tissue, especially considering they are directly connected to product leadership.

The other ops roles are focused on their discipline-specific activities, but always take their guidance and/or feed The product ops team.

Advantages:

  • A clear notion of the hierarchical structure.
  • Easy to define the scope of each, as the Product ops team is the “owner”.
  • Easily scalable.

Disadvantages:

  • The other ops roles may feel as if they don’t have any real autonomy.
  • There may be a skewed focus on Product needs over other disciplines.

Multi-disciplinary structure

Rather than having the ops roles spread out across their various disciplines, in this case, we have a central multidisciplinary product ops team, that is composed of the various ops roles needed.

This team has its own space and overlooks all the product-related teams (Product, Design, Research, Analytics, Data, Engineering, etc.) making it somewhat agnostic to disciplines and teams.

Advantages:

  • Is a neutral party outside the disciplines and teams.
  • The various ops roles are more connected to each other.
  • Able to think more broadly.

Disadvantages:

  • Hard to scale.
  • Potential of being too disconnected from the disciplines and teams.

Flat hierarchical structure

In this final option, we remove the hierarchical structure, meaning that no ops role “owns” operations and thus all ops roles have equal say.

Each ops role is working within their discipline space and each ops leader from each group is responsible for connecting and aligning with the other ops Leaders. Whether it be through a Guild or just a regular ops leadership ritual.

Advantages:

  • Everyone feels as if they have the same level of control.
  • No discipline feels under-represented.
  • Incentivises open collaboration.

Disadvantages

  • Hard to scale.
  • Disconnect from the team level of other disciplines.
  • Harde to define scope.
  • Easier to fall into the siloed model.


Any one of these models may seem correct for you and your organization. However, you might quickly find that you've taken the wrong approach. Whether because the model you chose just doesn’t work or the organization scaled and the chosen approach is no longer valid.

The important thing is not to be afraid to change and test a new model if need be. But first, understand what it is you expect from the structure. The solution isn’t always a change, sometimes it’s just looking at your current model in a new way.

Very few companies have implemented Operations across various disciplines and managed to get them all to work together without challenges, so don’t feel as if you’ve failed if at first, it doesn’t go as planned.

Final takeaways

  • Operations has been around for a while and has already proven its value.
  • Before deciding which ops role is needed and which structure makes the most sense, we must first understand the different ops roles and the needs of the organization.
  • There are a set of baseline principles and activities where all ops roles overlap;
  • Each ops role has its own extra value specific to its related discipline.
  • There are various potential approaches to structuring operations in a product team.
  • No matter the course we decide upon, we need to be willing to adapt and evolve if the need is identified.

Resources

Historical development of Operations management - IvyPanda

History of Operations Management - Wendel Clark (Bizfluent)

Get Product Ops Certified👇