I am a contractor (software development) that is currently in contract with a small business--about 6 employees. There is one project manager and one owner of the business. Both of those people seem to like the phrase, "we have been over this", or, "please refer to the original documentation" when I ask a question.

Unfortunately these two people do not see that there could be other interpretations to their examples/documentation, or that after "going over it" I just saw a new interpretation while attempting to solve the issue, and I just want clarification because I am not in their head and do not understand their interpretation.

These are both people who cannot step into someone else's shoes. I already tried to talk to the PM about some of the ways she communicates in a certain situation, and in response received "This shouldn't have been an issue in the first place", essentially placing the blame squarely on my shoulders again.

Those degrading phrases are starting to wear on me. Is there any way to broach this subject gracefully?

  • 1
    Do you reference your previous communications or documentation when you're asking the new question?
    – JMac
    Commented Nov 22, 2017 at 19:59
  • @JMac Yes I do.
    – Jeff.Clark
    Commented Nov 22, 2017 at 21:37
  • 1
    Have you already reviewed the documentation prior to asking?
    – jpmc26
    Commented Nov 23, 2017 at 14:20

4 Answers 4


When someone refuse an attempt to clarify ambiguity, proceed with one interpretation as if it's the only interpretation. Send an email:

I understand that this means X. So I will proceed with doing X, until you tell me otherwise.

I understand that this might means X or Y (or Z). I will proceed with doing X, until you tell me otherwise.from Anketam's comment

If this interpretation is wrong, they will need to correct you. If they do not correct you, then they should not (they can, unfortunately) reprimand you, because you've informed them how you will proceed.

As Doctor Strange's mentioned, the most important part is having a written conversation, just in case the management forgets that they had any discussion regarding the concerned topic.

  • 11
    I do a variant on this. I can interpret this to mean X or Y (or Z). For now I am going to assume you mean X until you tell me otherwise.
    – Anketam
    Commented Nov 22, 2017 at 20:57
  • 4
    I do this too, but it could be that the OP is just unable to understand the specs and needs repeated guidance. In this case the OP should be looking for technical help pronto or could lose the gig
    – Sentinel
    Commented Nov 23, 2017 at 0:06
  • 8
    @Sentinel: What you say is equally possible, but does not justify the manager's dismissal of OP's confusion. If OP is confused, regardless of whether the documentation is ambiguous or OP is understanding something that is not actually said, the project manager should help to disambiguate OP's confusion. Dismissively pointing at the past shows an unwillingness to assist with what is clearly an issue for the OP, and if unaddressed will become an issue for the project (wanna bet they'll blame the OP for it then, even though they could've prevented the issue by assisting him now?)
    – Flater
    Commented Nov 23, 2017 at 9:07
  • @Flater: I know what you mean but cannot fully agree. I have been in both situations where the spec authors or those with key info have been unable or unwilling to clarify, thus stalling progress, and been in situations where incompetent staff have had repeated clarifications and fail to remember or grasp the concepts, thus also stalling progress. If the case is indeed the latter, then what could be happening is the OP is being sidelined.
    – Sentinel
    Commented Nov 23, 2017 at 13:25
  • 1
    @Sentinel: I completely agree with your comment that we're seeing the problem through OP's eyes, and it becomes impossible to know if OP's perception is tainted by his role in it. I just also think that the management's response is not in any way productive, regardless of who is to blame :)
    – Flater
    Commented Nov 23, 2017 at 14:45

Show how your question is different from what you've already gone over.

It must be different, or you wouldn't be asking again, right? So something like:

I know you said it must be red and green, but then your documentation says it must be friendly for colorblind people. These two things are at odds, so which do you want me to do?

Or maybe:

The documentation says the page must load "very fast", but I'm not sure specifically what that means. Is one second very fast? One tenth of a second?

If you go to them and simply ask what colors should you make the page or how quickly it should load, then they're not going to understand why you're asking about it again. If you explicitly acknowledge the information you've already been given and why it's insufficient, then there's no way they can retort with "go read the documentation." If you say "I'm not sure what colors to use", then of course they'll say "I already told you this. Why are you asking me again?"

Another thing that can help is to put more effort into seeing these problems ahead of time, so you don't have to repeatedly go back to them for clarification. If you ask them a question about the color scheme ten different times, then it's completely understandable they'd get frustrated, even if they're all legitimate. Think through the request thoroughly enough the first time that you don't need to keep going back to them to clarify things.

Let me give you a real example from today that's not software related. My boss left a couple papers on my desk that I needed, but I was working elsewhere. I texted someone in that office to grab them for me because I was going to see them later. They were the only two papers on or in my desk, and my desk is very clean in general. Here's how the conversation went:

Me: Hi, will you grab the papers on my desk and bring them to me later?

Them: Yes.

[A couple minutes pass]

Them: Where are they?

