Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Defense against the dark art of estimation bargaining (2014)

monkeyandcrow.com

Post reply on HN
Print view View original

61–70 of 73 posts

Re: Defense against the dark art of estimation bargaining (2014)

#61

Post by avereveard »

netghost wrote: post #58
avereveard wrote: post #16

Earlier quoted context omitted.

Yeah a lot of these approach only work if applied to the perfectly spherical manager and engineers.

Hey there, I'm a bit surprised to see this reposted. I'm the original author. I don't think it requires perfectly spherical humans in a frictionless office, but it does require everyone to have the same incentives in place. When I wrote this, I worked on a pretty well aligned team with a very short power distance. If you're in a truly adversarial position, you probably need to take a different tact, or find a new rol…

> I worked on a pretty well aligned team with a very short power distance

then whatever management style would likely have worked; where I work I've the ultimate word on who works with me and I only allow hires that are well motivated and aligned and just set them in the direction of the goal and they barely need anything but some technical guidance every now and then. the downside is that we have a interview failure rate of about 98%, we're short of people and I'm under immense pressure from above to grow my team with whatever fit the job advert keyword.

> you probably need to take a different tact, or find a new role.

that is great personal advice, but to management, the golden egg is how to make dishomogeneous people work, even in face of adversarial behavior.

they managed to do it on the factory floor, and there's good money for whomever manages to bring some of the line working hell to creative workers, money which is currently being scooped up by scrum masters and the like, so the bar isn't even that high

Re: Defense against the dark art of estimation bargaining (2014)

#62

Post by ornornor »

mcherm wrote: post #52
Igelau wrote: post #22

Earlier quoted context omitted.

In my experience, management digs its heels in on scope and time anyway by bringing in more people. Usually lots of them, and the cheapest people they could get.

Under a huge number of common scenarios, adding manpower to a project INCREASES the delivery time. This has been well-understood since 1975[1]. [1] https://en.wikipedia.org/wiki/Brooks%27s_law

We all know that, but it seems management didn’t get the message.

Re: Defense against the dark art of estimation bargaining (2014)

#63

Post by Guthur »

geewee wrote: post #24
Guthur wrote: post #12

In my experience with internal dev teams there are very rarely any real deadlines. They do exist; fixed product cycles, government mandates, but most of the time its made up arbitrary marks in a calendar, sprint deadlines (yes, these are deadlines), quarterly goal deadlines, yearly objectives etc. Deadlines are just lazy management, we feel we need to set deadlines to motivate people and drive delivery, the problem i…

I think there's also a third option - that the deadline energizes. I've been in teams, where the team as a whole set a completely arbitrary deadline for the functionality they'd like to have done by a given time - and that worked well to motivate team members to hit it. Granted, this is probably not the norm though, but it's not impossible.

There is a away to set goals and these can have a time component, daily todo list, weekly goal. But as you mentioned this works when they are a personal tool, and best when broken down into small achievable increments.

Re: Defense against the dark art of estimation bargaining (2014)

#64

Post by throw394024 »

CraigJPerry wrote: post #8

Chapter 2 “saying no” of “the clean coder” book has the best treatment of this topic i’ve read. It’s just the most realistic based on my experience. He also addresses the common push backs - e.g. “you don’t understand, i can’t say no in this position right now”

Quick summary?

Re: Defense against the dark art of estimation bargaining (2014)

#65

Post by throw394024 »

I don't understand how to handle this. In my experience this is what happens:

  - You start with a PM/PO/Someone handing out tasks
  - You learn the system
  - You start doing more work
  - They start giving you harder work
  - They start asking you to manage the tasks/trace down AC for new tasks
  - They start asking you to fix bugs or change AC mid-sprint
  - No amount of logic gets through
We can have discussions all day about the three variables, or agile, or maintenance, but at the end of the day if it's just a free for all it's up to how much they like you/how much you can delegate/how much you can say no effectively (and on an ongoing basis) to.

We have agile/jira/all these systems. Why not use them? Why not plan 2 weeks of work... and do 2 weeks of work? Why do they always need to try to squeeze more? It's exhausting and unnecessary and annoying.

