How can I deal with the blame-game played by my colleague in office?

Question

My colleague (call him Bob) and I are Software Developers with experience of 1 year. Our CTO considers me to be more intelligent than him. For the last few months both of us have been working on the same technology.

Now, whenever Bob faces an issue, our CTO suggests consulting with me. 80 to 90 percent of the time, I am able to fix his issue and I inform the CTO that I have provided Bob with the solution.

Now, it has happened over 10 times that Bob implemented the solution provided by me incorrectly and he immediately goes to our CTO telling him that the solution provided by me is either incorrect or not working.

Listening to him, the CTO always gets angry over me and gives me a solid rebuke each time. Incidents like these have created a very bad impression of me in his mind that I don't do my work correctly the first time and only do the correct work after 5-6 repetitions and improvements.

Now out of compassion for Bob, I have never told our CTO that he frequently implements my solution incorrectly. If I tell him about Bob's inefficiency then Bob might get fired.

That's why I always remain silent when Bob commits some mistakes while implementing my solution. But the level of my patience has reached its limits now and I think it is the time to find a solution which could teach Bob a lesson.

Although I have talked to Bob regarding the same in the past and he said he understands, he keeps making same mistakes over and over again.

Now, I don't want to take revenge on Bob but I want a solution in which I can just stay away from this blame game played by Bob which results in CTO doing nothing to him but affects my reputation a lot.

Can anyone suggest what would be a good strategy to deal with this situation?

Answer 1

I think @Neo provided a solid answer with respect to documenting and focusing on the facts, but I also think you can take this a step further. Simply documenting/pointing out that Bob's implementations don't work may help you protect yourself, but it doesn't solve the ultimate problem (Bob's code is broken).

Basically, you have an opportunity to support Bob and turn this into a learning experience for both of you.

Your boss has directed you to help Bob when he asks you for help. Ultimately, this means that helping Bob is part of your job. You are giving Bob solutions and his implementations of them don't work. To a certain degree, you have some responsibility to help him succeed. There's a few things you can do to remedy the situation:

1. Before you give Bob a solution, make sure you understand the true problem. Often, less-talented programmers focus on a symptom and not the root issue. If he's giving you a symptom to solve, make sure the two of you agree on the root cause before there's any discussion of a solution.
2. Once you have a solution in mind, be sure you're giving it to him in a way that helps him succeed with it. If he's less skilled than you, you may take things for granted that he doesn't know about - how to build or deploy the solution, how to configure or test it, etc. Make sure your instructions are explicit and complete. This will set him up for success instead of needing to fail over and over before he stumbles upon the actual fix.
3. After he has tried your idea, actively help him test it before he has a chance to complain about it being wrong. This will give you an opportunity to "catch" any issues before he can tell the CTO that your solution is garbage. This step may include a code review or other implementation review, but should definitely at a minimum include verification that the actual problem has been fixed.
4. As a post-mortem, once the solution is finally in place and working, review the entire process with Bob. Go over what worked and what didn't work during the implementation. Document the reasons why the two of you had to try 5 or 6 times before everything worked. Document your solution and why you chose it. The next time he comes to you for help, you can start out by reviewing the last solution(s) - this will help both of you to avoid falling into the same problems over and over.

This may all sound like a lot of work but generally, in the long run, it's easier/better to do things "right" in a way that helps people learn from mistakes, versus just slapping on the quickest/easiest fix. To summarize: If you're asked to help someone, you should make sure your help is actually helpful, rather than just dumping an idea in their lap and moving on.

Answer 2

Can anyone suggest me what would be a good strategy to deal with this situation?

Document, document, document.

Each time you have to clean up Bob's mess, document it and copy the CTO. This may not seem like the nicest thing to do but at this point, I would be a bit more concerned with my reputation in the company and in particular the CTO's impression of you since you seem to be the one the CTO is getting angry with.

Remember when documenting this type of activity, do only report the facts. No need to embellish, the CTO can put 2 + 2 together. In doing this he will quickly see who adds more value, and who is doing more "talking".

It is not a pleasant thing to have to do, but I don't see another effective way to deal with it.

Answer 3

Now, whenever he faces an issue, our CTO suggests that he should consult with me. 80 to 90 percent of the time, I am able to fix his issue and I inform the CTO that I have provided him with the solution.

