Ten people sit in a conference room for an hour. Six team leads take turns reading slides, which rehash status already in JIRA. No decisions get made. Everyone leaves the meeting to do actual work. This happens every month. If asked, none of the attendees could name a single benefit of the meeting. It costs your company $24,000 a year.

Does this sound familiar to you?

The Problem

As engineering leaders, we are keenly aware of the cost of these meetings. We watch our teams go through the motions without genuinely engaging. Time that could’ve been spent more productively is instead spent on what I like to call “process theater”. The idea that if we just find the right process, have the right meetings on the right cadence, suddenly all problems are solved. Of course, this completely glosses over real business issues that can’t be solved by rubbing more process on them.

These are all symptoms of a trend I’ve observed emerging over the past decade or so — the overquantification of software development. The number of metrics and processes a software engineering team is responsible for is truly mind-boggling. It’s hard not to feel like we’re losing the plot. What difference does it make if a team delivered eight fewer story points this sprint if the business doesn’t have a clear vision for the product? Leaning on a team to find more work does absolutely nothing to correct strategic vision shortcomings. It’s a distraction.

Apparent Cause

My opinion, supported by my work experience, is that this seems to track pretty closely with the rise of the Project Management Organization, aka PMO. It’s supposed to be staffed by project management professionals who know how to Get Shit Done. At least, I hope that was the original intent. I honestly don’t know. What PMOs have become are shambling bureaucracies obsessed with defining Best Practices and processes, often in areas where they’re unqualified to have an opinion. The PMOs I’ve worked with have been fixated on defining software development and delivery processes, measuring and reporting compliance, and doing their best to blunt or deflect critical feedback.

How are they able to do this? The answer is surprisingly simple. Numbers and data. The explanations supported by PMO data sound reasonable to anyone not directly involved. Of course, team A’s velocity falling over the last three sprints directly contributed to missing their committed ship date. Clearly, we need to determine what’s going on with that team and address the issue.

This explanation glosses over so many real-life details as to be useless, if not actively misleading. Why did the team’s velocity drop? Product Management decided to rework key aspects of New Feature. In turn, this caused the team to spend several extra days in mandatory discovery and story-pointing meetings to follow the PMO’s work estimation process. As a result, two project status meetings were essentially useless, while the product manager and engineering team scrambled to adjust. The extra days of rework had to be absorbed into the already committed schedule. Why? Because the project was in the ’execution’ stage, the PMO’s process didn’t allow for requirements discovery and estimation.

Helpful, if messy, details like these are never included in PMO reporting. Why? PMOs are doing precisely what they’re incentivized to do: make software development look predictable and measurable. The problem is software development isn’t predictable, and the things that are easy to measure (story points, velocity, meeting attendance, and cadence) only tell part of the story. It leaves out critical aspects of the messy reality, such as unclear requirements, shifting priorities, and teams in limbo waiting for decisions.

Root Cause

This leads to the next question. What’s causing the misalignment between reality and PMO incentives? Executive incentives. All executives want to know what’s going on. They want to make impactful decisions supported by data. As leaders, they want to project certainty, confidence, and control. ‘We’re learning as we build’ is honest but doesn’t play well in quarterly reviews. A dashboard showing velocity trends and on-track projects does. PMOs exist to provide that dashboard.

The problem is that uncertainty lies at the heart of software development. You can do market research, prototype features, validate requirements - and still fail for reasons you won’t understand until you try. Leaders who embrace this reality and trust their teams to navigate it will have better outcomes than those who demand false certainty from dashboards.

Measuring The Cost

You can’t fix executive incentives overnight, but you can start quantifying what their desire for certainty actually costs. How Much is an easy-to-use meeting cost estimator I built that will never track you or store your data.

Armed with its estimates, you can at least start to push back on the most egregious waste. Click ‘Print Invoice’ to generate a PDF suitable for Slack, Teams, email, or whatever corp collaboration tool you use.

If these problems resonate with you, I’m building Collabchek - a tool to help engineering teams understand how they actually collaborate, not how the PMO thinks they should. It’s designed to give you the data you need to push back on process theater and focus on what actually helps teams ship.