63

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 Jun 15 '18 at 12:56
  • Have you tried asking him to consult you first before going to the CTO? – Mateen Ulhaq Jun 16 '18 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 Jun 18 '18 at 9:33
  • This is not a blame-game. The title might need changing. – Thorbjørn Ravn Andersen Dec 26 '18 at 14:08
133

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 Jun 14 '18 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. – TemporalWolf Jun 14 '18 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 Jun 14 '18 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. – AllTheKingsHorses Jun 15 '18 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 Jun 15 '18 at 11:39
83

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. – Mindwin Jun 14 '18 at 18:22
  • 30
    @Mindwin: I'm guessing CO = CC, and CCO = BCC? (Google suggests that those are the corresponding Spanish abbreviations for CC and BCC.) – V2Blast Jun 14 '18 at 18:37
  • 7
    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). – Wesley Long Jun 15 '18 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. – Greenonline Jun 16 '18 at 11:38
54

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). – Mindwin Jun 14 '18 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 Jun 14 '18 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. – Wesley Long Jun 15 '18 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 Jun 17 '18 at 20:07
9

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 Jun 18 '18 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 Jun 18 '18 at 6:38
  • "defeat the code review process" What does that mean? – Steve Smith Jun 18 '18 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 Jun 18 '18 at 14:00
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.

  • 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 Jun 17 '18 at 6:11
4

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.

-1

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 Jun 18 '18 at 0:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.