...

Listening to him, the CTO always gets angry over me and gives me a solid rebuke each time.

This doesn't really add up and I think that means that you are misinterpreting what the CTO is frustrated with you about. I agree with dwizum's assertion that "helping Bob is part of your job" but I would take it a step further. You are effectively Bob's lead. Your CTO doesn't want to to simply give Bob some advice and walk away. He wants you to take responsibility for making sure the work gets done correctly. The reason I feel pretty certain about this is that he continues to direct Bob to you. If the CTO thought you were the problem, he would not do this.

Think about it from the CTO's perspective. Bob comes in and says he has some problem. The CTO doesn't have time for Bob. He sends him to you for help. You give him some help, Bob doesn't get it and is back bugging the CTO. The CTO just wishes you would deal with Bob and see things through. He doesn't want to talk to Bob about his issues. He just wants the work to get done.

I think you should have a frank conversation with the CTO about this situation. Basically there are two paths here. 1. Bob is on his own. He succeeds or fails on his own merits. 2. You own the result and are responsible for making sure what Bob does is right. The CTO appears to want the latter option but hasn't clearly communicated this to you. If you and Bob are peers, it might be a good time to talk about a promotion. If you are a lead, you should be at the very least recognized for that and can expect to be compensated. I'd wager that you are already more highly compensated than Bob.

Answer 4

When you code reviewed Bob's work, didn't you spot the issues? You did perform code review, didn't you?

When Bob's work was tested, didn't the tests identify failures? You did perform automated testing, didn't you?

Nothing goes into production - or indeed into testing where it can be seen by anyone outside the dev team - until it's code reviewed. Implement a code review process and stick to it. When Bob does something that wasn't what you discussed, you find out in code review and either you or he reworks it until it's acceptable.

Also tell Bob that although you're supervising, you're not responsible for the quality of his work; he is. Any programmer should be able to critically evaluate the quality of their work. Blaming you for something he did badly is unprofessional.

Answer 5

There are some great ideas here already that you should consider. Here is another thought. When you come up with a solution for Bob, instead of handing it off and going to work on other things, you might sit down with Bob and do an hour or two of pair programming with him. It might just be a way to make sure he gets off to a good start, or it may turn out that in that process, you come to a deeper understanding of the problem yourself.

Organizations often avoid pair programming because they think it's wasteful for two engineers to work on the same piece of code. But there have been statistics indicating that the savings in bugs avoidance outweigh the expense of "wasting" the time of one engineer. If you think you might do this, you might want to review the literature on pair programming so you can make the case for it with the CTO.

Answer 6

You've already gotten some great answers in here. I've got a couple of small additions:

When teaching or providing Bob with solutions, keep in mind that we don't all communicate or learn the same way, so something that you teach in a way that you feel would be understandable might not be understandable for Bob. A good way to find out is to ask Bob to repeat any instructions or information you've given him in his own words to make sure he understood you correctly.

Another thing that might be a good idea would be to get a third party involved, preferably someone who can be impartial or unbiased and act as a mediator or advisor to Bob and you. Even better would be for the third party to be considered Bob's professional equal to make Bob more comfortable.

The group dynamic would be quite different from what you and Bob have when it's just the two of you. Right now you're the giver and he's the taker or you're the teacher and he's the student - either way, it's not a recipe for closeness or bonding or comfort and might even cause an awkwardness that's strong enough to prevent him from listening at times while he's busy inside his head.

In a group setting, there's a chance for Bob to identify with the third party and even take some cues from him or her. This opens up the possibility for the third party to set examples of asking questions, paraphrasing what was taught, or even theorizing about creative ways to use the newly acquired knowledge to show how it can be helpful.

My two cents.

Answer 7

As a C level manager, if this goes on too long I would fire both of you. All employees of the company must be committed as a group to achieving the goals of the company. The CTO cares about achieving the goals of the company, and he asked you to help Bob, so what he wants is for you to help Bob and get the problem solved, and he expects you are able to do it. He does not care who is to blame. He is angry because the problem has not been solved, and instead of you both solving it you are wasting his time with your petty bickering. This applies to both of you, so work it out between yourselves as adults.