This is literally the endgame.

And the only cure is instead building a company that's tolerant of mistakes while still aspiring to excellence.

The one I've worked at which got the closest had a corporate culture that failures were atrributable to processes, while successes were atrributable to individuals/teams.

Of course that had its own negative side effects, but on the whole it made the company a lot more honest with itself. And consequently got better work out of everyone.

> padding out their estimates by 150 or 200% - to avoid the blame storms they'd seen for missing "deadlines".

This is good advice, as devs tend to underestimate.

That is probably analogous to what happens in the American healthcare sector with physicians/hospitals/insurance carriers/pharma/etc. Each one padding their bills making it horrendously expensive for everyone at the end of the chain.

was this a company based out of Portland by chance? sounds like my last employer

> Volatility is how much the sprint changes. Sure you can pull one 5 pt ticket out and add in a 3 point and 2 point, but if you do that 12 times in a two week sprint, we will not finish the sprint even if total capacity stays under 40 points.

Isn't the entire point of a sprint that, once planning at the start of the sprint is over, you can't change what's in it by reprioritizing? All of product's reprioritizing should be in the backlog, not the sprint, and only affect what the next sprint is going to be, not the current one.

> What helped me was to track Sprint Volatility in addition to Sprint Velocity.

I dread to imagine the number of bike shedding meetings and planning poker it takes to change a 5 to a 3 or 7.

Jitter in agile; I love it.

So many bold claims in this comment and little to no justification.

For what it's worth I've seen pretty much the opposite. I don't know about competent vs. incompetent engineers. But when it comes to experience, I've seen the inexperienced ones giving super low estimates and the experienced people giving larger estimates.

> Maybe this is a good strategy for dealing with people who aren’t going to judge you for delivering slowly, or for managers who don’t know what the fuck is going on. For managers who do, they will see right through this.

I think a manager who doesn't know the difference between and estimate and a deadline is one who "[doesn't] know what the fuck is going on," and that's the kind of manager the GP uses this strategy with.

I've been considered high performer everywhere I went, only when I was beginning I usually gave very low and naive estimates, experience has taught me otherwise. Of course it will also depend on who and why I'm giving those estimations to.

Usually there are just too many unknowns that higher estimate is justified to avoid having to explain why you didn't make it by certain deadline. The estimates I give are not median or average that I expected the task to complete, they are so that I can be 95% sure it's possible to do it and then some.

It is however a logical follow up of the managers behaviour. If they try to hold the estimate as deadline, the estimate will be larger next time. If manager doesn't see this coming, the manager needs to work on some people skills.

The managers are often just as trained in this by the organization. If I'm in a "commitment" organization, I'm sure as hell telling them all to pad their estimates.

The punishment for a commitment culture is inflated estimates.

It's exactly this kind of prideful ego centric attitude that these managers rely on to get folks to commit to unrealistic estimates, then work nights and weekends (and cut corners) to fulfil.

I wouldn't advocate "super-inflated" estimates but within reason, there are long-term benefits if you go about it right.

Where I mostly worked, managers cared about deadlines they could tell to external clients, which they really hated to miss. Early on, I didn't realize that, and gave my best guess. If I guessed the correct median, I was missing it 50% of the time, and managers kept getting mad at me.

So I switched to estimates I could meet 90% of the time, and on the slow 10% I worked extra hours to meet my estimate anyway. Managers were happy. If I told them it would be done by Tuesday, it would be done by Tuesday.

But it had enormous benefits beyond that. In almost 90% of cases, I had free time. Sometimes I'd admit to finishing early, but I also used that time to clean up technical debt, automate the tedious parts of my job, or advance my skills. After a while, I could give estimates as short as my old 50% estimates, and still beat them 90% of the time because I'd made my tasks so much easier. Less technical debt also meant the resulting code was less likely to have bugs.

After a while, it seemed to me that all the other devs were overworked and I had it easy. But management gave me raises, and when they got in a jam, I was the guy they called on to bail them out.

I'm a junior and practically refuse to give estimates currently because the projects I currently get have no real requirements.

"We'd like to replace an excel table for some calculations with a dialog. Here's the template, how long do you need?" which sounds simple enough turns into:

1- Decypher what the example excel template developed by someone over 10 years even does.

2- Oh, there are actually 10 templates and manual actions that give the end result.

2.5- Oh, btw, we asked an external company about doing this for us a while back and they wanted 1kk euros, crazy right?

3- Oh, we also need to generate, send and track offers via the app with the ability to add comments and upload files related to the offer. We also want the user to be queried about what data he has on hand so that calculations he cannot complete are not offered/he's notified as to what else he needs to proceed.

4- Oh, we also need change tracking/audit logs for everything.

