Don't Add More Water

I spent a few years as a lifeguard. People complained about pee in the pool more than you'd expect. And every time, the answer was never more water. You find who's doing it and you make them stop.

Engineering teams have the same problem.

Same Pool

The pee is the urgent Slack message after the sprint is locked. The calendar invite that shouldn't exist. The ask to skip the process you agreed to, just this once, because there's a customer on the line and the deadline is Thursday and you're the fastest path to a solution. It builds up quietly until the team is treading water.

The water is headcount. And the instinct, eventually, is always to add more water.

It doesn't work. You're still swimming in pee. There's just more of it now.

Just One More Thing

Every engineer knows exactly who's doing it. It comes in some version of: "Just one more thing. Don't drop anything else. Still deliver on time. And can we sidestep the process we agreed to so we can make this happen?"

We've already locked scope. The sprint is already full. It's always urgent. It's always just this once.

And when it happens often enough, someone eventually asks whether the team needs to be bigger. Adding another person to the team may work in the immediate short term. Eventually though, the pee to water ratio will rise again and there'll be more talks of adding more water.

Not Malicious. Still Unreasonable.

The person peeing in a pool is being selfish. The PM or leader making these asks are almost certainly operating in a way they believe is best for the business -- unless you work at a dump.

They're responding to someone. A VP who got off a customer call with a commitment nobody approved. An exec who said something was coming by Friday. A competitor who just shipped and made everyone nervous. That pressure lands on the PM and their fastest path through it is you. The problem isn't malice. You're just downstream.

That doesn't make the ask reasonable. It makes it not malicious. There's a difference, and it's worth holding onto.

An Alignment Problem

In that moment, you and your PM are optimizing for completely different things. They're optimizing for urgency. You're optimizing for sustainability. Both are legitimate. Neither of you is wrong.

The pool has a pee problem. There's just no one to kick out.

Nobody agreed that urgency always beats process. They just started acting like they had. And now the team is full of engineers who feel like they're constantly getting peed on, and a PM who genuinely believes they're doing what the business needs.

They might both be right. That's what makes it hard.

Both Ends of the Pool

The fix isn't always headcount. It's the conversation that isn't happening.

Engineering has to show up with clarity on what's real. Not "we can't do that" but "here's what that costs, and here's what we'd have to give up." Pushback without a tradeoff isn't a conversation. It's a wall.

Product has to show up with honesty about what's actually urgent versus what just feels urgent. Not every customer request is a churn threat. Not every competitive announcement needs a same-week response. When everything is on fire, nothing is a priority and engineering can't triage a fire that product won't rank.

Too much product driving the process and the team is always in react mode, shipping half-finished work at a pace that feels productive until it breaks something. Too much engineering driving it and the team is technically excellent and completely disconnected from what users actually need.

Too much product or too much engineering. Either way, you're swimming in piss.