Should I take the blame for an error by someone on the team I lead?

Question

I am a software team lead. One of my guys built an update for android, but left the environment on "staging" and now everybody is freaking out: the marketing guys, PM, product owner.

So far I have taken the "blame", and it is my fault really for not checking before uploading... The app had to be unpublished, and the new fixed version appears that it will take some days for review...

Shall I mention that my colleague built the app in the wrong environment?

Or just take the blame and hopefully expect for the best (and of course check from now on)?

Answer 1

You are the team lead and so you are the shield protecting your developers from above. Pointing fingers might be good for you in the short term, but it will hurt team morale in the long term and come around to bite you. Blame culture is toxic and good programmers rarely stay around in one.

While the reason it happened might have been one specific developer, your whole team (and you) are at fault for letting it get that far. Your process for deployment is obviously lacking, which is specifically your job to fix.

My response to the complaints from above would be to promise to implement measures to prevent it from ever happening again while accepting blame for it having happened. Subsequently, I would implement code reviews, rework the deployment process and add automated testing that checks a build for correct flags before it gets pushed.

Afterwards, if you go that route, you can present those measures to those above, which can remove the black mark you have on your record. After all, mistakes happen, but you can show that you did something about it.

Answer 2

You are responsible for the actions of your team, and they are responsible to you.

I have seen this in dealing with clients where I had made a potentially costly mistake with their job. When meeting with the client, my director completely had my back and took ownership of what had been done (as well as arguing why it wasn't such a big problem and that part of the error was on the client's side). However, away from that meeting, he made it very clear to me what I had done wrong and what needed to change.

Your situation is slightly different in that it seems the blame is internal, not external, but the same principle holds - you are the team lead therefore you are responsible to those above. If you say "so-and-so messed it up", you are just acknowledging your failure in managing your team.

That is why management positions come with higher pay - because they are taking greater responsibility.

Answer 3

"Blame" is the wrong word to use here. I think you should use the word "responsibility".

"Blame" implies finger-pointing, etc. It fairly screams scream-and-shout. All in all, it's an unprofessional term to use, and it's an unprofessional thing to do. I encourage you to be professional* about this.

"Responsibility" is a more professional term. And since you're the team lead, you must take responsibility for this. Sure, someone on your team screwed up. When one person messes up, the whole team has messed up, and as the leader you take the hit. Don't worry, it's temporary - and hopefully it motivates you to improve your team's processes-and-procedures so that it doesn't happen again.

---

*What do I mean by "professional"?

First, you cannot "blame" anyone - on your team, on another team, or elsewhere in the company - no matter what happened. Even if everyone knows that Bob did it, you don't get up in a meeting and say "BOB DID IT!". When things go badly you have to go all in on calm-reasoned-and-professionally-impersonal - especially when things go badly! You need to say, "We had an incident". You have to say "We need to improve our process so that X, Y, and/or Z cannot happen again. The reputation of this team within the company is too good to allow it to be tarnished by minor oversights. How can we improve this?". When someone says "Well, we can fire Bob!" and the meeting threatens to blow up into a blaming match, you have to be the one who steps in and says something like, "This is not about personalities. Nobody on this team is perfect - and no matter how 'careful' we try to be, unless our process prevents us from doing X/Y/Z then it will happen again. Now, how can we rearchitect our process to ensure that things go smoothly in the future?". You have to be the one to redirect away from making Bob (name chosen because it's mine/not all Bobs are like me/features and options will affect final purchase price/see dealer for full details) the scapegoat and put the focus on process. Processes are repeatable (if designed properly) - people are not. You have to be the one to ask the team how to fix things - even if you think you already know How To Do It you need to ask the team - because, y'know, they might have some really great/fantastic/better ideas.

Answer 4

So far I have taken the "blame", and it is my fault really for not checking before uploading... The app had to be unpublished, and the new fixed version appears that it will take some days for review...

But is it really though? If a team makes a costly mistake, why does your company let a single team make costly makes? Where is the safeguards? Where is the automated tests? In reality things are more complex and there isn't a single person who is at fault and there is very little value in pointing fingers.

But a broken app has been published and that has had a negative impact on the business so it is worth to make sure that it doesn't happen again. Instead assigning blame to a person, you should look at the process that let to this. And you might find things like this (not exactly, since I am making this up):

• A single team member made a manual build of an app?
• The team lead did not check the build version, but there was not detailed guideline in how to do it
• Someone tested the app but didn't have clear instructions what to test
• There was no automatic build server
• There were no guidelines to do smoke tests
• No higher managers were involved in the release decision
• No experienced testers were around because it was Friday past 6

