10 project managers from Hell

10 project managers from Hell

Recently, Vlad Balabash  (FrontEnd Developer, AB Soft) and his colleague Kostiantyn Kulaksiz held an online meeting in IAMPM to talk about the PMs’ types that “do not annoy developers too much”.

We took notes on the most intriguing profiles and are happy to share them with you.

No hate speech!

Only instrumental tips on optimizing the working process, including shaping the requirements and interaction with the team and customers!

Dunno-man

This type of manager doesn't have a clue how to formulate tasks, what their evaluation criteria are, and what AC and DoD could possibly mean. With such an expert, the developers usually have to fit into the frames that are too abstract and extended.

A savvy PM detailizes the tasks from day one and adjusts settings for a task-tracker correctly.

Estimate-man

You can face such managers at strictly framed projects. They demand to estimate the time for every baby step and are very sensitive to any departures from original estimates.

There is only one tip here: work on flexibility, as it is very instrumental when projects with tough frameworks are implemented.

Meeting-man

With such a manager, you have little to no time left for actual work. Meeting-man calls up meetings on any trivial pretext. This guy, for instance, can derange an entire team from urgent matters only to make them present at the meeting that is only relevant for developers and testers.

Meanwhile, experienced PMs give clear reasons to gather the team together and are good at time management.

Incognito

This manager is not involved in the process, so the communication between a developer and customer has no mediators.

I suggest only one thing here: the manager should be in touch during office hours and maintain close communication with the customer, responding quickly to all significant issues.

Let’s-do-it-this-way-man

The developers are not happy when the managers put pressure on them, telling them what technologies they should use.

The manager can help select one or participate in the discussion, but their say regarding technical issues should be advisory rather than the last one.

Jira-man

Such a manager has Jira, and anarchy rules there: processes, filters, and labels are not adjusted.

Don't forget that even though developers and other team members should know how to use Jira, this tool is for managers in the first place. So, it is the manager's responsibility to adjust the settings for the team and keep the tool in order.

Yes-sure-man

This manager always sides with the customer and takes on all their tasks without any prior coordination with the team.

The solution to this problem is communication. Talk! No prior approval leads to conflicts as the manager sometimes gives the green light to the customer's idea the developers cannot fulfill.

Task-man

This person can’t evaluate how complex a task is and how much time it will take. Such managers often distribute the tasks among the teams in an unbalanced manner. A Junior gets complex tasks, while the Senior is assigned simple ones.

Within large projects, the following solution is used for such cases. They hire product owners who are in charge of several developers. The product owners know the developers very well, including their preferred technology. It smoothes the way to a balanced distribution of tasks.

Dodo-man

This person is nowhere near management but was appointed to this position. Without essential competencies, he or she acts illogically and inconsistently.

There are many Project Management courses these days, so you always have an opportunity to get an idea about the qualifications you may need when taking over a novel position.

Copy-paste-man

This manager does not bother creating new tasks - they paste the customer's description of those.

A perfect manager plays several roles simultaneously - he or she is a leader, mentor, and sometimes a translator. They must interpret the customer's wishes and requirements correctly. So, they have to be ultimately clear when announcing tasks to their colleagues.

Thanks for reading the article to the end.

Best of luck with working with your team!