For many years I’ve subscribed to the idea that in a product organization, there are essentially two types of contributors: makers and managers.

Makers definitely include your designers and your engineers, and supporting roles like user research and data analysts. Makers design and build the products we love, so most people understand the critical contribution of makers.

Managers definitely include the managers of designers, engineers, and product managers. Managers are primarily responsible for the staffing and coaching of the makers, so most people understand their importance, especially if you’re a maker fortunate enough to work for a manager committed to helping you progress in your career.

The only real question has been regarding product managers.

In a feature team, the product manager plays much more of a manager type role – not a people manager but rather a stakeholder manager and project manager. However, on an empowered product team, the product manager plays much more of a maker role, albeit a less pure version of maker than an engineer or designer.

But the point of this article is that over the past decade or so, we’ve witnessed a rise in a third type of contributor, which I’ll call here process people.

Different processes often dictate specific roles, such as the Product Owner and the Scrum Master roles for Agile teams, or the Black Belt role for Six Sigma organizations.

But more generally, these are people whose primary job is not to be responsible for the makers or the product, but rather they are responsible for the process.

Now, process is not inherently bad. But it is dangerous. As Jeff Bezos warns, “Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing. This can happen very easily in large organizations.”

I’ve already written about the serious problems that result when you take a process role, like a product owner, and ask them to cover a product job, like a product manager. I’m not trying to repeat that argument here. Rather, I’ve come to realize that the problem goes well beyond product owners.

In many companies, the latest trend in this dangerous direction is the rise of product ops.

Now it’s important to acknowledge that there are several very different definitions of product ops out there today (and in upcoming articles I’ll be writing about several of them including the helpful and valuable definitions), but unfortunately one of the most common definitions is to have a person, or in many cases, an entire team of people, that exist to provide the process, tools and methods for the broader product organization.

In order to understand the pros and cons of this, let’s step back a second.

Fundamentally, as organizations grow, there are two main ways today that organizations attempt to scale.

One is by scaling their leaders (the managers). The other is by scaling their process.

I’ve written an entire book about how companies scale with strong product leaders. But here I need to talk about the alternative: attempting to scale with process.

If you’ve read my writing, you already know I have very strong feelings about the problems with scaling with process, especially the so-called “Agile at Scale” processes.

But I’ll admit to mixed feelings about the people in these process roles.

I am convinced that the vast majority of the people I meet in these roles have good intentions. They sincerely want to help their companies.

But in practice, they often cause far more harm than good.

Why is that?

First, I can’t help but notice that so many of these process people have never performed either the maker role or the manager role in a strong product company. They have more enthusiasm than experience or knowledge. Not only does this put exactly the wrong people in control of how teams work, but these people are prime targets for the armies of consultants and vendors that have figured out that these people are their best path into your company.

Second, in many cases, these process people are hired because the managers are not willing or able to do their job – especially in terms of coaching and developing their makers. If that’s what’s really going on, then that is the problem that must be fixed. A process person is a very poor substitute for a strong manager with the necessary expertise.

Third, process is a lot like religion. People get fanatic about their favorite processes, and it’s very difficult to reason with a fanatic. (As a side observation, my theory is that since these process people aren’t makers or managers, they tend to have more free time than the rest of us, and many tend to spend a good portion of that time on social media preaching their particular religion).

And finally, if you believe as I do that there is no one right way of doing product, then the very notion of standardizing a process across a large organization just means that you’ll be institutionalizing a process that will be a poor fit for most teams.

At the risk of over-generalizing, I’ve seen the product owner problem taking root in Europe, and the product ops problem taking root in the US, but both stem from what I consider a misguided focus on process as the means to scale.

In every strong product company I know, the key to scale has been their leaders. In particular, their managers, and the commitment of those managers to coaching and developing their makers.

I certainly understand the attraction of scaling with process, and the hunger for a framework or some form of “recipe for success” at scale. But that’s just not the reality in good companies. The truth is that product leadership is hard, but necessary.

So what to do if you are a leader at a product company?

I’m suggesting that you consider very carefully your mix of makers, managers and process people.

Your makers are the ones discovering and delivering your products so you clearly want the focus there. Your managers are the people that will need to coach and develop these makers to success, so they are your key levers.

Consider very carefully each process person you hire, and realize that you are choosing to fund a process person over another engineer, designer or product manager.

Make sure their purpose and contribution is clear, and that they are not there to try to make up for managers that aren’t willing or able to coach and develop their people.