If you look at all the facts, you will probably notice that more than one thing let to this issue and instead of pointing fingers you should focus on fixing the process so that it doesn't happen again.

Answer 5

Shall I mention that my colleague built the app in the wrong environment?

No. There's no need for anyone to know the name of the specific person who made the mistake.

The team carries the fault. And as the leader, you are the public face of the team.

Or just take the blame and hopefully expect for the best (and of course check from now on)?

Mistakes happen. Blame is not the issue here.

As the leader, you need to speak with the individual and make sure they know what they did wrong, and the impact it has on other teams.

Then, you need to review your processes and determine how you can make sure this mistake never happens again.

Answer 6

There is blame, and there is responsibility.

It is your team, and you are responsible. The buck stops with you.

That said, the BLAME goes to the one who made the mistake, but you're not going to blame him or throw him under the bus.

The professional way to approach this is to accept responsibility for your team, nothing about the workings of your team gets discussed outside your team.

You take the hits with the higher-ups, and say simply:

We found the cause of the problem, and have corrected it, on behalf of my team, I apologize.

And leave it at that.

Your team member made a mistake, have a long talk with him and explain what happened, and ask him how he will ensure that it does not happen again, and leave it be unless it happens again.

If there was no economic impact, and the other groups continue to harp on you, simple repeat:

The problem was caught in time, and corrected. Thank you for your concern.

The most important thing in a team is trust. As a team leader, if you threw one of your people to the wolves, not only would you lose HIS trust, but the trust on everyone in the team, as they'd know you wouldn't protect them.

Also, if I were in the position of any of the stake holders, I would lose respect for you as well. It looks very bad when a team leader blames one of his team for anything, and I'd assume you were weak or incompetent, or both.

Standing up, and taking RESPONSIBILITY for your actions, and the actions of your team is what a leader does. Assigning blame is not.

Answer 7

If you've read Phoenix Project or Unicorn Project, you would know: in a good environment, no one gets "the blame". Environments with finger-pointing and shaming are not good environments.

It's not about "Who did this?!" It's about "What happened? Why did it happen? What can we do to prevent it from happening in the future?"

If you or someone on your team "gets the blame" or "is responsible" for what happened, you will all be more likely to hide your mistakes, rather than let each other know what happened.

When talking to those outside of the team, instead of "One of my team members caused X to happen. I talked to the person who did it and told them not to do that again." Instead, a more helpful approach is more like "X happened. We put policies in place to prevent X from happening again." If you still feel the need to phrase it as "So-and-so did X", instead of saying "I let this happen" or "My team member accidentally did this", maybe try "We accidentally did this". The problem lies in the process, not necessarily on an individual.

As for "blame" vs "responsibility/accountability", it is smearing some syntactic sugar on that wound. But as Mary Poppins said "A spoonful of sugar helps the medicine go down". It's slightly easier to swallow, and less finger-pointy. But it can still lead to the same exact issues.

However, if there are not serious negative consequences for the specific person who you're blaming, then I wouldn't worry about it. But don't throw any team-member under the bus for a single incident. If they get hurt because you said stuff, then you'll be less likely to find out when these things happen, and how they happen, and how to fix them.

---

Btw, for your specific case, you should look into automated pipelines which build the app for you in set environments. That's what we do for our applications. We have a pipeline that runs when we push to dev, which tests and deploys the dev version of the code, a pipeline that builds and deploys the staging version, and a pipeline that builds and deploys the production version. All three have to run by the same set of automated tests. Or if you can't do automated pipelines, then at the very least, the other environments should build to a file with 'staging' in the name.

Answer 8

Your job is to shield the team, so you take the heat, but not the blame.

Explain to management that one of your developers made a mistake and that your team, including you, failed to find it and your procedures were insufficient to prevent it.

Explain what you are going to do to ensure such a mistake cannot happen a second time.

Case closed.

Under no circumstances reveal the name of the developer who made the mistake to management. If they press, switch from "someone on my team made a mistake" to "my team made a mistake".

Answer 9

This is a quality problem. Quality problems are never individuals persons fault, but a fault of the team. If a single misclick in a GUI can result in a bad situation with direct consequences then the right solution is not to blame the person making the mistake, but put it in a checklist and establish a review principle for the critical step, where a second person reviews according to the checklist.

The answer to such problems is therefore for the lead: I am sorry that this slipped trough our procedures right now, we will include the problem in our future reviews.

Answer 10

Being a leader you are responsible for every error that you and your team makes and you help the team in every possible way, you can pass the blame if you are Boss. It all depends on your thought process.