Should I own up my own mistake in public?

Question

I am working as a software qualify assurance engineer and partially due to my work, a bug managed to get to our production code.

• Our customer service team has reported back this issue to us on Slack.

I am thinking if I should publicly own up this mistake and come up front to take responsibilities.

• Our company has a no-blame culture, which means no one blames anyone else. But I think I need to admit it is my fault that this bug has escaped to our customers.

If I should come up front, how far should I go?

Thanks

Answer 1

If you're working in an Agile shop, and you're part of a Scrum Team (or similar arrangement), the team has collective accountability for this kind of thing. You should certainly own up to the mistake with the team - That's how the team maintains individual accountability. However, as far as the rest of the business is concerned, the team owns the mistakes, because no one person is likely to have been the sole source of a problem. (You didn't write the buggy code, did you?)

Answer 2

You don't need to make a big thing of it, but admitting you should have caught it is no bad thing. The best way to respond to this (internally or otherwise) is to admit responsibility and show you've tried to ensure it won't happen again:

My bad on this one I'm afraid - slipped through our testing nets as the x testing script doesn't cover y which caused the bug. I'm in the process of updating that script now so this shouldn't slip through in future iterations, and I'm in conversation with Bob who may also be able to catch this ahead of time via a unit test.

That sort of a response isn't overly apologetic, but to the point and gives the impression that you "get stuff done".

Answer 3

Taking responsibility for your mistakes shows a level of maturity that is good to have, both personally and professionally. It is definitely a characteristic that stands out more with consistent use, so don't just do it today and expect consistent returns for years to come. Yes, own your mistakes. No blame means don't point fingers. It means human mistakes can and should be understood. Not that you aren't supposed to acknowledge that you personally goofed.

That is internally. Customer facing personnel should handle statements that go out to the public consumer. There is more to consider there. The face of the company, legal liability in admitting fault, etc...

Answer 4

Yes, please own your mistake. A no-blame culture doesn't mean you can't take responsibility for your own mistakes.

I work for a company which also has a "no-blame" culture. This implies that if something bad happens, the first thing we do is "mitigate the effects". Then we fix the cause. And afterwards, we write a document explaining what went wrong, how did we notice it went wrong, which steps were taken, and offer suggestions how to avoid that in the future. And we make this document available to everyone (we've an internal website to search those documents).

But while we don't blame (notice that all steps describe above are focused on "what happened" not on "who's responsible"), we still value owning up to mistakes. The person who made the mistake is going to be one of the more valuable people to fix it -- they're the one most familiar with the code. Owning but not blaming also helps in getting bugs fixed as soon as possible.

Of course, that doesn't imply you need to make a big show out of it. Just say "I made a mistake. I'm working on a fix right now".

Answer 5

Before you get too wound up about your mistake, please keep one thing in mind: The only people who never make mistakes are the people who never do any work. Good QA can reduce the number of defects which come to the attention of the customers, but even the best QA can not guarantee a 0% defect rate. That means a few defects slipping through is to be expected. This is a normal thing in the IT industry.

So before you come forward and apologize, consider if you actually did something which makes you responsible. Did you not use the budget and resources you were allocated? Did you not follow the agreed upon processes? Did you not test all the use-cases you explicitly committed to test? If none of these is the case, then you did the best you could and have no reason to blame yourself.

If you decide that you need to point out that you indeed deserve blame, do not focus on self punishment. Focus on what you are going to do different to prevent this mistake from happening again in the future.

Answer 6

No there is no mistake to own.

No disrespect but you seem pretty novice and naive. Bugs getting their ways in production are part of the life. I'm sure your product have a few out there (maybe less critical, again no disrespect. It's just the way it is). No need to need to own anything. Why would the dev be less likely to "own" the mistake? After all he wrote the code (I'm a dev myself).

I don't know maybe it's something super obvious and it have been caught before the release, in this case you and the dev(s) are as much at fault here.

I'm all in to own mistake when there was one but in a case of a bug getting it's way into production is not one of them. In any complex system it's practically impossible to cover all cases. Proving a negative is really hard, that's what you do when you test the product. The question is not "Does this product is 100% defect free?" it's more "Are we confident about the quality of the work done by the team (80-99% depending on the team, product, etc)