My co-worker withholds information about his systems and blames me for "bugs" which aren't my fault

Question

I've been working at a company for some years in a lead position where I have responsibility for a large array of systems. I work with another co-worker at the same level, on independent systems, which we must integrate and work together to interface with.

My co-worker constantly withholds information about how his systems behave such that I can't understand why my integrations are failing; He will then try to blame me for the failures. We then waste time proving it is not my fault, and after hours of debugging, he will reveal information which is the root cause - which if he had simply told me how the system behaved in the first instance of my specific targeted question, we would have resolved it in approximately 10seconds.

I have had this problem for the entire time I've been here.

Often we are the only two people with a stake in resolving the problem, and are in fact the only two people to witness our discussions - so I fail to comprehend his behaviour when failure or wasted time means we both suffer the repercussions equally.

I have tried to rule out ego because there is nobody to witness it. Therefore trying to make me look technically incompetent is a useless endeavour because a fully functioning system is the only result we are held accountable for.

For example, "What happens when X server begins shutting down?" His answer: "Nothing." Some time passes and he reveals that some pipeline is ended instantly, a new behaviour he didn't tell anybody about, and which we already agreed upon and tested previously

What could be the cause this behaviour and how can I resolve it? Is this a symptom of personality disorders?

Answer 1

This appears to be very much an interpersonal problem, and not necessarily initiated from the OP's side. I disagree with most of the other answers, since they try to ignore the "why" of the problem. They want to say "fix the process" or "do this/that for better communication" without understanding the reason for the coworker's behavior.

There's several possibilities that could be going on, but there's only 2 likely ones that I'll touch on.

1. The coworker is trying to sabotage the project or the OP deliberately. This breaks down into 2 subcategories: failing the project because they don't like it; and failing the OP because they don't like them or because the OP has better (real or perceived) coding skills.

Trying to kill a project has some nuances to it. They could be morally opposed to it; they hate the language it's written in; they are bored with it; there's so much wrong with it they want to rewrite it instead of continuously fixing it; they dislike the customer it's written for; and so many more reasons than I can list. I'm sure we've all had those projects we "just hate". There's even some (slightly) legitimate reasons to want to kill a project, such as trying to kill off a Frankenstein of a 20+-year-old program that's had 80% complete projects scabbed on and translated between +4 languages that just needs to be completely rewritten from the ground up. Or letting hardware fail due to heat issues because the hardware was cheap junk to begin with.

If this is the case, it's best to have it be an open secret. Otherwise it's making other's lives a living hell. When people aren't part of that scheme, they have to take up the "slack" of fixing things and the people in on it grow to hate the people doing the "good faith" fixes.

When someone is trying to deliberately kill a project, doesn't tell anyone, and is not doing it for the benefit of anyone other than themselves, there's no training or communication that'll make them quit. There's no process change they'll adhere to and change their ways. They simply need to be removed from the project. This is a win for the company, since the person is no longer doing active harm to them, and if the person wanted to be taken off the project, it's a win for them as well.

2. The coworker dislikes the OP because of some slight, real or imagined. It could be that the OP accidentally to purposefully stepped on the coworkers toes some time in the past and they haven't forgiven them for it. Maybe the OP has shown that they are a better programmer than the coworker, either deliberately or incidentally. Possibly the coworker is insecure and just believes something happened, could happen in the future, or just doesn't like them for no real reason.

Sometimes grudges last for a long time, even when the original "sin" was years past and the reasoning no longer matters. It's hard to get past that and sometimes it never happens. Mental maturity has a lot to do with this. It doesn't matter what the physical age of the coworker is, if they still act like a 10 year old, they don't have the maturity to handle some things, including someone being better than them at some things.

If they are insecure, they need positive reinforcement of the things they do well and encouragement to learn and practice the things they don't do well. The only time negative reinforcement should be used is when there is a clear "something" that shouldn't be continued and is paired with a replacement "something" to do instead. "Don't use your sleeve to wipe your mouth" is an example of negative reinforcement. Doing this alone is generally bad. Including direction to "use your napkin instead" pairs it with positive reinforcement of a replacement action and is considered a learning opportunity. Tone of voice and use of expletives can greatly change how this is perceived, though. A neutral or cheerful tone can make the experience stick more positively in a persons mind, while swearing or using a forceful or derogatory tone will make it a negative experience, likely making them more insecure.

Having the correct responses in situations will make people more confident. If they are constantly being derided for something like SQL injection and told to "RTFM" or "figure it out", they probably won't figure it out. I've heard this as "rock management". It's described as a "rock collector" here:

This manager is an enigma to the entire team. Everyone is eager to please her, bringing rocks of all varieties for her inspection and approval, but few ever pass muster. The rock collector keeps everyone guessing about what she really wants and causes frustration because she is never completely satisfied. This undermines the team's confidence.

