In every team, there are people doing work that isn’t considered core. Product operation teams are figuring out what “core” is (see the myriad of examples here, here, here, and most recently here). The origin from operations and operations-hybrid roles (e.g. devops, research ops, etc.) points us towards maximizing value and reducing waste in the system. But what are we supposed to focus on?

For example, engineers do more than write code. Of course, if code is not written there is no product but it isn’t the only work that needs to get done. There are plenty of tasks that are needed to keep the team working together efficiently.

Product managers do a large number of tasks that build team alignment, decision facilitation, and generally wrangle the uncertainty of the world that doesn’t result in a specific work product. When we start to consider the processes for these tasks we get into the realm of operations, specifically product operations.

With every role within an organization we incentivise the work that is needed (and core) vs. the work that is “nice-to-have” when there is time. This is why we see so many groups think they can move forward without a product team at first. A great example of that is Stripe not having product managers for the first five years!

If we don’t align the incentives of this work, also known as “glue” work, we will find that our team won’t perform to the level that it could.

In the most recent Product Operations Summit I hosted a panel on the “Pillars of Product Operations” with Victoria Wood (Shopify), Wafic El-Assi (Uber), and Chris Compston (Farfetch). One of the questions was about how product operations are really about aligning the “glue” work that we do with the incentives of the role (starting at 37:31). This article outlines the discussion from that panel. We make the case for the value of this “glue” work, why aligning incentives of this work with the product operations team is key, and what limits there are to the product operations team taking this on.

What is “glue” work?

The term “glue work” was coined by Tanya Reilly to describe the work that goes unrewarded for individual contributing engineers but achieves an important impact on the team:

"Glue work is the difference between a project that succeeds and one that fails. This is why technical program managers and project managers make such an impact: they do the ultimate glue role. They see the gaps and fill them."
"In teams without a project manager, what happens? In some teams, the manager takes up the load. In others, the work gets spread among the people willing to do it, or the people expected to volunteer for it."

I highly recommend the entire talk:


In the end, without this glue work, the team will not be anywhere near as effective as they would have been otherwise. Managers tend to take on the glue work as part of their role. Sometimes individual contributors do but it could be hazardous for their performance evaluations. The reason is that this work isn’t seen as “core” like coding would be for an engineer.

Product management already has a good amount of team glue work. The building of alignment, decision facilitation, and generally helping management understand what the team is doing is all glue-like work.

Chris Compston said this about “glue” work of product operations:

"A lot of the work that we saw in the early days was definitely glue work. Really basic things like documentation standards, having one version of a 1-pager rather than 17 different ones… highlighting that work can be a daily challenge.”

And Wafic El-Assi continues:

"Yes, most of the work that we're going to do is glue work. But I’m looking for work that can unlock [gross merchandise value], profitability and scale the company overall."

Organizations that value impact look at glue work and don’t know what to do with it, even for product managers. When I was at Facebook, team cohesion was very little of what we were evaluated on from a performance perspective. I’d argue that glue work helps build team cohesion (and better relationships with stakeholders) but can rarely be directly tied to an impact even though Reilly identifies it as such.

Why is that? It’s because glue work can be easily mistaken for low value work - I’ll call it “bullshit” work.

“Bullshit” work

When I first started as a program manager at Microsoft a long time ago, the team would joke that it was my job to get the developers pizza and sodas. While it was a joke there was some truth in it. When the team worked late to meet a deadline I’d stick around, actually order the pizza, and set it up with sodas in a conference room.

Fast forward to later in my career and I would see issues with Jira tickets having the wrong status on the board. When discussed in a retro the engineers had forgotten. As part of the same retro, I was horrified when a product manager offered to move the cards for the engineer.

Moving cards around the board could be seen as something that isn’t as important as the coding. What’s worse is that the board is important for certain reasons but is seen as below the other coding work. The most likely person to take that work on is the product manager. This is “bullshit” work and the product person on a team is the most likely to take it on.

Now that there are product operations people starting to pop up in teams, there is someone else that is worried about the important work that product managers are doing. In fact, product managers see the value of this. In Pendo's "The State of Product Leadership report" people on product teams feel much more positive about their work if they have a product operations team:

Credit: The State of Product Leadership 2021

As seen above, having a dedicated product operations team is almost 25 points higher than the product team doing the product operations work.

How do we know when a product operations person is taking on this bullshit work from a product manager?

Primarily, I use a similar criteria as we do as product managers thinking about product decisions. I’m always trying to build products that maximize the impact and leverage for our customers overall. That means that I will avoid building custom solutions for particular customers. They are much less likely to be built correctly for more general adoption. If you are doing some work for only one product person it may not be worth the time.

Secondarily, we should be considering what is the highest leverage work that we could be doing at any moment. As Wafic and Victoria mentioned in the panel, we need to be considering the impacts we have on the team. Is this helping us stop attrition, create a great environment or making great product decisions. Some impacts are easier to see and track than others.

Product people (and product operations people) all have a drive to make things better. That is why we are in the roles that we are. There will be times that product operations could step in to help a product manager avoid failure. When do we just take on the work regardless of it being bullshit? As Victoria said in our panel:

“There's only one criteria for me: will it have a negative effect on our merchants. That's it.”

We can’t forget that as product operations people we are helping the product managers that are helping customers.

Align your incentives with the needs of the team

The product operations role is one that will make product teams more effective and drive a bigger impact on the product, even if we can’t quite show full causation yet.

What’s important about the operations role is that we’re making the glue work, which was usually taken up by people volunteering, and making it aligned with the incentives that drive us. The performance evaluation of a product operations person should be highly focused on the glue work impact of the rest of the team.

The hazard is we may take on too much of the bullshit work from product people (or the rest of the team). Without pushing back on some bullshit work we will end up being personal assistants to the rest of the team.

Get Product Ops Certified👇

Join Product Ops master Chris Butler for this unmatched certification on the game-changing phenomenon that is product ops. Chris will teach you how to PM the PM experience so you can increase the leverage of product management with your teams.

With Product Ops Certified you’ll:

  • Understand the terminology, expectations and roles of product ops people
  • Be able to apply product management expertise to improve your product community
  • Confidently build world-class product communities

Whether you’re just getting started or you’re looking to build and grow your team, Product Ops Certified takes a nuanced and unique approach to the field.