Iyfjky

Question

I have a hard time understanding how and why mistakes are attributed to someone specific in a company. For example, if I have the task to write report X, and another colleague has the task of correcting/proofreading report X - why would it be my fault if the other colleague makes a change that make it worse? (as reported in my other question)

I think there are other examples like this which keep happening to me, and I usually don't feel like it's my fault.

I can do everything possible to improve the situation, to go above and beyond to prevent it in the future, and make suggestions on how to change the whole thing and make it work, but... why should I see it as my fault in the first place? Wouldn't it be a bit self-condescending if I had to apologize for something wrong that did not originate from me?

You are ultimately responsible for the correctness of the report because you are the author. In other words, you have the ownership. The only way you relieve the responsibility is to give up the ownership. — Jan 31 '14 at 10:46

CMW 5,78912849 · Answer 1 · 2014-01-31 10:48:50Z

There are a few misconceptions here:

Mistakes are somebody's fault. Mistakes like accidents happen. Nobody is automatically at fault, just for making one. Making the same mistake over and over again or defending it as the right thing, that's when somebody starts being at fault.

Somebody has to apologize. Somebody has to take responsibility. That's the point. Apologizing won't get the company anywhere, even those that practice a blame culture.

The one the mistake originated from is responsible for it. Responsibility is taken. You see something is wrong; you go "Oh, that's wrong"; you take responsibility for it, ensuring it's fixed and won't likely be wrong again.

Why should you see it as your fault?

You shouldn't.

