Problems of transition to middle managers - are these problems?
Good day. This post appeared as an answer to this post , which describes the problems of transition to a middle manager. In my opinion, the signature "from the sandbox" reflects not only the place where this post came from, but also the place of work of the author. I will reveal my thought.
To begin with, I would like to clarify that I once went from a programmer to a boss, and visited various posts. Maybe my truth is due to the fact that these have always been small groups and small companies (in terms of the number of employees, and not in terms of turnover). Therefore, I can assume that such a short list was born only because the author works in a large company, where the process of climbing is smoother and more gentle. Nevertheless, I want to note that not everyone works in megacorporations - rather the opposite.
I agree - bida (spelling error is special). Nevertheless, the problem is solved, as the author rightly pointed out in the first part, through coding. Own project, someone else's - yes, don't care, in fact, whose exactly. But the second part just got mad. Anyone who has encountered while working with a customer who is “I also coded” will understand me. If the work, the code, its style and writing are not governed by clear rules, accepted standards or internal instructions of the company - get away from the developer! He is not obliged to write the code in such a way that you like it (again, the remark “you” is a general appeal, and not directed at a specific author). He is obliged to write code so that it works. And all our preferences and requirements - just our vision of the code. And if this is a junior, where you are afraid to find a structure of the form:
id = 0;
id ++;
id ++;
id ++;
then this must be followed by one who is represented to this person as a boss, but not a Timlid.
And again the author under the correct title pushes the full, sorry, nonsense. To ask a programmer for a project or money for a birthday card is a complete nonsense compared to what problems can really arise. While you are a programmer, you have communication with a team leader, a code, TK as a divine thought, and occasionally - with those programmers with whom your code crossed due to the moon phase. When a handful of people are subordinate - this is the main problem. Vary the vector depending on whether you are communicating with the customer or not.
')
I wrote the code like this. And here I am. And he's not right. And I did not break it. And the designer went crazy. And do it for 2 weeks. And I put on the deadline in a week. And the architect was wrong. And here it was necessary like this. And the database is not correct. And let's guides indexes.
Few? There is also a customer.
And here it should be so. And here it is. And I do not care for TK. And I will not sign the act. And I visual, until I see it - I will not say how it should work. And here you need a button. And I do not care what to rewrite the floor of the project. And you are deceiving me. And why you did not immediately laid, if now the floor of the project is rewritten. And in general, I wrote labs on pascal 20 years ago, I will teach you how to work.
This, in my opinion, is a problem. Which is much more serious than approaching the director for more than fifty thousand dollars per cooperative.
Generally did not understand what this post is about. As practice shows, this problem is all. Well, actually everyone. At the programmer level, it did not have time to test, write, embed, document, and so on. These problems are always and everywhere. Micro- and macro-management work according to similar rules. If the author is ready - I can argue on this topic. And if such problems have arisen, then there are only two reasons - either the question of structuring the processes and fitting them to an already working "to be on time" concept, or - there was no understanding how this should work.
Perhaps the only thing with which I would not argue. Nerves goes in direct proportion to the amount in the payroll. As one of the chiefs once told me - “The more money, the more cockroaches in the team”.
Work with documents. It really becomes a problem when their size increases in steps. Everybody likes to write comments, right? Especially to the finished code? Each programmer in the shower relishes that sweet moment when you begin to perform the most difficult and important thing - to write comments on the code that appeared in just a minute of work, but think about it, with your left heel in between coffee and cigarette. But enough of the irony - even if documenting the code causes a clear gag reflex, then what to talk about when you need to write a lot more of this rubbish.
Work with the team. Already described, but I will stop separately. You suddenly emerge, and you see that programmers are around too. And - oh, horror! - they all write in different ways. Someone solves the problem like this, someone else. Who writes a bunch of code, if only it was beautiful and elegant, but at the same time it performs a task for 8 hours during 40 hours, the other solves the problem head-on. The third is Krivogteter oligophrenic, who does not know how to write software correctly, unlike the great guru of you. Even if it is not broadcast in the open, then one hell it climbs implicitly, like worms. And this has to be fought and strangled. Moreover, all these people work at different speeds. Which at the same time also depends on external factors. Which, naturally, nonsense.
When you were programmers, such an explanation, how you didn’t get enough sleep, could be an excuse, and a significant one, for your reduced work speed. And when you became a leader - what a pokemon ?! Difference is difficult to understand and feel.
Worst of all, when you are thrown to a level in which you have not swam before. Did you write business logic? And on-ka you designer! Creati guy? Here's a job with databases. And Schnell, Schnell! Time = money.
Responsibility for the result. Forget about explaining why the function doesn't work. Forget what functions are. There is a product. He either works, and you are well done, honor, respect, and +2 cookies for tea, or - does not work. It is clear that you can justify almost anything. But the fact is primary - in the area of ​​YOUR responsibility there is NO result. There is progress, there is no result. It is necessary to change the paradigm of thinking.
Work with outsourcing Somewhat specific, but also found everywhere. Especially the collapse - with freelancers. You will, albeit belatedly, find out about the problems on the line with the provider in the city in which the performer lives, about the non-flying weather, about the health of your unknown grandmother, and if you're lucky - about a beautiful stranger and a no less beautiful night. Maybe even with the details, but this is an amateur. And you will learn how to learn to code yourself in an unfamiliar language in 2 hours to complete the task.
The financial question Is also not applicable to everyone, but still. You will know the Zen of balancing between the developed centuries of evolution desire to grab more reserves and physical violence for unrealistic budgets.
The problem of colleagues You have to be friends with colleagues. For beer, vodka, sausage - herring. And in general, the atmosphere. And in general - cover, I overslept. And if in the same team you go to the heads, then it will be extremely difficult to do something with this team. It is difficult to get on the head for the unfulfilled code from someone whom you covered yesterday in front of the same bad, flimsy, incompetent, idiotic, incompetent authorities.
To summarize, there may be a lot of problems. Maybe my list for someone seems short. Yes, and it seems to me to be short from the point of view of the manager - I still have a lot of factors that I could tell about. But at the same time it is no longer the task of the middle manager. But what was written in the article is greenhouse conditions. No options. The reality is more cruel, unpredictable, and most importantly - it is full of people. On which to focus. All the rest is secondary.
Some lyrics
To begin with, I would like to clarify that I once went from a programmer to a boss, and visited various posts. Maybe my truth is due to the fact that these have always been small groups and small companies (in terms of the number of employees, and not in terms of turnover). Therefore, I can assume that such a short list was born only because the author works in a large company, where the process of climbing is smoother and more gentle. Nevertheless, I want to note that not everyone works in megacorporations - rather the opposite.
The author's postmarks
I stopped creating
I agree - bida (spelling error is special). Nevertheless, the problem is solved, as the author rightly pointed out in the first part, through coding. Own project, someone else's - yes, don't care, in fact, whose exactly. But the second part just got mad. Anyone who has encountered while working with a customer who is “I also coded” will understand me. If the work, the code, its style and writing are not governed by clear rules, accepted standards or internal instructions of the company - get away from the developer! He is not obliged to write the code in such a way that you like it (again, the remark “you” is a general appeal, and not directed at a specific author). He is obliged to write code so that it works. And all our preferences and requirements - just our vision of the code. And if this is a junior, where you are afraid to find a structure of the form:
id = 0;
id ++;
id ++;
id ++;
then this must be followed by one who is represented to this person as a boss, but not a Timlid.
Communication with people
And again the author under the correct title pushes the full, sorry, nonsense. To ask a programmer for a project or money for a birthday card is a complete nonsense compared to what problems can really arise. While you are a programmer, you have communication with a team leader, a code, TK as a divine thought, and occasionally - with those programmers with whom your code crossed due to the moon phase. When a handful of people are subordinate - this is the main problem. Vary the vector depending on whether you are communicating with the customer or not.
')
I wrote the code like this. And here I am. And he's not right. And I did not break it. And the designer went crazy. And do it for 2 weeks. And I put on the deadline in a week. And the architect was wrong. And here it was necessary like this. And the database is not correct. And let's guides indexes.
Few? There is also a customer.
And here it should be so. And here it is. And I do not care for TK. And I will not sign the act. And I visual, until I see it - I will not say how it should work. And here you need a button. And I do not care what to rewrite the floor of the project. And you are deceiving me. And why you did not immediately laid, if now the floor of the project is rewritten. And in general, I wrote labs on pascal 20 years ago, I will teach you how to work.
This, in my opinion, is a problem. Which is much more serious than approaching the director for more than fifty thousand dollars per cooperative.
All have time on time
Generally did not understand what this post is about. As practice shows, this problem is all. Well, actually everyone. At the programmer level, it did not have time to test, write, embed, document, and so on. These problems are always and everywhere. Micro- and macro-management work according to similar rules. If the author is ready - I can argue on this topic. And if such problems have arisen, then there are only two reasons - either the question of structuring the processes and fitting them to an already working "to be on time" concept, or - there was no understanding how this should work.
Nerves
Perhaps the only thing with which I would not argue. Nerves goes in direct proportion to the amount in the payroll. As one of the chiefs once told me - “The more money, the more cockroaches in the team”.
Missed
Work with documents. It really becomes a problem when their size increases in steps. Everybody likes to write comments, right? Especially to the finished code? Each programmer in the shower relishes that sweet moment when you begin to perform the most difficult and important thing - to write comments on the code that appeared in just a minute of work, but think about it, with your left heel in between coffee and cigarette. But enough of the irony - even if documenting the code causes a clear gag reflex, then what to talk about when you need to write a lot more of this rubbish.
Work with the team. Already described, but I will stop separately. You suddenly emerge, and you see that programmers are around too. And - oh, horror! - they all write in different ways. Someone solves the problem like this, someone else. Who writes a bunch of code, if only it was beautiful and elegant, but at the same time it performs a task for 8 hours during 40 hours, the other solves the problem head-on. The third is Krivogteter oligophrenic, who does not know how to write software correctly, unlike the great guru of you. Even if it is not broadcast in the open, then one hell it climbs implicitly, like worms. And this has to be fought and strangled. Moreover, all these people work at different speeds. Which at the same time also depends on external factors. Which, naturally, nonsense.
When you were programmers, such an explanation, how you didn’t get enough sleep, could be an excuse, and a significant one, for your reduced work speed. And when you became a leader - what a pokemon ?! Difference is difficult to understand and feel.
Worst of all, when you are thrown to a level in which you have not swam before. Did you write business logic? And on-ka you designer! Creati guy? Here's a job with databases. And Schnell, Schnell! Time = money.
Responsibility for the result. Forget about explaining why the function doesn't work. Forget what functions are. There is a product. He either works, and you are well done, honor, respect, and +2 cookies for tea, or - does not work. It is clear that you can justify almost anything. But the fact is primary - in the area of ​​YOUR responsibility there is NO result. There is progress, there is no result. It is necessary to change the paradigm of thinking.
Work with outsourcing Somewhat specific, but also found everywhere. Especially the collapse - with freelancers. You will, albeit belatedly, find out about the problems on the line with the provider in the city in which the performer lives, about the non-flying weather, about the health of your unknown grandmother, and if you're lucky - about a beautiful stranger and a no less beautiful night. Maybe even with the details, but this is an amateur. And you will learn how to learn to code yourself in an unfamiliar language in 2 hours to complete the task.
The financial question Is also not applicable to everyone, but still. You will know the Zen of balancing between the developed centuries of evolution desire to grab more reserves and physical violence for unrealistic budgets.
The problem of colleagues You have to be friends with colleagues. For beer, vodka, sausage - herring. And in general, the atmosphere. And in general - cover, I overslept. And if in the same team you go to the heads, then it will be extremely difficult to do something with this team. It is difficult to get on the head for the unfulfilled code from someone whom you covered yesterday in front of the same bad, flimsy, incompetent, idiotic, incompetent authorities.
To summarize, there may be a lot of problems. Maybe my list for someone seems short. Yes, and it seems to me to be short from the point of view of the manager - I still have a lot of factors that I could tell about. But at the same time it is no longer the task of the middle manager. But what was written in the article is greenhouse conditions. No options. The reality is more cruel, unpredictable, and most importantly - it is full of people. On which to focus. All the rest is secondary.
Source: https://habr.com/ru/post/202754/
All Articles