Does team leader have to take blame for subordinate errors?

Question

In a software company, does the team leader have to take responsibility for every error the subordinates do?

The client sent an angry email because some parts of the code were incomplete and not all logs were set into place. The error was done by one of my subordinates and he's the type of person that writes code in a hurry just to finish fast and "forgets" about writing good tested code.

The issue is that in my company I have to do very many things that aren't always related to team-leading abilities. For example I have to do some financial estimates on each month and other similar activities that many times take a day or two to solve. And the client shouts why don't things go in the time he scheduled.

The company has also a very bureaucratic system and I also have to fill-in very many wikis, etc. that also take lots and lots of time.

In the end, the client sends new specifications every day and many modifications of old specifications and he expects to finish all fast like the only thing I'm doing is his project. But I guess even if I'd be doing only his project I'd need more time because I tend to work from home many times just to finish in time and he's still unsatisfied.

Could you give me a hint on where the issue is or what could I do to improve this situation?

Edited: Thank you all for your very detailed responses and for the links to resources that will help me improve the skills.

I'll take your advice on talking with my employees to find a way to improve the code or if that doesn't lead to any result, talking to my superiors about the situation.

Answer 1

Answering the title question: You just cannot blame an employee to a customer

You take the blame and then, internally, take appropriate actions if necessary.

About what and how to improve, i think you need time management skills. You might be interested in trying "The Pomodoro Technique"

Answer 2

It sounds like there's a number of problems and whilst I don't think as team leader you should be solely responsible, your team should be accountable as a whole for any bugs that make it through to production.

You should probably look at introducing code reviews to help check the code before it goes into any environment.

I also think that you need to improve your testing processes as well as provide an earlier opportunity for the client to get a hands on "beta" of the product before it is released because in reality, there are always going to be bugs and you need a process to help reduce those bugs rather than trying to blame a single person for any particular bug.

Answer 3

Well to the outside world the leader is the interface for the team. So externally, I guess you have to handle the blame (handling the blame is a little different from taking the blame:) ). As of internally you have to take over a Root Cause Analysis.

Its very important that you don't use the word "blame".

In a professional world, every mistake should be considered as a shortcoming and after the root cause analysis, you find that how to overcome the shortcoming and how to avoid it in future. A good leader should have the skill to manage both the external and internal world exclusively. Your subordinates need not know the pressure and problems from the outside world as they may under-perform under the pressure. Internally you have to handle it as an internal problem.

For example my CEO is not interested in knowing that my subordinate X forgot to put a null check which caused the NPE. He/she only needs to know that we missed some testing scenarios and so improving on UT is now our priority task. Internally you make Mr./Mrs. X practice check style, find bugs, and do more UT etc...

Again never get used to the blame game. It's easy to get to dependent on it.

Always regard it as a problem and find out what you could do to avoid that type of problems in the future. This way the external powers will adorn your leadership qualities and your subordinates will learn to respect you when they realize from somewhere else (if they ever do) how maturely you protected them from the outside pressure.

There's a difference between a manager and a leader.

Learn to be a leader, not a manager.

Well as for the technicality issues (QA, bureaucracy, blah blah), trust me, it won't matter if you understand the core philosophy in the above.

Answer 4

Vinko is right. You can't tell a client it was the fault of an employee. The team failed, and if you're in charge of that team, you need to figure something out.

One option: fire the lazy programmer and hire someone better.

A better option: Make QA testing someone's primary job responsibility.

Many people believe that programmers should never test their own code. They're inherently biased.

Right now, QA seems to be your job by default. But you've already got a huge pile of responsibilities. So you either need to offload some work and become a QA person, or hire someone who knows the job.

Lots of successful projects employ more QA testers than they do programmers. Many would argue that QA testing is a lot harder than programming.

Answer 5

Unfortunately, if you're the contact point with the customer then you're going to seem responsible for your subordinates' mistakes in your customer's eyes.

You'd need better internal tracking of your subordinates' performance. I can suggest regular code reviews if you're not doing that already, and maybe you should review whether your issue tracking system is actually being used properly.

Another unfortunate issue is that your client updates the specs regularly. At our company the specs were set up before hand and all effort is invested in meeting those requirements. If the customer changes requirements along the way there is a formal process, and the customer is aware that this may affect the schedule or the cost.

Answer 6

Answer this question for yourself: Did you know about the issue before it happens? What did you do about it?

