Zeng Ziyi: In my three provinces and my body, reflection is an extremely valuable ability that human beings have evolved.
I have been leading the team at Ali for more than four years, and it is necessary to sum up the gains and losses here; In addition, a few days ago, I was chatting with a classmate who had just started leading the team, and he felt that the role change was quite a challenge for him, so I wanted to make a summary that was not mature and share it. Of course, the first part of this article does not mean that I must be a mature manager; The second does not mean that my summary is universally applicable (in fact, many people’s management methods and the methods I advocate are the opposite, but if evaluated from some perspectives, these people are more successful); Third, I don’t have the ambition to answer all my questions. Summarizing is simply hoping to help yourself become a better manager through reflection, while sharing is hoping to help other managers more or less.
This article will focus on my understanding of recruitment, goal management, team communication, and engineering culture. I chose these topics to talk about, mainly because during this period of time with the team, I think these elements are the core of the team’s long-term combat effectiveness and innovation ability. It’s not easy for me to get this realization, there are a lot of books on the market (especially in airport bookstores) trying to tell you what leadership is, companies have relevant training presentations, and there are many TLs around you who tell you how they do it every day. But I think this knowledge that comes from around it, a lot of it is ineffective, and there is more that is wrong. For example, there is TL sitting in the office every day until midnight, giving the team huge overtime pressure, which looks like a struggle, but in fact makes everyone tend to pay more attention to the length of work, thereby reducing the thinking about the value of work; There are also some examples of when the team students make mistakes, the fault is strongly associated with performance, which in my opinion not only does not help everyone to think deeply about the robustness of the system, but also encourages blame and stifles innovation; A more common example may be TL’s positive upward reporting, committing to delivery beyond the team’s responsibility, resulting in the team completely ignoring the engineer culture, and over time the loss of excellent talent, the overall team’s research and development capabilities are actually weaker.
Many things are easier said than done, and technical TL practice is even more so, and then continue to learn, execute, and reflect, in order to slowly do better. If my classmates in my team look back on this time five or ten years after they left the team, they will sigh: “How good our team was at that time, we did a lot of interesting things together.” Then my work with this technology TL is excellent.
1. Recruitment
The first principle of recruitment is to prefer lack to abuse. So out of everyone will agree, but the actual implementation will often be deformed because of short-term pressure, especially recruitment is more and more difficult, it is difficult to face a classmate who looks similar, it is inevitable that there will be a little inclination in the heart, forget it, first recruit in. This is actually very dangerous, because once the wrong person is hired, the administrative time required for TL is multiplied, and this time could have been used for more important time. More dangerously, the wrong person can have a negative impact on the team as a whole, such as needing others to constantly fill in positions, or constantly arguing with people, consuming everyone’s energy.
Therefore, recruitment must be strictly required, how to interview I will not go into detail, usually I will pay attention to the following aspects, basically indispensable:
coding ability;
Passion for technology;
Be able to communicate concisely and concisely;
Positive and optimistic;
Identification with the team’s goals.
Recruitment is a long-term affair, and it is often very difficult to just find someone at a window with a quota. When I meet the right person, I will keep in touch with him for a long time and understand the status of the other person’s work, which is actually a relationship that constantly builds trust. When the opportunity is right, the other person will definitely prioritize you.
When a candidate chooses an opportunity, the kind of person the team’s TL is certainly one of his key considerations. Therefore, TL must make a technical voice, whether it is participating in open source projects, writing technical articles, or giving speeches at technology conferences, which are important opportunities to fully reflect TL’s personal technical capabilities, technical thinking, and personal characteristics.
Second, the goal
The reason why the team is a team is because these people have a common goal, and if there is no common goal, these people are scattered soldiers, unable to cooperate with each other, unable to achieve great value. The team’s goals are mainly defined and clarified by TL.
It’s been a recent hit to talk about OKR (Objectives and Key Results), and I think that’s a way to work with teams to focus on goals. Directional O(Objective), Goal-Setting KR (Key Result), is the expectation that the team can come together, work in a common direction, understand and support each other. Quantified indicators (KRs) are used to guide direction and expose problems. I am more opposed to using KR or other quantitative indicators to simply and rudely assess engineers, if the digital indicators are used for assessment, it is easy to lead to everyone to give up the end. For example, someone KR is 200% complete, but digs a bunch of pits; And someone KR is 50% complete, but it does solve the tricky problem, and the code is solid. I am bound to give good performance to the latter and poor performance to the former.
Defining a team goal is actually a very difficult thing to do, because the definition of this goal requires you to answer:
Whether you’re fully communicating with your users/customers, understanding what they really need, what problems you can solve for them, and how their work will change because of your team.
If you can do a good job of collaboration with upstream and downstream collaborators, who will you rely on to do what to deliver on the value you promise to your customers? Who do you need to be involved with? Do these dependents and collaborators agree with your goals?
Are the goals and values you define consistent with your own TL goals, or your own department’s goals?
In the technical team, did you consider technical competitiveness in your goal definition? Continuous building of technical competitiveness can not only help the team develop better in the long run, but also help attract more outstanding talents.
Of course, if the goal is a little idealistic, it is even better. Engineers are a little more easily attracted to idealism. After having a clear team goal, it is necessary to communicate with the team continuously, so that everyone can clearly understand the goal, do not fear repetition, do not fear of verbose.
The next step is to break down the team goals into everyone’s goals, which are essentially product architecture or technical architecture. Why? When doing software design, we will say high cohesion, low coupling; Will say contract-oriented design. When people collaborate with each other, we also want everyone’s goals to be clear enough (comparing the definition of software delivery functions, or the measurement of non-functional indicators), and the boundaries of collaboration between people and people (comparing contracts between software systems). Therefore, we must constantly think about the structure of the team responsible for the product, and continue to discuss the refinement with the team until the structure and goals are clear enough. Of course, there are some horizontal goals, or project management work goals, that need to be undertaken by classmates, which is no problem, but I very much recommend that in the R&D team, let a classmate spend more than half of the time doing horizontal, because the technology is not breadth without depth.
3. Communication
If your team is looking for you, respond as soon as possible. Immediate response means that if you have time in the moment, communicate with him immediately; If your daytime is full, communicate with him at night; If you have taken up your time in the evening, immediately schedule a time tomorrow and send out an invitation to the meeting. If students do not think that they are important, they generally will not take the initiative to communicate with the supervisor, and immediate response is an important way to build trust with classmates. If a classmate doesn’t get a response to you once or twice, or if the response is slow (giving people the feeling of not paying attention), then slowly many things will not find you. In the worst case, the next time a classmate comes to you, he may be transferred to a post.
Try to do 1-on-1 with your classmates, full-time management positions abroad, and do 1-on-1 as a very serious daily work, and the frequency is also very high, such as once every two weeks. At Alibaba, Technology TL usually doesn’t have that much time, because the responsibilities on the body are not only to manage, but also to bring technology, projects, and so on. But you should still do a good job of daily 1-on-1 communication, not just the performance season. The ideal frequency is once a month. At 1-on-1, very specific feedback is given on the one hand, such as:
The x plan you did was very well designed with collaboration with the team next door in mind.
Your recent code doesn’t do enough on UT overlay.
I see that the y project you are advancing, the progress is not ideal, is there any problem? What help do I need?
In addition to feedback 1-on-1 More importantly, listening, when the students express their work, how good are they doing? Where did I run into the problem and how could being a TL help? _In fact, many times, even if you can’t help anything temporarily, but with a serious attitude to listen to the mood of the classmates, whether the mood is full of enthusiasm, or depression, or confusion, it is very important for the students. When I do 1-on-1, I will make a simple record, keep the next 1-on-1 review, and do a good job of tracking.
Fourth, engineering culture
To build a team with combat effectiveness, an excellent engineering culture is indispensable. What is a good engineering culture? That is to write the code, write the tests, write the design, make the product, all these engineers’ outputs, and have enough respect for its quality and details. Why a good engineer culture is essential, I explain it through the following points:
From the perspective of the long-term development of the team’s products, only by ensuring excellent quality can we ensure that the products can be long-term, efficient and continuous iteration. If the design is messy, the code quality is poor, and there is no test coverage, then gradually everyone’s energy will be consumed on various “safe production” problems. Gradually, the on-line implementation of a requirement evolved from hours to days, or even weeks.
Only a team with a good engineering culture can attract good engineers. Good engineers really regard programming as a craft and take pride in their craft. If Team TL doesn’t think it’s a craft to be proud of, everyone is gradually seeing things as the same nature as moving bricks, and the difference is only the salary. In such an atmosphere, the talent composition of the team must be second-rate or even third-rate.
The construction project culture is to encourage everyone to do Code Review, write UT, do a good job of CI, and do knowledge sharing. These things sound easy, but the hard thing is how to stick to it when the project is under a lot of pressure. In addition, it is to acknowledge the existence of technical debt, after the product is online for a period of time, there will inevitably be a lot of “temporary solutions”, as TL to create space for the team to encourage them to take the time to repay the technical debt.
Engineering culture is the foundation of the technical team and allows everyone to have a correct reference, what is right, what should be learned, and what needs to be followed. We can see a lot of teams that have lost their engineering culture, what kind of state they have evolved into, writing PPT that looks similar, pulling this and that, encountering problems they do not go to the root of the matter to figure out the principle, but pull the group, group meeting, communication… Gradually, the technical talent of such a team will gradually be lost, and the rest of the people will continue to survive with the non-technical skills they are good at.
5. TL says to himself
In addition to the outside world, I often say to myself:
Be true to yourself
Don’t Panic！
Be patient
Be true to yourself. Everyone has their own personality traits, although because of life experience, people’s personality will change, but in a short period of time a person’s most essential things will not change. Or gentle and elegant, or narrow and proud, or active and diligent… “True without pretending” is one of my favorite values of Alibaba. It is easy to disguise yourself for a while, and you will disguise yourself as a kind of person for many years, first, you will be very tired, and second, the team members are not fools, sooner or later you will see the hypocritical side of this. And once a TL feels hypocritical, there is no way to build trust. Of course, for self-analysis, knowing yourself is not a simple thing, psychological analysis books are vast, I like to read some in the middle of the night.
Don’t Panic！ TL will face all kinds of pressures, goal changes, goals are difficult to achieve, performance appraisals, conflicts between people and people, conflicts between teams and teams, and everyone is watching how you deal with them at this time. Under so much stress, people’s natural response is anxiety and even panic. We know that when exercising, when speaking, excessive anxiety can lead to distortion of movements, and even unable to play their normal level. In this state, TL is more likely to make wrong judgments, and severe anxiety is easily transmitted to the entire team. The more such moments, the better to stabilize themselves, under limited conditions, try to make the most reasonable judgment, we must admit that no matter how smart and diligent we are, we are just ordinary people, not superheroes in Marvel.
Be patient. Programmers may be the most impatient group of people, code to write, first expect the machine to give feedback, secondly, expect the machine to give feedback immediately, right, or something went wrong, everything must be clear and clear. But when the role of the programmer becomes that of a manager, everything changes dramatically. The goals you promote to the team may be remembered by some people and some people may not remember; The problems you point out to your classmates may not be changed for months and six months, or he does not want to change at all; The engineering culture you want to build on the team seems to be moving very slowly, too far from what was expected. In fact, all this is very normal, the human brain receives and transforms information, unless it is life-threatening information, otherwise the efficiency is very low, a person’s own accumulation of decades of behavior patterns, even if it makes subtle changes, it will take a long time. Therefore, important information, do not be too troublesome, can be said three times or even more; And when you are kind enough to point out problems to your classmates, do not expect the other party to accept and change immediately, many times it is normal for him not to make any changes. But that’s not a reason why we don’t do the right thing, if one or two of the ten classmates break through some of the bottlenecks in their careers because of your guidance, that is already a huge achievement that TL can achieve.
6. Further reading
Yang Dai has a sentence that I like very much, she wrote this sentence in a reply to the young students:
Your problem is mainly that you don’t read much and think too much.
In my opinion, many people I see in my work today, the so-called innovation, the so-called idea, are all blind tosses that do not read much and think too much. As a technology leader, experience and thinking are necessary, but if you only rely on your own thinking and experience, you will often take many detours, or even the opposite direction. Therefore, I recommend that you read some related books. Here are some of the ones I’ve read and recommend to you:
“Win”
“How to Define a Company”
Talent is paramount.
“Driving Force”
How to motivate people in addition to using money.
The Secret Behind the Door
Why 1-on-1 communication is so important, and how to do 1-on-1 well.
Nonviolent Communication
Everyone can speak, but many people who speak well will not, and those who are good at listening are even rarer.
Past Recommendations:
Technical trivia
Based on the idea of distributed design, architecture and system, it also discusses the bits and pieces related to R&D, not limited to code, quality system and R&D management.