What to say instead
There's a genre of LinkedIn post that always does well: things PMs say versus what they actually mean. Just flagging (there's a problem and it'll ruin your day). Just a quick one (it won't be). No rush (I'll nag until it's done). One tiny thing (I'm luring you in). Let's park that (I'll never unpark it). I'll leave you to it (for about two hours, then I'll ask for an update). Usually signed off with a guilty face, because the whole thing is a joke at the author's own expense.
I saw one of these recently and laughed, because it's well observed and every line landed. I've said all of them. I wrote a whole dictionary of this stuff myself, so I'm hardly in a position to be sniffy about the genre.
But it did start me thinking, which is the best thing a funny post can do. Not "these are bad people", because they plainly aren't; the joke works precisely because the author is admitting to things we all recognise in ourselves. More like: I've quietly trained myself out of most of these, and not for noble reasons. So this is the unfunny companion piece. What I say instead, and the entirely selfish reason why.
The selfish reason
I want the dev team still talking to me when the next thing catches fire. Something always catches fire.
That's it, really. It isn't ethics, it's self-interest played long. Each of those phrases spends a small amount of credibility, and the spending is invisible until the day you need the balance. "No rush" followed by three chase messages teaches the team that your words and your behaviour don't correlate. "One tiny thing" teaches them your sizing can't be trusted. "Let's park that" teaches them that agreements with you don't survive a deadline.
None of it is a sackable offence, and each instance is trivially small. But it's withdrawn from the same account you'll need when you genuinely have to ask someone to do something hard, fast, because the client moved the launch and you need them to believe you when you say this one actually matters.
Worth saying: a lot of those phrases exist because the PM is under real pressure and trying to be kind. "No rush" is usually someone softening a request they feel awkward making. The instinct is decent. It's the effect that misfires.
The freelancer's exception
There is one context where none of this applies, and I think it explains a lot about why the genre exists. If you get a new team every engagement, burning a little goodwill costs you nothing. You're gone before the invoice clears, and the interest never comes due.
Most of us don't work like that. I'll be in a room with these same developers next month, next quarter, on the project that matters more than this one, at 5pm on the day something breaks in production. Relationships that outlast the project change the maths entirely, and everything below assumes yours do.
The swaps
None of these are softer. Most are blunter, which is the point: the original phrases hide information, and the replacements hand it over.
Instead of "just flagging", say what it is and what you want from them. "This is a problem. I don't need you to fix it today, I need you to know it exists." The word "just" does the work of a hand hovering over a doorbell. Drop it and people stop bracing every time you appear.
Instead of "just a quick one", give the real size and let them pick the moment. "This needs about twenty minutes of your head, whenever suits before Thursday." Developers protect focus for good reason, and whoever tells the truth about interruption size gets given time willingly.
Instead of "no rush" or "when you get a chance", give a date and a reason. "I need this by Wednesday because the client review is Thursday." False softness is harder to work with than a deadline, because the team has to guess your real urgency and will eventually guess wrong. If there genuinely isn't a date, say so, then honour it by not chasing on Tuesday.
Instead of "can we sanity check this?", own the doubt. "I think this approach might not work and I'd like to be proved wrong. Walk me through it?" The original outsources your scepticism to an imaginary third party. Owning it makes disagreement safe and makes you someone who can be argued with, which is a reputation worth having.
Instead of "one tiny thing", size it honestly, including when the honest answer is "I don't know how big this is, that's partly what I'm asking". You lose the lure. You gain people believing your descriptions of work, permanently.
Instead of "let's park that", pick one and say it. Either "we're not doing that, here's why" or "that's real, it's on the list with a date in October". A park nobody ever unparks is a no that wasted six weeks of someone's hope. Developers remember their parked ideas. All of them.
Instead of "I'll leave you to it" followed by a check-in two hours later, agree the check-in up front. "I'll come back to you at four, does that work?" Same information arrives, no ambush, and they can plan a run at the problem instead of composing status updates in their head.
Who you work for
Underneath all of this is a stance. Mine: the team should feel like I'm working for them, and the client should feel like I'm working for them. Both are true at once nearly all the time, which is what stops it being a con.
The tiebreak, when it's genuinely needed: if both are in the same room and the positions can't be reconciled, the client wins. They pay the bills, and pretending otherwise is a fantasy that ends with nobody getting paid. That's the rare case, and the only one. Everywhere else, you back your team.
Including, and this is the part I'd most want to pass on, the difficult situations where you think they're actually at fault. Especially those. Throwing a developer under the bus in front of a client feels like accountability and functions as sabotage, because you're still in the hole afterwards, now with a team that has just watched what you do when things go badly. Handle the fault internally and directly, with the person, after. United front outward. The instinct to distance yourself from your team's mistake is the same instinct that guarantees the next one lands worse.
The bit that isn't about phrasing
The best project managers I've worked with all had one thing in common, and it wasn't a methodology. Their teams worked harder for them than for anyone else, because those teams genuinely believed the PM would go the extra mile for them. They were right to believe it, and that's the whole mechanism.
You can't phrase your way there. It's built from small moments where you told the truth about a deadline, took the hit in front of a client, or unparked something because you said you would. Which is why I've ended up avoiding those phrases, despite finding the joke funny and having earned my place in it.
The post was a laugh at our own expense, and a fair one. This is just what I do on the Monday after.
