6

Some of my colleagues don't share information in general. They have their own cliques, sometimes they part of "rival" teams, but some in particular will systematically retain information. The setup is:

  • I ask for information about a specific project
  • my colleague, VERY politely, explains why it's not possible and why he doesn't think it's a good idea
  • at this point, I have to put on extra work than usual.

I have to explain things three times every time to get the information I need. And even then, I might get rerouted to other teams for extra, often unnecessary, approval. This stresses me out and slows down my work, which I guess it's my colleague's wanted outcome.

However, I don't want my request to be framed as "he asked for information, I clearly explained him why it wasn't necessary, now he's being pushy".

I would like to understand if there is a good way to systematically counter that "polite rejection" behaviour, in general.

3
  • 2
    "explains why it's not possible and why he doesn't think it's a good idea" - does he actually explain why something is impossible, or just a vague and evasive opinion? "often unnecessary, approval" - is it merely "often" unnecessary, or always unnecessary? There's a big difference between "withholding information" and "clearly explaining why it's not possible", and between being sent for "unnecessary approval" and "being sent for approval, that sometimes turns out to be unnecessary". I'd be careful to distinguish between your colleagues being obstructive, and merely cautious.
    – Steve
    Sep 26, 2020 at 11:56
  • 2
    What did your manager do about this? Making sure you get everything necessary to complete the project is his/her job. They should've introduced you to that team, explained the business needs behind your questions, asked for all required approvals, etc...
    – Igor G
    Sep 26, 2020 at 20:03
  • 1
    "my colleague, VERY politely, explains why it's not possible and why he doesn't think it's a good idea" I'm confused. Does "it" refer to the project? Is this project one that your team has been assigned? The way you've described this, it doesn't sound like "providing partial information" is the central issue. The central issue is that people on other teams consider themselves to have the authority to veto your teams' projects. Sep 27, 2020 at 21:44

1 Answer 1

11

I've encountered this kind of behavior enough times that it seems like there's recurring themes at work in these situations. It's especially common for folks in cross-functional roles to experience these kinds of problems.

The first thing you'll want to evaluate is your own questions (see, How to get domain experts to answer questions correctly, completely & concisely). It's common for some people to eschew "open-ended" questions-- even if they're warranted. You might be able to reduce the burden of answering your question by making it specific and narrow enough that the SME (subject matter expert) can provide it to you off the top of their head or refer you to a resource which is hopefully more specific than "google it".

Next, consider that by engaging with you by providing you with information, the SME is effectively putting themselves and their department "on the hook" for what they said. What if they gave you incorrect information? What if you used that incorrect information and it lead to a serious problem? What if you misinterpreted an off-the-cuff statement? Or maybe everything you're told is totally accurate and you understand fully, but now, you created a dependency and the other team isn't free to change things without breaking your stuff. Who's responsible for all these kinds of problems? It's impossible to say, but in some workplaces, "blame-storms" happen and people get in big trouble for seemingly minor things they may have said or suggested. Some places literally require a traceable, versioned, formal document for any communication between groups. Yes, it can be THAT BIG of a deal. In such scenarios, you really have to make your communication with this other department part of a formal workflow. You'll need to engage with management between the two parties.

Finally, and in my experience the most common case, there's an issue of trust. They might not know you well enough to trust you to use the information they give you. Bringing outsiders into the internal workflow of a group, creates the possibility of the outsider exposing problems within the group to the larger organization. You might be seen as a threat to their way of doing things, or even their future employment. The only way around this is patience and taking the time to develop informal rapport with these people. If you can put yourself into a role where you provide something to them, they might be more willing to act reciprocally and "return the favor" by providing you information when you need it-- even if you were just doing your job by helping them earlier.

You must log in to answer this question.