If we know the expectations of people around us and we know the correct responses to give them, we can avoid dealing with all the negativity that goes along with answering incorrectly. Also, if we have confidence we have the real answer to a problem and know the people we're talking to want to hear the wrong answer, we can effectively argue that our answer is correct and not back down due to their ignorance.

It can take a lot of time and effort to help someone who is insecure, but take it from me as someone who became confident, it can happen. It takes years of learning, being coached, getting the correct feedback, and more to get there, but someone who was insecure can eventually become confident. Whether the OP and their company has that kind of time is a different issue.

If the coworker just doesn't like the OP for no reason, there's not likely anything to fix that. Sometimes communication can fix it and sometimes it'll make it worse. There's not a whole lot to do about this, although there's probably a bunch of books out there that try to solve it.

If the OP's coworker refuses to learn, refuses to change their behavior, refuses just about anything and everything to get them to be a team player, then it's time for other changes. Maybe the process and system really are broken. Do they have good reasons to not follow them? If they do, things do need to change. If they don't, then it's time to separate ways. Other's have spent time explaining how to change the process and "the system", so I won't go into that. This Answer is pretty long anyway.

Hopefully I've shed some more light on why knowing the reason behind the behavior is the key to solving he process, and why ignoring that "why" will likely never solve the problem.

Answer 2

Your company needs a better testing culture.

I can't understand why my integrations are failing

Do the tests for the API you're integrating with pass? If so, then can you write a new test to reproduce the case that's failing for you and give it to your co-worker?

He will then try to blame me for the failures. We then waste time proving it is not my fault

Do you have tests that make calls against a mocked version of his API that prove that your component works as expected, when given expected input?

If this testing was in place then it wouldn't fix your co-worker's unhelpful attitude, but it would save a lot of the time that you spend going back and forward to determine where the problem is.

---

In response to your edit:

For example, "What happens when X server begins shutting down?" His answer: "Nothing." Some time passes and he reveals that some pipeline is ended instantly, a new behaviour he didn't tell anybody about, and which we already agreed upon and tested previously

In my opinion this statement is synonymous with "we have no testing".

"Tested previously [and it worked, so it's fine]" isn't a thing. Tests need to be repeatable, automated, and frequent. "We did it once before and it worked" isn't good enough. Your company needs a better testing culture.

Answer 3

I had a coworker with similar issues. I disagree with the other answers about not needing to understand the reasons behind the behavior. Once I found out the reasons, I was able to take a different approach which was somewhat more effective.

In my coworker's case, the cause was actually a relentless drive for quality in his system. Because quality was his number one goal, and he spent so much time trying to improve the quality, he had a hard time believing there were any flaws that he hadn't considered and addressed, and assumed any flaw must be external to his control. It created a huge blind spot for him.

It was only after I started making quality arguments that I was able to make any headway at all. In our case, I found out about the quality thing because our team took personality tests and shared some of the results. In retrospect, I could have figured it out if I had paid more attention to the arguments he was making. I had a huge blind spot because I assumed not being receptive to feedback meant he didn't care about quality.

Answer 4

There are two questions:

What could be the cause of his behaviour

We don't know, and frankly speaking, we don't need to know.

and how can I resolve it?

If this is a pattern, then it indicates a deliberate attempt to degrade / sabotage the work, intentionally or unintentionally. Try to limit the face to face communication and stress on written communication and e-mails. That way, at least you will have the root cause of delay / failure documented. You need to come clean from your side.

To elaborate:

• Please ensure that you ask all the information you believe to be relevant for your work to be completed and integrated. Make sure you mention a date and time (with some buffer time for yourself) for the expected response. Basically, instead of trying to co-work from the beginning, try to rely on the documentation. If the documentation is not available, please stress on getting them created - time invested in creating good documentation will heavily reduce the time wasted in integration effort due to improper / incomplete knowledge.

• Also, mention that the estimated completion time for the integrated product currently stands at X date and if the information is not revived within the stipulated time, it will get delayed.

• Next, if they try to accuse you of causing delays and introducing bugs, show them that email where you already asked for the info you needed and you did not get a response. This helps establishing the fact that you are not the culprit here.

Then, even after that if this issue persists, you need to have it escalated to the next level. You don't need to know why they are doing it, you just need that to be discontinued.

Remember, you are not against the co-worker, you are against the behavior they are exhibiting - so you need to attack the behavior and change that.

Answer 5

I'm going to skip answering about proper procedure and focus a but more on the IPS:

At the end, when he tells you the actual problem, I would reply with a simple, non threatening:

Wait, you knew the answer from the beginning? Why didn't you say, we could've saved a few hours?

