How can I deal with a coworker who keeps trying to put blame on my shoulders?

Question

I have this coworker that I help out very often. One reason he would approach me is that he doesn't have much experience in web applications. However, he is good in his domain.

This person has a pleasant demeanor, but he has this tendency that I don't know how to deal with. Recently this person needed help in a web application based task he was working on and approached me for help (he has done this many times before). I told him what needed to be done and I also told him that he should encrypt values before sending it to the UI.

When he was almost done with his task he told me that he was skipping the encryption, and there was no sensitive data involved, and he started trying to convince me that there was no need for it. I said okay. Later on during his code review he was told by the reviewer that he had to encrypt the values. He then told the reviewer that I agreed it was okay not to encrypt! I know this because his cubicle is close to mine and I overhear everything.

Every time I help him, he says he is going to do the task in a particular way and forces me through an argument into a position where I say okay.

At times he just walks over to my cubicle and tells me what he is doing and at the end he would add, "that is good correct?". Now I don't have time to sit and verify everything he is doing, so I just say yeah. Even on these occasions he uses my name if something goes wrong.

So my questions are:

1. How do I tell him that it's his responsibility and not mine, in a polite way?
2. If I say yes or okay in an informal conversation, do I really share the responsibility from that point on?
3. Is there a way to say that, I am not putting too much thought into it, but on the surface I don't see anything wrong?

Answer 1

The central thing here is when he "forces me through argument into a position where I say okay". The solution is: don't say "okay".

Assuming you are helping him out as a peer and that you are not formally reviewing his code, the next time he says he is going to do something against your advice say "I think it should be done this way but if you want to do it that way it's up to you". If he explains again why he thinks it should be done his way, just repeat your view. Don't let him try to force you into a position where you agree with him - just keep stating that it's his responsibility. Then walk away.

If this is part of a formal review, don't approve his way of doing things if you think its wrong.

If you are questioned later you can say you didn't approve of his way of doing it. (The fact that you haven't been questioned indicates to me that his attempts to stick you with the blame aren't working.)

Answer 2

Whenever I have had a coworker who puts blame on me for helping him, I've stopped helping him. No matter how pleasant they are, blaming others is a sign of incompetence or malevolence: they aren't responsible for the failure - you are. It is possible that by using your name to his superiors, he could be setting you up for discipline, or perhaps he grew up believing that any failure could be waved away with a suitable excuse to parents & teachers. If he's setting you up for failure, keep this old joke in mind:

Steve and Mark are camping when a bear suddenly comes out and growls. Steve starts putting on his tennis shoes.
Mark says, "What are you doing? You can't outrun a bear!"
Steve says, "I don’t have to outrun the bear-I just have to outrun you!"

Source.

When dealing with this person in the future, avoid saying "OK". Depending on context, that word is understood to be a social noise that substantially means "I hear you, keep talking." Your coworker only seems to be hearing it as an affirmative blessing. To help mitigate these sorts of communication failures in the future, I recommend reading How to Disagree Without Being Disagreeable. While this book is aimed more at handling hostile language in the workplace, it gives a framework for understanding what the other person is really trying to say.

Answer 3

Why does he ask you?

He could be asking you for a variety of reasons. Each will have a different way to deal with them appropriately:

1. He is legitimately stuck and you're approachable
2. He is a help vampire
3. He is looking for someone to defer responsibility when something goes wrong

Generally if it's case 2 or case 3, you shouldn't waste your time (company resources) aiding a horrible habit. But perhaps you're the type of person who can't say no. If that's the case, the following tactic will likely work for you regardless of the reason he's asking.

Give a Man a Fish...

This is the wrong way to help him:

You should encrypt values before sending it to the UI

This teaches him absolutely nothing. It tells him what he should do, but not why he should do it. Here is a parable to demonstrate the principle from another answer:

If you ask me what the current rate between JPY and USD is, I can tell you (about 95 JPY/USD). If you need to know the same thing again next week, or next month, and I'm not around, what will you do?

It may be efficient in the short-term to just tell you to use 95, but long-term if an important part of your work is knowing what the JPY to USD rate is, it's much better for me to teach you how to figure it out rather than just telling you the answer.

Now many people may assume this means I should just give you a link and then it will all be okay because you can find it next time. Problem solved, right?

