Aurornis didn't say that. He specifically said "because they won’t sound good for the week".

With time and experience, you'll learn that those who can quickly churn out features and bug fixes are deemed extremely valuable to the company.

Let's say we have a wicked bug that has very little chance of happening. But if it does, it'll bankrupt the company, no questions asked. Spending 3 weeks fixing it is nowhere as impressive to the company as Joe who's churned out 10 features per week while your status updates are "Hunting for the wicked bug", even if you describe it it more details.

Even if the detail was something like, "if this wasn't fixed, we were at the risk of losing half our customers" ?

> Even if the detail was something like, "if this wasn't fixed, we were at the risk of losing half our customers" ?

Yes, because this one task appears as a single line item for the manager's manager. They don't care for the complexity or consequences until the fire actually happens. And if the fire happens, they just blame engineers.

If the industry incentives were changed such that manager heads would roll for mass outages, managers would start appreciating big fixes.

If you spend more than a few hours looking for a bug, you should start writing code to go around the bug completely. Even if it results in technical debt, if the company can go under if the bug isn’t fixed, you’d be stupid NOT to charge that TD card.

That’s why devs who understand that survive layoffs and the ones who spend three weeks “hunting for an extinction level bug” don’t.

You are describing a situation where management has failed. No amount of better practices can help in a situation where your management chain cannot evaluate your work correctly.

Yes. The manager has failed you. Doesn't mean you should put your ass on the line to fix things for the business.

That's why these kind of incentive structures are dangerous and why things like OKRs put such heavy emphasis on regular, company wide, failure. (I.e. they punish 100success rates)

> if your team is optimising for the status report

If you're providing a status report, you're optimizing for the status report. Period.

Eh, my personal experience has been that just as often we have a mandatory status report that nobody cares about (including my direct and skip level managers). It's just something that needs to be done for contract compliance.

I admire the confidence with which you hold this opinion.

Engineers are not providing status reports. The manager is collating them. How is it any different to a sprint summary?