Ask HN: Do you celebrate failures at work? Hello folks! Do you have any process, ritual, etc.. that you use at work to embrace and celebrate failures? E.g. I've recently learned that for a period at AirBnB there was an award for the biggest failed project and feature. How have these practices impacted your work? Do you feel that failures at work are accepted by the leadership and are used to create value (personal growth and business level)? Curious to hear your opinions and experiences. |
oh no, i can remember. i once restarted a trading server process that could not easily be restarted once it crashed - crap code, not written by me, which caused quite a few problems. but that's about it.
Or maybe, you haven't ever worked in a real job?
People screw up and make mistakes all the time.
I'd have no employees if I fired everyone after every mistake. I'm almost certain the same is true of virtually every company on earth.
What really matters is how people handle themselves and others when failures occur, which is what the OP is asking about. Very valid question. Unfortunately a lot of low quality responses in the comments so far.
From my POV, mistakes/failures are a fact of life, you can't avoid them. So instead, you have to manage the risk of failures/mistakes and work to reduce that risk until it's at a risk level where management is comfortable. At in IC level, that probably means doing retrospects on major failures, why they occured, how to avoid in the future... and most importantly, focus the retros on the -process- rather than the -people-. Processes can be easily and quickly improved.. "this slipped through QA because it's not on our QA checklist" compared to "Bob is a bad coder, it's his fault"
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 tongue-in-cheek slack channel for those folks who have caused a "p0", i.e. most-severe-breakage
Post-incident review
https://support.atlassian.com/jira-service-management-cloud/...
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.
Failing early and often is a healthy approach to learning. That doesn't shame people or cause serious harm.
Now I find the expression almost repulsive. Failure is part of work, not punishing failure is ok, celebrating it by saying "we learned so much" is a serious company smell for me.
* Where, when systems fail, they go through the motions and jump straight to celebrating. "Thank you for finding this, X!" "Thank you for fixing this, Y!"
* Where a post-incident report is little more than "We found defect X and then we fixed it"
* Where psychological safety means "let's avoid talking about this and the risk management systems that allowed this to happen because the people responsible for those areas might feel attacked. Trust that the managers have dealt with the situation"
We need to be more specific than just saying "celebrate failure" to non technical managers, or this is what we get.
– Thomas John Watson Sr., IBM
I'm trying to imagine a world where failure is seen as a good thing - it implies risks were taken, and without risk there is unlikely to be progress. I suppose AirBnB is a bit of a poster child for move fast and get sued later so that sort of fits.
I wish the consequences for failure were uniform across various organizations. Some companies will fire you for minor infractions. Others let failures grow because they are never addressed. Government is notorious for having negative incentives (failures are often rewarded).
One of my favorite movie quotes is from Ray's character (played by Dan Aykroyd) in Ghostbusters when they were fired from the university: "Personally, I liked the university. They gave us money and facilities, we didn't have to produce anything! You've never been out of college! You don't know what it's like out there! I've worked in the private sector. They expect results."
A culture of experimentation, which as a requirement leads to failures, does not need to celebrate failure. That's like cargo cult mentality, thinking that the failure itself is causally doing something good.
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.
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.
Anyway, the way I've seen it be embraced:
* healthy incident management culture with postmortems
* teams giving internal talks/writing blogs on biggest goof ups
* coworkers buying you shit if they break something. Mind: this wasn't required, just something people did it because they felt bad. I've received many beers/whiskeys this way
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.
I'd be interested in the cases when even a company that practices no-blame post-mortems has to fire the people who screw up multiple times.
They celebrated these - like, a real celebration. But first they made sure that it really fit the definition.
I don't. But I'm sure my bosses celebrate my failures since it makes their decision of who to give a bad rating to very easy.
Learning from failure makes complete sense, but not celebrating it.
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.
