65

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?

user9385381
  • 658
  • 1
  • 5
  • 11
  • 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 '19 at 15:39
  • 2
    Is "Nothing" actually a believable answer to the question "What happens when X begins shutting down?" – user3067860 Oct 25 '19 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. – user9385381 Oct 25 '19 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. :) – Captain Man Oct 25 '19 at 18:28
  • Well if you read the OP carefully,"I have had this problem for the entire time I've been here." also your analogy does not reflect engineering. – user9385381 Oct 25 '19 at 18:42
  • 3
    ... has something happened to prompt you to write this question here now, after a few years of things building up with this guy? – seventyeightist Oct 27 '19 at 19:44

10 Answers10

75

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.

Player One
  • 22,679
  • 16
  • 77
  • 89
  • 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 '19 at 13:28
  • @mao47 The issue is that some of the issues I've had communicating with him actually can't be resolved by testing / mocks (which there are a lot of already).

    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.

     – user9385381 Oct 25 '19 at 14:10
  • @user9385381 that would be useful information to include in your question - the more specific you are, the more specific we can be – Player One Oct 25 '19 at 14:14
  • 1
    It is a great answer though, and indeed the one I have used in similar situations. It takes a lot of time to set up your own test harnesses, but it is worth it. Of course you're right that you can't handle errors with specific responses if you don't know the output to handle, but if you have an interface document you both sign off on...... then he's on the hook for her/his side of it. Have clear test results for the published interface, share them in an email to her/him and copy whoever needs to see it. – Mike M Oct 25 '19 at 14:31
  • 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 '19 at 14:34
  • I suppose ultimately this is the correct answer whether or not I am able to put this in place. – user9385381 Oct 25 '19 at 14:37
  • 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 '19 at 14:45
  • 1
    Thanks though :) And your question has hit HNQ now, so I expect you'll get a lot of attention – Player One Oct 25 '19 at 14:47
  • 1
    Improve testing culture is the best solution, but also long term. You will need to involve the entire department. Short term you could sit 1v1 with your manager, present the issue, ask for advice on how to improve communication with this person. He might suggest to add a witness to your meetings, maybe himself. This time you will need to protect your reputation and it might be a good way to bring up the tests and start to change the culture. – Alex L Oct 25 '19 at 14:50
  • 1
    This is a good answer, but it assumes the problem stems from accidental negligence, instead of intentional hiding of "features", unsolved problems, and other issues. Automated tests can fix some of this, but the majority of this can only be fixed by honest communication, which doesn't appear to happen (with the new info in the comment and edit). – computercarguy Oct 25 '19 at 16:13
  • 1
    Testing and/or design specifications before coding and consequences for noncompliance. – WGroleau Oct 25 '19 at 18:10
  • This - make it measurable. – Thorbjørn Ravn Andersen Oct 26 '19 at 22:23
  • This so much. We have the perfect tool to communicate our intentions in a clear, non-ambiguous way: code! If you ever need something from a service, interface, module or whatever that someone else provides, write tests that describe your expectations. Send any failing tests as a bug report, or open a discussion about the goal of the service. @user9385381 anything can be tested, if not it's bad code. If it was tested previously and somehow changed, either the tests fail or they're bad tests. – Kevin Oct 27 '19 at 04:08
  • 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. – Lightness Races in Orbit Oct 27 '19 at 17:22
  • @Lightness Correct - It was documented in some way. His change was not documented. – user9385381 Oct 27 '19 at 20:15
  • 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. – Lightness Races in Orbit Oct 27 '19 at 20:16
  • 1
    @LightnessRaceswithMonica you can't write the tests in advance. You observe a failure in the system you have control of, and write a test to reproduce that failure. I haven't said (and don't believe) that this is the OP's fault. For the record, user9385381 is the OP: at this point you've asked your question to each of us only once ("I will ask you again" was directed toward the OP, about a statement that I, not they, made). – Player One Oct 29 '19 at 14:55
  • 1
    @PlayerOne In this case, "you observe a failure in the system you have control of" is exactly the problem: the failure is not observed until much later than it should be. – Lightness Races in Orbit Oct 29 '19 at 15:54
43

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.

Karl Bielefeldt
  • 20,730
  • 7
  • 41
  • 68
  • 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 '19 at 14:05
  • 5
    What do you mean by "making quality arguments"? Can you elaborate a little bit? – Peter Mortensen Oct 25 '19 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. – Karl Bielefeldt Oct 25 '19 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 '19 at 21:45
24

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.

Community
  • 1
computercarguy
  • 3,746
  • 11
  • 22
  • 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!

     – user9385381 Oct 25 '19 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 '19 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. – user9385381 Oct 27 '19 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. – computercarguy Oct 28 '19 at 15:54
  • I think you said there were several, but 2 likely. In my experience likely means probable and unlikely aren’t worth noting. Also, the “several possibilities” tends to be a literary device so as not speak in absolutes - something I do as well - but doesn’t imply that these possibilities are known or thought out. – vol7ron Oct 28 '19 at 15:58
  • 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. – computercarguy Oct 28 '19 at 16:05
  • I think my first sentence confirms what you said and acknowledges what I had said was not completely. I should have added “likely”. My original comment should have said “I disagree that those are the only two likely reasons”. Also, my follow up comment wasn’t an attempt to prove you wrong (or me right), it was just supplemental to expand on the idea and reinforce the point. – vol7ron Oct 28 '19 at 16:25
10

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.

Sourav Ghosh
  • 72,905
  • 46
  • 246
  • 303
  • 1
    "We don't know, and frankly speaking, we don't need to know." Yes, the OP needs to know this. Handling an "attempt to degrade / sabotage the work, intentionally or unintentionally" depends entirely on what that situation is. If it's unintentional, it can be often times be taught out of the person. If it's intentional, there's very few ways to handle this and the easiest is to get rid of them. If the OP doesn't know the root cause of the situation, they'll never figure out the solution, just like the software problems they are having. – computercarguy Oct 25 '19 at 16:17
  • 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. – Sourav Ghosh Oct 25 '19 at 16:22
  • 1
    How do you treat a person without treating the behavior? Intentional or unintentional behavior makes a huge difference. If someone is intentionally sabotaging a project, nothing will likely get them to change. If they are doing it out of ignorance of better solutions, they can likely learn those better solutions. One is a major problem that can't be fixed and the other can be fixed, that's the difference. – computercarguy Oct 25 '19 at 16:26
  • @computercarguy Did you mean to write "How do you treat a behavior without treating the person"? – Sourav Ghosh Oct 25 '19 at 16:31
  • 1
    @computercarguy I beg to differ, if no one is there to correct the mistake - why does it matter whether it's a mistake (unknowingly) or a misconduct (knowingly)? You correct the process, you correct the behavior. That's the starting point. – Sourav Ghosh Oct 25 '19 at 16:33
  • 1
    Correcting a process solves nothing if the behavior ignores the process. And treating a person without treating the behavior does nothing, since you are ignoring the behavior, which is the whole reason for "treating" the person. Without knowing why they are doing something, you have no way to know how to treat the behavior. Firing someone for lack of training is almost as useless as trying to retrain someone who wants a project/coworker to fail. Applying the wrong solution to a problem won't get anyone anywhere, so you need to know the "Why" behind the behavior to know the correct solution. – computercarguy Oct 25 '19 at 16:43
  • 2
    How would someone make a "deliberate attempt... unintentionally"? It can't be both. – Kat Oct 25 '19 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 '19 at 18:59
  • 1
    @barbecue, you don't have to be a therapist to be able to ask questions or "read between the lines". Figuring out behavior problems doesn't require any "authority", and since there is a problem with the coworkers behavior, the OP and the boss have a right to figure it out. And you won't truly fix a problem without determining the motives, which is why so many problems aren't truly fixed in a work environment. Glossing over or totally ignoring personal motives by an employer is what makes so many people hate their jobs. – computercarguy Oct 25 '19 at 19:36
  • 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 '19 at 20:17
  • 1
    @barbecue, the actual problem is the root of the behavioral issues. You wanting to ignore that will likely make things worse. Unfortunately, that's SOP for businesses and individuals and why careers/jobs and relationships don't last as long as they used to. "Psychoanalyzing" doesn't have to be intrusive and it doesn't have to be true psychoanalyzing. Understanding the "why" of things actually does make things better, we've just lost that idea in today's world. – computercarguy Oct 25 '19 at 20:56
  • 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 '19 at 17:34
5

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.

virolino
  • 27,187
  • 8
  • 60
  • 103
  • 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. – computercarguy Oct 25 '19 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 '19 at 12:52
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.
Martijn
  • 4,285
  • 1
  • 16
  • 39
  • 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. – user9385381 Oct 25 '19 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 '19 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. – computercarguy Oct 25 '19 at 16:35
4

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

Justin
  • 9,059
  • 2
  • 28
  • 40
Mawg says reinstate Monica
  • 12,680
  • 4
  • 26
  • 57
  • 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. – computercarguy Oct 25 '19 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 '19 at 17:38
  • 1
    And, if his part of the system is not documented, explain the bus factor to your PM / joint management – Mawg says reinstate Monica Oct 26 '19 at 08:02
2

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.

Chris
  • 3,960
  • 13
  • 22
1

"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.
HenryM
  • 5,792
  • 1
  • 14
  • 28
0

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

Danubian Sailor
  • 2,612
  • 2
  • 12
  • 23