3

There is a manager at my company whose mindset I struggle to understand.

Thankfully I haven't had to work with him that deeply or for extended periods, but because my company essentially rotates us around projects, I figure it's only a matter of time before this happens.

The few times I have been exposed to him, I've found him difficult to work with, and others who have worked with him also share that sentiment.

Some examples of his behaviours:

  • Prioritises speed of delivery over product quality every time; will compress project timescales to unfeasible levels to appease customers
  • Doesn't introduce any order or structure into projects, just leaves people to flounder and "self-manage" with no guidance
  • Doesn't appreciate the time it takes to work with legacy projects he's previously managed and which are now in a bad state; expects things to be done quickly
  • Doesn't offer any constructive feedback during or after the project, just says e.g. "You need to fix this"
  • Never has time to listen; always seems to be in meetings and doesn't respond to emails
  • Similarly, although it's his job to interact with customers and clarify their requirements, this is done very slowly and shallowly
  • When we raise concerns e.g. lack of resources, they're not acted upon
  • When projects go badly, he blames the developers and says that they "Didn't work hard enough" or "Weren't organised enough" etc.
  • Is very headstrong; thinks that his opinion is the most important, will interrupt and talk over others, and shoot down their ideas

We have other managers who are much easier and more pleasant to work with, and their projects are often more successful. The problematic manager is fairly senior and well-respected within the company, and his voice is given a lot of weight. His projects almost always end up being trainwrecks that barely scrape by; he's more concerned with meeting the customers' requirements on paper and getting short-term revenue than delivering a useful product that can be maintained in the longer term.

I feel like I can't say any of this to this manager or anyone else, because his position makes him practically immune to criticism. I'm worried that when I end up working under this manager, it'll not only be unpleasant but also not good for my career since I'll be forced to rush development and do bad practices.

It's difficult for me to say that I don't want to work with this manager; at my company we're almost always short-staffed so you don't get much choice in what you work on. I'm also worried that saying such things will make me look like I'm not willing to put in effort.

My current approach will be to suck it up and do the best that I can, and hope that the project isn't a total trainwreck. Is there anything more I can do to make it more successful, or at least more pleasant?

I know that he's probably very busy and needs to fill some quotas; fine, but I think my question still stands.

3
  • 1
    Is the behaviour of this manager well understood by others, including senior management? Apr 13, 2021 at 11:41
  • 1
    @GregoryCurrie I get the impression that it's generally understood, but because he delivers short-term results and technically isn't doing anything "wrong," nobody says anything. I also get the impression that people are reluctant to engage with him since he's so headstrong.
    – Touchdown
    Apr 13, 2021 at 11:44
  • 1
    I suppose my comment would be that your reputation won't take much of a hit. My suggestion would be to swim with the tide as much as you can, which isn't much of an answer. I would be highly skeptical of any answer that tells you to rock the boat. Apr 13, 2021 at 11:50

3 Answers 3

6

There's good managers and bad managers, sometimes they're the same person, it's all in the perception.

Your best strategy is just to concentrate on your own tasks and let things that are not your responsibility or under your control wash over you. Working in high pressure environments isn't always bad, there are things you can learn from it that will give you valuable experience in later years.

1

Do you best and improve what you can. If you get stuck with them document the behavior that you feel created a hostile environment and report it to HR.

0

I have a manager that is almost completely like this - only difference is that he is a CEO and company owner.

Although I don't come from a work culture that is quite as top-driven as in other countries, I can relay some of my own personal experiences that can alleviate the problem:

  • Prioritises speed of delivery over product quality every time; will compress project timescales to unfeasible levels to appease customers.

It depends on his experience with the kind of work you do. In my case i'm a lead developer, although I wasn't originally hired as one. I did have previous project management and leadership experience, however.

What I did was find ways to work smarter, not harder - I brought a number of tools into the team that made steps easier or faster to complete.

However, we also (as a team) made sure there was no ambiguity when it came to an unrealistic deadline. The end result was that we (the dev team) got to plan and estimate the deadlines.

  • Doesn't introduce any order or structure into projects, just leaves people to flounder and "self-manage" with no guidance.

