Hacker News Reader

Comment by dunkelheit | Hacker News Reader

I remember a pretty similar dialogue that I had with a PM once, it went like this: PM: so what is your estimate for this feature? Me: 4 weeks to prod. PM: hmmm, that looks like a lot for a small task that is also very important for us, maybe you can do it in 2 weeks? Me: no, considering the amount of additional commitments that we have, I’m pretty sure this will be done in 4 weeks. PM: well, I’ll provisionally set the deadline to 2 weeks and then we can revise it. Me: whatever. 4 weeks later the feature is delivered to prod, nobody bats an eyelash.

The thing is most of the time these deadlines are totally artificial and simply a psychological trick to induce a sense of urgency. Moreover, PMs know that deadlines will slip and are prepared for this , they just want them to be slightly unrealistic so that you feel pressured (even better if you yourself suggested the deadline under their intent stare, then the pressure is higher).

View on HN

One of the key points you raise is separating the task effort from overall workload. Something I do in similar situations is “Here are the 4 other things I’m working on and their customers. Who do you want to talk to about deprioritizing their work?”

How this gets handled says a lot about an organization. (Priority conversations vs “suck it up”)

> PM: well, I’ll provisionally set the deadline to 2 weeks and then we can revise it. Me: whatever.

A PM doing that would be a red flag for me.

Clearly the PM isn't trying to manage the project in a tranparent, sustainable manner. They're trying to politic, manipulate, and pull the wool over everyone's eyes. This will only erode trust on all sides over time.

I've seen this poison tech orgs in the past. It turns them into a soured marriage where nobody seems to understand the other side and feels like actual communication is impossible.

Fix the incentive for the PM to play the games. TFA somewhat addresses this (bargain scope, not time), but it doesn't really address the underlying political forces the PM is acting under.

If the other person isn't even bothering to listen, there's no point talking. It's not a good-faith attempt to get estimates, it's not a two-way conversation, it's them trying to play dictator over time and space (or else play machiavellian politician). The only thing you can do is try to limit the amount of damage to yourself caused by the mess that they're going to make.

(I mean, you might be able to limit the damage to the company, too, but that would take exposing and undermining the PM now, rather than once the damage shows up. This is difficult, for two reasons. First, upper management really wants to believe what the PM is telling them, because it sounds better. Second, it's a political battle, and most coders aren't equipped to fight those successfully. One reason not to bother is the "nobody bats an eyelash" - if everybody knew it was a BS estimate, so there wasn't any damage to the company because nobody relied on it.)

4 weeks later the feature is delivered to prod, nobody bats an eyelash.

What do you do when eyelashes get batted?

Seems like you'd get accused of "not being a team player" or some such bullshit if you say the truth, which is: "The PM set that deadline after consulting with us, and us telling the PM that 2 weeks wasn't feasible."

In a good environment, you do something like give your boss a flag "hey, this PM is putting a two-week deadline this thing which we can't do by then because of all this other scheduled work" so they can have a chat with that PM's boss and then the two of them can potentially rope in whoever else is needed if re-prioritization is really necessary.

That's what middle management is for. The PM isn't your boss (I'm assuming). And they have a boss too who's job is to keep them in check, and the other middle managers are supposed to have relationships with each other. If there's any sort of middle management at the company yet things like that still either fall on the individual developer or dev team, that's a pretty bad environment (which then falls on the CTO, for having a tech management team that can't navigate the company, but in a different way that it would be on them than in a tiny company with devs reporting directly to the CTO.)

If PMs set developer schedules or are managing devs, it's a pretty big red flag for a company.

Reply on news.ycombinator.com