Ask a founder whether someone's tracking delivery, and most say yes before I finish the question. There's a project manager, a scrum master, sometimes a title that's some combination of both. Standups run on schedule. The board is current. Ask for a status update and you get one within the hour.

And the vacuum is still there. It just has better meeting notes now.

‍

The Job Nobody Posts For

Small companies don't start here. In the early days, the tactical layer — who's blocked, what's late, what needs a call this week — gets absorbed by whoever's already in the room. Usually the tech lead, because they're closest to the work. Sometimes the PM, because product people default to owning whatever's unowned. It works, for a while, because the org is small enough that improvising the gap doesn't cost much.

Then it stops working. A tech lead's job is knowing how to build the thing. Ask them to also run the tactical operational layer and you're asking them to carry a second job, indefinitely, on top of the one they're actually good at. Something gives. Usually the board goes stale first, or the tech lead gets stretched thin enough that one of the two jobs slips — and it's never the code. The build fails loudly when that's wrong. Nothing enforces the same discipline on the tactical layer, so that's the side that falls apart without anyone announcing it.

It's a little bit C-3PO and Han Solo: one of them can recite the odds all day, the other one actually has to fly the ship through the asteroid field. Most orgs want both. Most only think to hire the droid.

At that point, almost every founder reaches for the same fix: hire a project manager, or a scrum master. It's the closest role that actually exists on a job board. Nobody posts a listing for "owns whether this whole thing lands." So they hire the job that's actually listed on LinkedIn.

‍

Great at the Stats. Useless in the Asteroid Field.

I watched this exact sequence play out on a large multi-year program. Growing fast, the tactical load had outgrown what the existing team could absorb informally, so the org brought in a dedicated project manager to run point on the day-to-day — tracking, ceremonies, status.

The hire was good at the job they were hired for. Strong process instincts. Tight tracking. Nothing fell through administratively, ever — if an auditor had ever needed to reconstruct exactly what happened and when, they'd have had a beautiful paper trail to work from.

But all too often a decision would come up that only made sense if you understood why the product was being built a certain way — not just what state it was in. Cut the feature to hit the date, or slip the date to protect what the roadmap promised. The kind of call that has to get made mid-sprint, not tabled for the next ceremony. And the PjM had nowhere to stand. Not because they weren't sharp — because nobody had handed them the product and strategy context that call required, and that context was never in the job description they were hired for.

So those calls escalated. Every time. To me, or to the founder.

I've watched this same recognition surface outside my own client work, too. A product leader, describing an underperforming PM on a public forum, ran through whether replacing the person would even help — and landed on "probably not, they'd hit the same wall in a different squad." That's the Hire Trap, described by someone living inside it, without the vocabulary for what they're actually looking at.

Tracking the state of things and owning the outcome are two different jobs. Most orgs only hire for the first one.

The PjM became an extra layer between dev and product — not the connective one. Status got tracked beautifully. The org was no faster at making the decisions that actually mattered. If anything, there was now one more handoff before a judgment call could reach someone able to make it.

We rolled the role off the project. I picked up both functions — the daily tactical ownership and the judgment calls that needed product and strategy context — while the founder kept doing the job that was actually theirs: owning strategy, one level up, without also running point on execution.

‍

The Operator Vacuum, Wearing a Different Badge

That's the Operator Vacuum wearing a different badge. Most PjMs and scrum masters are exactly right for the job they were brought in to do — this was never a tracking gap in the first place.

If you've already got someone in that seat and you're still here, the question isn't whether they're good at their job. It's whether their job was ever the job that needed doing. When a decision comes up that only makes sense in light of the why — not the what's-the-status — who actually makes that call? If the honest answer is "it gets escalated" or "it waits for the next meeting," the tracking is fine. The ownership isn't there.

‍

The Question Before the Requisition

I'm not going to tell you how to restructure the role — that's not a template problem, and it depends entirely on what actually needs bridging in your org. What I'll say is that the fix usually isn't "hire a better PjM." It's recognizing that tracking and owning are two different jobs, and most orgs have only ever hired for the first one.

The tech lead can't carry both jobs forever. Neither can the PM.

At some point somebody has to hold technical direction, tactical tracking, and product judgment together — bridging all three — or the vacuum just changes departments.

The question before the next requisition isn't "PM or scrum master?" It's whether anyone's job is to own the outcome, not just report on it.