"Should Technical Managers Become Technical Experts in Their Teams?"

This article is Lu Canwei's 24th original piece.

You shouldn't drink coffee at night; this article was typed at 2 AM, and I estimate that by the time I finish writing, it will be around 4 AM in Shanghai.

During this period, I've been going through some interviews, and I encountered an interesting situation in the past couple of days. After one interview, when I asked the interviewer about areas for improvement, the interviewer said that as a head of R&D, your technical depth should be the strongest in the team.

At this point, many people might have differing opinions, so let me share a little story from a while ago.

I

Not long ago, I went to Kunming and met a guy whom everyone likes to call Lao Wu. It's quite interesting because I heard him speaking Cantonese with another guy, so I started chatting with him in Cantonese as well.

This guy's experience is also quite interesting. He worked in a state-owned enterprise for over ten years, and according to him, he is currently "on the road," having been wandering for four years. He is about ten years older than me, so as a junior, I was both curious and eager to learn, so I discussed a bit with him.

He said he never thought he would enjoy this kind of life; he really enjoys the feeling. I asked him how he views the past and the present, and he didn't provide a good or bad comparison but told me that our lives are diverse, and every period and state of you is still you; you must learn to accept it.

Later, I asked him about my frequent dissatisfaction with results. He told me that the results you can achieve are the best you can get at the moment.

II

Having finished the side story, let's return to the main topic.

I remember in my third year of work, our boss was a very impressive technical expert who used very new technologies and built a rendering engine from scratch, which performed several times faster than the rendering engines available on the market.

We subsequently worked on delivery projects, coupon projects, and group buying projects, all of which failed.

At that time, I was pondering, what exactly is technology? I came to an answer: technology serves the business, not the other way around.

Whether in future startups or as a technical lead in a small startup, I focused on rapid iteration. Later, when I went to Ele.me as the mobile lead, I spent a lot of energy developing a rendering framework for Android, significantly improving development efficiency.

For this reason, as the team leader at that time, I spent a lot of time on R&D. I built the underlying architecture and dynamic rendering components, making me the busiest person. Many issues had to be pushed to me for resolution, and for a long time, I didn't leave work before 2 AM.

Later, the team encountered significant problems; the Android and iOS teams were completely inconsistent in their development progress, with Android's efficiency being several times higher than iOS, leading to poor planning for iterative versions on the product side and major collaboration issues with other teams. It was a complete mess.

In my later work, I began to reflect on this experience. I am very experienced in Android development and can also work on iOS, but can I be better than a senior iOS developer? I don't think I'm the kind of person who is proficient in all technologies. Although I can do full-stack development, my energy is limited, and achieving a score of 70 in all areas is already impressive.

Later, I shifted my focus to the team, letting the right people do the right things. What I could do was help the entire team improve efficiency. For example, if there was a problem that the front end couldn't solve, and I happened to understand both front and back end, I would share my thought process with the team members and let them refine the solution with their expertise.

For instance, in the case of automating the packaging process, since I understood continuous integration, Ruby, and the details of mobile packaging, it became much easier to push this forward.

At this point, you might think my answer is that as a technical manager, you don't necessarily have to be a technical expert, especially since everyone in the team has better technical skills than I do.

You can imagine, during your school days, who was the person everyone wanted to listen to in class? This person was likely not the class monitor. Why did everyone trust and follow him? It’s likely because they thought that if there was a problem, he could definitely solve it, or he understood everything, and if he didn’t, he could be consulted.

This is mentioned in Zhang Sihong's book "Minimal Relationships." Typically, in the workplace, there are many situations where cross-departmental cooperation, uneven distribution of interests, resource allocation, task breakdown, and interest balancing lead to conflicts, or simply confusion arises at work. At such times, people feel that whoever speaks up can greatly help resolve the issue.

So who is this "who"? It can actually be you. As a team manager, what you need to do is become this "who." Whether you are a technical expert yourself or can find a technical expert to help solve problems, the core issue is not your title, your ability, or your position; the key point is that you help your team members solve problems.

Everyone's experiences and growth backgrounds are different, so there are different views and answers at different stages. However, regardless of the approach, as long as it can generate benefits for the team, you are a qualified technical manager.