While it's not always the optimal move to do so, in my case, I took the reins of the tasks and projects given, and laid out the track for the projects. In my case, it got me promoted, but it can also be a dangerous move in some places.

  • Doesn't appreciate the time it takes to work with legacy projects he's previously managed and which are now in a bad state; expects things to be done quickly

In our case, we introduced a simple kanban board for each project where any bugs, issues and notes were logged - along with giving the manager access to the boards. If anything needs to be prioritized, he has the full ability to do so and mark tasks accordingly.

In my case, the legacy code was a very bad case of "patchwork coding", which was basically rendered unsalvagable when the scope of demands for our systems was vastly extended. Along with documenting the bugs and problems of the existing codebase, I also actively started a discussion about the future scope of the projects and the system in general - this has since resulted in a major overhaul of our entire system.

About 2/3 of the new system is actually designed to solve the pitfalls of the previous design, and especially to allow much more detailed debugging.

It's always a gamble to prove a manager wrong, but it's also worth to note that there is a reason why you're in that position to begin with.

  • Doesn't offer any constructive feedback during or after the project, just says e.g. "You need to fix this".

I had an important discussion with the CEO that we weren't simply there to help him, but to help him help himself. The more he can assist with tracking down the problem, the better a foundation you have to solve it.

While, again, it can be considered a bold move - it has helped, as we have proved that the problem-solving process goes much quicker in the end.

  • Never has time to listen; always seems to be in meetings and doesn't respond to emails.

If anything is in writing, continually refer back to the given mail where the issue was raised. This is especially the case if a quick and/or proactive decision has to be taken in his absence.

  • Similarly, although it's his job to interact with customers and clarify their requirements, this is done very slowly and shallowly.

There is no harm (apart from simple ineptitude) to ask into the given requirements. Again, make sure that as much as possible is in writing, including a note that "the feature was asked for by X" in the task description. Also note whenever the feature or item changes and who changes the requirements.

Again, taking the bold path, you can ask proactively to assist in the requirements discussion and the project mapping and showing that you're aware that he can't think of every question on his own.

  • When we raise concerns e.g. lack of resources, they're not acted upon

This is probably the hardest part - but in this case it's basically the best to keep "bugging" them about the lack of item XYZ.

In any case, if you're missing a tool or a device to complete a given task, it's best to have and serve a list of arguments and consequences. So something like: "Tool ABC will cost $XXX, but it gives us the ability to YYY and ZZZ. However, if we have to make do without it, task WWW till take 3 times as long every time we do it, and we've had to do it 10 times this month."

Keep pressing for the tool or item in writing as well - then you have something to refer back to if the consequence rears its head.

  • When projects go badly, he blames the developers and says that they "Didn't work hard enough" or "Weren't organised enough" etc.

We had the problem in my team as well, and even got blamed on completely unrelated problems as well because "Device X produces data and thus it's your responsibility".

This is why proper documentation and references is important - in our case, we've had people in other departments that acted without the consent and knowledge of the CEO, on stuff that was completely outside of our control.

The documentation and reference also subtly and silently aids in pointing the finger back at himself. Nobody says anything bad or discriminatory against him - if anything it shows that you're organized and working with the tools you have.

The problematic manager is fairly senior and well-respected within the company, and his voice is given a lot of weight. His projects almost always end up being trainwrecks that barely scrape by; he's more concerned with meeting the customers' requirements on paper and getting short-term revenue than delivering a useful product that can be maintained in the longer term.

And this especially is why you need to coordinate and document your work and interactions in projects - again you don't actively mention or say anything derogatory to him. However, if the problems escalate to his superiors, then you have a chance to protect yourself and the team - you "force" the "finger of blame" towards the one who actually needs to be blamed.

Again, these are just examples of how I handled my manager, and yours might not take quite as kindly to it. While my approach hasn't solved everything, it has made going to work that much more bearable.

You must log in to answer this question.

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