Microsoft researched what made employees happy

...but he works in a field where stuff is still 80% on paper and he has colleagues with self-purchased reference books and the ilk literally from floor to ceiling.

He spent a week clearing out his office and will be going into full retirement now. There's no way he'll be spending time lugging around a pallet worth of books to a new hotel desk every morning - nor will he give his own books to the company.

It could have been a really interesting technical experience, because the frontend was an absolute nightmare, but it serviced millions of people daily and billions in transactions annually. But I just couldn't catch up with so much bullshit. The best time was when nobody was there, so sometimes I'd work later, but then I'd be chastised for not showing up to the fucking standup on time.

Our school has a mandatory safety training before students go on internships, and the reason for that is that interns have died in the past. A lot of things can be dangerous at work (including ladders) and not everybody is familiar with the associated hazards. Ladders, compressed air, electricity, machinery, confined spaces, chemicals, dust, and so on are all things that are dangerous, and the fact that they injure or kill people every year even though they're known hazards is a testament that people are too complacent around them.

What's wrong with ensuring that people know how to use a ladder safely?

What's wrong with aspiring to have zero accidents in a work place?

The prevailing atmosphere is it's never the injured person who is at fault, it's always somebody nearby who has money.

People can't see the self-evident anymore. The Kantian and Nietzschian thing-in-itself is dead. People have to be told not to walk into boxes otherwise they will, while they dream of some heavenly work project in their mind.

How do we control it? Zero accident policies, you gotta remember not to walk into boxes and you gotta remember to slap on sunscreen, as if the material world only starts to exist again in people's minds when you mention it.

It varies by state as well. In New York, for example, any third-party work related fall from a height can be the company’s responsibility. You you need to have a bunch of procedures around ladders and lifts to get insurance or avoid excessive rates.

A zero accident policy means that you don’t accept employee injuries as part of the job. There’s usually a safety committee and they look at root causes for accidents, and processes to control them. From a company POV, I have no idea what your physical condition is, but when you something stupid like deadlift and transfer that 50lb piece of equipment on a ladder, I have to pay for it.

I worked at a place years ago where the procedure to decommission a hard drive was to puncture the platters with a drill press and remove the electronics with a pry bar. All good until an IT guy got metal debris in his eye, and required extensive surgery. Turns out the IT folks removed safety equipment to make the process faster, didn’t wear eye protection, and had the press improperly situated. Correcting any of those things would have prevented that accident - and they were fubar because no process existed to question it, and everyone felt comfortable doing what they were doing. It may seem like infantilism, but there’s a guy who suffered and continues to suffer from an eye injury because nobody was accountable for his safety.

You see, there must be "one rule for everyone". The head-office suits can't be seen as discriminating against the plebs at the mine sites. It's a perception thing, people won't obey if it's "rules for thee, not for me".

So... I got a talking to by HR for a solid hour because I didn't hold the handrail when taking two steps down to the cafeteria.

For many teams who get requests from external stakeholders in widely varied technical environments - ie consulting, often - estimation is functionally just a conversion process to a consistent unit. But you're absolutely right that for some teams the stories themselves are a good enough unit.

"Why not just estimate hours anyway?"

Because humans are extremely bad at estimating time, which is borne out by studies many times over. A good overview is the original research on this, for which Kahneman et al won a Nobel prize (yes, the same Kahneman who would later go on to write HN favorite, "thinking fast and slow"). The broad stroke is, the very best time estimators in the very best circumstances only underestimate their time needs by 33%. The norm is more like 80%. They propose a few time estimation strategies to get around it, like "third party estimation" and "tripartite estimation". But the simplest approach (which emerged in later research) is to ask them to estimate "size" of task, and use statistical corellation to convert that to a number.

This last is hand wavy unless you're familiar with the law of large numbers, the law that makes casinos profitable. A casino cannot (without cheating) determine the outcome of a single roulette spin. But they can predict with extremely high certainty the aggregate outcome of a thousand spins. This is the same with your estimates. You can't predict the corellation to time of a single story point. As you pointed out, sometimes something that looked complicated turns out to be easy and vice-versa. But given a sufficient sample size (of estimates with a consistent corellation to time), you can predict with extreme accuracy the time for 1000 story points.

"Consistent corellation to time" is a bit of a PITA in a group, BTW. If you have developers do their own estimations individually, each one will have a different corellation to time. You would need a very large sample size to overcome that much variation. This is why so many systems encourage team estimation, so the consistency is dependent on the team dynamic, which is much more stable even when adding/removing engineers. But as I said, if it's the same person or team always writing your tasks, you can use their team dynamic instead, since their story size will be consistent.

FWIW by sufficient sample size, I mean after about 3 sprints (of any duration) you can make reasonable predictions. After 6 sprints you'll have confusing outliers, and after about 9 sprints it will be clear with some numerical weight to it.

Which brings up question 2, "the commitment ends up being a deadline". This is a human nature thing, you're right! But the problem isn't a mismatch between human nature and your estimate. The mismatch is between human nature and the uncertainty of reality. How you push to improve this is contextual to your org. In hard situations I reverse the statement of my estimate, to "if we set dec 15 as the deadline, there's a 5% chance we won't make it. What's our fallback?" Asking that question a lot is helpful. But there's no magic bullet to making leadership - or worse, people who are afraid of leadership - plan appropriately for uncertainty. The best you can do is expose the uncertainty as clearly as possible, and give lots of lead time for the times when they still run into conflict between deadline, resources, and scope. After that, it's the manager's job to "manage" things and decide which variable they will alter to break the conflict.

Put another way: reality is uncertain. When that uncertainty leads to a conflict between deadline, scope, and available resources - because that will happen sometimes per point 1 - only someone with deadline, scope, or hiring authority can solve it. That's (usually) not within your purview as a lead engineer. The best you can do is to 1) call out the uncertainty as clearly as you can, as early as you can, and 2) signal that conflict as early as you can, so those managers have maximum leeway. Abstracted estimation makes that possible. Guesses and hopes don't.

E.g. last half, I had about 350 separate people I DM'd. Per year I generally break 500. If you include the size of email groups I have sent messages to, I'm consistently over 1,000 most months, possibly over 2,000 (maybe even significantly more). Microsoft has around 180,000 employees, that number could trivially go much much higher if I worked there.

17 is nothing if that's the criteria. Probably just noise, and you'll likely get different results next year.

For people I would consider to be my network... 30-40? Maybe 50? They're the ones I actually interact with repeatedly on purpose. Reducing that by 17 is substantial, and I don't think I'd be as useful if I cut that size.