You should see it as wrong. As a mistake. Then take responsibility for it by saying, for example, "I'm sorry this mistake got out. I did not double check the result of the proof reading, but I will do so in the future". This way you don't apologize for the mistake that other person made but take on responsibility for not having double checked it (which probably isn't even your job, at the moment) and make it your duty to do so in the future (thus accepting the responsibility in advance, making it obvious you care about the fact that this shouldn't happen).

^{This is just one suggestion, maybe you find better ways of improving the situation.}

Another example:

I'm a senior developer with not management or team leading role at all. I'm working on a new feature, togehter with two junior developers and while I'm out to lunch they deploy a version which I haven't seen before and which introduces a bug to production. I get back and see the mess that clearly didn't originate from me and I can either let it play out and see who's being hurt (usually the company in general) or I can take responsibility for it, hurrying to roll back the deploy, make sure everything works and put measures in place that - if approved by the mananger - make sure this won't likely happen again, like a rule that all deployments have been done by teams of two where at least one has to be a senior dev or above.

You should.

In a way. "Your fault" doesn't have to mean "the fault that originated in you", but can mean "the fault that you found and took upon you to eradicate". That's how you should see it.

There's a fire. The firemen see it as their fire, not because they started it but because it's in the area they're protecting, so it's theirs to extinguish.

+1 for this alone, "Your fault" doesn't have to mean "the fault that originated in you", but can mean "the fault that you found and took upon you to eradicate". That's how you should see it. — Jan 31 '14 at 12:08
Ã·1 for taking responsibility to verify someone else's edits to your document. You're responsible for the doc, they're only an editor. You accept or reject changes to ensure meaning wasn't lost. If they are a gate rather than a guide, you work collaboratively with them to ensure the review is meets its pass criteria before it's released — Jan 31 '14 at 14:57
+1 for the fire fighter analogy. I wish I could give another +1 for the bad deploy story. — Jan 31 '14 at 17:50

maple_shaft 15.8k75296 · Answer 2 · 2014-01-31 12:43:55Z

Blaming is a useless and ultimately fruitless activity that does nothing to promote the team and the company beyond the problems and challenges that they face.

Don't Blame

Instead of feeding into the culture of finding fault in others and assigning blame, become a person that elevates themselves above such unseemly behaviors and be a person who is focused on solving the problem.

Take Responsibility

Regardless of who caused the problem, come up with a plan to fix it, and then execute. Even if you didn't cause the problem. Simply because you took responsibility doesn't mean you will be punished or blamed, and if you are then you have to ask your boss if he is more concerned with punishing people or getting the job done.

This is a position of strength and integrity. You protect your team, especially weaker members on your team who will start looking up to you. Bosses will trust you more.

Be Forward Thinking for Next Time

If it was an event or something that can't be fixed then come up with a plan or strategy to prevent it from happening again. Let people know that rather than subject yourself to being belittled or trying to protect yourself you are primarily focused with making sure that problems never happen in the first place.

Don't EVER be coerced into Apologies

When a superior is trying to solicit an apology from a subordinate then they are not concerned with the problem and how to fix it. They are concerned with punishing and bringing others down. Don't let your boss do this to you, even if you legitimately and objectively were the cause of the problem.

Hilmar 23.3k65772 · Answer 3 · 2014-01-31 12:58:44Z

Who cares who's fault it is ? The blame game is really unproductive and rarely anything good comes from it.

Here is a different approach to handling mistakes.

If you are never making a mistake, you are not doing it right.

Doing things better, different or innovative involves risk. Occasionally you will fall on your face. That's normal and to be expected. If that never happens you are just playing it overly safe and defensively. Mistakes are also one of best ways of learning. If you never make any you are probably not growing.

Communication is key

If you make a mistake, fess up immediately. Explain exactly what happened, what the immediate impact is, what the potential options are and a recommendation of what to do next. There is no need to beat yourself, it's all about "the car is in the ditch, how do we get it out of there". If you are about to take a calculated risk communicate upfront about this: "We are going to build another 100 units next week, there is risk that they will fail radiated emissions tests. However, if we don't, the schedule is guaranteed to slip by two weeks. If this goes wrong we have to toss 100 units and the schedule will still slip. Let me know if you want me to do anything differently".

Don't Blame

Even if your very first thought and reaction is "How the heck did that happen?", don't say it. It just makes people defensive and doesn't help at the moment. Again, the car is in the ditch and you need to get it out there as quickly as possible with as little damage as possible. Right away it's not so important how it got in there. Of course there needs to be a follow up but it should be later and in private when the immediate emergency has been resolved and tempers are cooler.

Don't make the same mistake twice

Mistakes are one of the best ways of learning new things. Typically the lessons sticks. Having an open and blame-free environment helps enormously with this. All mistakes are out in the open which means other people are a lot less likely to repeat them and can freely analyze them. For example you can easily approach a senior person and ask them: "Hey I screwed up on the release of project XYZ, what do you think I could do differently next time?"

"Mistakes are one of the best ways of learning new things." -- One of my favorite quotes is: Good judgement is the result of experience; however, experience is usually gained as a result of bad judgement. While "bad judgement" isn't necessarily the cause of a mistake, the aphorism shows that failure isn't necessarily a bad thing. — Jan 31 '14 at 16:20

score 1 · Answer 4 · 2014-01-31 11:56:46Z

You're each responsible for your own actions. But if you are the report author then I'd suggest that you're responsible overall for the correctness of the report (note the lack of blame for any mistakes in that statement).

If you were supposed to write an accurate report but didn't then you own the errors that led to that. If someone else is supposed to proof-read reports to catch mistakes then they own the errors in the proof reading process. Both you and the proof reader should spend less time worrying about who gets the blame and more time thinking about how to do your own job better next time.

I'm getting the impression that you either work for a company that practices a blame culture, or at least you feel as if you do. In any case, it's more sensible to concentrate on what went wrong and how to fix it than it is to obsess over who, precisely, was at fault.

In the meantime, if someone asks you about the error, all you have to do is share with them the draft you presumably have of your original report that doesn't contain the error.

CMW 5,78912849 · Answer 5 · 2014-01-31 10:48:50Z

There are a few misconceptions here:

Mistakes are somebody's fault. Mistakes like accidents happen. Nobody is automatically at fault, just for making one. Making the same mistake over and over again or defending it as the right thing, that's when somebody starts being at fault.

Somebody has to apologize. Somebody has to take responsibility. That's the point. Apologizing won't get the company anywhere, even those that practice a blame culture.

The one the mistake originated from is responsible for it. Responsibility is taken. You see something is wrong; you go "Oh, that's wrong"; you take responsibility for it, ensuring it's fixed and won't likely be wrong again.

Why should you see it as your fault?

You shouldn't.

You should see it as wrong. As a mistake. Then take responsibility for it by saying, for example, "I'm sorry this mistake got out. I did not double check the result of the proof reading, but I will do so in the future". This way you don't apologize for the mistake that other person made but take on responsibility for not having double checked it (which probably isn't even your job, at the moment) and make it your duty to do so in the future (thus accepting the responsibility in advance, making it obvious you care about the fact that this shouldn't happen).

^{This is just one suggestion, maybe you find better ways of improving the situation.}

Another example:

I'm a senior developer with not management or team leading role at all. I'm working on a new feature, togehter with two junior developers and while I'm out to lunch they deploy a version which I haven't seen before and which introduces a bug to production. I get back and see the mess that clearly didn't originate from me and I can either let it play out and see who's being hurt (usually the company in general) or I can take responsibility for it, hurrying to roll back the deploy, make sure everything works and put measures in place that - if approved by the mananger - make sure this won't likely happen again, like a rule that all deployments have been done by teams of two where at least one has to be a senior dev or above.

You should.

In a way. "Your fault" doesn't have to mean "the fault that originated in you", but can mean "the fault that you found and took upon you to eradicate". That's how you should see it.

There's a fire. The firemen see it as their fire, not because they started it but because it's in the area they're protecting, so it's theirs to extinguish.

+1 for this alone, "Your fault" doesn't have to mean "the fault that originated in you", but can mean "the fault that you found and took upon you to eradicate". That's how you should see it. — Jan 31 '14 at 12:08
Ã·1 for taking responsibility to verify someone else's edits to your document. You're responsible for the doc, they're only an editor. You accept or reject changes to ensure meaning wasn't lost. If they are a gate rather than a guide, you work collaboratively with them to ensure the review is meets its pass criteria before it's released — Jan 31 '14 at 14:57
+1 for the fire fighter analogy. I wish I could give another +1 for the bad deploy story. — Jan 31 '14 at 17:50

maple_shaft 15.8k75296 · Answer 6 · 2014-01-31 12:43:55Z

Blaming is a useless and ultimately fruitless activity that does nothing to promote the team and the company beyond the problems and challenges that they face.

Don't Blame

Instead of feeding into the culture of finding fault in others and assigning blame, become a person that elevates themselves above such unseemly behaviors and be a person who is focused on solving the problem.

Take Responsibility

Regardless of who caused the problem, come up with a plan to fix it, and then execute. Even if you didn't cause the problem. Simply because you took responsibility doesn't mean you will be punished or blamed, and if you are then you have to ask your boss if he is more concerned with punishing people or getting the job done.

This is a position of strength and integrity. You protect your team, especially weaker members on your team who will start looking up to you. Bosses will trust you more.

Be Forward Thinking for Next Time

If it was an event or something that can't be fixed then come up with a plan or strategy to prevent it from happening again. Let people know that rather than subject yourself to being belittled or trying to protect yourself you are primarily focused with making sure that problems never happen in the first place.

Don't EVER be coerced into Apologies

When a superior is trying to solicit an apology from a subordinate then they are not concerned with the problem and how to fix it. They are concerned with punishing and bringing others down. Don't let your boss do this to you, even if you legitimately and objectively were the cause of the problem.

Hilmar 23.3k65772 · Answer 7 · 2014-01-31 12:58:44Z

Who cares who's fault it is ? The blame game is really unproductive and rarely anything good comes from it.

Here is a different approach to handling mistakes.

If you are never making a mistake, you are not doing it right.

Doing things better, different or innovative involves risk. Occasionally you will fall on your face. That's normal and to be expected. If that never happens you are just playing it overly safe and defensively. Mistakes are also one of best ways of learning. If you never make any you are probably not growing.

Communication is key

If you make a mistake, fess up immediately. Explain exactly what happened, what the immediate impact is, what the potential options are and a recommendation of what to do next. There is no need to beat yourself, it's all about "the car is in the ditch, how do we get it out of there". If you are about to take a calculated risk communicate upfront about this: "We are going to build another 100 units next week, there is risk that they will fail radiated emissions tests. However, if we don't, the schedule is guaranteed to slip by two weeks. If this goes wrong we have to toss 100 units and the schedule will still slip. Let me know if you want me to do anything differently".

Don't Blame

Even if your very first thought and reaction is "How the heck did that happen?", don't say it. It just makes people defensive and doesn't help at the moment. Again, the car is in the ditch and you need to get it out there as quickly as possible with as little damage as possible. Right away it's not so important how it got in there. Of course there needs to be a follow up but it should be later and in private when the immediate emergency has been resolved and tempers are cooler.

Don't make the same mistake twice

Mistakes are one of the best ways of learning new things. Typically the lessons sticks. Having an open and blame-free environment helps enormously with this. All mistakes are out in the open which means other people are a lot less likely to repeat them and can freely analyze them. For example you can easily approach a senior person and ask them: "Hey I screwed up on the release of project XYZ, what do you think I could do differently next time?"

"Mistakes are one of the best ways of learning new things." -- One of my favorite quotes is: Good judgement is the result of experience; however, experience is usually gained as a result of bad judgement. While "bad judgement" isn't necessarily the cause of a mistake, the aphorism shows that failure isn't necessarily a bad thing. — Jan 31 '14 at 16:20

score 1 · Answer 8 · 2014-01-31 11:56:46Z

You're each responsible for your own actions. But if you are the report author then I'd suggest that you're responsible overall for the correctness of the report (note the lack of blame for any mistakes in that statement).

If you were supposed to write an accurate report but didn't then you own the errors that led to that. If someone else is supposed to proof-read reports to catch mistakes then they own the errors in the proof reading process. Both you and the proof reader should spend less time worrying about who gets the blame and more time thinking about how to do your own job better next time.

I'm getting the impression that you either work for a company that practices a blame culture, or at least you feel as if you do. In any case, it's more sensible to concentrate on what went wrong and how to fix it than it is to obsess over who, precisely, was at fault.

In the meantime, if someone asks you about the error, all you have to do is share with them the draft you presumably have of your original report that doesn't contain the error.

Category

Random preview

Are mistakes the fault of who is responsible for a task, or of who made/contributed to the actual mistake?

4 Answers 4

There are a few misconceptions here:

Why should you see it as your fault?

You shouldn't.

You should.

Don't Blame

Take Responsibility

Be Forward Thinking for Next Time

Don't EVER be coerced into Apologies

If you are never making a mistake, you are not doing it right.

Communication is key

Don't Blame

Don't make the same mistake twice

Your Answer

Sign up or log in

Post as a guest

Post as a guest

4 Answers 4

4 Answers 4

There are a few misconceptions here:

Why should you see it as your fault?

You shouldn't.

You should.

There are a few misconceptions here:

Why should you see it as your fault?

You shouldn't.

You should.

There are a few misconceptions here:

Why should you see it as your fault?

You shouldn't.

You should.

There are a few misconceptions here:

Why should you see it as your fault?

You shouldn't.

You should.

Don't Blame

Take Responsibility

Be Forward Thinking for Next Time

Don't EVER be coerced into Apologies

Don't Blame

Take Responsibility

Be Forward Thinking for Next Time

Don't EVER be coerced into Apologies

Don't Blame

Take Responsibility

Be Forward Thinking for Next Time

Don't EVER be coerced into Apologies

Don't Blame

Take Responsibility

Be Forward Thinking for Next Time

Don't EVER be coerced into Apologies

If you are never making a mistake, you are not doing it right.

Communication is key

Don't Blame

Don't make the same mistake twice

If you are never making a mistake, you are not doing it right.

Communication is key

Don't Blame

Don't make the same mistake twice

If you are never making a mistake, you are not doing it right.

Communication is key

Don't Blame

Don't make the same mistake twice

If you are never making a mistake, you are not doing it right.

Communication is key

Don't Blame

Don't make the same mistake twice

Sign up or log in

Post as a guest

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Comments

4 Answers
4

4 Answers
4

4 Answers
4