From engineers to managers: maintaining technical skills

I became a technical manager about two years ago. During this time, one of the most difficult tasks was finding a balance between the responsibilities of a manager and the desire to program.

It seems that I am not the only one who has encountered such difficulties, so I think that it’s worth adding five kopecks to the discussion of this issue.

Why Technical Managers Must Have Technical Competence

In my opinion, the ideal leaders of teams consisting of engineers are technically competent managers with practical experience (as well as those who manage to avoid the Dilbert Principle most of the time).

Technically competent manager:

• understands the hidden complexity of the tasks facing his team, which greatly facilitates communication with subordinates, as well as the transfer of this information to employees and managers of other departments of the company who do not have sufficient technical training;
• is a more effective mentor to the engineering team and can be an example for them;
• is aware of new tools and frameworks that can be useful to the team, and is able to better determine the direction of technical development ;
• more often gains the trust and respect of team members (which, of course, does not mean that managers who do not have technical training cannot win trust and respect);
• if desired, in the future may return to work as an artist.

I think we agreed that the preservation and development of technical skills is a really good idea. But there are serious difficulties on this path.

Coder or tutor?

The first difficulty that you are most likely to encounter is the conflict between your engineer and mentor . The engineer will always want to solve interesting technical problems on his own, and the mentor should strive to entrust these tasks to other team members, thereby enhancing their skills.

This problem is particularly pronounced in teams where there are many young employees and not enough experienced specialists who could teach young people. In this situation, the technical leader should pay special attention to mentoring.

Lead your team to success

In the first place should be your people, and independent programming in this case is secondary. This is a necessary condition: if and only if your team is successful, you can devote some time to programming.

As a leader, you are not creating a product; you are creating a team that knows how to create products . Thus, the success of the team should be your main goal and the main metric on the basis of which your work is evaluated. If you lead a successful team of satisfied engineers, you will spend less time meeting with your colleagues from other departments and management, trying to explain or sell them your achievements.

A self-sufficient team of empowered responsible professionals, where you are not a bottleneck when making decisions, will allow you to set aside more time to do something else.

The weight of your words

Another problem for me was that during the discussion of technical issues I spoke too much or imposed my point of view on the team. I did not realize this problem until the employee pointed out her during the feedback session, in which the whole team participated. She said something like: "During our technical discussions, you too insist on your point of view ... I think you should put less pressure on us, give us more freedom."

Some leaders, no doubt, talk a lot, and quite often from a position of strength. I realized that this prevents others from expressing their alternative points of view or expressing their disagreement, which in the end may lead to the adoption of a less qualitative decision.

What can I advise?

I like the sound of your voice, especially when you shut up.

Always speak last and ask questions instead of giving answers.

This statement is so important that, as much as it is isolated, it will still be small. Experienced managers know that every word they say or write potentially drowns out the ideas and suggestions of team members.

James Everingham went even further and suggested that, just by watching, the manager was already changing the outcome of the project. In his Quantum Mechanical analogy (Quantum Mechanics analogy), he writes:

The effect of the observer manifests itself in the workplace. You can influence the outcome of any project only by your presence. It often happens that a manager gathers everyone together and says: “This is what we have to do,” or “This is what I think,” or “Let's look at this question from this direction,” starting with drawing something on the board. He is trying to add value. We all strive for this. But if you say this from the position of power, then first of all you seek only narrowing the range of possible options and seriously hamper the path to success.

Creator or leader?

When I tried to combine the Creator's and Executive's schedules, I ran into an organizational problem. Paul Graham says (added bold):

The most powerful people live according to the schedule of the leader, which is mostly in the distribution of instructions. But there is another way to use time, which is common among people creating, such as programmers and writers. They generally prefer to divide time into units that are multiples of at least half a day. It is impossible to write a program well, measuring time in hours. An hour is barely enough to get you started.

In short, a fragmented, reactive, and meeting-filled executive schedule hinders the concentration required for programming (which is a type of Deep Work ). We can say that the characteristics of the schedules of the manager and the creator are antagonists: the engineer needs to be distracted as little as possible, whereas the reputation of the manager who does not attend meetings or does not interact with the team can suffer greatly due to "insufficient visibility."

