Is the behavior of the project manager in the described situation justified?

Question

Project management

I work as a tester in a small company. One day I came across this text:

...
Cross-competence down is a situation when a person is a specialist in one area, has achieved results in this field, and therefore considers himself competent in absolutely all areas that he puts below his competence. Example: when a manager thinks that if he manages an organization, then he knows how to build the work of a department better than the head of the department. (Sometimes this is true, but often it is cross-competence.)
...
Cross-competence up - the performer may believe that he is a good leader, and would have coped with the leadership of a department or company no worse, if not better, than the current leader. Practice proves that not always a good performer becomes a successful leader.

After reading, the thought does not leave me that something is wrong in my life: either I do not understand the specifics of the industry, or I have an endless streak of "interesting projects".
It seems to me that project managers who come across on the way climb into all matters, even where they do not need to meddle. I decided to speculate, but actually why? And he concluded: because ordinary workers have a clearly measurable result of work: written lines of code to fix bugs, executed test reports. And at the manager: talked to the customer... took an important call... sat in a meeting... so abstract, intangible
I will give examples:
- The first manager liked to tinker with the frontend and promoted his solutions on js instead of the solutions of his colleagues
- The second manager periodically (and unsuccessfully) fiddled with configuring php-fpm and nginx for the needs of the project, had an income from a pet-project on ruby ​​and littered with the phrases "how difficult it is with these people, unlike programs. Everything is simple with them: true or false, but with these..."
- The third manager was a former tech. writer. He reviewed the documentation, told juniors how to work with the database, and also combined the position of a test lead
- Now I'm in another office, a new manager... literally climbsin everything, like Julius Caesar. He "suggests" how to test, but from the outside the ideas look ridiculous. Check the validation of input values ​​less, do not go beyond the main scenarios (well, this can still be understood), operate only with objective quality criteria (sorry, of course, but if generally respected testing experts like Bach, Bolton, Weinberg declare the subjectivity of the concept of quality for each individual , but here ...), automate the project as much as possible so that testers do not pay attention to it in the future (the Ostap has already suffered; and who should support autotests? But what is not covered by them?). He can pick up the request hung on me, "check" (in a couple of minutes), and then complaints come from the customer. Half of what testers want to start is, in his opinion, "not a bug, but a feature." Cuts the terms for the test lead to the minimum. Makes cynical jokes about bugs that I would consider acceptable at most for anonymous comments on the same resource with a .it domain. Regarding development, he has his own clear ideas about what technologies are true and what is not true. Estimation of deadlines, realism of implementation, man-hours - isn't it teamlead's business? As it turned out, no. The UX design department is overwhelmed by his visions of good design, according to articles from Habr. At the same time, only the backend is hired in the development, there are no programmers dedicated to the frontend. People who are able to optimize database queries, who understand the intricacies of orm and nginx settings, should delve into js-noodles like small children, making 2-3 other bugs for each edit, for which testers will be rewarded later. Makes cynical jokes about bugs that I would consider acceptable at most for anonymous comments on the same resource with a .it domain. Regarding development, he has his own clear ideas about what technologies are true and what is not true. Estimation of deadlines, realism of implementation, man-hours - isn't it teamlead's business? As it turned out, no. The UX design department is overwhelmed by his visions of good design, according to articles from Habr. At the same time, only the backend is hired in the development, there are no programmers dedicated to the frontend. People who are able to optimize database queries, who understand the intricacies of orm and nginx settings, should delve into js-noodles like small children, making 2-3 other bugs for each edit, for which testers will be rewarded later. Makes cynical jokes about bugs that I would consider acceptable at most for anonymous comments on the same resource with a .it domain. Regarding development, he has his own clear ideas about what technologies are true and what is not true. Estimation of deadlines, realism of implementation, man-hours - isn't it teamlead's business? As it turned out, no. The UX design department is overwhelmed by his visions of good design, according to articles from Habr. At the same time, only the backend is hired in the development, there are no programmers dedicated to the frontend. People who are able to optimize database queries, who understand the intricacies of orm and nginx settings, should delve into js-noodles like small children, making 2-3 other bugs for each edit, for which testers will be rewarded later. it As far as development is concerned, he has his clear ideas of what technologies are true and what are not true. Estimation of deadlines, realism of implementation, man-hours - isn't it teamlead's business? As it turned out, no. The UX design department is overwhelmed by his visions of good design, according to articles from Habr. At the same time, only the backend is hired in the development, there are no programmers dedicated to the frontend. People who are able to optimize database queries, who understand the intricacies of orm and nginx settings, should delve into js-noodles like small children, making 2-3 other bugs for each edit, for which testers will be rewarded later. it As far as development is concerned, he has his clear ideas of what technologies are true and what are not true. Estimation of deadlines, realism of implementation, man-hours - isn't it teamlead's business? As it turned out, no. The UX design department is overwhelmed by his visions of good design, according to articles from Habr. At the same time, only the backend is hired in the development, there are no programmers dedicated to the frontend. People who are able to optimize database queries, who understand the intricacies of orm and nginx settings, should delve into js-noodles like small children, making 2-3 other bugs for each edit, for which testers will be rewarded later. according to articles from Habr. At the same time, only the backend is hired in the development, there are no programmers dedicated to the frontend. People who are able to optimize database queries, who understand the intricacies of orm and nginx settings, should delve into js-noodles like small children, making 2-3 other bugs for each edit, for which testers will be rewarded later. according to articles from Habr. At the same time, only the backend is hired in the development, there are no programmers dedicated to the frontend. People who are able to optimize database queries, who understand the intricacies of orm and nginx settings, should delve into js-noodles like small children, making 2-3 other bugs for each edit, for which testers will be rewarded later.
At the time of studying at the university, I had an understanding that PM is needed for negotiations with customers and for transmitting the thoughts of top management to us in a form understandable to mere mortals. Why can't you just entrust these matters to department heads, and if they mess up, then find more competent leads? Am I "cross competency up" or is the above abnormal?

