Disclaimer: The so-called technical management notes are the management notes of a former coder in a big company who is unwilling to be lonely and joins a start-up company. The gap between a large company and a start-up company is all-directional, with systems, atmosphere, resources and talents. From the initial inadaptability to all the way to live up to now. Filled with gratitude and luck, I felt compelled to record and summarize. The project started in November 2017, and by this time, the technical team I managed was 50 people. This background can be used for reference, examples may not be consistent with your team, but the idea may be the same, welcome to discuss with the same people.

When many students slowly transition from engineer to technical manager, they often have two ideas:

  • Management style: as a technical background, I have always been logical, management is not the pursuit of rigorous? I am confident that I can design a set of institutional processes to make the team orderly and efficient, such as a good release process, system design review process and code review process

  • Technical fan: I am a technical elite, so my team must be elite. Just like silicon Valley, I should not interfere with my team too much. I should respect everyone’s ideas and let everyone play freely. I must share high quality technology every week and keep up with the trend of technology, including GO, virtualization and machine learning. So you can make a great product and attract more great people to join

These two ideas alone can not lead to a strong team, the essence is only to focus on the shape, but not god, the real good management is “non-intervention”. Lao-tzu thought, “I do nothing, while the people transform themselves; I am quiet, and the people are self-righteous; I do nothing, and the people get rich. I have no desire, but the people from the simple “, and stressed that “do nothing but do everything”.

“Governing by doing nothing” does not mean doing nothing. It means not intervening too much, giving full play to the creativity of all people, and achieving self-actualization. In short, be truly “people focused”, not “management”.

Many students will say that they pay attention to people. Ok, I talk to everyone every day to understand their ideas and meet their needs. Of course, this is a very important tool, but there is a very important step that needs to be done before that, and that is to identify people.

Why, for example, did Trinket manage to get things done? For he had long distinguished those who belonged to the Emperor, those who belonged to the Association of Heaven and Earth, those who belonged to the Divine Dragon Cult, those who were for money, those who were for power, and those who were for the people. He adopted different treatment strategies for each kind of people, precisely matching the needs of various people, just like the Switch case written in our code, logical isolation and precision. Only in this way, can we give full play to the ability of everyone in the team, so that the team becomes more and more efficient.

Here’s my own “process of meeting people.”

Know a man before you do something

As mentioned before, when you’re building or taking on a team, don’t rush to change the way things are done or the process. The focus should be on getting to know who your team is, what they care about, whether their goals are aligned with yours, and what their abilities and potential are. Just like when you are familiar with a system, do not start to change before you see the original logic clearly and find how many holes there are, otherwise it will be easy to change the BUG, and this logical order must not be wrong. The more detailed this information about people is, the better it will be for the follow-up work.

Create categories for members

In general, I would classify a technical team into the following categories:

category define
Excellent Engineer Good technical skills, identify with company goals, strong self-drive, like to find and solve problems
Potential programmer with some engineer mentality Identify with the company’s goals, have a strong self-drive, technology is still in the rapid growth stage
An ordinary programmer with an engineer’s mind Identify with company goals, strong self-drive, average technical potential
Skilled programmer Technically solid, but not too much of an engineer
Ordinary programmer The technology is mediocre and not much of an engineer

Identify members into different categories

General ways to identify: face-to-face communication, private side understanding, observing their way of doing things. Stick to one principle: be objective. Compare their actual performance in past projects and their thinking performance in daily communication with the table above. If a person has 10 things, then 80% or more of the categories are basically true.

Different categories adopt different strategies

category Coping strategies
Excellent Engineer Give him more responsibility, more responsibility for things (such as a big chunk of the technology architecture), and more resources
Potential programmer with some engineer mentality Provide more professional guidance and a bigger stage (let him work on key projects, be technically rigorous, start with code details), and provide more resources
An ordinary programmer with an engineer’s mind Put them in charge of some work that is not technically difficult but requires a lot of rigor, provide some guidance, don’t put too much pressure on them and let them grow
Skilled programmer To improve his way of thinking (non-technical), carefully consider his potential versus his value ratio. Before the way of thinking is improved, I may have to do some relatively independent work that does not require high teamwork. Ask them to coach new hires in technology, but not in thinking.
Ordinary programmer Maintain the status quo, no resource tilt

Simply put, the so-called staffing strategy is: how to define the role of people, how to arrange affairs, how to arrange resources comprehensive plan. The key is to focus your energy on the things that matter most, and on the people you really need to care about. The bigger the team, the more challenging it is for your energy, there is a saying that you can only manage six people effectively and directly.

The basics of identifying people are covered, and if done right, 40% of team management is successful. If you want to improve your ability to judge people, follow this process strictly. In case of deviation in practice (mainly due to the identification of members in the wrong category due to experience problems), it is necessary to make continuous summary, reflection and timely correction. In the early days when I was building a team, I would do reflection and summary almost every day, and repeatedly weigh and consider the code written by everyone, the system design done by everyone, the performance of communication and the completion of the project. Once you have a category, be confident in yourself and stick to your strategy. This is so important that a leader must have confidence in his or her own decisions that he or she has considered over and over and execute them, or don’t do them.

In the next chapter, we will look at technical team management notes (2)- Bring people