Introduction: As a technical TL (Team Leader), in addition to its own skills, it will also face many difficulties and challenges in team management. How to define and clarify the goals of the team? How to establish an excellent engineering culture? What is the core of the team's long-term combat effectiveness and innovation capabilities? Based on four years of team management experience, the author of this article shares his thoughts and summaries on recruitment, goal management, team communication and engineering culture, introduces relevant experience methods, and recommends several books on experience and thinking. Hope to inspire students.
Zeng Zi said: I think three times in my body, and reflection is an extremely precious ability that humans have evolved. I have been leading the team in Ali for more than four years. It is necessary to summarize the gains and losses here. In addition, a few days ago I chatted with a classmate who had just started to lead the team. He felt that the role change was a big challenge for him, so I wanted to do it. It's not a mature summary and share it. Of course, the first in this article does not mean that I am necessarily a mature manager; the second does not mean that my summary is universal (in fact, many people’s management methods are contrary to the methods I recommend, but if From some perspectives, these people are more successful); thirdly, I have no ambition to answer all the questions. The summary is only to help oneself become a better manager through reflection, and sharing is to help other managers more or less.
This article will focus on my understanding of recruitment, goal management, team communication and engineering culture. The main reason for choosing these topics is that during the period of time leading 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 understanding. There are many complicated books on the market (especially in airport bookstores) trying to tell you what leadership is. The company also has related training introductions. There are many TLs around to tell you with daily words and deeds. How did they do it. But I think many of the knowledge from the surroundings is invalid, and many more are wrong. For example, TL sits in the office until midnight and leaves work every day, which puts a huge pressure on the team to work overtime. On the surface, it seems to be a struggle. In fact, it will make everyone tend to pay more attention to the length of work, thus reducing the right thinking about the value of work; For example, when teammates make mistakes, they strongly correlate failures with performance. In my opinion, this not only does not help everyone think deeply about the robustness of the system, but it also encourages responsibility and stifles innovation; a more common example may be TL being positive Reporting, promising to exceed the delivery capacity of the team's responsibility, resulting in the team completely ignoring the engineer culture, the gradual loss of outstanding talents over time, and the overall research and development capabilities of the team are actually getting weaker.
Many things are easy to know and difficult to do. Technical TL practice is even more so. After that, you can learn, implement, and reflect continuously to gradually do better. If the classmates of my team leave this team for five or ten years and think about this period of time, they will sigh with emotion: "What a great team we had at the time, everyone has done a lot of interesting things together." Then my technology TL Work, even if done well.
One recruitment
The first principle of recruitment is to prefer not to overrun. Everyone will agree with that, but the actual implementation is often deformed due to short-term pressure, especially when recruitment is getting harder and harder. After finally meeting a classmate who looks similar, it will inevitably be a little bit inward. Forget it, recruit first. Up. This is actually very dangerous, because once the wrong people are recruited, the management time required for TL will be doubled, which could have been spent on more important time. What's more dangerous is that the wrong person may have a negative impact on the team as a whole, such as requiring other people to constantly fill positions, or arguing with others, which consumes everyone's energy.
Therefore, recruitment must be strictly required. I will not go into details about how to interview. Usually I will pay attention to the following aspects, which are basically indispensable:
- coding ability
- Passion for technology
- Can communicate concisely
- Positive and optimistic
- Acknowledgement of team goals
Recruitment is a long-term affair. It is usually very difficult to find people only at the window with quota. When I meet the right person, I will keep communicating with him for a long time to understand the work status of the other person. This is actually a relationship that continuously builds trust. When the opportunity is right, the other party will definitely give you priority.
When a candidate chooses an opportunity, what kind of person the TL of the team is must be one of his key considerations. Therefore, TL must be a technical voice. Whether it is participation in open source projects, writing technical articles, or giving a speech at a technical conference, it is an important opportunity to fully reflect TL's personal technical ability, technical thinking, and personal characteristics.
Two goals
The reason why a team is a team is that these people have a common goal. If they don't have a common goal, these people are stragglers. They cannot collaborate with each other and cannot achieve great value. The team’s goals are mainly defined and clear by TL.
Recently, it is more popular to talk about OKR (Objectives and Key Results). I think this is a way to coordinate a team to focus on goals. Setting the direction O (Objective) and setting the number goal KR (Key Result) means that the team is expected to gather together, work in a common direction, and understand and support each other. Quantitative indicators (KR) are used to guide the direction and expose problems. I am more opposed to using KR or other quantitative indicators to evaluate engineers simply and rudely. If digital indicators are used for evaluation, it will easily lead to abandonment. For example, some people have completed 200% of KR but dug a lot of pits; while someone completed 50% of KR, they did solve the tricky problem and the code was solid. I will inevitably give good performance to the latter and poor performance to the former.
Defining team goals is actually very difficult, because the definition of this goal requires you to answer:
-
Have you fully communicated with your users/customers, whether you understand what they really need, what problems you can solve for them, and how their work will change because of your team.
-
If you can collaborate with upstream and downstream collaborators, to fulfill the value you promised to your customers, who will you rely on for what you do? Who needs to participate with you? Do these dependent and collaborating parties agree with your goals?
-
Are your defined goals and values consistent with your own TL goals or goals of your own department?
-
In the technical team, do you consider technical competitiveness in your target definition? Continuously building technological competitiveness can not only help the team develop better in the long-term, but also help attract more outstanding talents.
Of course, if this goal is a little bit idealistic, so much the better. Engineers are so easy to be attracted to idealism. After having a clear team goal, it is necessary to continuously communicate with the team, so that everyone can clearly understand the goal, don't be afraid of repetition, don't be afraid of wordy.
The next step is to decompose the team goals into everyone's goals, which is essentially product architecture or technical architecture. Why do you say that? When doing software design, we all talk about high cohesion and low coupling; we talk about contract-oriented design. When people collaborate, we also hope that everyone’s goals are clear enough (compare the definition of software delivery functions, or the measurement of non-functional indicators), and that the boundaries of collaboration between people are clear (compared between software systems contract). Therefore, we must continue to think about the structure of the product that the team is responsible for, and continue to discuss and refine it with the teammates until the structure and objectives are clear enough. Of course, there are some horizontal goals, or project management goals, which need to be undertaken by students. This is no problem, but I strongly advise against letting a student spend more than half of the time in the R&D team to do horizontal work because the technology does not Depth cannot be discussed as breadth.
Three communication
If your teammates approach you, respond as soon as possible. Immediate response means that if you have time right now, communicate with him immediately; if you are full during the day, then communicate with him at night; if you are really occupied at night, then immediately arrange for one tomorrow Time, issue a meeting invitation. If students don’t think important things, they will not take the initiative to communicate with their supervisors. Immediate response is an important way to build trust with students. If your classmates do not get a response to you once or twice, or the response is slow (it feels like being ignored), then many things slowly won't find you. In the worst case, the classmates may be transferred to another post when they find you next time.
Try to do 1-on-1 with your classmates as much as possible. If you are a full-time manager in a foreign country, you should do 1-on-1 as a very serious day-to-day job with a high frequency, such as once every two weeks. In Alibaba, technical TL usually does not have so much time, because in addition to management, the responsibilities of the person must also bring technology and projects. But you should still do the daily 1-on-1 communication, not just the performance season. The ideal frequency is once a month. In 1-on-1, on the one hand, you must give very specific feedback, such as:
- The x plan you made is very well designed, taking into account the collaboration with the team next door.
- Your recent code has not done enough in UT coverage.
- I see that the y project you are pushing forward is not progressing as expected. Is there any problem? How can I help?
In addition to feedback 1-on-1, what is more important is to listen. Are students in good condition when they express their work? Where did you encounter a problem, and what help can you provide as a TL? _Actually, many times, even if you can't help much for the time being, it is very important for the students to listen to the feelings of the classmates with a serious attitude, whether the mood is full of enthusiasm, depression, or confusion. When I do 1-on-1, I will make a simple record, and keep it for review and follow up the next time I do 1-on-1.
Four engineering culture
To build a fighting team, an excellent engineering culture is essential. What is an excellent engineering culture? That is to have enough respect for the quality and details of the code, the test, the design, the product, and the output of all these engineers. Why it is said that a good engineer culture is indispensable, I will explain through the following points:
-
From the perspective of the long-term development of the team's products, only by ensuring excellent quality can the product be ensured for long-term, efficient and continuous iteration. If the design is messy, the code quality is poor, and there is no test coverage, then everyone's energy will gradually be consumed on various "safe production" issues. Gradually, the online realization of a demand has evolved from a few hours to a few days or even weeks.
-
Only a team with an excellent engineering culture can attract excellent engineers. Excellent engineers, sincerely regard programming as a craft and take pride in their craft. If the team TL doesn't think this is a craft that should be proud of, everyone will gradually regard things as the same as moving bricks, the difference is only the level of salary. In such an atmosphere, the talent composition of the team must be second-rate or even third-rate.
Building engineering culture is to encourage everyone to do Code Review, write UT, do CI well, and share knowledge. These things sound easy, but the hard part is how to stick to it when the project is under great pressure. In addition, it is necessary to recognize the existence of technical debt. After the product goes online for a period of time, there will inevitably be many “temporary solutions”. As a TL, it is necessary to create space for the team and encourage them to take time to repay the technical debt.
Engineering culture is the foundation of the technical team, which allows everyone to have a correct reference, what is right, what should be learned, and what needs to be observed. We can see what kind of state many teams that have lost engineering culture evolved into, and write PPTs that seem to be the same. Everyday pull will promote this and that, and if you encounter problems, you will not investigate the fundamentals and figure out the principles. It is to pull groups, form meetings, communicate... Gradually, the technical talents of such a team will gradually drain, and the rest will continue to survive with their non-technical skills.
Five TL said to myself
In addition to externally, I often say to myself:
- be yourself
- Don’t Panic！
- Be patient
be yourself. Everyone has their own personality traits. Although a person's personality will change due to life experience, the most essential things of a person will not change in a short time. Or gentle and elegant, or narrowly arrogant, or active and diligent... "Do not pretend to be true" is one of my favorites in Ali's values. It is easy to pretend for a while. For years to pretend to be a persona, you will be very tired. Secondly, the teammates are not fools. Sooner or later they will see the hypocrisy. Once a TL makes people feel hypocritical, there is no way to talk about the establishment of trust. Of course, self-analysis and knowing oneself is not a simple matter. There are so many books on psychological analysis, and I like to read some in the dead of night.
Don't Panic! TL will face a variety of pressures, changes in goals, difficulty in achieving goals, performance appraisal, conflicts between people, and conflicts between teams. At this time, everyone is watching how you handle it. Under so much pressure, people's natural reaction is anxiety, or even panic. We know that during exercise and speech, excessive anxiety can cause movement deformation, and even unable to perform at a normal level. In this state, TL is more likely to make wrong judgments, and serious anxiety is easily transmitted to the entire team. The more this kind of moment, the better we can stabilize ourselves and work hard to make the most reasonable judgments under limited conditions. We must admit that no matter how smart and diligent we are, we are just ordinary people, not Marvel’s superheroes. .
Be patient. Programmers may be the most impatient group of people. When the code is written down, the machine is expected to give feedback first, and then the machine is expected to give feedback immediately. Yes, there is still an error. Everything must be clear and plain. But when the role of programmers changed to managers, everything changed dramatically. The goals you promote to the team may be remembered by some people and others may not be remembered; the problems you pointed out to your classmates may not be able to change for months and a half, or he does not want to change at all; the engineering culture you want to build in the team , It seems that progress is very slow, and it is too far from expectations. In fact, all this is normal. The human brain accepts and transforms information, unless it is life-critical information, otherwise the efficiency is very low. A person has accumulated decades of behavior pattern, even if it makes subtle changes. A long time. Therefore, don't be too troublesome to say important information three times or more; and when you kindly point out the problem to your classmates, don't expect the other party to accept and change it immediately. It is normal for him not to make any changes. But this is not a reason for us not to do the right thing. If one or two of the ten classmates break through some of their own bottlenecks in their careers because of your guidance, it is already a great achievement that TL can achieve.
Six further reading
Yang Jiang has a sentence that I like very much. In a reply to young students, she wrote this sentence:
Your problem is mainly that you don’t read much and think too much.
In my opinion, what many people see in their work today, so-called innovations, so-called ideas, are all fuss about not studying much but thinking too much. The same is true for being a technical 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 go the wrong way. So I suggest you read some related books. Here are some of what I have read and recommend to everyone:
"win"
"How to Define a Company"
Talent is essential.
"Drive"
Besides using money, how to motivate people.
"Secret behind the door"
Why 1-on-1 communication is so important, and how to do 1-on-1 well.
"Non-violent communication"
Everyone speaks well, but many people do not speak well, and people who are good at listening are even rarer.
Original link: https://developer.aliyun.com/article/781284?
Copyright statement: The content of this article is voluntarily contributed by Alibaba Cloud real-name registered users. The copyright belongs to the original author. The Alibaba Cloud Developer Community does not own its copyright and does not assume corresponding legal responsibilities. For specific rules, please refer to the "Alibaba Cloud Developer Community User Service Agreement" and the "Alibaba Cloud Developer Community Intellectual Property Protection Guidelines". If you find that there is suspected plagiarism in this community, fill in the infringement complaint form to report it. Once verified, the community will immediately delete the suspected infringing content.