If you knew and just let it happen (for whatever reason), who is responsible? The developer (who isn't in the position to make decisions) or you (a manager, who, by definition, makes decisions)?

In my own project, I take all the blame and the team gets all the praise. My reasoning is that I make the important decisions, so it's my fault when something goes wrong. I either didn't care to ask enough questions or I knew that something would probably happen but didn't act. Often, there is nothing I can do, but again, I decided that there is nothing I could do (really, this is just a different way to say "it's too much effort to change").

In any case, I made a decision and if it only was "I don't care" which means I can't blame anyone else. If you're swamped, then why is that? Because everyone heaps work on you? How can they do that without your consent? Are they saying "Yes" when they give you work?

If something goes well, then it's always because of the effort of everyone. So how could I claim the praise for myself?

Answer 7

I don't want to prescribe Scrum as the solution to your woes, but we've been using it for close to a year now, and while we've had numerous issues we're getting to the point where problems similar to what you describe happen far less frequently. I would minimally read the Agile Manifesto and a book on Scrum and consider implementing it.

We as the team all meet the customer (product owner). We together bash out the requirements (user stories critically with acceptance criteria). As a team we commit to a number of stories and as a team we've decided to write tests and test plans first, code review each other's work, pair up to write tests and code (though not always) and crucially demonstrate each story to the product owner. We have retrospectives to discuss what went well and what didn't (like how bugs got missed) and we collectively try and come up with process improvements.

Try getting the customer to meet the team and sell them on why it's important to get their buy-in.

Answer 8

Sometimes saying no and then proving yourself is worth than everyday accepting and pissing yourself.

Try to analyze the specs which client sends and then try to communicate client (in the language he/she understands which depends on the client knowledge) the fallback of the task if done in the ongoing manner, this should emphasize more on the product's stability and not on your company internal status like more task to lesser resources etc.

Analyze the client is technical guy or a business guy, accordingly you need to handle the client to buy appropriate time for the work provided.

Once he/she gains faith on your capabilities, you can buy some more time to improve your already deteriorated modules.

Answer 9

In my point of view, it is team lead responsible to see the code or anything that involve in the project. Team Lead has to take what subordinates doing and their work.

Answer 10

To your managers, no, don't blame your subordinates.

Your subordinates are your team, you are responsible for them (even if you don't directly manage them!). Blaming them makes you look incompetent, your manager doesn't care who messed it up, he just cares that it was your responsibility and it went wrong.

To your customers, no, don't blame your subordinates.

Your customer really doesn't care what went wrong, or how, or who. He just wants his product/service to work perfectly, all the time. It's not even about blame in this case, just apologise to the customer and do your best to improve the situation or ensure it doesn't happen again.

What to do then?

If you think one of them messed up, then talk to them about it person to person separately and in a positive must do better way. If you think they are a liability, do everything you can to get them off your project in future.

Answer 11

Imagine for a second being Microsoft CEO, with over 50 000 people working for you and something going awfully wrong every day making someone incredibly unhappy. If things never went wrong, there never were any incidents to deal with, no dissatisfied customers with urgent issues, and the team never ever failed, then you wouldn’t really have learnt much as a team lead, would you?

And can you see yourself in Microsoft CEO shoes whilst shifting the blame “That’s due to Steve’s not doing his job properly!” during one of these important business meetings?

Team lead represents both the team and the company. Apportioning blame to someone else might seem as an intuitive and easy way of making the unpleasant incident go away, become someone else’s problem. Works really well for anyone responsible just for themselves with modest expectations placed by others. Small kids, for instance.

Shifting the blame to subordinate won’t work for a team lead:

1. Since he or she represents the team and the company, the problem won’t go away as long it remains even remotely linked with the company in the customer’s mind.

2. Team lead is expected to deal with the difficult situations. This is what having “more responsibility” which is often associated with a better pay and higher position exactly looks like in the real life.

3. Concentrating on the blame raises expectations of penalty. No one wants to be accused or penalised and would naturally attempt re-attribute the blame. And be assured there is good chance of the accusations to boomerang having caused an irreparable damage on the way.

Often blame is irrelevant to the problem resolution.

Some tips on approaching the “unhappy customer” scenario:

• Keep customer informed of any change in production environment and potential impact in advance. Prepare a contingency plan.

• When a customer calls after the change took place it’s much more likely that they seek help with an issue, rather than intend to praise your efforts.

• Ease the tension by acknowledging the complaint, but not the source or cause of the problem then ask for time to investigate and let them know when you plan to get back with the results.

• Focus the conversation on the way forward and interim remedy where possible.

• Don’t be disillusioned, in the world of business customers are more likely to seek quick resolution and concessions rather than just aimlessly take their personal frustrations out on you. It’s not like a personal fight. They might throw a little tantrum first but if you keep your cool, show empathy, stay rational they’ll fairly soon move on to the actual need. Just make sure you understand the impact of the problem on them and steer the conversation to the ways the issue can be resolved (if it’s not already apparent).

• Be first to tell the customer about any known issues that are going to have a negative affect on them.

• Be first to tell your management about any problems to secure their support.

• Conduct a fair investigation with the primary aims of providing an interim and long term solution and also fixing the process that led to the incident. As a team lead you’re responsible for the process and the chances are this is the process and not the team members to blame.

• Change the process as appropriate.

• Inform the customer and management about your findings and any changes but keep the communication relevant to the relationship involved.

• It’s only when a team member has violated an existing process, see if the process is reasonable, and discuss the incident with the team member casually in private without attributing the blame for what has happened. It’s likely there is a good reason, i.e. lack of resource, time, poor estimates, emergency or miscommunication.

• Collect information first before making any decisions.

And one last thing, there is a surprising evidence that customers who had something go wrong and then dealt with swiftly and appropriately by a company become more loyal and more likely to recommend the company to the others than customers who had never made a complaint.

Answer 12

First point: The customer doesn't care if the code doesn't work because you have a bad employee. Heck, the customer doesn't care if the code doesn't work because you ran out of unicorns to barbeque. The customer made a deal with your company, and your company didn't come through. That's the only thing the customer cares about. If you have a bad employee or insufficient unicorns, dealing with the employee or finding more unicorns is your problem, not theirs.

Second point: You can't give the customer everything the customer wants, which is at least perfection for free. Given that, the customer wants to know the deliverables, the cost, and the schedule, and wants to be able to count on them. The worst thing you can do for a long-term relationship is promise a whole lot and fail to deliver. You need to be able to deliver on your promises, so you need to get into a positioning of promising no more than you know you can deliver. While the customer may argue about this at first, it's better for everybody in the end. If the customer is unsatisfied because you're doing a bad job, that's one thing, but it's much more likely that the customer is unsatisfied because you've promised more than you can deliver. Negotiate reasonable expectations and you can stop working from home.

Third point: The customer will try to get as much as possible, and will probably have a skilled negotiator out to get the best deal. If you're a team lead, you're probably a techie, and therefore you're probably not a good negotiator. This means that, unless you watch things carefully, your customer will have you promising all sorts of things that you can't deliver. Negotiation is a learnable skill, but like anything else talent is involved, and you can't afford to study negotiation on anything like a full-time basis.

The correct response is to make rules for yourself while talking to the client. Remind the client that changed specs have costs, and refuse to commit yourself to a cost without a quick evaluation. Remember that changing even something small can have costs: it will take me perhaps an hour total to make an obvious single-line change in the codebase here, due to the procedure involved. Also, make a good estimate of how much time you've got for that customer. The customer will want you to be working 24/7 on his project only, of course, and you have to tell him that just isn't going to happen.

Bear in mind that the customer is used to walking all over you in negotiations, so you're going to have to make it clear that you're changing how deals are made, and you'll have to be especially firm for a while. It may be hard on you, but not doing this will be much harder on you.

Fourth point: You're in a role that's part management now, so one of your jobs is getting the most out of your employees. This includes handling problem employees. If you're ever thinking of getting into more management roles (and that is often where the money is), you're going to need to get better at this. You probably have some disciplinary authority, if only in an annual review, so let your employee know that you can and will use that if necessary. Other people have suggested code reviews, which is a great idea, since that way your other team members will be leaning on him to shape up, since his screwups will make more work for them. You may or may not be able to get the slacker off your team, and you can at least make the request. What you have to be able to do is get a good product out on time, without relying on every employee to be competent and enthusiastic.

Fifth point: You have other duties which take up much of your time. Take a look at them and see if you can delegate any of them and still have them done well. It's very common for technical people turned manager to try to do everything themselves, since it's usually easier to do one particular task than to get a subordinate to do it right the first time. Given twenty-five tasks like that, you're overwhelmed, so you need to pass off whatever you can. Learn how to delegate, and who can be relied on to do what. One good book (recommended to me by my father-in-law) is Managing Management Time.

Finally, you're obviously in over your head here. You'll have to learn to deal with this situation. Remember that you're responsible for what your team accomplishes, and neither your superiors nor customers are really interested in the internal details. Remember that you need to do what the customer needs, not flail haplessly trying to do what the customer says he wants, and remember that you need to substitute confidence in your estimates for negotiating ability. And learn about management.

Answer 13

As someone once said to me,

Hire people that are good at their jobs, and let them do it.

If your developer isn't doing his job - which is the case if he's having a negative impact on revenue or product quality, which typically go hand-in-hand - he needs to shape up or, unfortunately, find another position. Remember that the goal of your group is to produce reliable products with given resources. Quick-and-dirty code often creates additional delays long-term that cancel out any gains from saved time up front.

I don't suggest firing on a whim, or because of a single mistake; we've all made them and will again in the future, and its always a crap shoot when hiring someone new. Still, we're there to do a job, and do it right, not to socialize.

As others have said, customers don't care about your internal difficulties, and your superiors probably don't, either. You need to manage their expectations by providing realistic estimates, even if those estimates aren't what your client (internal or external) wants to hear.

As a team lead/manager, it's your job to keep your team working smoothly. If you can't do that, some changes need to be made. That can be in the form of education, discipline or replacing some members of the staff. Either way, you're ultimately responsible for the outcome.

Answer 14

The error was done by one of my subordinates and he's the type of person that writes code in a hurry just to finish fast and "forgets" about writing good tested code. [...] Could you give me a hint on where the issue is or what could I do to improve this situation?

If this guy reports to you, then you can and should address this problem. Disciplinary action is not out of the question. If you haven't done so already, start documenting this guy's activities and the ways in which he screws up. You'll need it when you ask HR to terminate his position.