Congratulations - you are a new manager! No, honestly, with all my heart. Do you hear sarcasm in your voice? Well, excuse me, I tried as best I could, but of course, with anxiety there is some doubt and sadness. You will probably have to go through everything that I and many others went through. You worked as a software engineer for many years (or put another profession in here), you showed yourself well, deserved the title of “senor” and you were considered an informal leader in the team. Probably, up to the present moment they were timlid. Perhaps for some time they even resisted this “increase”, did not want to leave programming, lose their skills. But in fact, they were afraid that they would not cope. Finally, somehow you were persuaded to take the risk - and here you are. From the leading engineer to the novice manager.

How to succeed in a new role? How again to go through all the steps and achieve such a level of results and confidence that everyone expects, especially yourself? Hundreds of books and thousands of blogs are trying to find these answers, so I won’t pretend that I have the secret to success. But I know several ways that absolutely guarantee you a failure.

1. Continue programming

Surely the storm will rise in the comments. Your company can expect managers to continue to program in part, working in two ways. My experience and the experience of many others seem to say that this is usually the path to nowhere. It’s impossible to sit on two chairs and pay enough attention to each of the two jobs, so you will fail in both. If you are lucky with the company, then you will be forced to almost sign a cessation of programming.
')
Okay, even if you are partly expected to write code, this is definitely not the main task now. The point is that your attempts to program talk about uncertainty about what to do in your new role. Therefore, you turn to work that is familiar and convenient. This can bring short-term benefits in some projects and give you a feeling of comfort, but I guarantee that you are moving away from your main goals. You harm the long-term result of the team and also do not grow in the new profession.

It is unlikely that someone will want to take and abandon the valuable and hard-earned technical experience. This article provides some good options for managers who want to keep programming practice.

2. Focus only on work, not on people

The manager has two important responsibilities: to develop the team and bring benefits to the business. And I would say that priorities should be placed in that order. The first strengthens the second.

A typical picture of effective work is the completion of projects, the release of functions, the correction of errors, etc. And if you managed to avoid the trap of the “lead programmer” and avoid daily programming, then you somehow try to satisfy the usual need for daily tasks to get it sense of utility. This often leads to a situation where a person acts as a project manager or supervisor: assigns tickets, tracks metrics, requests status updates, discusses architecture, keeps history, and so on. In short, focused on work . Every day you tick the list and feel that things are progressing.

And there is. But this is only half the job. Light half. Because the other half is more difficult, it is unlike what you did before and probably this is where you most lack experience. This is the growth of your team. Helping people grow not only technically, but also in productivity. Look for ways to improve interaction. Talk one-on-one, listen, train. It turns out that these "easy" lessons are the hard part. And if you ignore it, then block most of the performance. You will achieve the result, but it will be far from the maximum potential of the team. You will show an increase in efficiency, but not true progress. You will never seriously raise the bar - and you will not know why.

The effectiveness of the team begins with the employees themselves, and not with their work.

3. Evaluate your performance value

In the past, as a separate employee, it was easy for you to evaluate the performance of work: “today I implemented two functions”, “fixed this crazy bug”, “all tests passed”. These are tangible work units tied to group results. And your name is in commits. It is easy to see the work of a particular employee and evaluate it by how closely the result brings the team closer to their goals.

But now most of your influence is in second order effects. They are more difficult to relate to the work of the team. Confusion adds that your work is no longer formalized in a clear list. You are not even sure that you are doing any “work”.

Therefore, as a new manager, you usually grab a few specific tasks - and do them in order to achieve a sense of completeness, benefit. In this case, probably overestimating the actual importance of these tasks. Presentations, budgets, status reports, Scrum artifacts - this can be counted, but this is not work. In fact, your work is determined by the achievements of the team. Their achievements are the main goal. Ultimately, your value is measured by their success. Focus on the team and on what they need to succeed.

4. Do not talk about their expectations.

You clearly formulated for yourself what you expect from the team? From each person? Did you tell them?

It’s quite natural for us to think that the mind of another person works just like ours. That we have the same discipline, motivation and logic. And this leads to many assumptions. If we are looking at the same set of tasks with the same specifications, then naturally we must come to the same conclusions as when this work will be done. Oh well. So we distribute tasks with a certain amount of information, but with unspecified and implied expectations. And you know what happens in such cases.

When assigning a task, be sure to agree on the assumptions and expectations.

“Just don't forget to document your findings and then review them with the team before writing some code.”

“This story blocks QA, so this is your top priority. I assume that you need 30 minutes to pause the current work. If the story cannot be done before the end of the day, let me know as soon as possible. ”

It is much more difficult to formulate subconscious expectations - those that you are not conscious of until they are violated. This is your personal decision making model, how would you do it. You just assume that it will be so. But of course, you have not formulated them, and when the result does not match, you will be disappointed in others. It is very demotivating and demoralizing the team. If you have expectations regarding their work, it is better to report it. You can not force to guess. And if you are not confident in your expectations, then take the time - understand yourself and understand them. This is your job, your responsibility to the team, and probably your boss’s expectations.

5. Refuse from obligations