Say that 'surprised', not hostile. It's a somewhat confronting aproach, but it puts him on the spot.

• If he has a good reason, he can tell you (you might get surprised!).
• If he hasn't got a good reason, this moment will turn awkward for him, incentivizing to answer more to the point the next time.

Answer 6

What could be the cause of his behavior

I really does not matter. Your problem is not your colleague, your problem is the threat at the success of your project.

how can I resolve it

The easiest way to solve it is to identify the real problem. Your question focuses on the secondary problem - the behavior of the colleague.

---

I have responsibility for a large array of systems

This makes me understand that your company is fairly large, and therefore you should have some development processes established.

---

My co-worker constantly withholds information about how his systems behave such that I can't understand why my integrations are failing

The correct statement (the real problem) should be something like:

The interfaces between the systems are not (well / properly / at all) documented,
and therefore the integrations fail.

---

What I recommend you to do

Start documenting your project(s) - lead by example. Clearly specify the interfaces (both provided, and required) of your system(s) and make sure you distribute the documents through the established official channels in the company, to all relevant stakeholders (including your colleague).

When something will fail, you will be able to compare their words to your documents - you will win definitely, if the management is at least remotely professional.

When your colleagues will start documenting their interfaces too, there will be two situations:

• all interfaces defined by everybody match properly and there are no problems;
• some interfaces will not match and a solution can be found;

The interesting case is the second, when something does not match. So, before implementation starts, everyone should (ideally) release their interfaces, and everybody reviews the parts which are relevant. When conflicts (between interfaces) occur, they are discussed, and a solution found. In the worst case, an interface-matching wrapper will be created.

When somebody refuses to comply to the process, then management should jump in and do their job.

---

Note: I do not imply that you must change the currently implemented processes. You only need to apply them better, and improve them only where they are not suitable enough. Follow the path of the least resistance (and least work). Changing an official, established, documented process is a LOT of work.

Answer 7

What could be the cause of his behaviour

We can't tell, but it does not matter. This is simply a matter of following a process.

and how can I resolve it?

Why is his system not documented and reviewed? At least the interfaces?

Stop whatever you are doing and push for that. Push your PM or joint management and back it up with the number of hours lost to debbugging.

Explain it in terms of cost to the project, and it will get done (at least, it would if I were your PM).

Answer 8

Sometimes people do not naturally volunteer information (or forget it until recalled via a detailed line of thought). I have found in my years that some people are very forthright with information in detail, while others you need to squeeze it out of them. What I do these days for such people, is to ask very specific questions.

Using your example, as an example:

Question: When X server exits, do you terminate the Queues immediately? Do you kill all threads? (etc)

Answer: No (Likely forgotten)

Question2: But what if I have something in the Queue which relies on X server, how is that handled?

Answer: oh yeah...

The discussion obviously fake, I do not know your system at all, but throwing corner cases as response questions is a great way to get people to naturally remember.

Answer 9

"What could be the cause of his behaviour"

• A. He forgot because the system is too complicated for him to remember it all.
• B. He has poor listening skills and you are verbally asking him questions.
• C. You have a history of accusing his side of having the problem without providing sufficient evidence and/or him proving you wrong.
• D. He's trolling you. He thinks not having API specifications is silly but the company culture has forced him into this situation. His only outlet is getting you to freak out now and then.

"How can I resolve it?"

• A. Look into his code/systems. Maybe you will find things that you can reference and make it easier for him to understand/see what the problem might be.
• B. Don't verbally ask him questions. Use email which documents the exchanges and provides him with an easy reference.
• C. Never submit a bug report without evidence and reproduction steps.
• D. When something breaks, assume it's his side and don't make a big deal of it. If management/clients don't like it he will feel the pressure. I mean IF you have bothered to create good logging on your side and you know you aren't changing your side. Just send a brief email about the break. Then sit back and have your coffee.

Answer 10

The problem is that this is you fault in a way. Because you've programmed against the API without knowing, what the routines you're using are actually doing. Because from what you've said, nothing was documented.

It's a common practice to make some common thought assumptions about how some other piece is going to work, both withing company or with third parties, but it requires a spirit of cooperation. If there's no spirit of cooperation (and there's none in your case) such approach is deemed to fail and you'll be the one to blame because you've written something that doesn't work (because his thing do work and he can easily prove that).

Dealing with that requires the change of the approach. You need to know what the routine you're calling is doing, and you need to have it on writing. It's a blocker. Unless you don't get that, you can't start writing your part. If some constellation of input data is not defined, you can't use than constellation until the documentation will be amended. If you're unable to put your job forward, escalate.

Then, if the integration fails, you can test his routine against the documented output, to prove, that the output doesn't match the documentation. Then it's not the problem on your side, but on his (either his routine needs to be fixed, or the documentation).