What happens if you need to know the rate between USD and EUR? What will you do then? Of course I can give you another link, but then you will just have two separate links, and run in to the exact same problem if another currency is required.

If you guide him through the thought process, rather than just giving the answer, it will have the following effect:

If he is legitimately stuck

It will give him a tool on how to think through the situation on his own, and help him ask fewer questions in the future. You win. He wins. The company wins. And you look like an awesome mentor, which is always good.

If he is a Help Vampire

It will get him to say things like, "Yes, but what's the answer?" or "But I don't have time for this?" in which case you can easily see that he is just mooching off your brains to do his job for him. I would respond to future requests with something like this:

I'm a bit busy working on a project right now, but if you absolutely need help would you mind running it by my boss first?

If he is a responsibility-evader

It will get him to say things like, "What would you choose?" or "Is it okay if I...?" in which case you can understand what he's after. I would respond to future requests with something like:

I can tell you what the concepts are as far as I understand them, but for the specific requirements you'd be better off discussing it with your boss.

The Curse of Competence

The problem with competent people in virtually any workplace is that they think the ability to do more work is a universal benefit. "I can do it better than they can, therefore I should do it" is going to come to bite you in the end.

You can either view this as an opportunity to become a better teacher (rather than a supplier of results), or as an opportunity to become better at saying no. Don't just blindly do whatever work is thrown at you -- with great competence comes great responsibility to use that ability where it will have the greatest impact.

Wasting your time on help vampires will end up having people call in to question your judgment, rather than have people congratulating your talent.

Answer 4

I am sorry to say this: you're in the wrong here.

You should never say Okay to something that you don't agree with be it in your personal or professional life.

Strong communication is the key for every people related issue you'll have, and brushing off people with an 'Okay', is the opposite of strong communication, you're not communicating your intent, and if you want to remain political about it, you can always communicate a different intent which won't hurt the person.

"If I were you, I'd implement that encryption"

"I don't really have the time to discuss this issue right now, I'm sorry"

Answer 5

This is very profession specific..

But browsing code and reviewing code are two entirely different activities.

When working with them in the future establish better, clearer expectations of each other. First, make sure its in the scope of your responsibilities. You have your own work to do and reviews and mentoring take time. Are you helping to pass a review, or helping him to get past a small bump in the road?

If they are looking for a review, even if its merely as a sanity check before thy proceed with a formal review, insist on the requirements or bug reports they based this work around, the style-conformance reports, the tests, and the test reports. Evaluate those before even looking at the code in question. Even if they haven't completed the feature and not all the tests are written and passing, the style and test reports show the level of detail and effort thus far applied, where they are having success, and where they are perhaps falling a bit short. The tests will show how well they are exercising the different aspects of their feature, to know whether it is robust and usable, or fragile and too naïve.

If they have questions about some implementation issue, then look at their actual system code. If you see something that can be improved in that aspect, offer a technique and maybe a couple of tips on how to apply it, but let them do the research. Point out that they have research to do because there are consequences to that technique that they need to know about (as there is with any technique). Some of the consequences you may not remember, and may not know how it fits with the rest of what they are doing. When looking for information on that technique they may come across alternatives that fit even better. That is why they need to do their own research.

Make it clear you do not have all the answers. This is where you both had problems: they were treating you as an authority, an authority that could be pliable. Don't be the authority, and you can be as pliable as you want. Or be the authority, and expect nothing less than for them to respect it.

If they, on the other hand, need help understanding what something is doing, help them isolate the 'extra stuff' from the 'critical parts' so they can see for themselves what is going on. Make it clear the 'extra stuff' matters, but look past it to appreciate the larger intent of the 'critical stuff'. Its a fair concern that looking at a section of code or a group of modules for so long can easily get you lost in the forest. Sometimes it takes an outside view to regain perspective.

Answer 6

This situation needs to be clarified by your supervisor. Get specific expectations about your helping this person with web development. Are you a resource for help (i.e. a glorified Google) or are you responsible for how web apps are developed in your company?

Once you've clarified this with your supervisor make sure your coworker understands the relationship.

If you are a resource, your coworker takes full responsibility for any code he/she writes. Your name is not to be mentioned. If you are responsible for web developement, you'll need to be involved in the review process. You'll need to be more demanding in your views being implemented.

Some things can be handled by using exceptable practices (Passwords are considered sensitive data about 100% of the time.), but the others should be driven by requirments and specifications.