In my company we have this computer guys who always fix the system and add new features. My task in this process is to divide the workload among the developers and to get status updates to the higher-ups (How is it going?, When are we going to finish this project?, and so on...).

Always when I bring a new requirement to the nerds (sorry for my wording but it will soon become clear why I call them like that) downstairs they freak out and over-talk everything. The will say that some things don't work this way or that they have to set up a separate system or some excuses like that. I am looking for project management tools where I just write down what they have to do and they will get the appropiate work assigned, prefered automatically. I don't want to waste my time talking to this eggheads but instead get my and the company's work done. Less 'yada yada', more working. I want to spent as little time as possible with them, they should just know what they have to do.

  • If the engineers "just know what to do" and you won't have to talk with them, what exactly do you think your job is going to be? – Erik Jul 5 '18 at 13:47
  • @Erik My job is to manage the whole thing. Get budgets assigned, looking if we have enough employees, giving tasks to the appropiate people. Yes I am totally cool with assigning the tasks. But I don't want to get bogged down by talking 2 hours straight about a new button in the web-interface. (No exaggeration) – KillBean Jul 6 '18 at 9:02
  • Sounds like you need someone between you and them who handles the critically important task of turning "what we want" into "how we'll do it". – Erik Jul 6 '18 at 9:37

I want to spent as little time as possible with them, they should just know what they have to do.

Stop and ponder this sentence. The other two answers have called attention to the attitude that is evident here. To me this conveys a fundamental disrespect for the team members in question and top down command driven management style. These indicate to me that I don't want to work on this team. In particular "they should just know" is a klaxon warning of huge project risk. The PM's job is 90% communications; if the PM wants to spend less time communicating, my spider sense is alerting me to a significant problem in the project. It is very unlikely that the Subject Matter Expert (SME) will ever "just know" unless the requirements are clearly communicated to them, and they are given the chance to explore the requirements.

In my personal opinion, the more planning I do with the SME, the greater the fidelity and assurance of my project schedule. Discussion with the SME tells me where the requirements need to be refined, where they are unclear, and where they are unrealistic. Discussion of the work package with the SME reveals my trade space when I have to make decisions about how to manage risk. My most common complaint is that SME are unwilling to talk about the requirements - I work to build up trust with them, so that they're willing to discuss, rather than just falling back into a defensive/conservative estimate.

If the SME are telling you that things don't work the way you've described, that is evidence of another problem. Granted, I will never understand the product as well as the SME's do, but when they tell me that I don't understand, that is a signal that it is time for me to listen - they are willing to share their expertise, and I have the opportunity to learn.

It is of course also possible that the SME's are simply irrationally resistant to change, and are expressing that resistance through a form of white mutiny. My response doesn't change - if they are irrationally resistant to change, then it is my role to get them to trust me - to convince them that changes will not be irrational or capricious. My role to ensure that their voice is heard in the change control process. That work package estimates will be based on their input, and that I will manage slack/risk to ensure that they can stay in a comfort zone between boredom and overwork.

Senior manager recently asked what I did while there was a SME in the room. I told him that "I keep the team's queue filled with interesting work." My goal is to keep delivering them interesting challenges that lead to satisfying rewards. Allocate the boring work so that everybody gets a fair share, and develop new work that enables them to stretch their skills without ever confronting the impossible. Enable them to deliver high quality work on time and on budget. (fortunately the SME smiled and understood). Point is not to glorify myself, but to outline that there are alternatives to the command structure implied in your question.

  • 1
    "klaxon"! Nice. Stealing it. – David Espina Jul 5 '18 at 13:37

I'm going to assume you're the team's manager and not an 'organizational bystander'.

What I'm getting from this is, essentially, "the developers on my team are annoying and afraid (of me/the higher-ups/being blamed/the company going down the wrong path). How can I avoid dealing with this unpleasantness while still making sure my job gets done?"

You seem to have two problems here.

The first is your disrespectful attitude towards your team members. Luckily enough, that one is easy to fix - stop using derogatory words to describe them and their actions. Also stop being dismissive of them and start paying attention to their concerns. Or at least, to their underlying concerns, which brings me to your second apparent problem...

Your developers appear to be alarmed by any new work that comes in. Maybe they're afraid that if they get behind in their work, they'll be penalized, and thus want to avoid that by any means necessary. Maybe they've found legitimate concerns about the viability of what you bring them, and are simply unskilled in conveying those concerns (not surprising; many developers I know are the same). Maybe they just have excitable personalities, and like to talk in such a manner. You don't know. So don't jump to a conclusion/assumption and instead try to get to the underlying issue first. Then and only then should you know how to proceed.

Just be careful about how you go about getting to the underlying issue - if it is that the team is afraid, you'll have difficulty assuring them until you've gained their trust. To do so, start by reading my paragraph regarding your attitude.


Your write-up is throwing out all kinds of signals of an environment that is not conducive to collaboration and an environment with nonexistent, weak, or under performing PM processes. You have also seemed to conflate bringing a new requirement into the project with gathering status updates. These are two distinctly different processes.

Part of the work in knowledge-type projects is yada yada. Your project team should have established avenues where they can yada yada and, based on your disclosed discomfort or even hatred of the yada yada, it appears there is no avenue to do so and they are taking advantage of whenever they yada yada and it is ruining your day.

Certainly some people have the tendency to get on their soap box and have trouble getting off of it and you do need to manage that. But the words you used on this write-up suggests this is not your problem.

So, just based on your write-up, the nerds are not the issue. You seem to have more organic PM issues.

  • Yeah organic PM issue. I know what you mean but I can not fire my whole department. a. That's not a nice way to treat people and b. then I have to train a whole new team. This does not help – KillBean Jul 9 '18 at 7:23
  • It's interesting you read from my comment that I was suggesting firing your PM department. I am suggesting no such thing. What I am suggesting is, you don't have a PM department...at least not a functioning one. Build one, don't fire what you have. @KillBean. – David Espina Jul 9 '18 at 11:51

Checked your profile out of curiosity to try to understand your thinking…

Although you don’t seem to like books and prefer to talk about getting knowledge from experience, I strongly suggest for you to educate yourself (read books and, if possible, go to classes). Books and training are made from people with loads of life experience and "most of them" are also based on facts and research. Just give some of the recommendations a try and look at the results.

Some books to look at:

(for readers beyond 2019, please disregard the books as some greater books might come up by then)

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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