Edit: I've worked extremely hard to do everything management asks, and I think this is the problem. I always do. How do you say no? Is it in private? Does the "scope talk" work? Do you do it for every story? Do you end up doing a lot of the planning work and always know what's on your plate as things are added so you aren't overloaded?

I really don't want to be the "make a ticket" guy, but it seems management can handle little less.

Re: Defense against the dark art of estimation bargaining (2014)

#66

Post by CraigJPerry »

throw394024 wrote: post #64
CraigJPerry wrote: post #8

Chapter 2 “saying no” of “the clean coder” book has the best treatment of this topic i’ve read. It’s just the most realistic based on my experience. He also addresses the common push backs - e.g. “you don’t understand, i can’t say no in this position right now”

Quick summary?

Manipulation, passive aggression, telling you that your jobs on the line, … the chapter plays through a few realistic dialogues in the context of a developer providing an estimate the manager doesn’t like and the ways the manager tries to persuade the developer that they’ve guesstimated wrong.

He rounds out the short chapter with an appeal to professionalism.

Re: Defense against the dark art of estimation bargaining (2014)

#67

Post by ornornor »

peterkelly wrote: post #14

Here's my approach: "Look, there's two ways I can respond to this. I can be honest with you, and tell you the truth about how long I think it's going to take. You might not like the answer, but at least you will be in a position to make properly informed decisions about what to do, such as reducing the scope or adjusting the launch date. Alternatively, I can lie to you and give you an answer that will make you feel s…

What do you do if they choose “door number 2”, when the deadline is approaching and you’re pressured to work overtime while delivering subpar code that will be a major pain to modify and maintain for the rest of your time on that project, leading to even more pressure and overtime?

Re: Defense against the dark art of estimation bargaining (2014)

#68

Post by throw394024 »

CraigJPerry wrote: post #66
throw394024 wrote: post #64

Earlier quoted context omitted.

Quick summary?

Manipulation, passive aggression, telling you that your jobs on the line, … the chapter plays through a few realistic dialogues in the context of a developer providing an estimate the manager doesn’t like and the ways the manager tries to persuade the developer that they’ve guesstimated wrong. He rounds out the short chapter with an appeal to professionalism.

This is something I've never learned how to defend against. I've always tried to stay professional... but I'm a chronic under-estimator, and also find it difficult to say no, which is a recipe for disaster.

Unfortunately people usually don't work like the team they purport to be (managers shielding their ICs, POs tracking down AC)-- they just see your willingness to work and exploit it for as much as you'll do, rather than trying to make a system that hums forward quickly. They demand speed, but don't want to improve process to get that, they just want you to work more and harder.

Is there a way to build trust or consistently set boundaries or protect your time? Some of my co-workers say "I'm almost out of hours for this week", which I think is one of the only things they understand, but then you really have to close the chat client and not help other devs, lest you miss your "estimates".

Re: Defense against the dark art of estimation bargaining (2014)

#69

Post by Igelau »

mcherm wrote: post #52
Igelau wrote: post #22

Earlier quoted context omitted.

In my experience, management digs its heels in on scope and time anyway by bringing in more people. Usually lots of them, and the cheapest people they could get.

Under a huge number of common scenarios, adding manpower to a project INCREASES the delivery time. This has been well-understood since 1975[1]. [1] https://en.wikipedia.org/wiki/Brooks%27s_law

Yeah, that was my point.

Re: Defense against the dark art of estimation bargaining (2014)

#70

Post by Sebb767 »

netghost wrote: post #60

Wow, hey folks as the author here, I'm really surprised to see this pop up on HN. It's been a long time since I wrote this, and I've come to appreciate that there are a lot of nuances, a lot of different teams, and a lot of different ways incentives are aligned in different environments. I'd love to hear some illustrations of ways y'all have navigated these issues. What factors made it successful? When would it not h…

What I tend to do is take a good estimate and triple it. So, at the end, I'll still have some leeway for things I didn't anticipate even after negotiating. But you method is definitely a step up.
Post reply on HN