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.
