I have an interesting case. A new person joined the company which is something like a project manager. I do not report to this person.

It is starting to become apparent that this is a person that can not really do a proper planning or describe to the team what needs to be done. The thing is that the person tries to distract from a mess that he is responsible for.

For example: when team is blocked and asking to write details on what needs to be done, the answer is:

we can not allow documentation to block us.


Is it efficient to spend time writing 5 pages of requirements?


why don't you want the team to talk? That's why the team sits near by to easily talk.

Basically whatever statement he hears he exaggerates and misrepresents it so that his position appears the reasonable one and I suspect in order to cover up by blaming others for the mess e.g. That the person has no support.

Basically he is using the strawman logical fallacy.
What are effective strategies to handle this pattern of behavior?

As mentioned I do not report to this person. I have to get involved occasionally in some of the things the team that is working with him is doing to help them finish as I know the system and technical aspects really good. I have seen the frustration of the team in meetings and for me the impact is that my time is wasted and I can't neither get the answers I need or understand what is expected as an outcome from what we are working on.
I suspect from the comments that someone will suggest to talk to my boss but at this point I do not want do that for 2 reasons.
1) I think it would be good for me to be able to handle conversations with such people effectively especially if I want to move higher up.
2) I am giving a small chance that the person is not realizing what he is doing and I would prefer someone else to report him with more stakes than me on this

  • Why vote to close? Isn't it a specific question?
    – smith
    Oct 27, 2017 at 20:34
  • Does the entire team feel this way, or is this only your opinion?
    – Roger
    Oct 27, 2017 at 20:50
  • 3
    @smith we have a few close-happy people here. Oct 27, 2017 at 20:56
  • @Roger: no other people start to notice. I have actually figured out what he does as a formal pattern. Others have realized that discussions go down the drain but I think they haven't realized what's happening.. So far I have avoided to highlight exactly how he does what he does
    – smith
    Oct 27, 2017 at 20:57
  • 3
    @smith I edited your post to make it a bit more easy to follow. Oct 27, 2017 at 21:08

4 Answers 4


Not worth documenting requirements is ludicrous. Come at him head on.

If there are 5 pages of requirements then yes. No one is going to remember 5 pages of requirements from conversations. Once the product is complete there will not agreement on verbal requirements. As PM it is your job to document requirements. I am not willing to put myself in a situation where you say that is not what I said. Yes I would like to talk to the team about documented requirements.

If he cannot write up 5 pages in 2 hours then he did not know what the requirements were in the first place.

  • 1
    If you don't have your requirements in writing, how do you write your test specifications? Oct 28, 2017 at 13:01
  • I like a lot the first 2 sentences. Aren't the rest a bit aggressive?
    – smith
    Oct 30, 2017 at 20:16

Like proper backups, this sort of stuff only becomes apparent when things go wrong.

In the general scheme of things 5 pages is not a lot. But here are a few things that are a lot of time/money.

  • Trying to figure out how something works after the team has changed/quit.
  • Customer refusing to pay because it’s not what they requested, and you have no evidence to prove otherwise.
  • Wasting time on feature creep.
  • avoiding arguments on what the application is supposed to do.
  • Unable to easily access the quality of your requirements.

Requirement documents also change during the project, but in the long term help reduce time.

How to make your PM follow it I am not sure. I would recommend reading “Code Complete” section: Requirements Prerequisite. Maybe give the book as a present.


The book you want to read is When I Say No, I Feel Guilty by Manuel J. Smith. Do not let the title mislead you, it doesn't describe the book accurately. Read its customer reviews on Amazon.

Applying the formula of that book on your examples, you'd end up saying something like:

we can not allow documentation to block us.

Sure, documentation can block us sometimes, but I want us to write these requirements down.

Is it efficient to spend time writing 5 pages of requirements?

It may not be the most efficient and I may not be the most efficient worker around, but I want us to write those details down.

why don't you want the team to talk? That's why the team sits nearby to easily talk.

I know I'm frustrating you and the team with all this talk of taking notes and writing things down, but I still want to write those things down.

The second part of each response would be your "broken record". Honestly, I'm not sure what things you need to write down, or who needs to write those things down, so that's why I'm not being very specific with that part. If you get bored in your head of how many times you need to repeat the same broken record, just keep a count in your head. Just don't deviate from the book.

The first part of each response is "fogging" or acting like the "fog", you'll have to read the book to understand how it works. I'm sorry I can't explain more. I'm really busy this week. Hopefully, I'm giving you enough to get started on studying this stuff.

If the book feels too abstract to you, read the end and the middle of the book first.


Maybe you could politely correct his overzealous interpretations of your points of view. Make sure to acknowledge his perspective and try to avoid being condescending.

For example:

Is it efficient to spend time writing 5 pages of requirements?


I agree, that would be a waste of time. So, five pages may be a bit of an exaggeration but I feel it's important to have a good understanding of the project goals before we begin. This could help us to avoid having to repeat work. A simple outline should be sufficient.

Anyone overhearing the conversation will know who is in the right.

  • The problem is not about people overhearing. The question is how to handle interactions with him effectively.
    – smith
    Oct 27, 2017 at 22:00

You must log in to answer this question.

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