November 20, 2013 at 03:17Problems 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 the middle manager. In my opinion, the signature “from the sandbox” reflects not only the place from which this post came to the hub, but also the author’s place of work. I will reveal my thought.
To begin with, I would like to clarify that at one time I went from being a programmer to a boss, and went to various posts. Maybe my truth is due to the fact that it has always been small teams 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 ascent process is smoother and more gentle. Nevertheless, I want to note that not everyone works in megacorporations - rather the opposite.
I agree - a bid (a mistake in writing is special). Nevertheless, the problem is solved, as the author rightly pointed out in the first part, through coding. His project, a stranger - but do not care, in fact, whose exactly. But the second part was simply enraged. Anyone who came across while working with a customer who “I also coded” will understand me. If the work, code, its style and writing are not regulated by clear rules, accepted standards or internal orders of the company, move away from the developer! He is not obliged to write the code in a way that you like (again, the remark - “you” - is a general appeal, and not aimed at a specific author). He is required to write code so that it works. And all our addictions and requirements are just OUR vision of the code. And if it is a junior in whom you are afraid to find a structure of the form:
id = 0;
id ++;
id ++;
id ++;
then this should be monitored by someone who is presented to this person as a boss, but not a team leader.
And again, the author, under the correct heading, pushes through complete, excuse me, nonsense. To ask a programmer for a project or money for a birthday card is complete rubbish compared to what problems may actually arise. While you are a programmer, you have communication with team lead, code, TK as God's idea and occasionally - with those programmers with whom your code crossed due to the phase of the moon. When a bunch 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 is not right. But I didn’t break it. And the designer went crazy. And do it for 2 weeks. And I put on the deadline in a week. But 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. I don’t give a damn about TK. And I will not sign the act. And I’m visual, until I see - I won’t 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 didn’t you immediately lay down, if you now rewrite the floor of the project. And in general, 20 years ago I wrote labs in Pascal, so I will teach you how to work.
This, in my opinion, is a problem. Which is much more serious than going to the director for an extra fifty dollars to a cooperative.
I did not understand what this post was for. As practice shows, this is a problem for everyone. Well, generally all. At the programmer level - I did not have time to test, write, deploy, 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 arose, there were only two reasons - either the question of structuring the processes and fitting them to the already running “keep up to date” concept, or of understanding how this should work, was not at all.
Perhaps the only thing I would not argue with. Nerves leaves in direct proportion to the amount in the payroll. As one of the bosses once told me, “The more money, the more cockroaches in the team.”
Work with documents. This really becomes a problem when their size increases spasmodically. Everyone loves to write comments, right? Especially for the finished code? Every programmer in his heart relishes the sweet moment when you start to do the most difficult and important thing - to write comments on the code that appeared in just a minute of work, let’s think, with your left heel in the break between coffee and a cigarette. But irony is enough - even if documenting the code causes a clear gag reflex, then what to talk about when you need to write such rubbish by orders of magnitude more.
Work with the team.Already described, but I will dwell separately. You suddenly emerge, and you see that there are also programmers around. And - oh, horror! - they all write differently. Someone solves the problem this way, someone else. Whoever writes a bunch of code would be beautiful and elegant, but at the same time complete the task for 8 hours for 40, the other will solve the problem head on. The third is a crank oligophrenic who does not know how to write software at all, unlike the great guru of you. Even if this is not broadcast in the open, then one damn thing it climbs in the background, like worms. And with this you have to fight and strangle yourself. Moreover, all these people work at different speeds. Which at the same time also depends on external factors. Which, of course, is nonsense.
When you were programmers, such an explanation, if you didn’t get enough sleep, could be an excuse, and substantial, for your reduced speed. And when you became a leader - then what kind of Pokemon ?! The difference is difficult to understand and feel.
Worst of all, when you are thrown to a level in which you did not swim before. Were you writing business logic? But wait for you designer! Created Guy? Here you have a job with databases. And schnelle, schnelle! Time = money.
Responsibility for the result.Forget that there is an explanation why the function does not work. Forget what functions are. There is a product. It either works, and you are doing fine, honor, respect, and +2 cookies for tea, or it does not work. It is clear that almost anything can be justified. But the fact is primary - in the zone of YOUR responsibility there is NO result. There is progress, no result. It is necessary to change the paradigm of thinking.
OutsourcingSomewhat specific, but also found everywhere. Especially collapse - with freelancers. You will, albeit belatedly, find out about problems on the line with the provider in the city where the performer lives, about bad weather, about the health of a grandmother unknown to you, and if you are lucky, about a beautiful stranger and no less beautiful night. Maybe even with details, but it's not for everybody. And also you will learn how to learn to code in an unfamiliar language yourself in 2 hours to complete the task.
The financial issue is also not applicable to everyone, but still. You will learn the zen of balancing between the centuries of evolution advanced by the desire to fill up more reserves and physical reprisals for unrealistic budgets.
Colleagues problemYou need to be friends with colleagues. For beer, vodka, sausage - a herring. And in general, the atmosphere. And anyway - cover, I overslept. And if in the same team you go to the bosses, then it will be extremely difficult to do something with this team. It’s hard to get a head for an unfulfilled code from the one you covered for yesterday with the same bad, unflattering, incompetent, idiotic, mediocre bosses.
To summarize, there can be many problems. Maybe my list for someone seems short. Yes, and it seems to me short from the point of view of the leader - I still have a lot of factors hanging around that I could talk about. But at the same time, this is no longer the task of the middle manager. But what was written in the article is the greenhouse conditions. No options. Reality is more cruel, unpredictable, and most importantly - it is full of people. On which we must emphasize. Everything else is secondary.
Some lyrics
To begin with, I would like to clarify that at one time I went from being a programmer to a boss, and went to various posts. Maybe my truth is due to the fact that it has always been small teams 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 ascent process is smoother and more gentle. Nevertheless, I want to note that not everyone works in megacorporations - rather the opposite.
Remarks on the post of the author
I stopped creating
I agree - a bid (a mistake in writing is special). Nevertheless, the problem is solved, as the author rightly pointed out in the first part, through coding. His project, a stranger - but do not care, in fact, whose exactly. But the second part was simply enraged. Anyone who came across while working with a customer who “I also coded” will understand me. If the work, code, its style and writing are not regulated by clear rules, accepted standards or internal orders of the company, move away from the developer! He is not obliged to write the code in a way that you like (again, the remark - “you” - is a general appeal, and not aimed at a specific author). He is required to write code so that it works. And all our addictions and requirements are just OUR vision of the code. And if it is a junior in whom you are afraid to find a structure of the form:
id = 0;
id ++;
id ++;
id ++;
then this should be monitored by someone who is presented to this person as a boss, but not a team leader.
Communication with people
And again, the author, under the correct heading, pushes through complete, excuse me, nonsense. To ask a programmer for a project or money for a birthday card is complete rubbish compared to what problems may actually arise. While you are a programmer, you have communication with team lead, code, TK as God's idea and occasionally - with those programmers with whom your code crossed due to the phase of the moon. When a bunch 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 is not right. But I didn’t break it. And the designer went crazy. And do it for 2 weeks. And I put on the deadline in a week. But 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. I don’t give a damn about TK. And I will not sign the act. And I’m visual, until I see - I won’t 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 didn’t you immediately lay down, if you now rewrite the floor of the project. And in general, 20 years ago I wrote labs in Pascal, so I will teach you how to work.
This, in my opinion, is a problem. Which is much more serious than going to the director for an extra fifty dollars to a cooperative.
Keep up with everything on time
I did not understand what this post was for. As practice shows, this is a problem for everyone. Well, generally all. At the programmer level - I did not have time to test, write, deploy, 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 arose, there were only two reasons - either the question of structuring the processes and fitting them to the already running “keep up to date” concept, or of understanding how this should work, was not at all.
Nerves
Perhaps the only thing I would not argue with. Nerves leaves in direct proportion to the amount in the payroll. As one of the bosses once told me, “The more money, the more cockroaches in the team.”
Skipped
Work with documents. This really becomes a problem when their size increases spasmodically. Everyone loves to write comments, right? Especially for the finished code? Every programmer in his heart relishes the sweet moment when you start to do the most difficult and important thing - to write comments on the code that appeared in just a minute of work, let’s think, with your left heel in the break between coffee and a cigarette. But irony is enough - even if documenting the code causes a clear gag reflex, then what to talk about when you need to write such rubbish by orders of magnitude more.
Work with the team.Already described, but I will dwell separately. You suddenly emerge, and you see that there are also programmers around. And - oh, horror! - they all write differently. Someone solves the problem this way, someone else. Whoever writes a bunch of code would be beautiful and elegant, but at the same time complete the task for 8 hours for 40, the other will solve the problem head on. The third is a crank oligophrenic who does not know how to write software at all, unlike the great guru of you. Even if this is not broadcast in the open, then one damn thing it climbs in the background, like worms. And with this you have to fight and strangle yourself. Moreover, all these people work at different speeds. Which at the same time also depends on external factors. Which, of course, is nonsense.
When you were programmers, such an explanation, if you didn’t get enough sleep, could be an excuse, and substantial, for your reduced speed. And when you became a leader - then what kind of Pokemon ?! The difference is difficult to understand and feel.
Worst of all, when you are thrown to a level in which you did not swim before. Were you writing business logic? But wait for you designer! Created Guy? Here you have a job with databases. And schnelle, schnelle! Time = money.
Responsibility for the result.Forget that there is an explanation why the function does not work. Forget what functions are. There is a product. It either works, and you are doing fine, honor, respect, and +2 cookies for tea, or it does not work. It is clear that almost anything can be justified. But the fact is primary - in the zone of YOUR responsibility there is NO result. There is progress, no result. It is necessary to change the paradigm of thinking.
OutsourcingSomewhat specific, but also found everywhere. Especially collapse - with freelancers. You will, albeit belatedly, find out about problems on the line with the provider in the city where the performer lives, about bad weather, about the health of a grandmother unknown to you, and if you are lucky, about a beautiful stranger and no less beautiful night. Maybe even with details, but it's not for everybody. And also you will learn how to learn to code in an unfamiliar language yourself in 2 hours to complete the task.
The financial issue is also not applicable to everyone, but still. You will learn the zen of balancing between the centuries of evolution advanced by the desire to fill up more reserves and physical reprisals for unrealistic budgets.
Colleagues problemYou need to be friends with colleagues. For beer, vodka, sausage - a herring. And in general, the atmosphere. And anyway - cover, I overslept. And if in the same team you go to the bosses, then it will be extremely difficult to do something with this team. It’s hard to get a head for an unfulfilled code from the one you covered for yesterday with the same bad, unflattering, incompetent, idiotic, mediocre bosses.
To summarize, there can be many problems. Maybe my list for someone seems short. Yes, and it seems to me short from the point of view of the leader - I still have a lot of factors hanging around that I could talk about. But at the same time, this is no longer the task of the middle manager. But what was written in the article is the greenhouse conditions. No options. Reality is more cruel, unpredictable, and most importantly - it is full of people. On which we must emphasize. Everything else is secondary.