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?

  • 43
    I disagree that you've "ruled out ego". Just because you two are the only ones affected, and no one else witnesses discussions/disagreements/arguments does NOT mean his, or in fact, your egos are obstructing harmony here.
    – CGCampbell
    Oct 25, 2019 at 15:39
  • 2
    Is "Nothing" actually a believable answer to the question "What happens when X begins shutting down?" Oct 25, 2019 at 15:42
  • 1
    @user3067860 No. It was a dismissal of my contribution or involvement - implying I don't need to know what happens to the system. It impacted my ability to analyse my side of things and ability to add to the system in future. The result of the discussion in the end was that he would of course resolve this but it took the usual battle against his bluntness before we could establish anything. So that leaves me questioning whether anything I am responsible for is working as intended when he won't communicate and changes things without informing me. This happens multiple times a day. Oct 25, 2019 at 16:05
  • My point is, are there other examples where this person is intentionally withholding information or is this possibly just bad communication? Because the answers for both are different and I want to make sure you get the best answers. :) Oct 25, 2019 at 18:28
  • 3
    ... has something happened to prompt you to write this question here now, after a few years of things building up with this guy? Oct 27, 2019 at 19:44

10 Answers 10


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.

  1. 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.

  • 1
    I think this is heading in the right direction to answering the "why", and I agree now that, as other answers have suggested, further emplacement of testing / documentation processes may leave the issue unresolved and simply push it back further in the process. Though they may create evidence for making the case for disciplinary action. You've presented more realistic possibilities than my quick assumption of some sort of personality disorder. There is a lot to consider, and I fear as an employee I may not have time to understand a colleagues' state of mind in such depth. Thanks for this! Oct 25, 2019 at 22:13
  • I disagree that those are the only two reasons. An open ended question seeking an immediate response will often overlook things. Many times brains require massaging (and time) to think about the different implications. A question of “what happens when server X begins shutting down?” should be followed up with plausible examples “is anyone notified? is there any logging? does a restart get scheduled? can you think of anything else that might happen during a shutdown?”
    – vol7ron
    Oct 27, 2019 at 19:51
  • 2
    @vol7ron In some cases I could agree but in this particular instance the consequences of X shutting down was originally only 1 action. He added another action, and also changed action 1. At no point did he inform me or ask to test this change before moving on. We both have a lot on our plate but giving the answer "Nothing" and proceeding to blame me, wasting our time, is flippant at best. Oct 27, 2019 at 20:19
  • 1
    @vol7ron, I didn't say there were only 2 reasons, just that I would talk about the 2 I thought most likely to be relevant to the situation. If a server goes down and the 2 most likely causes are the brownout and the updates that happened overnight, are you going to investigate other possibilities first? Sure, it might have been a hacker or a hardware failure, but those aren't the most likely failures until you can rule out the brownout and the updates. Oct 28, 2019 at 15:54
  • 1
    @vol7ron, while what you say is mostly true, that still doesn't prove that I said "there are only 2 reasons". I can definitely think of other reasons for this behavior, such as trying to "game the system" to make the coworker look better than the OP at promotion time, they are just having a hard time at home and take it out on people at work, and the guy just being a stubborn grump. Without ruling out the first two "usual suspects" and without more context from the OP, which would be too much for this forum, we can't really know what's going on all the way down that rabbit hole. Oct 28, 2019 at 16:05

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.

  • 14
    This is the right answer. It is unreasonable to assume a single person can list every intricacy and nuance of a complex system. Based on OPs description it seems likely that the other person simply didn't think of feature X that affects this seemingly unrelated feature Y. With this procedure in place it puts the burden on the other person to figure out why their system is not meeting the requirements, and they should discover X without wasting as much of OP's time.
    – mao47
    Oct 25, 2019 at 13:28
  • 3
    Probably also have version control on the interface document, so it's clear when it is updated and by whom, to really manage the c-y-a side of things ;-)
    – Mike M
    Oct 25, 2019 at 14:34
  • 2
    @user9385381 You should hold off on accepting my answer - give it a day or two and someone may give a better one.
    – Player One
    Oct 25, 2019 at 14:45
  • 2
    Sounds like you're assuming the coworker is publishing an API. Yet to me it appears the entire problem is that he is not. How can you write tests against undocumented things that you aren't aware of? That's the very crux of this issue. Oct 27, 2019 at 17:22
  • 2
    @user9385381 Right, so the API (the actual API, not some hypothetical, old, unused version) is not fully documented. I will ask you again: how can you write tests against things you aren't aware of? This is not the OP's fault at all. Oct 27, 2019 at 20:16

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.

  • 2
    Upvoting this, because its the only answer that takes the right tack. This is a personal interaction problem, and that can't be solved with a process solution (short of flat out getting rid of one of the two people invlolved).
    – T.E.D.
    Oct 25, 2019 at 14:05
  • 5
    What do you mean by "making quality arguments"? Can you elaborate a little bit? Oct 25, 2019 at 17:37
  • 5
    I didn't elaborate because it may not be the same underlying cause as the OP's colleague, but basically, "It would improve the quality if...", "The coupling is good, but we are neglecting cohesion, which is another important measure of quality", "This change would solve this class of bugs we haven't considered yet", etc. Before that, my suggestions were mostly received as matters of subjective style. Oct 25, 2019 at 18:12
  • 1
    But this isn't your job - it's your manager's job. If a team member is not working constructively with other team members, it's the manager's job to work out why and fix it. That's what they're paid to be good at, in the same way you're paid to do good engineering. If they're not doing it, either they're a bad manager, or you and your team are concealing information from them which stops them doing their job. Either way, this guy is a symptom of a broken team, and the broken team is the real problem here.
    – Graham
    Oct 27, 2019 at 21:45

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.

  • 2
    @computercarguy Why does it make any difference whether it's intentional or unintentional? The end result is what matters here. Going down the written communication path is a starting point - and that can be done without the need to know the reason. As I mentioned in my last statement, we're not trying to treat the person, we're trying to treat the behavior. Oct 25, 2019 at 16:22
  • 2
    How would someone make a "deliberate attempt... unintentionally"? It can't be both.
    – Kat
    Oct 25, 2019 at 17:31
  • 2
    @computercarguy nobody involved has the right or the authority to delve into the mind of the person and understand his reasons. OP isn't a therapist, he's a coworker. Focusing on the motives of the person rather than the actual problem is pretty much the opposite of what you want to do in a work environment.
    – barbecue
    Oct 25, 2019 at 18:59
  • 2
    @computercarguy We're just going to have to disagree. Delving into the internal motives of a person you're in conflict with is not going to end well for anyone. Just focus on the actual problem, and completely avoid any attempts to psychoanalyze the person.
    – barbecue
    Oct 25, 2019 at 20:17
  • 2
    Conflict resolution in an office environment is about eliminating the problem, not fixing a broken person. Armchair psychotherapy of an employee who reports to you is marginal at best. In the case of a peer, it's inappropriate, unprofessional, and possibly dangerous. Amateurs armed with pop psychology trivia inflict far more harm than help when they try to "fix" people.
    – barbecue
    Oct 27, 2019 at 17:34

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.
  • 2
    This creates conflict and personal emotional response which I am trying to avoid; the other answers are on the right lines of providing an impersonal framework to ensure this either cannot happen or produces evidence, however they may cause me to step on toes by changing processes laid out by those above. Oct 25, 2019 at 13:35
  • 2
    While I think the most voted answer is the long-term solution, this is what I would do. Conflict is created by attitude, not actions. If you prefer, you could phrase it under curiosity, by saying "Has it always worked like this? I thought you said it was different when i asked before". My take is to always assume good intentions and honest mistakes, and behave accordingly. Long-term solution may be the best but won't help with non-collaborative managers and surely not in the short-term.
    – bracco23
    Oct 25, 2019 at 15:15
  • 1
    @user9385381, sometimes you need to create some conflict to get things "out in the open". If you let your antagonist create problems without them getting the fault and become the center of that problem, they'll likely never change. If you don't negatively reinforce a negative attitude, they will think they are in the right. To balance this, you have to also positively reinforce a positive attitude and behavior. This is very much an IPS problem that's manifesting at work and it needs to be dealt as an interpersonal situation, not just a workplace problem. Oct 25, 2019 at 16:35

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.

  • 1
    "I really does not matter" is diametrically opposed to " solve it is to identify the real problem". The real problem is the behavior of the colleague, it's not the secondary problem. If there weren't problems with their behavior, this situation likely wouldn't happen as often or as strongly. Their ego is at stake when bugs happen, so they refuse to admit bugs. "When somebody refuses to comply to the process", yes, and this is a behavior problem that you are trying to ignore. Oct 25, 2019 at 16:23
  • 2
    Depends on the emotional status of the worker. If the worker is unstable, better leave him alone first and we deal with him later.
    – Larry Lo
    Oct 26, 2019 at 12:52

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).

  • 1
    "it does not matter", yes it does. If they are purposefully not following the process, then it needs to be dealt with very differently than if they are unintentionally not following the process. Doing it purposefully wrong likely can't be fixed while doing it by accident can likely be by better training. Oct 25, 2019 at 16:28
  • 1
    @Justin, I'm with you on the cultural rollback. I only made that edit to qualify the other edits (min. required).
    – donjuedo
    Oct 25, 2019 at 17:38
  • 1
    And, if his part of the system is not documented, explain the bus factor to your PM / joint management
    – Mawg
    Oct 26, 2019 at 8:02

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.


"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.

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).

You must log in to answer this question.

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