3 ms·

Nothing in OPs comment says it should only be completed stuff that goes into the status. Also, if your team is optimising for the status report, your manager h

Nothing in OPs comment says it should only be completed stuff that goes into the status. Also, if your team is optimising for the status report, your manager has already failed you.

fjfuvucucuc 3y ago
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)
ranting-moth 3y ago
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.
- neeleshs 3y ago
  Even if the detail was something like, "if this wasn't fixed, we were at the risk of losing half our customers" ?
  - nine_zeros 3y ago
    > 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.
- withinboredom 3y ago
  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.
- yathaid 3y ago
  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.
commandlinefan 3y ago
> if your team is optimising for the status report If you're providing a status report, you're optimizing for the status report. Period.
- DiggyJohnson 3y ago
  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.
- yathaid 3y ago
  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?

Nothing in OPs comment says it should only be completed stuff that goes into the status. Also, if your team is optimising for the status report, your manager has already failed you.

fjfuvucucuc 3y ago

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)

ranting-moth 3y ago

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.

neeleshs 3y ago
Even if the detail was something like, "if this wasn't fixed, we were at the risk of losing half our customers" ?
- nine_zeros 3y ago
  > 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.
withinboredom 3y ago
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.
yathaid 3y ago
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.

commandlinefan 3y ago

> if your team is optimising for the status report If you're providing a status report, you're optimizing for the status report. Period.

DiggyJohnson 3y ago
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.
yathaid 3y ago
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?