Answer 1

As I understand it, the question is more rhetorical than requiring a practical solution or code review) So to speak, the cry of the soul that left the comfortable body) We swam, we know.
If you need an answer - PM is mostly asshole, stupid and has an overestimated heart rate, suffers from Dunning-Kruger syndrome (it is an effect, but these people suffer from itclearly). Due to the fact that there is no such profession as such, these people are engaged in broadcasting from "Make Schaub beautiful" to "We need to make everything up on the bootstrap in flat design, we will make a spa." That is, either incompetent developers, who realized the futility of their efforts in the field of development, or vice versa, middle managers from MVideo, who realized the coolness of modern technologies, but, again, do not pull on the developer. Some part chose this direction consciously and responsibly, there are few of them, but they exist, they are pulling the project, they are well versed in people and planning, in short, a kind of Charlie's guardian angels of the company. The species is rare, disappearing, listed in the Red Book.

Answer 2

To be honest, it's not very normal. But you do not work for relationships, but for money. Therefore, it turns out that just the same you climb into the affairs of the manager, and not he into yours. A little hint for further reasoning)

Answer 3

I deduced for myself a long time ago: a good boss can always be a good subordinate, a good subordinate can not always be a good boss.
Because the boss is aware of what subordinates should be in order for the office to work like clockwork, he saw them from above, he led and knows all the rakes and problems, the subordinate is always a performer, but he thinks that he knows better. Each has its own area of ​​responsibility.
The programmer is responsible for his code, the manager for how he understood the customer and what he proposed for implementation. The manager sees the project from above, he has an understanding of how everything should look. The manager set the task, he sees the whole project, he knows what he wants. If he climbs to the encoder to tell how the classes should be connected and what patterns to use, then this is not his area of ​​​​responsibility, but if the proger starts telling whether to do a spa or not, then this is not his business.
Everyone gets a hat for their work. If the manager said, we will do a spa, and this doubled the development price, but the customer doesn’t care, and it’s not indicated in the technical specification, then the manager will get a cap, so the proger should not be interested in this. If there are bugs on the page, then the question is to the competence of those who coded, and this is not the fault of the manager.
In general, my advice: do not worry about what the manager does, worry about the tasks for which you are responsible.

Answer 4

that PM is needed to negotiate with customers and to translate the thoughts of top management to us in a form accessible to the understanding of mere mortals.

now it was a shame (
In general, all 4th PMs are afraid of delegation, and when a PM sits down to do something instead of developers, it's unfortunate.
Expressions from PMs like "Not a bug but a feature" and cutting deadlines \ cutting down some kind of testing = in 90% the dude was just given a project with burning deadlines and he is looking for ways to meet these deadlines, so I would only call him "half-asshole"

Answer 5

All this is done, in my opinion, from idleness and a lot of free time for the PM.
The PM should have the main tasks:
1. organize the development process;
2. control over the development time of software versions;
3. DELIVERY OF THE DEVELOPED PROGRAM TO THE CUSTOMER: registration (or organization of this), RECEIVING, SIGNING ALL NECESSARY DOCUMENTS JUST ON TIME.
4. SOLUTION OF ALL POSSIBLE PROBLEMS AND POTENTIAL PROBLEMS WHEN DELIVERED BY THE CUSTOMER FOR THE PURPOSE OF SEE. P.3.
It’s just with paragraphs 3-4 that the PM often has problems, they need to deal with this. It seems like there are job descriptions even on the Internet with a description of what the PM should do.
Note: I read one article, which once said that often former specialists (including developers), becoming a manager, cannot quit (realize) their previous activities. And often because of this, the company suffers, incl. in terms of financial results.
How to solve a similar problem, how to "prompt" the PM about this, so that later it doesn’t backfire at the moment I can’t imagine)

Answer 6

At the time of studying at the university, I had an understanding that PM is needed for negotiations with customers and for transmitting the thoughts of top management to us in a form understandable to mere mortals.

It may well be combined with a team lead.

Answer 7

Oh how I envy you