When It Breaks at 2 AM — Who's On Call?

The people pushing for speed are never the ones who get paged.

Your CEO wants more vibe coding. Your head of sales wants features faster. Your product leaders want to ship and look innovative. They capture the upside — the demo, the press release, the board slide that says "shipped."

The people who pay the cost? Engineers just keeping the lights on for code they didn't write. PMs stuck in constant triage mode fielding tickets on a product nobody owns. Customers depending on something that's one bad deploy away from breaking.

They didn't agree to carry that risk. Nobody asked them.

When you ship something without a maintenance owner, you're not moving fast. You're transferring risk to people who had no say in the trade-off.

I call this the ownership vacuum — the gap between who decides to build something and who's responsible when it breaks. And it's the fastest way to destroy trust between product and engineering.

Engineering Isn't Resisting. They're Negotiating.

When engineering pushes back on maintaining AI-generated code, they're not saying "we don't want to innovate." They're saying "we don't want to be accountable for something we had no hand in shaping."

That's not resistance. That's a boundary negotiation. And they're losing it — because the people with organizational power keep overriding them.

Every time a leader pushes past engineering's concerns about supportability, the team learns something: our judgment doesn't count when speed is on the line. That lesson compounds. First they stop raising concerns. Then they stop caring. Then they leave.

That's not empowerment. That's conscription with a motivational poster on the wall.

This dynamic isn't unique to tech. A financial services PM told me her team inherited a compliance reporting tool after a reorg. Nobody asked if they had capacity. Nobody assigned ownership. The tool broke during an audit cycle, and her team — who hadn't built it and didn't understand it — was on the hook. The people who approved the original build had moved to different departments.

The Conversation That Rewired Me

I've been the person who pushed for speed and left someone else holding the bag.

I championed a rapid prototype to prove a concept to stakeholders. Built it fast, demoed it brilliantly, got the green light. Then I moved on. The engineer who'd helped build it didn't. She spent six months maintaining something that was never meant to last, while her actual project work fell behind.

I didn't realize it until she told me — directly, in a one-on-one — that she'd lost trust in my judgment. I'd captured the upside. She was paying the mortgage. And I hadn't even noticed.

That conversation rewired how I think about shipping. The question isn't "can we build this fast?" It's "who carries what happens next, and did they agree to it?"

Three Trust Signals to Check

The ownership vacuum doesn't announce itself. It shows up in behaviors:

Escalation rate on shipped products. How often do issues on recently shipped products get escalated to people who weren't involved in the build decision? If engineering is constantly fielding problems on things they didn't choose to own, you have a trust problem disguised as a support problem. Track it. If escalations on "fast-shipped" products are 2-3x higher than planned releases, that's your signal.

Decision reversals by leadership. How often does a senior leader override engineering's pushback on maintenance concerns? Every override that ships something without an ownership plan is a withdrawal from the trust bank. Count them. If it's happening more than once a quarter, your team is learning that their judgment doesn't matter.

Voluntary attrition on maintenance-heavy teams. Who's leaving, and what were they working on? If your best engineers are quitting and their last six months were spent maintaining orphaned products, that's not a talent market problem. That's a "we burned the people who couldn't say no" problem. Check your exit interviews for the phrase "I was just keeping the lights on."

The Move — In Both Directions

Product leaders sit between the people demanding speed and the people absorbing the consequences. That means you have two hard conversations, not one.

The conversation downward — with engineering: Stop overriding their judgment on supportability. If engineering says "we can build this, but we can't maintain it without two more weeks of hardening," that's not resistance. That's professional judgment on what it takes to own something responsibly. Defend it. When you treat their maintenance concerns as obstacles instead of expertise, you teach them to stop raising concerns at all.

The conversation upward — with your CEO: When the CEO asks "why aren't we moving faster?" you need language that reframes speed as a total-cost question. Try: "We can build it in two weeks. Maintaining it costs us one engineer at 20% for the next two years. That's the real number. Do we still want it?" That's not slowing things down. That's giving the CEO a complete picture instead of a half-truth. Most executives will make better decisions when they can see the full trade-off. They're not choosing slowness — they're choosing with real information for the first time.

The conversation across — in every product review: Name who captures the upside and who carries the maintenance burden. Say it out loud. When the room can see the imbalance, it self-corrects. When it's invisible, it compounds.

If you're the PM carrying the burden, not the VP setting it: You probably can't force the structural conversation. But you can start naming the cost. Next time maintenance pulls you off roadmap work, document it. "I spent 6 hours this week on [orphaned product]. That's 6 hours not spent on [roadmap priority]." Send it to your manager. Not as a complaint — as data. You're not being an order taker when you surface the tradeoff. You're doing the job.

Empowerment isn't giving teams permission to build fast. It's giving them the authority to say "not without an owner" — and giving leaders the full cost so they can decide wisely.

Prompt

Think about the last three things your team shipped. For each one: who decided to build it, and who's maintaining it today? Are those the same people? Did the maintainers agree to the arrangement?

Forward this to the person on your team who's carrying the most invisible maintenance. They need to know someone sees it.

Reply and tell me about the gap — I read every response.

Landed here from a friend? Subscribe here.