I was in a leadership meeting just last week. I saw eight people in the room. Four of them had this ops role in their title. So we had four of those. We had two product managers. Both of them looked exhausted, by the way. Now the agenda was clarifying decision rights for the Q1 platform roadmap. 90 minutes later we had a Miro board with 47 sticky notes, zero decisions.
And here's what the product managers said to me afterwards: "Lance, I used to own the roadmap. Now I need approval from platform operations to use their APIs, input from product operations on prioritization frameworks we use, and to boot, a program manager to schedule the meeting where we discuss what we're allowed to discuss. Next, we need to create a RACI chart."
So now we have three new roles, more meetings, slower decisions, and nobody can tell you who actually owns the system. Sound familiar?
Hi, I'm Lance Dacy, otherwise known as Big Agile. And today we're going to be talking about the ops role explosion.
Now, I used to be one of them — product operations, director of product operations. I know how it plays out. But to me the real importance is to know if you're building enablement or just building bureaucracy. We all suffer from that. Those are the mistakes that I feel like hide behind a buzzword called "scaling." We use that often.
Leaders Are Hiring Support Roles Faster Than Delivery Teams
So here's what I'm seeing as part of the last few years when this product operations role is really fermenting. I feel like leaders are hiring these support roles faster than they're hiring delivery teams, and they just brand it "scaling."
Here's how it goes. Let's see if it sounds familiar to you.
We created siloed component or function teams, sometimes called application teams. Your platform team is building an internal developer portal. Six months ago the adoption was like 11%. So our leadership says, "Well, that's not fast enough." So they create a platform operations role to drive the adoption, hold people accountable to it. And then the product ops gets hired to also streamline the roadmaps. Then a senior program manager appears — or portfolio manager, whatever you want to call it.
Now, what's their job? To coordinate all the dependencies between these teams. So now we've got four people in a room debating who owns the SLA for our DevOps pipeline or CI/CD pipeline. And to me the answer's always the same: "Well, we need another meeting to clarify that," or "Let's build a RACI chart." Or how about this one, right? The responsibility matrix. I'm a big fan of those, right? They have their place.
But I get it. I mean, our teams are struggling. We try to help. You try to help. And that makes sense until you look at the actual numbers. Are you helping the teams? Are you actually hurting the teams? None of us are intentionally hurting them. I hope not.
The Numbers Tell a Different Story
So we talk about our lead time, right? What is that? Well, it's up 40% since last year. Not a good metric, by the way. How about our deployment frequency? Well, that's down — that's going the wrong direction. And we find that our best engineers are spending Fridays updating tickets instead of shipping or reviewing code.
You thought you were building an operating system for product development. But instead, we tend to build a lot of friction into the system. Now we want it to be lean. We're trying to practice agile. Is friction a good or bad thing for lean, right? So that's what we want to focus on.
Now, the kicker to all this is everyone's busy. We've been talking about that, right? Calendars are full, dashboards are getting built. And when we ask, "Hey, what shipped this month that actually moved the needle?" there's this long pause. Now that pause is expensive. It's friction. Nobody can answer the question because there's too much friction.
Organizations Confuse Coordination With Value
So here is what I typically see that's really going on. I want to try to diagnose it. Obviously there's many permutations of this, but organizations often confuse coordination with value. When I see teams that are struggling to ship, the instinct is to add more process or oversight or even add roles. It feels productive because those people stay busy, and leadership thinks of it like what I call a "warm blanket." They know that somebody's watching and they know that the meetings are happening and that somebody makes a decision, and that's really all they care about. But it's not reducing friction.
Busy is not the same as effective.
And so the real delivery data that we have out there — and that's a pretty good amount of data — they're blunt about it. High-performing organizations don't have more operations roles per engineer. They have cleaner decision rights, better interfaces between the teams, and they have a lot less of what I like to call "handoff tax."
Platform Teams Are Not Service Desks
Platforms succeed — platform teams succeed — when they can reduce the cognitive load for our stream-aligned teams, not when they create new approval gates. It's the piece most organizations miss, this approval gate process. We should focus on team topologies. By the way, a platform team isn't a service desk. It's a platform or a product team that happens to serve internal customers. That's what we're looking at. Which means we need clear mission, decision rights, and accountability for those outcomes — not ticket velocity outcomes.
Product operations should be an enabling factor to these product teams, to help make those decisions go faster, not becoming another layer between the team and its customers. So if your product operations person spends, let's say, 60% of their time in status meetings, I mean, you don't have an ops problem. You have a clarity problem. And you can't hire your way out of that. We try to. Or reorg chart yourself out of that. That's what happens a lot as well.
I find adding more people to an already chaotic system, well, it just breeds more chaos.
Think of Ops Roles as System Designers, Not Support Functions
So we need to talk about how we would go about looking at an organization. What are some things to look at? They're all different, but maybe we should stop thinking about ops roles as support functions. Let's instead start thinking about them as system designers. That's how I like to think of it. System architects, right? Process architects.
Their job isn't to coordinate people. Their job is to design systems that make that very coordination unnecessary. Most of the time you're not going to get rid of all of it, but most of the time we want decentralized control that beats centralized control when two conditions are met: clear decision rules and fast feedback loops. That's it. That's what we're looking for.
So ops roles should be building those things into the system, not inserting themselves into every single decision point. And worse yet, if leaders want this because they don't trust the teams, well, that might be your root problem.
So we go back — we're an agile coaching and consulting group. Recall agile principle number five: we hire motivated people and trust them. Now, if you haven't done that as a leader, the problem's you. And then we can look at agile principle number eight: agile processes promote sustainable development pace. So that's reducing friction. Let's go deliver sooner by removing the friction.
What Ops Roles Should Actually Do
So what should ops roles actually do? I think these three things.
Number one: Design interfaces between teams so that they can operate interdependently — not schedule syncs, but design the actual contracts between the teams.
Number two: Build decision rules that let teams move and do their thing without asking permission. If an engineer needs three approvals to experiment with something, I feel like our decision rules are broken. And that happens quite a bit.
Number three: Create transparency so that teams see their own constraints — systems that make the invisible visible. Kanban really excels at that. That might be a good starting point.
The Haier Model: Platform Owners, Not Compliance Enforcers
Here's an example that I love. Think about Haier, this Chinese appliance company. They run 4,000 micro-enterprises with minimal central coordination. Like, how in the world?
They use what they call "platform owners." These people facilitate collaboration but have no direct reports. What's their job? Open channels, not enforce compliance. We use that platform owner concept quite a bit. It needs different things in software teams, it seems like. So it sounds kind of like a Scrum Master if we're using Scrum, but that's the model. Operations roles exist to reduce the transaction costs, not increase them.
A Decision Guide for 2026
So let's get practical. I like these videos to be a kickoff for the week and talk about a decision guide for 2026 to really try to focus on this as a theme, especially in Q1.
If product teams can't ship their stuff without waiting on other teams, you don't need product operations to go schedule dependency meetings. You need streamlined decision processes. You need streamlined team boundaries and clear contracts.
I like to use a term that's often in the industry: team topologies. Organize teams around the value streams. We call them product groups or feature teams at Agile, and then give them full ownership of their outcomes. We're defining clean interfaces — kind of practice what we preach, or "drink our own champagne" — in software architecture. So if Team A needs something from Team B more than, let's say, twice a sprint, then your boundaries are wrong. Let's go fix the boundaries, not add a dependency coordinator.
If platform adoption is low — like we're building all these developer tools and teams keep building the same thing twice — you don't need platform ops to go drive adoption. You need a platform team with product ownership and usage metrics, just like a real product. A lot of us launch products and we don't even have that. But internally we want to do the same thing.
Treat your platform like a product. Hire a product manager for it. Measure time to first deployment. Measure net promoter score from the internal customers. Manage it like you would a regular product, even though it's internal. Now, if your developers would rather build whatever it is you're supposed to be building for themselves than use the platform, then your platform's not the problem. It's not your adoption strategy — the platform is the problem.
If leadership can't see what's blocked or at risk, well, we don't need product ops to compile weekly status reports to fix that. That's a symptomatic adjustment of the problem. You need flow metrics. You need self-service dashboards. Let them go see it for themselves.
We want to try to automate that visibility. A lot of teams will use cumulative flow diagrams. They'll track lead time, deployment frequency, change failure rate, time to restore. Those are DORA metrics, and they're quite popular. If you need a human to tell you what's blocked, then your instrumentation's broken.
We want to build these processes and automate them so that those things are highlighted. It's a push system or pull system — so we can go pull the data anytime we want. And the pattern here is really simple: ops roles should build systems, not become systems unto themselves.
If your ops person is in more meetings than your engineers, then I find something could be very wrong with that. I don't like to call them meetings anyway — they're working sessions.
Four Traps to Watch For in Your Organization
So let me show you some traps and see if you can diagnose your system. I see these every single week that I work with teams.
The Empire Builder
You have some people — product ops or platform ops — they hire a team, and suddenly they need more and more headcount to justify their existence. Before you know it, you've got an ops organization with its own roadmap that's actually competing for budget with actual product teams but not really delivering any value. I don't mind that if they're delivering value, per se. But if your ops team has more than, let's say, three people, you've probably made a mistake, and we want to evaluate that.
The Meeting Factory
Y'all know these people. These are operations roles that start measuring their value by how many meetings they facilitated. They schedule things — standups, planning sessions, retros, program increment meetings, all these things. Our calendars fill up and work actually slows down. The more time we're in meetings, the less time we're building product. And I'm not saying all meetings are bad, but that's coordination theater, typically — not coordination.
The Proxy Product Owner
Product operations starts actually making product decisions because they're closer to the data. So now your product owners just defer — like they did in the meeting that I introduced — to operations for prioritization. I mean, congratulations, you just added a layer or two or three between the person who's accountable for the outcomes of the product and the team that actually is supposed to deliver them. That's not enablement, that's bureaucracy.
The Dependency Coordinator
Program managers, project managers, whatever you want to call them title-wise — they become full-time dependency trackers. They map dependencies, they run dependency resolution meetings. And hey, I love those, let's get rid of them. But here's the thing: if the dependencies that we're managing are a permanent job or even a full-time job, I feel like your team boundaries are likely wrong.
So let's fix the boundaries. Don't institutionalize a workaround for the dysfunction. We teach a lot of advanced agile coaching classes and we call that activity "being an accomplice to dysfunction." We have to be comfortable calling out and planning for that dysfunction's extinction, even if it takes years to do that. Have a plan. That's all I'm asking for. I'm okay with a lot of these things as long as they're short-term and moving us to the next thing.
Your Monday Morning Challenge
Monday morning — here's your one-week challenge. For this week, or the next week whenever you do this, I want you to audit one ops role if you have one in your organization. Product ops, platform ops, or program management — whatever you want to do.
Ask them to time-track for maybe three days. How much time do we all spend in meetings versus designing systems or building product? Count the recurring meetings. If you see more than five per week — I mean, something's probably off. It's probably less than that, by the way. But if you see five per week, that's not good.
Then we can ask the teams that they support. Go ask the customers this question: "If this role disappeared tomorrow, what would break?" And if the answer is, "Well, we would have more time back to build product," then you kind of have your clarity there. If people don't see value in those roles, then that's a problem.
I want you to rewrite their charter — the product operations charter — using this template: "Our mission of [whatever role this is] is to [whatever the outcome we want] and not to [whatever the activity trap is]." And then you can say, "Success looks like [this metric], not [some other vanity metric]."
Ops Roles Can Be Powerful — If We Get Them Right
I find if your ops roles are spending 70% of their time coordinating dysfunction, well, they're not fixing the system. They're likely actually becoming part of the problem themselves.
Look, ops roles can be powerful. I don't mean to put them under a microscope and indict them. I'm at the very core one of those people. So I get it. But we've swung the pendulum too far. The best product operations people design a decision framework and then get out of the way. That's the best thing we can do.
If your operations roles are empire building, well, that's a leadership problem. We need to clarify that. If they're spending all day in meetings, well, that's probably a decision rights problem. And if nobody can explain what it is that they actually own, well, that's probably an accountability problem. So it's our job as product operations people to go highlight these things and not become part of the problem.
You don't fix those problems, by the way, by hiring more ops people. You fix them by getting clear on who owns what, defining decision rules, and protecting — by goodness, protecting — our team's boundaries as they work in there, or clarifying them.
Ready to Build Enablement Instead of Bureaucracy?
If you're a leader trying to move from output theater to outcome delivery, that's exactly what Big Agile helps organizations do. Whether you're looking to sharpen your product ownership skills, get practical with flow metrics, or level up your agile coaching, explore the classes and courses Big Agile offers to help you and your teams cut the friction and start delivering real value.