Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Ask HN: Do you celebrate failures at work?
27 points by ReginaDeiPirati on Feb 8, 2023 | hide | past | favorite | 53 comments
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.



We 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 tongue-in-cheek slack channel for those folks who have caused a "p0", i.e. most-severe-breakage
I'd not want to work somewhere that didn't have the above; it's just part of being a mature organization.


#4 does more good than most realize. If you can’t joke around about it then you aren’t really comfortable with it. And we all must be comfortable with the potential to cause problems occasionally. You have to break a few eggs to make an omelet.


> post-mortems (hate that term, nobody died)

Post-incident review

https://support.atlassian.com/jira-service-management-cloud/...


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.


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.


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.)


Failure doesn't have to mean "people screw up" and one would hope there'd be something in place to avoid failing badly.

Failing early and often is a healthy approach to learning. That doesn't shame people or cause serious harm.


The only place I ever worked at that "celebrated failure" (their own words) was an overgrown startup with no customers that was unable to ship a single product.

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.


THIS. I have seen cultures that performatively celebrate failure:

* 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.


“Recently, I was asked if I was going to fire an employee who made a mistake that cost the company $600,000. No, I replied, I just spent $600,000 training him. Why would I want somebody to hire his experience?”

– Thomas John Watson Sr., IBM


The most popular ritual I've seen for celebrating failure is firing people. I can see a case for the company declaring bankruptcy being considered a ritual.

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.


It depends on the level of the failure. Some failures are minor problems that can be easily fixed with minimal impact on the business. Some failures are colossal and can drive the company out of business.

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."


What do you think that make companies firing people as a first choice, as opposed to accepting the associated risk as part of the learning process?


I worked somewhere that did it and it was completely performative.

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.


This is an interesting question. I always am telling my kids: "If everything you try works, you aren't trying hard enough." Because they tend towards doing the easy thing so it'll be a success, but most of life's interesting things happen at the intersection of failure. But, on the other hand, I don't really want to enable their doing of totally asinine things, the number of views on Jake Paul's videos not withstanding...


I've heard it said that in Japan management seeks to fix the problem when there's a failure rather than fixing the blame. I have no idea if that's true of the Japanese but I know it's true in America. And once the blame is fixed then the person blamed is ejected from the organization and that's considered a fix to the problem. So why would anyone volunteer to talk about failure when that is the status quo?


Any culture where a failure means somebody needs to be fired is a toxic culture where people will be unwilling to take any risks whatsoever. That's not normal and is a sign that the company's future isn't going to be very promising.


Ha I worked for a startup that said this was one of their guiding principles. What it really meant was we will pretend to understand and will save it for later when we need to lay people off. Was also big on radical candor but that really meant radical candor flowed from above but not so welcome when it went back the other direction.


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.


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.


I started a podcast about this. I'm sick of the rah-rah confident founder BS we see on here and all over the Internet. Sometimes we need to learn from our failures. Anyway, check it out. Keep Going: https://podcasts.apple.com/us/podcast/keep-going-a-podcast-a...


I'll say there are ways to embrace it, but celebrating it, just that phrase, I suspect will turn off the suits who might misinterpret it.

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


I'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.


In my experience, you can own your mistakes by buying breakfast for the team the next day. I agree that this is different from a failure. But deleting your own account, or the production database, sending a useless email to the whole company, etc ... can all be redeemed with a breakfast, as long as it means that you own your mistake in good faith, and that you will do your best not to repeat it. (Disclosure: I'm french, we have a thing for breakfast and pain -bread)


Culture in a lab I worked at was to bring donuts in when you messed up. I don't think this is "celebrating" failure, so much as a fun way to say sorry for messing up.


Usually passing the buck, playing the blame game, and most of all never changing anything and then being surprised, shocked, I mean, really shocked, that it keeps happening.


what do you think is driving this behaviour of reiterating on past mistakes?


Yep, sure do. When I got to my current job last year one of my early activities was brainstorming a set of team principles for my SRE team, and one of them is “We improve by taking risks, learning, and taking risks again.” The critical thing about failures is learning from them. So really you’re celebrating the learning, not the failures.


I assume occasional mistakes are treated differently than negligence, willfully going against policy, or multiple failures from the same person (i.e. a pattern of failure, perhaps just incompetence).

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.


Somebody (DEC, maybe?) had something they called a "perfect failure". They had a very precise definition. You had to try something, realize that it wasn't working, kill it quickly, and learn something from it.

They celebrated these - like, a real celebration. But first they made sure that it really fit the definition.


We 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.


Used to at Amazon, those guys had a great engineering onboarding that was nothing BUT failures and anecdotes about them. It was really memorable and humbling to see some great engineers share where they went wrong.


At my past job yes, at the current one it's swept under the rug. I even know someone that got fired for doing an error. (edit: and actually most teams seem to struggle with a lot of technical debt)


"Do you celebrate failures at work?"

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.


Why would anyone celebrate failure? Celebrating failure simply doesn’t make sense.

Learning from failure makes complete sense, but not celebrating it.


If you succeed at every project you work on, you're likely not taking on ambitious enough projects.


That’s fine and I agree. But, why ‘celebrate’ the things that fail? I don’t get it.


Traditionally I embrace failure by taking a few weeks for my own hobbies before I start looking for a new job after they fire me.


We promote them to middle management.


with a pie to the face!


to be really honest, never had a failure at work. not boasting, simply never happened.

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.


This is trolling, right?

Or maybe, you haven't ever worked in a real job?


I run a 20+ person tech company.

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"


Many companies try to signal that it's okay to try new things by celebrating them even when they aren't successful. I've been on teams like that. Nobody is happy about the failure itself, but the idea, effort, and commitment that was shown, even if it was not successful, is worth rewarding. You miss 100% of the shots you don't take, a ship in harbor is safe, etc. I think this is pretty much an inarguably healthy thing to do for a company that wants to keep morale up and encourage experimentation.


I'm sorry to hear that, it seems to me that failure has never been an option where you worked. How was it possible in your org to innovate if they don't embrace failures?


There's a huge difference between innovating and embracing failure.


The only way to innovate is to keep trying new things until one of them succeeds. Failure is inherent to innovation.


Innovation isn't valuable or necessary for most businesses. Optimization, refinement, and careful evaluation of legal consequences get you a lot farther.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: