When you work as a developer, all the time you see how team leads sit on a heap of calls, are responsible for everything, write as much code as you do, and at the same time they have no more money. Either ideological or idiots will go for this.
I'm not an idiot, my ideas don't revolve around business values, so you won't subscribe to me. But we are not always asked about this. First, I was hired as the first and only developer in a reborn startup, then they told me to hire more people, and then I found myself in charge of three developers, two testers and one analyst.
In short, everything is even worse than it looked from the outside.
Six people every day are waiting for you to tell them what to do, then you will tell them how to do it, and then you will also evaluate whether you did well. The seventh person at the end of the day will also ask what you did yourself. In the sense that you coded yourself, and what each of the people for whom you are responsible did.
I here once complained that the calls are a crutch that allows you to control without delving into, and now I am once again convinced that I was right. They come to me with a question - and I have no idea what to answer. We call each other, and a person elicits an answer from my unfortunate brains without my participation. I am also not ready to formulate my questions - I have no idea what to ask them. So I just call and watch how everything settles itself out. And even better - I make sure that they phoned each other, without me at all. For a month now I have not been able to close a fairly simple task, because my brain is exhausted from managerial duties, and most of all from the fact that I do not know how to perform them.
I thought, okay, that's the way it should be. I didn't study to be a manager. Then I looked at my past, remembered all my leads, and suddenly I realized - no one studied! None of them knew how to manage. They also masked it with endless calls and procrastination. They didn't know what to answer me, they didn't know where we were going, they didn't know what was going on at all, and who was doing what.
When I was doing a simple task for two months, and every day I was lying that I had great difficulties, and there was a serious problem there - and then I made a pull request for four files sketched overnight - no one scolded me, not because they were sorry. They just had no idea what I was doing there. And they looked at my code line by line - to get to the bottom of the naming and find juicy anti-patterns - but not delve into it. Because there is no time to delve into, I do not want to, and it is not clear why.
All my previous bosses have embraced and idolized agile - it's one big set of crutches, a game that helps a bunch of people who have no idea what's going on to pretend that everything is fine and we are moving forward.
I worked with homegrown provincial team leaders, who in serious teams would not even be admitted to layout, I worked with cool development managers from top foreign companies, worked with people whom someone considered to be real geniuses in programming.
And all of them, when it came to management, sat on the ass. I learned the rules of this game in my first job with agile. We called each other every morning, and everyone said what they had done, were doing and would be doing. At the first such call, I came with the idea that I should report and prove that I am not eating my bread in vain. I began a long, very long speech about my task, explained in detail why it was not ready yet, and what I am struggling with now. I was cut off in the middle: “Phil, do you want anything from us? No? Okay, we all figured out who's next? "
The person who controlled us needed to know only one thing - whether I would throw problems for him for today, or not. Does he have to spend time with me today. Before I began to speak, he already had the perfect speech in his head for me: "everithin gous akordin that plan." Any other development of events for him is pure evil.
There is another option. When the problem was brought to him not by me, but by other parts of the system, the agile schedule is rotten, and now he cannot say at his meeting for leads that everything is going according to plan - and also becomes someone's problem. This automatically makes me his problem, and he knocks on the PM.
We start discussing something, and we both understand - we need to find a way to stop being problems. It has nothing to do with the product or project. We have a fucking ticket that we need to move. And we move it - in the simplest way available. We fix it with the code, put it in the norepro, put the label “blocked by” - whatever. At this moment, we absolutely do not give a damn about the product, we have a ticket. Or a lot of tickets.
There were two realities in any team where I worked. One reality is a real product, and real people who improve it because they want to. And then there was jira, which exists absolutely parallel to all this. And the only person who can synchronize the real state of the project with the cards is the team lead.
All the team leaders I worked with don't know how to do it - and they don't want to. They work as they work, and they use jiru to consider their managerial responsibilities fulfilled. After all, people who evaluate team leads look at jira, not at the product. And people who look at the product can only generate new tickets for the jira. They cannot evaluate programmers. But jira does not affect anything! I've seen horrible products that had their kanban board in perfect condition, and great products that had tickets in the “at work” column for three months with the title “make a project”.
The “I saw” argument is not very good, but it will do, because I'm pretty sure you saw it all too.
In a broad sense, a team lead should make sure that people who really want to work don't have any problems. And people who do not want to either kick out or be transferred to the first category. The whole pain of management lies in the second - there are many more. And nobody does anything with them. Only a developer can adequately determine whether a developer works well. This is a very understandable story - you need to thoroughly review his pull requests and delve into his tasks, and there is one problem - it eats as much time as it would cost to do everything yourself. In short, not an option.
Therefore, it was pure managers, not developers, who decided to identify bad developers. They came up with a bunch of systems with tickets, charts, all sorts of performance reviews and such a hat. And it would even work, on some dumb ones. But even the worst of the developers are intelligent enough to fool this system. Well, you know how it's done. They measure everything in tickets, right? Cool. I will decompose the "redesign the interface of the X form" into ten tasks in the style of "fix the label in the Y button". The same amount of work, more tickets. The team lead would kick me in the face for such feints.
But in the current system, he will never do that. After all, firstly, the more tickets are closed, the less problems it has. Secondly, it is itself loaded enough to dig into my tickets and my code. Thirdly, he does it himself - because because of his Leadership duties, he also lacks the strength to perform well. And fourthly, and this is the most important thing, he may well be one of those people who do not want to work.
This is my experience, the experience of all my acquaintances - but it has exceptions. There are companies where the development process really works great. I'll tell you why - they won the lottery. They turned out to have a lot more people who want to work - with people like you do not manage, everything will go well. They even use managerial tinsel with boards for business, and their performance is clearly visible both by jir and by intuitive metrics. And when their non-developed managers come to get in the way, they have a great product behind them that gives them the right to send these talking heads to hell.
Such teams are self-replicating - during the hiring process, they intuitively approve only people like them, and they have enough weight in the company not to give decisive words to HRs who play their “metrics” and psychology.
But such a team is fantastic luck. And what usually happens is this. For ten people, you have two who want to work. One of them is a team lead, and the other quits. The development works poorly, and managers come to fix it. And from that moment on, there will be no chance. Managers will build a process around jira, take control of things they don't understand at all. They will build a hiring of people whose work they don’t know a damn thing about, they will start inviting existing developers there who will amuse ChSV, log this time into the time report, and give random feedback. And then they decide who to hire - also randomly. People who want to work will from time to time get into such teams, where they will either turn into idlers or will not take root.
I don't mean that managers are idiots and they can't do anything. They still know how to manage. But not by developers. Developers can only be controlled by a developer who really knows how to manage. Such a person will fix the team with any ratio of willing and unwilling to work.
The only pity is that they almost do not exist. To become a good developer, you need to be smart and learn a lot. To become a good manager, you need to have talent and a lot of learning. And what then is the chance that one person will combine these two qualities? That's the same. At the same time, most of the team leaders in the industry became them, because, well, someone should. Absolutely random.
I think you need to learn to understand that development is one skill, management is the second skill, and development management is the third skill that includes parts of the first. And this should be studied separately. And very methodically and efficiently. Until we do this, we will have developers who cannot manage developers, and managers who cannot manage developers.
Advertising
Many customers have already appreciated the benefits of Vdsina's epic servers .
These are inexpensive VDS with AMD EPYC processors, CPU core frequency up to 3.4 GHz. The maximum configuration will allow you to realize almost any idea - 128 CPU cores, 512 GB RAM, 4000 GB NVMe. You can also order!
