-2

How should you deal with a project manager who tries to have it his way even when it's against the company best interests? I am not sure if I am crazy, but I had this project manager argue against me and tell me to not follow UX guidelines and proposed a solution that was really terrible for the UX. We then went back and forth and I made some compromises, and he still suggested that his idea was the best and we should implement it the way he see fit. And some people agreed with me and tried to find a solution, but every time we tried to tell him that his solution was as terrible as mine, he tried to have it his way by using the same arguments I told him.

I told him I need to look for alternative solutions to make sure to address his concerns and UX guidelines, and then someone came up with an alternative solution. I said I agreed, and he kept disagreeing until everyone ended up agreeing with me that this was the best solution. He felt visibly frustrated, and I feel he's just using his ego to push bad solutions onto us to tell us what to do and boss us around. Did I behave as I should? The guy screamed at some other dude after firing him, and he raised his voice against me 3-4 times already when I try to make sure we adopt the best solution to every problem.

Another issue is that he goes back to his previous agreements, he doesn't really listen, he doesn't agree with almost anything, seem to not listen to developer's feedback unless we raise our voices against him. It's crazy.

Improve this question
5
  • Have you discussed this with your line manager, and if not, why not?
    – Philip Kendall
    Mar 16 at 17:33
  • I need to know if I am 100% in the right.
    – deliguy
    Mar 16 at 17:39
  • 11
    Spoiler for life: you're never 100% in the right.
    – Philip Kendall
    Mar 16 at 17:41
  • 2
    "every time we tried to tell him that his solution was as terrible as mine..." So, you have 2 "terrible" solutions at work. Wouldn't it be more productive to come up with a mutually agreed solution that is better than the 2 "terrible" solutions ?
    – Job_September_2020
    Mar 17 at 5:24
  • 1
    @informant: actually you are very close to 100% wrong. It is the job of the PM to make decisions, not yours.
    – virolino
    Mar 17 at 9:32

4 Answers 4

Reset to default
4

Who is the Technical Leader or who are the Technical Leaders?

This is the important question. Whomever that is is the one who gets to make the final decision on technical decisions. This can be a manager, senior engineer, the program manager (PM), or even the customer in some cases.

In some cases there are multiple people who are the technical leaders, for these cases an Engineering Review Board (ERB) is recommended. Each item that needs a technical decision is sent to the ERB where the pros and cons of the different options are briefly discussed (any lengthy discussions should have happened before the ERB) and then each technical leader casts a vote in a yay or nay style.

If your PM is not the technical lead then you need to have a talk with the technical lead since the PM is overstepping their authority. Now if you are the technical lead then you need to have a private talk with them where you two clearly define who is responsible for what and possibly deinvite the PM from all further technical meetings that do not touch on something the PM is responsible for.

Now the rest of this answer assumes the PM is your technical leader:

At the end of the day technical leaders are the ones who get to make a decision even if it one that you disagree with. Leaders make bad decisions all the time. Sometimes it works out, they were able to see something everyone else could not, and sometimes they really had no idea what they were doing. Good leaders will take input from people more knowledgeable than them and weigh the pros and cons, and be able to explain why they are going to make the decision they are going with even if it is not the popular decision. Unfortunately your PM does not appear to be this.

Working with Authoritarian Leaders

Your PM follows an authoritarian type of leadership. When working with these types of people, directly confronting them and saying through actions or words they are wrong is only going to make things worse, since it is a challenge to their leadership. One thing worse than that is to do it in a public setting with other people present like a meeting that they are leading. They tend to not care about what others think and expect people to do what they are told. So when someone does not comply it is a threat that undermines them, and they feel compelled to squash it (in some cases by any means necessary) otherwise anarchy will take over.

As such a better approach working with an authoritarian leader is to talk things over in private. Do not mention any idea you have that is better than theirs. Instead walk the authoritarian leader through their own idea, the risks and challenges it has. Ask them questions about their idea in a way that shows interest, but at the same time causes them to think through to bad parts of the idea. It is far better when working with an authoritarian leader if they realize what is wrong with their approach than you telling them it directly.

Once they realize the problems with it, then they will be far more receptive to ways of fixing it, at that point you still do not want to give your solution. Only give some initial thoughts that could form the groundwork for your solution. Ideally the authoritarian leader will take your initial thoughts and come with the solution themselves. At that point the idea is their idea and not your idea, and you praise their idea and never talk about the original idea ever again.

With all that said there are times where one should directly confront an authoritarian leader and refuse to comply with a decision they are pushing. Those times are when the decision could result in fines, jail time, lawsuits, injury, and/or loss of life. In those cases you want everything in writing, and depending on the severity or risk may even need to be escalated to higher levels of leadership.

Conclusion

In the end it does not matter who is right. What matters is who gets to make the final decision. Make sure your leaders have as much information as possible to make an informed decision even if they end up choosing something you disagree with. And when they make a decision you do not like, diligently work on it in such a way that when things fail the fallout/damage of it is minimized and don't say things like "I told you so."

Improve this answer
0
3

No, you did not do correctly. You should have worked with him to understand why he wanted the change, and then to find a solution that addressed his concern within the existing framework if possible. If that couldn't be done, work with him to present his concerns to the architects and see if they have a better answer or if the guidelines need to be changed.