Do not mix these two types of schedules.

Don't even try. This is a direct path to frustration and a constant feeling of unproductiveness. Like water and oil, they are best kept apart from each other.

I try to separate these types of activity with natural breaks, such as lunch. All meetings with my participation are held in the morning, which, of course, is very tiring, but it allows you to reincarnate as a Creator after lunch and concentrate on complex programmer issues. I strive to do this exercise at least twice a week.

I also found that a long break for lunch and a walk outside the office, if possible, very well help to disconnect, to clear the head from meetings. After the break, I return to the office rested and ready for productive work as a programmer.

Being in the role of Creator, you should try to avoid any distractions. First, disable the mail. Next, close all unnecessary tabs in the browser - ahem, Facebook, - or open a new browser window only for the necessary documentation. One last thing: I would also disable HipChat / Slack. In this case, of course, you need to leave some way of communication in case of urgent issues and important people (your team).

The ability to focus and be productive largely depends on the context in which you are physically and spiritually. You can spend a lot of time adjusting your work environment (working at another table / from another place; listening to certain music; doing something else to help you) in order to find the right context that would provide maximum productivity.

In the book Deep Work , written by Cal Newport, you can find many other techniques to deal with the problem of achieving deep concentration (shallow vs deep) .

How not to become a bottleneck

Given the busy work schedule, it may be very difficult for you to complete the tasks of writing code in time. This is likely to result in blocking the affected functionality in Production. Worse, if you have problems, you may be busy with other things and not being able to take up urgent technical issues, such as a broken authorization on the site or a pipeline breakthrough.

As a team leader, you should first of all protect your employees from distracting meetings so that they can concentrate on programming. Again, your job is not to write code, but to provide conditions that allow the team to write code efficiently. It is also very important to help employees publicly talk about their achievements.

Your code should not fall into production

One good friend gave the following advice when talking about experienced technical managers:

You should not be a bottleneck in your team. You need to teach and instruct your employees so that they can cope with all the technical problems without your help. In no case should you be required to write a production code. You can apply your programming skills in dirty work that is not related to the functionality of the product. Accelerate the assembly of code, select the common functions in a high-quality library. Look for such things that will increase the productivity of the team or simply make the work more enjoyable. You can maintain your technical qualifications by programming concept proofs (Proofs Of Concepts), researching new technologies that the team can use, or working on third-party projects , doing this together with other employees or independently.

I decided to follow this advice and am very pleased with the results. I now worry less, knowing that I am not a technical bottleneck. And, importantly, my team got more opportunities to solve problems on their own, gaining invaluable experience in the process.

To transfer my technical knowledge, I solve interesting problems by programming in pairs, and also I spend “Net Code Sessions”, in which all team members solve technical problems together using “mob programming” or simply share their opinions and technical issues. knowledge.

Now most of my programming work is related to third-party projects. This also applies to Expedia ( Expedia Alexa Skill ), and to my third-party projects, such as markpress or the useless, but pretty, Rolex GMT Chrome Start tab extension.

Conclusion

Being a leader who can write code is almost the same as working two jobs . To do this, you need to work hard, devoting himself to the chosen case. It is likely to feel overwhelmed with work and burned out , especially if you do not keep a balance between team management and honing your technical skills.

Perhaps, in order for the combination to work, you need to love the leadership of people and programming to the same extent, since this will require spending a lot of free time to improve your manager and programmer's I. But it's worth it! And ultimately this is life .

What else to read on the topic

• Developer turned manager - an article written by David Haney working at Stackoverflow .
• Average vs Great manager is an article written by Facebook Julie Zhuo .
• Maker's schedule, Manager's schedule - an article written by Paul Graham.
• Deep Work is a book written by Cal Newport.
• Team of Teams: a book written by General Stanley McChrystal.
• The Principles of Quantum Team Management - an article written by James Everingham , head of technical department on Instagram .

References:

1. Original: From Engineer to Manager: keeping your technical skills .