Hacker News Reader

Comment by mden | Hacker News Reader

  and no one is willing to say so.

Except most engineers are perfectly willing to say so in my experience but management decides to ignore them or force them to say a made up number promising falsely not to hold them to it. Even worse what happens very often is an engineer would give an estimate and then a manager would "bully" it down to a lower number.

On the reverse of course it makes sense to have estimates otherwise how should managers or product people decide what should be done next?

A big part of the issue is we don't have good knowledge how to estimate work. It's not a skill that is heavily invested in and is wrongly assumed as an inherent ability.

View on HN

As a manager over a new project with a ridiculous release date, I'm subject to the same political bullshit as everyone else. At this point, I'm of the opinion that anything with a realistic ship date simply won't get funded. So all I do these days is commit to things that I am certain aren't achievable in the time frame on the table, just so that we can get the project off the ground in the first place. From that point, I immediately start to play the game of politics and showmanship to put together a narrative with the usual culprits for why a project is late. Shifting requirements, other teams that didn't deliver what we depended on, etc.

Then I make more promises and estimates, playing the emotional card of "sunk cost" to convince upper management to continue funding the team rather than torpedo the project. Then we ship, and I quickly get everyone on my team promoted "because we shipped" before it becomes clear to upper management that we shipped something essentially worthless to the company. Because we're in a huge profitable company, everyone can jump ship to the next shiny thing, and whoever is left holding the potato on its way to deprecation just gets re-org'd when it gets canned.

I know it's a bullshit game. But I play it well, and all the software developers on my team get paid and promoted because I am so good at it.

You're subject to the "same political bullshit" because you choose to be. You don't have to partake in it, but you do. You can choose not to, you can choose to try to bring the company around you to greener pastures - but you don't.

You sound wise and such in general, but perhaps your time would be better spent making a difference in how people believe work should be done at a place that actually allows brewing better practices instead of lauding bad ones.

This would just result in them not managing any projects anymore, and "Yes we can do it in 2 weeks" Joe will get them instead

One day you might play it so well, you find yourself on the Board.

Will you then argue that all new projects should avoid deadline dates, that no project should have anything other than an MVP and a iteration plan after that?

How do we change the expectations?

> So all I do these days is commit to things that I am certain aren't achievable in the time frame on the table, just so that we can get the project off the ground in the first place.

This is exactly the point of the article: Organizations routinely fail to prevent untenable projects from moving forward.

What I don't get about your strategy:

Why not work on something so valuable that even if it takes twice as long as the best estimate, with twice the headcount working on it, it would still be worth it?

As a a manager, I feel that helping to find projects that have that amount of value is an important part of my job, so that if I am fighting for a project my team's working on, I'm actually in the right from a business case point of view, not simply playing some BS political game.

If there are no projects that fit that value filter, then that's a completely different organizational problem.

Lol holy shit, this explains so much of my experience that I never even knew.

> I know it's a bullshit game. But I play it well, and all the software developers on my team get paid and promoted because I am so good at it.

On one level I have to take my hat off to you because you sound like exactly the kind of manager - one who has your team's back - that a lot of people would want to work for.

On another level you're part of the problem: you're wasting organisational resources that could be better and more profitably used elsewhere.

Still, needs must I suppose, because the real fault here - as the article itself hints - is in the determination of what the most valuable use of everyone's time is. I.e., if projects are going to be late (and they are) then you ought only to deploy teams to work on the ones with a putative 10x ROI.

Though this be madness, yet there is method in ‘t

I had this experience recently. We don't use a lot of detailed estimates in my team, because the work needs to be done regardless, and the estimates are then largely a waste of time.

But there was one occasion, where a product launch had been announced by a C*O before the product was finished, and the engineers were very clear that this launch date was impossible. So there was a lot of drama and bad feelings, and the engineering team eventually said, "okay, let's make a detailed estimate so we can be certain". The estimate came in at three weeks development time, one week after the announced launch date.

One week of the estimate was meant for testing and fixing problems that are found in testing. The business experts immediately jumped on this: "Testing and fixing unplanned errors won't be a big deal and certainly not a whole week. We'll skip that so we can get it done in two weeks".

Thankfully, this is retail banking, so releasing an obviously broken product flies even less than missing the deadline. The product was eventually launched uneventfully, one week after the detailed estimate and two weeks after the announced launch date. All in all a success.

I have, on more than one occasion, said so, and the response was always bafflement or annoyance, and in either case and unwillingness to accept that answer. When I was younger, I would eventually give a guess, along with a "...but that's just a guess". Nowadays, I don't even give that, because the caveats get forgotten/ignored.

I have this sort of discussion, at minimum, three times a week (we're in-house developers). Very often the project scope isn't even defined and upstream dependencies are known to be critically lacking and will need to be augmented to even perform the work. Yet we're always pressured for dates and the caveats given are immediately forgotten and almost never communicated.

The biggest pet peeve is when I give an estimate such as "I don't currently see a reason why we can't deliver X by the end of next week, assuming no other priorities come up." Of course something more important comes up in the mean time and I get scolded in a large meeting with a statement such as "You promised me I'd have X by Friday!" — this is especially infuriating when it is the PM's other project that is the higher priority interruption.

It might not be viable, but I used to "publish" internally my own project one pagers, and update the timelines - any discrepancies simply became a shield for this future arguments.

In short it sounds like you don't have the power to say no - but actually you do.

It doesn't get a lot of love on HN, but these problems are addressed by Scrum. Sprints have a pre-allocated amount of work in them, which makes estimating easier. You can't predict exactly how much time you'll lose through meetings and emergencies, but estimating in story points will add a rough statistical estimate.

Of course, if you already have a toxic development culture like the one you describe, then they'd probably abuse more agile processes too.

Instead of caveats, add to the estimate. Every caveat is some additional time.

Another thing that helped us is to answer with ranges instead of dates e.g., "this will take 1-3 weeks".

Reply on news.ycombinator.com