5- Oh, we also need to get data from this place, find a free API and also a way to get data out of this software here.

In comparison to that at my previous job the tasks were way smaller and clearer so I'd essentially give myself deadlines when talking to my manager by saying X and Y should be done by Z, A by B.

The only thing I can think of in this situation is to essentially make internal pseudo contracts regarding requirements but then I'm making a pseudo contract with someone 3 levels in the hierarchy above me who's also the person who can terminate me. It's not like that pseudo contract will be read by anyone besides us so it seems better to display lots of uncertainty. At least if you're senior you have more authority in discussion and don't really have to give a fuck since everyone's looking to hire senior devs + your downgrade is a normal dev position. From junior the downgrade seems to be testing or McDonalds and you get to redo junior.

> The engineers who are most likely to be under-performers are also those who give super inflated estimates for simple tasks.

Definitely did not seen this. Under performers are underestimating or just do wild random guesses. Under performance is most likely to be in the form of "making small estimate, try to make it technically, but then it has about millions of problems".

Big estimates require courage and confidence - under performers usually do not have either. They are too scared to estimate high.

This can only hold water in reasonably small orgs. In large orgs you often have to coordinate with large number of teams to get something delivered. Those teams have changing priorities that can impact when they complete their tasks. Your teams priorities can be shifted too to fight some fire. So this small estimate has no value because it has 0 correlation to the overall delivery date higher ups can commit to for the overall project.

> In my experience, super large estimates don’t make you look good in the long run, they make you look incompetent.

The manager need to know how to make the estimate to know is bullshit.

If the manager knows how to make the estimate and what it represents, there is no need to inflate it for them.

Yeah but missing estimates makes you look super duper incompetent by comparison.

>It's beyond me why we, as a supposed engineering profession, are unable to talk about risk, probabilities, and confidence intervals. And that isn't just on managers.

Because management quits listening after hearing "3 months," and bad management heard "3 months minus three weeks" and goes "okay 2 months it is".

But you have to remember that the manager is going to be asked for an estimate by his boss. He can't just say some time between "1 day and 10 years." In the real world, you have to be able to give some sort of estimate and help the poor guy do his job.

Here is an approach for estimation that works pretty well (from the point of view of a manager).

1. Ask the dev team to provide an optimistic estimate, and to then multiply by 2 to make it "realistic".

2. On top of that, add another x2 (which can be recalibrated as you learn how accurate this tech team is over time with estimates). Don't tell the developers about this, but make sure your higher-ups understand that this is what they need to be prepared for in terms of budgeting and time limits.

The reason you don't ask the developers to multiply by 4 directly, is to keep them motivated to aim for the x2, and avoid slacking or over engineering while feeling overly comfortable early on.

But by having the extra x2 in reserve, your back is covered, and you can afford to be cheritable with the dev team as they (as usually happens) go a bit over the x2 estimate.

This buys some early goodwill that can later be traded back in if you need them to up their game later on.

The alternative to the above is to exclusively find managers (at all levels) that can combine manager skills with high level engineering skills. Such managers often have the ability to expose unneccery delays directly, which includes the ability to tell apart delays caused by devs slacking from incompetence, scope creep or unexpected but valid causes.

Such people are really hard to find, though, for most companies. But companies that manage to build such high level top to bottom tech lead cultures may certainly be able to go from the 4x back down to 2x or even 1x compared to companies with non-technical managers.

The irony is that managers who demand certainty often undermine the very trust and collaboration they need to get reliable insights

Doesn't the article say that for experienced developers, the scaling factor tended to be converge on an average for each individual, even if variable for any particular task?

And Joel sidesteps the unknown-unknowns problem in that piece, by discussing boiling down tasks to <1 day chunks.

But what if you need to build a prototype before you sufficiently understand the project and options to decide on an approach? Where does that time get estimated?

The more projects I work on, the bigger of a fan of spiral development [0] I become.

Because, at root, there are 2 independent variables that drive project scheduling -- remaining work and remaining risk.

This estimation problem would drastically simplify if it allowed for "high confidence, 30 days" and "low confidence, 5 days" estimates.

And critically, that could drive different development behavior! E.g. prototype out that unknown feature where most of the remaining technical risk is.

Trying to instead boil that down to an un-risk-quantified number produces all the weird behaviors we see discussed elsewhere in the comments.

[0] https://en.m.wikipedia.org/wiki/Spiral_model

I’m more of a Parkinson’s Law person: "Work expands so as to fill the time available for its completion.”

Things take longer but if you over-estimate the project won’t come in significantly any earlier.

Knew what this was without clicking on it.

"Just trust me" approaches can be just as damaging as rigid demands for precise estimates