You are the new manager and you want to impress the boss. “Of course we can do it,” yes, yes, yes. To give promises that the team will not be able to fulfill. I am sure most of us were on the other side. You are given unrealistic deadlines and tasks for which you have never agreed. What do you think about your boss? Of course, the team can unite and give the impossible, but I am sure that the story will not end there. Your boss now looks great - and just keeps making the same promises. Pretty soon, the team is running out of patience, people began to quit, move to other teams or leave the company altogether.

It's hard to go against the current, but you have to stop it. Need to protect the team. How to do it? For starters, don't be a hero. Do not immediately answer “yes” to any request from a boss, customer or business partner. Win some time and get the team involved in the commitment. As far as possible, show the employees the big picture. Why is this important to the company? How will affect customers? What is actually being asked of us? And most importantly, involve the team in the decision: “Given all the information, how do you think we can do?”

Sometimes you have no choice but to take and give orders, but it is much better if the team is involved in the discussion.

6. Confuse command with leadership

Becoming a chair and giving out orders is not leadership. It often happens that the manager coordinates the work and distributes tasks. But do not confuse this with leadership. Reinforced distribution of commands is often a symptom of what we call micromanagement — this leads to the fact that teams lose their ability to work autonomously. Employees are waiting for all decisions to come from you. And in the end you will become a bottleneck for the team. You have created an inefficient group that simply performs familiar movements, expects the next task and mindlessly performs it.

The leader is inspiring, not commanding. He draws a picture of the goal and sets the direction, but does not give instructions. He instills a general sense of purpose and meaning. Provides sufficient context through mission, strategy and objectives so that people make the right decisions.

7. Avoid hard talk.

If you managed to avoid most of these mistakes, I have a personal challenge for you. This is what distinguishes the team leader from the usual manager, the student from the teacher, the beginner from the pro.

When you were a developer, you probably had hot discussions about design, design, technology selection, programming methods, and the like. But the real problems of people, personal conflicts and complaints? Well, usually the boss does it, if at all someone has a deal. Guess what? Now you are the boss, and all this is flying to you. One of the employees is drawing you into a problem or someone else wants to solve an incident. But more often than not, you personally see a problem with some actions and behavior. They do not correspond to your values ​​or the values ​​of the team - and you really need to do this. You are straining, and the mind begins to invent all sorts of excuses and reasons to avoid it. But it is at this very moment that your courage and professional qualities are being tested. The most important point. This is the best opportunity for you to make a real change in your organization. It is at such moments that you help people rise to a new level (including yourself). A positive attitude to such situations is the secret of building a highly effective team.

How not to be afraid of hard talk and solve problems face to face? We must stop them running. Like many other skills, the only way to learn is to practice. In a sense, you code here in production. But there are ways to prepare and certain tactics that increase your chances of a good outcome. There are a lot of tips on the Internet, so look for - and choose some technique for testing. It may be worth starting with the book "The most important conversations . "

Here are some basics:

• Try to solve the problem as soon as possible. The longer the pull, the harder the conversation.
• Be specific and give examples. This is another reason to quickly raise the problem, while the information is fresh in my head.
• Get ready. Think about how to start a conversation, and most importantly - what you want to get from this conversation. What is the main message and what is the desired result? Think about the possible reactions, questions and answers of the person, and think about how to answer.
• The conversation should be focused on the behavior or actions, and not on the person himself. Instead of the phrase “you are disrespectful,” try “when you make X, it looks disrespectful.” A good idea is to focus on the consequences of their actions. Impact on others or negative and unobvious consequences for the person himself.
• Choose a suitable time and place. Intercepting a person in the hallway can be wonderful for quick feedback, especially in support of the last conversation. But if you expect a long and tough conversation, then make sure that there is a private place for him and enough time. The worst thing is to schedule a small time interval, and then stop, leaving the conversation unfinished.
• Of course, the best plan is his absence. Do not bring the situation to complex collisions, but solve problems from the very beginning, to escalation. Regular and effective interviews with employees are a great opportunity to discuss problems while they are still small or do not exist at all.

When I first prepared for this conversation, it was very scary, I was tormented for several days. But everything went much easier than in the apocalyptic picture that my imagination painted. That conversation really helped and greatly simplified further communication. So overcome the fear - everything will not be as bad as you think, and the results are worth it. Your team deserves it, and you yourself will say thank you.

8. Stop perfecting your skills

Remember the years spent on learning the latest technologies, tools, languages, frameworks in an effort to become a great engineer? The role of the manager here does not change anything. Management is a skill, art, practice. This is an ability that you acquire over time. It requires the same effort and dedication to learning as an engineer.

I found that many of the same successful methods that I used as a programmer work in management. Blogs, books, conferences and social networks. For each article about container management in Kubernetes there is an article about scaling the Lean methodology team. For each book on learning Golang there is a book on effective negotiation strategies. And for each lecture at the conference on monitoring microservices there is a summary of best practices for studying the team using metrics and indicators.

All right, I exaggerated. In fact, the ratio of resources about technology and management is rather 100: 1.

There are bad managers and there are excellent managers. Novices and experts. As in programming, there is a natural gift, but the main and decisive factor is the continuous thirst to learn and improve your level of skill.

---

When I switched from developers to managers, I felt depressed, but also an invigorating feeling. Start all over again and study so much ... but I’m learning so much. I can define my personality from a completely new side.

I have a long way to go. When I pass it, I can write about how to succeed. In the meantime, I concentrate on simply not failing.