In other words, remember that your manager is your immediate customer, and that while they may not express their request well, they have some reason for making it. That reason is what needs to be addressed.

You'll see us doing that frequently here in SE. Someone will make a strange request, and the response will be "This is an X/Y question. You are jumping to a proposed solution. If you instead tell us what you are trying to accomplish, we can not only tell you whether this will do it but whether there are better approaches."

Not everyone communicates well. Not everyone interrogates themselves well. With some patience we can help them past those hurdles... or help them understand why we can't, or why we need approval from another source.

But first we need to actively listen.

Improve this answer
3
  • "You should have worked with him to understand why he wanted the change, and then to find a solution that addressed his concern within the existing framework if possible" That sounds like the most ideal approach or at least a good place to start.
    – Job_September_2020
    Mar 17 at 2:23
  • I admit that it's easier said than done. But the alternative is either trying to bypass your manager -- a last resort -- or getting it on record that this is what he said was required, then doing it his way under the policy of "he may know of policies/requirements/exceptions I don't, and it his department; if he wants to do it this way and is willing to take responsibility for it, we can do that."
    – keshlam
    Mar 17 at 2:47
  • 1
    The part that I quoted in my first comment above is the part that I like (even if it might be easier said that done). In most places with good teamwork, people would always try to listen honestly and politely to the other sides first to understand their points, and then follow up with a professional discussion.
    – Job_September_2020
    Mar 17 at 5:52
0

Your company need to clean up your development and decision making process. Too many cooks in the kitchen with no clear accountability is a recipe for disaster. It's not entirely clear what your role is, but then again it doesn't seem clear what anyone's role is.

Talk to your management: it's their job to set this up

  1. Clarify roles and responsibilities
  2. Who owns what decision ?
  3. What's the accountability and business result or metric that's tied to that authority.
Improve this answer
5
  • 2
    Before anything, it is not the job pf the workers to make decisions. A PM is a PM exactly for that purpose. While things can be better / improved, facts are facts. A workers should not have the right to override a PM on a daily basis. Especially not a worker like OP who is a bugs creator - see his own other question.
    – virolino
    Mar 17 at 9:31
  • @virolino, that might suggest that the underlying problem is that people are in the wrong roles. Does the PM have the technical background and skill to design software and to manage software developers? I mean, you wouldn't put a monkey in charge of the marketing department, would you? Yet it's common enough with software.
    – Steve
    Mar 17 at 13:25
  • @Steve: yes, people might not be right for their jobs. But they all accepted their responsibilities. Until the responsibilities change, they should play the role they undertook, instead of undermining / sabotaging other people's work.
    – virolino
    Mar 17 at 21:39
  • @virolino, it's highly unlikely that anyone in higher authority has been explicit about the respective responsibilities, because more often than not they don't understand what the responsibilities actually are. I'm not saying the OP is in the right on this particular question, but dysfunction is so common in software management that it's entirely plausible that you have someone who has no development competence at all, trying to lead a handful of developers at only junior grade, and farce ensues.
    – Steve
    Mar 17 at 22:14
  • @Steve: you are totally right, things there are dysfunctional. But allowing the team members lead the project, while the PM gets kicked for the bugs (which the team creates every day, without solving any of the old ones), only amplifies the dysfunctionality - a lot. Refusing to call things by their name only creates and amplifies dysfunctionality.
    – virolino
    Mar 18 at 22:16
-1

Things are clear:

  • managers should manage;
  • workers should work;
  • occasionally, they exchange information.

Why do you think that you should make decisions, overriding the PM? Ultimately, it is his head for his decisions.

What is more, it seems that it his head even for your own mistakes. And that is very bad.

I am not there, I cannot see what is going on, but I know for sure that you are the kind of element I would not want around me. Not at work, not at home, not anywhere else. You cannot do your work properly, and you do not let others do their work either. You are a problems creator.

How should you deal with a project manager who tries to have it his way even when it's against the company best interest?

What is your exact position in the company? You seem to be perfectly knowledgeable of the company's best interest. You failed to mention it in both your recent questions.

As a worker who creates bugs more than features, it is not your job to "deal" with anybody.

Improve this answer
3
  • The most common pattern with software development is that the developers are in fact the "managers" who are responsible for a variety of technical concerns, which are complicated professional skills which non-technical staff cannot intuit and which most developers will struggle to explain coherently and convincingly (because they are very often acquired through experience, without passing in through the medium of the written or spoken word). The "workers" - in the sense you mean of those there only to do practical work, and not to think - are the machinery and the software.
    – Steve
    Mar 17 at 13:21
  • 1
    @Steve: there was no mention of any software development, or engineering, or anything. I used worker to be as generic as OP. Maybe they are engineers, maybe programmers, maybe anything. Regardless of that, the discussion remains the same. The "workers" raise concerns, the PM's make decisions and answer for their decisions. I have never heard of any failed project in which the workers were kept responsible.
    – virolino
    Mar 17 at 21:42
  • He's definitely a programmer - "UX" is jargon for the screens. It's true the "workers" may not be directly penalised for project failure, but they can still be downsized when a project does not succeed. Moreover for juniors, they are deprived of the experience of working in functional ways and participating in successful projects under effective managers, which has consequences both for their future productivity, and their perceived reputation and future confidence.
    – Steve
    Mar 17 at 22:33

You must log in to answer this question.

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