Me: On my desk. (Thinking: didn't my last text say that?)

[A couple more minutes pass]

Them: Is it the X papers?

Me: Yes. (Thinking: those are literally the only papers I could possibly mean. Right?) Are there any other papers on my desk?

Them: No, just those two.

At this point, I'm wondering if they drank too much the night before or hit their head or something. From my perspective, they kept asking for clarification when I had clearly given them enough information to do the job. They never justified their confusion. I said "grab papers on my desk". All they had to was look at my desk and grab the only visible papers.

Now imagine if they had sent the following along with their initial response: "I don't want the people sitting next to you thinking I'm stealing things from your desk. Can you tell me exactly where the papers are and what they look like so I can grab them confidently and not seem suspicious?" Then I would have understood why they were asking and could've promptly resolved it. As it was, I'm sure we both ended up annoyed.

In conclusion, make your question specific, explicitly give a reason for your confusion and why you can't solve it on your own, and do your very best to ask all your questions when the problem first arises.

  • This is the answer. This gives them more context, too, allowing them to better understand what you're asking and respond appropriately. I'm on the fence about trying to, "put more effort into seeing these problems ahead of time." It's not a bad thing, but it's hard to foresee everything in software. If you find yourself asking similar questions a few times, an equally valid approach would be to reference previous decisions and ask for confirmation that this one will be handled the same. You could also start phrasing your "question" as a notification that you're doing the same thing as before.
    – jpmc26
    Commented Nov 23, 2017 at 14:27
  • @jpmc26 I agree it's difficult to do well and impossible to do perfectly. Maybe you need to have one conversation when the request is made and another after you've had a chance to sit down and do some design. My point is you shouldn't be asking questions about the same topic a dozen times, especially if you are getting a reaction of "I already told you this" rather than "hmm, I hadn't thought of that."
    – Kat
    Commented Nov 23, 2017 at 16:39

I've found the following phrase to work well for this attitude.

I understand that, but without clarification, I cannot proceed, so what do you suggest I do?

That puts the ball right in their court. You are essentially saying that if they don't help you, the project is stalled.

Pretty standard IT runaround. Just pushback a bit like that example.

  • 3
    When I have tried this, it has sometimes resulted in an infinite loop where they keep replying back "Read the documentation" until I give up and do a different strategy
    – Anketam
    Commented Nov 22, 2017 at 20:55
  • 1
    @Anketam: If their sole response is "read the documentation", then the OP cannot be faulted for doing his work in a way that fits the documentation (even if it's only one of many possible interpretations). If they refuse to disambiguate the ambiguity, then they can't complain afterwards that the OP randomly guessed the wrong interpretation.
    – Flater
    Commented Nov 23, 2017 at 9:11
  • 3
    @Anketam: Essentially: "Give me a fork!" Do you want the green one or the red one? "A fork! Give it!" Yes, but do you want the red one? "Give me a fork!" [gives random fork] "I did not ask for a red fork! Give me the green one!" If you refuse to specify details (such as color), then you can't complain after the fact about the details not being exactly as you wanted them to be.
    – Flater
    Commented Nov 23, 2017 at 9:13
  • 2
    Still people will complain afterwards because their picture of the fork is green and everyone else has to be an idiot for not considering forks to be green. Commented Nov 23, 2017 at 15:21
  • @Flater it certainly can be that the OP can be faulted for being unable to follow directions that would have been sufficient for a more experienced engineer - what I'm seeing in the quoted comments like "This shouldn't have been an issue in the first place" is that OP requesting them to spend more effort than they intended. Their expectation seems to be that the information is sufficient to do the job, they've delegated this to OP and that OP should be capable of picking the right interpretation for business needs and take responsibility for the consequences of this choice.
    – Peteris
    Commented Nov 24, 2017 at 9:31

I've developed software for a small company before. As programmers know too well, there is no language that frees you from the burden of clarifying your ideas. My employer would avoid details because he wanted me to take responsibility for the decision in question. It can mean a few things:

  1. He wanted me to shift the responsibility of clarifying his ideas on to me, along with the blame if I did it the wrong way. This can be because he doesn't understand the importance of the detail, because one changed detail can take far more work than those unfamiliar with programming would expect. It can also be laziness on his part, he wants to avoid the mental labor of understanding a choice he's paying for.
  2. He wanted me to just do my job, if he were capable of breaking his problems down into unambiguous instructions he could save himself some serious money and just do it himself.

These two are not mutually exclusive and navigating them was, by far, the most difficult part of my job. My advice is this. Situation: you asked once, they gave you the "read the docs" line. This means they do not or do not want to understand the problem. Your turn again:

If it is easily changed later: make an executive decision based on your intuition and past dealings with them. Cite all the relevant parts of the docs, say "I interpret this to mean" and describe as simply as possible the consequences of your choice, email it. Don't wait for a reply, just proceed. If they complain later, no big deal to change it.

Else: Start by explaining that this decision must never change, we have to choose one and stick with it. Outline two or three (clearly numbered and separate) choices with an emphasis on their potential problems/limitations with each approach. Put those parts in bold font. Recommend one, reiterating the problems/limitations. Reference the documentation wherever applicable. Do not proceed until they respond having unambiguously chosen a path.

Referencing the documentation shows you did the leg work. Including them on the choice shares the responsibility. Making a choice/recommendation shows you did your job. Do it by email so there is a record. If it's easily changed, don't throw it in their face when they change their minds. If it's not, don't hesitate to use the emails to protect yourself.

Not the answer you're looking for? Browse other questions tagged or ask your own question.