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?

  • 2
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Masked Man
    Commented Jun 15, 2018 at 12:56
  • Have you tried asking him to consult you first before going to the CTO? Commented Jun 16, 2018 at 9:23
  • Why do you feel that telling the CTO "I had to help Bob with X, he was doing A and I told him to do B" is OK, but telling the CTO "I had to help Bob with X again because he did C, instead of B as I told him" is not OK?
    – walen
    Commented Jun 18, 2018 at 9:33
  • This is not a blame-game. The title might need changing. Commented Dec 26, 2018 at 14:08

7 Answers 7


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.

  • 16
    +1 to this, although you should include code review of Bob's implementation at 3 or between 2 and 3.
    – Rup
    Commented Jun 14, 2018 at 16:44
  • 6
    All of these are solutions to the root issue, which is the OP isn't effectively communicating... either with Bob, the CTO or most likely both. Commented Jun 14, 2018 at 21:56
  • 2
    Wish I could upvote this more than once. Taking the time to teach the solution properly saves time and heartache in the future.
    – Thomo
    Commented Jun 14, 2018 at 23:17
  • 5
    If OP has this level of responsibility to supervise Bob's work, they are effectively Bob's supervisor... and that should be made explicit by the CTO to both Bob and OP. If OP tries to manage Bob's work without clarifying that first, there's a good chance it'll breed resentment. Commented Jun 15, 2018 at 10:48
  • 3
    @AllTheKingsHorses not sure if I'm 100% in agreement. There's a difference between being explicitly put in charge of someone as their supervisor, versus being asked to help them with their problems. I do believe that even in the latter, the "helper" bears responsibility for the correct application of the solution, even if they're not explicitly the other staff's supervisor. In other words, if you're asked to help someone, you should make sure your help is actually helpful versus just dumping an idea in their lap and running on to the next thing.
    – dwizum
    Commented Jun 15, 2018 at 11:39

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.

  • 8
    And by all means CO the CTO. Don't use CCO in this case. You want BOB to know the boss is listening in. Commented Jun 14, 2018 at 18:22
  • 32
    @Mindwin: I'm guessing CO = CC, and CCO = BCC? (Google suggests that those are the corresponding Spanish abbreviations for CC and BCC.)
    – V2Blast
    Commented Jun 14, 2018 at 18:37
  • 8
    Nothing will win the CTO over more quickly than a grid with 2 columns and rows showing what steps you recommended, and what steps Bob actually did (along with the results of incorrect actions). Commented Jun 15, 2018 at 2:17
  • 1
    @V2Blast - In Spanish CC = CC (Copia de Carbón), BCC = CCO (Copia de Carbón Oculta). I don't know CO refers to... that looks like a typo. Commented Jun 16, 2018 at 11:38

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.

  • 13
    One should not let oneself slip into a managerial position without adequate compensation (not necessarily material/monetary). Commented Jun 14, 2018 at 18:23
  • 1
    @Mindwin I agree fully but I make a distinction between a lead and a supervisor/manager role as I think most HR (at least in the US) do.
    – JimmyJames
    Commented Jun 14, 2018 at 19:37
  • 14
    "Hey, CTO - I have noticed you get upset with me when Bob has problems. Am I misunderstanding something? Did you want me to do more than give him recommendations? What is the expectation you had that I'm not meeting?" No accusations, and LISTEN to the answer. Don't argue or debate. That part comes later. In the first discussion, just LISTEN. Commented Jun 15, 2018 at 2:19
  • 2
    "One should not let oneself slip into a managerial position without adequate compensation" - and definitely without the proper authority. YOu can not deliver without the authority to do your job.
    – TomTom
    Commented Jun 17, 2018 at 20:07

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.

  • On two separate occasions we had two engineers completely defeat the code review process.
    – Joshua
    Commented Jun 18, 2018 at 0:51
  • 1
    @Joshua "defeat" the process? Why? It's not meant to be adversarial. I can understand that sometimes stuff has to be rushed through in an emergency but generally acting in bad faith like that would make me seriously question someone's future at a company. What happened to them?
    – Tom W
    Commented Jun 18, 2018 at 6:38
  • "defeat the code review process" What does that mean? Commented Jun 18, 2018 at 9:32
  • @Tom W: When you are bent on checking in deliberately bad code it is. We found a ring of programmers signing off on code reviews without having meaningfully done them. The ringleader was forced out via "constructive dismissal" .
    – Joshua
    Commented Jun 18, 2018 at 14:00

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.

  • 2
    +1 And I would go further: You and Bob can take collective responsibility for the problem, code the solution using pair programming, and submit the solution after both of you are satisfied with it.
    – jkdev
    Commented Jun 17, 2018 at 6:11

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.


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.

  • 2
    This is a really bad answer. If given this position from a C level manager I would merely have to report that I cannot fix Bob's ability.
    – Joshua
    Commented Jun 18, 2018 at 0:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .