|
|
|
|
|
|
by sublinear
1233 days ago
|
|
|
The whole premise of this question is kinda backwards. If a dev messes up an implementation detail, that's a bug. It could be a small bug, could be a big bug, or could be a forced bug caused by contradictory requirements. Usually if it's a big bug then it's also probably the requirements. So then now there's at least one more owner of that bug besides the dev. Then you dig in further and find that the requirements are bad due to other seeming organizational problems, etc. so there are even more owners of the bug... Natural to ask at this point when is a bug a feature? What is failure anymore if you managed to redefine things and embrace that there was no organizational dysfunction after all and that the nature of the problem revealed some deeper truth about how to solve it? These are not abstract questions. What I'm saying is that work is just as much a process of discovery as it is a process to get some expected result. When the expectations have to change that's not failure, so there's really no such thing as failure and nothing to really celebrate or blame anyone about. If you're working then there's progress and that's all that really matters. If people can't keep up with expectations it's completely arbitrary to decide to either adjust expectations or fire people. That's a matter of running the business, not a judgment one way or the other of the work that was done. This is the reason they say to not take it personally. It's not just a bunch of bull to make you feel better. It's simply irrelevant. |
|
|
Something can be communicated and not acted upon.
Org structure can prevent action.
Failure can be an outcome from a hedged bet, where the chance of success was low, but the reward potentially high.
There are more abstract types of failures than engineering bugs. I would be impressed with a company that can turn a bug report into a ticket owned by a c suite person to reorganize the company.