We promote them to middle management.
Ask HN: Do you celebrate failures at work?
51–58 of 58 posts
Re: Ask HN: Do you celebrate failures at work?
#52We don't exactly celebrate failure, but: 1) We have a culture that accepts "failures happen". People screw up, sometimes badly. 2) Imperative to this is a culture of ownership. You hide failures, your job is at risk. You own it, go public, get help, and all is well. Well, not exactly well, since there was a failure, but you get the picture. 3) Blameless post-mortems (hate that term, nobody died) 4) We do have a tongu…
[deleted]
Re: Ask HN: Do you celebrate failures at work?
#53Earlier quoted context omitted.
We say our battery's 'dying' or the site or something's 'dead' or 'live' or 'alive again' though - post mortem makes sense in that case, I understand the objection but I think you have to object to the rest too.
We declare an "incident". After it, you review the "incident". The site might not have even "died", but you still have an incident.
I agree it makes more sense, from first principles as it were, I'm just saying 'post-mortem' is consistent with other usages, so if we don't like it then we probably shouldn't like 'the server is dead' or 'the site is on its knees' etc. either.
Re: Ask HN: Do you celebrate failures at work?
#54The 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 ar…
Process can fail. 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.
Sorry I guess I wasn't clear since I only gave the one the "bug" example. I was already writing a long comment so didn't want to push it.
I just meant that the process of discovery and changing expectations exists for everything. I almost don't want to call it a "process" since it's ultimately unavoidable. You learn things and either change your attitude about it or bust.
Re: Ask HN: Do you celebrate failures at work?
#55Earlier quoted context omitted.
I'd also add that high-performing teams require psychological safety (e.g. mistakes don't get punished), the research is pretty clear. So punishment is explicit blocking of high-performance.
It depends what kind of mistakes and whether they are repeat mistakes. Everyone makes mistakes, sure, and that should be accepted, but if they are caused by carelessness or incompetence, or if the same mistake keeps being repeated then there ought to be consequences. A safe environment does not mean anything goes.
I think to an high degree it depends on whether the individuals could realistically prevent new instances given resources (e.g. access, head count, number of other high priority tasks, etc.)
Re: Ask HN: Do you celebrate failures at work?
#56We post a meme in our chat (this one: https://i.imgur.com/V54NdN0.png) every time there is a problem on prod, then we create an entry in our doc that explain the problem and how to resolve & prevent it.
Re: Ask HN: Do you celebrate failures at work?
#57Earlier quoted context omitted.
I'd also add that high-performing teams require psychological safety (e.g. mistakes don't get punished), the research is pretty clear. So punishment is explicit blocking of high-performance.
It depends what kind of mistakes and whether they are repeat mistakes. Everyone makes mistakes, sure, and that should be accepted, but if they are caused by carelessness or incompetence, or if the same mistake keeps being repeated then there ought to be consequences. A safe environment does not mean anything goes.
I honestly believe that this is an exception. Most people aren't going to be repeat offenders if proper blameless post-mortems/root cause analysis are performed. It will get to the roots of what actually caused it, and that can provide for a training opportunity.
Incompetence is generally caused by a lack of training, and carelessness is driven by culture. Yes, there really are cases where an individual is a problem, and potentially even needs fired. But most of the time it's the organization and its culture, policies, etc. that are truly at fault.
Re: Ask HN: Do you celebrate failures at work?
#58I'm not in the aviation industry or an aviation expert, but it seems like they have a really healthy approach towards viewing failures even though their failures can cost hundreds of lives and are far more impactful than some dumb bug in a dumb social media website.
When something goes wrong in aviation, they don't seem to rush to blame the pilot or an individual engineer who coded or welded something badly.
They look at the overall process and view it as a process failure.
They look at the flight checklist requirements and see if there are are any ambiguities or gaps.
They look at the manufacturing process and try and figure out if there are any better QA tests they can do.
They look at the design of the plane and see if there's anything that might have been overlooked as a possible issue.