The PM Trap: Process as a Primitive, Not a Prison

I’ll be honest: I have very little patience for project management that gets in the way of the project. Coordination matters. But the machinery built around it can become antithetical to actual delivery.

There is a familiar pattern in software tools. A new product arrives lean and focused, promising to replace a bloated incumbent. Then it accumulates features for every conceivable buyer until it becomes the very thing it was supposed to replace. The team trying to get work done inherits all that complexity.

The problem isn't just the tools. It’s the philosophy behind them.

Stop Forcing the Taxonomy

It's tempting to begin with a standard hierarchy: initiatives, epics, stories, tasks. Before doing that, I want to know what problem the hierarchy is solving.

Imagine a tool whose users think in terms of documents and revisions, but which insists on calling everything an "entity." The abstraction may be convenient for the system. It doesn't follow that it is useful for the person using it.

The same applies to process. If engineers spend more time debating whether something is an epic or a story than clarifying the work itself, the taxonomy is adding friction. I prefer to start with a simple unit of work and introduce distinctions only when they help people make decisions.

I don't care how things are broken up. I don't care about burn-down charts or velocity. I care about what needs to be done.

Process Should Not Be a Prison

A lot of companies go wrong by creating a heavy process that optimizes for a small subset of people (usually PMs or executives) at the expense of the people actually doing the work. You end up doing extra administrative work just so someone else can do their job better.

Different roles legitimately need different views. Someone coordinating a roadmap needs to see dependencies and priorities. Someone doing the work may need a scratchpad and a clear immediate queue.

A useful compromise is to agree on a small set of shared primitives: enough common information to coordinate, with room for people to organize their own work.

For example, a hypothetical team could agree on a few broad categories for reporting while allowing optional labels and personal views. The shared structure serves a specific purpose without becoming the only permitted way to think.

A good tool gives people primitives to build the visibility they need, without mandating a process that impedes everyone else.

Lower-Friction Visibility in the AI Era

Process is usually a "push" system: engineers are forced to push status updates upward so leadership knows what's going on. I believe a "pull" system is vastly superior.

Good integrations can reduce duplicate reporting by drawing on information that already exists where the work happens. AI tools can help draft summaries or organize that information for different audiences.

That is a possibility worth exploring, not a claim that visibility is free or automatic. The information needs appropriate access controls, and generated summaries still need review. Automating an inaccurate status update doesn't make it more useful.

The goal is to make important work visible with less administrative effort, rather than adding another reporting ritual.

The Estimation Illusion

This brings me to a ritual I often find unhelpful: planning poker.

Without a shared understanding of what the numbers mean, a conversation can get stuck like this:

• PM: "Is this a 3 or a 5?"
• Engineer: "What's a 3?"
• PM: "Smaller than a 5."
• Engineer: "So what's a 5?"
• PM: "Bigger than a 3."

That discussion isn't reducing uncertainty. Software work often includes things a team hasn't done before; a more precise-looking number doesn't remove that fact.

I'm not blind to why teams estimate. A general sense of effort helps people decide whether something is worth doing now, later, or never. It also helps establish realistic expectations with stakeholders.

But Fibonacci numbers aren't the objective. I prefer enough discussion to understand the rough effort, the unknowns, and what could change the estimate. If a technique helps a team reach that understanding, use it. If the debate is mostly about the numbering system, it has stopped helping.

What actually matters beyond that rough baseline is expectation management. You can't express a delay or a pivot in a story point, but you can express it in a quick Slack message or a brief mention in a standup.

When you strip away the premature optimization, the forced taxonomies, and the heavy reporting structures, you are left with what actually matters: clear priorities, useful coordination, and delivery. Process should support those things, not compete with them.