Qualities of a Project Leader

Many projects have several types of Leaders:

1. General Talk

Often, leaders only give a general direction and some high-level theoretical directions, and leave the work to ordinary developers. After that, they may turn around and complain that the developer's level is not good enough and does not meet their expectations. In the end, the software product is released with some problems and fails to meet expectations. The responsibility is put on the developer, and the leader again offers a gorgeous reconstruction plan or a second-phase plan.

2. Purely technical

There are many such leaders, who may be promoted from the top talents within the team or from outside. They have one thing in common: they love to “play” with technology. Such leaders may have too much “engineer temperament” and may be resistant to or not good at management, personnel, project progress, customer relations, etc. They believe in the free working atmosphere of large Internet companies and advocate “awesome” technology. I met a leader of a team of 20 people. The company had a product with great expectations, which was to be developed using the GO language.

3. Pure management

There are also many team leaders who are not technically skilled but pure managers. Many of them have no problem with management ability, but when it comes to software projects, they often make the team run around in a hurry. Because the number of employees in a software project is difficult to accurately measure, and the technical difficulty (productivity) is difficult for pure managers to grasp, they cannot fully grasp the project, and cannot effectively control the technical risks and time risks in the project.

An ideal Leader should have at least the following qualities:

1. Strong technical ability, but not interested in technology.

I believe this is enough to pass 90% of people. Is it contradictory? No, it is not contradictory. Only those with strong technical ability can be the leader of the software project and control the overall situation. There is no doubt about this. But he must have a clear goal and a big picture, and know what he is doing, because technology and projects are two completely different things. If you want to do a project, don't play with technology. If you want to play with technology, please go to a research institution. Many leaders like to use emerging technologies that they don't understand when taking on new projects, just to add a stroke to their resume, but they have a serious lack of understanding of the risks involved, and even the final effect is far from ideal.

2. Ability to reduce complexity, not add complexity.

This is an extension of the previous point. As a leader, whether you are working on a product or a project, technology is not the goal, but the process of achieving the goal. The more reliable and easier this process is, the lower the cost and the lower the risk. A strong leader can decompose complex target requirements, unravel complex development technologies, and lead the development team to move forward step by step.

From the perspective of enterprises doing projects and products, there is no distinction between "awesome" and "backward" technology. Many people sneer at the technology from two years ago and flock to new concepts. I personally think that such people can only be classified as "software development enthusiasts." Mature technology means reliability, low learning cost, mature solutions, and most importantly: low risk.

In terms of coding, many leaders advocate some awesome writing methods and awesome design methods, and praise the work that is usually completed in 10 lines of code, which can be reduced to 2 lines. If it is a personal project, it is fine as long as you are happy, but for team collaboration and commercial projects, this is not advisable. All goals should be placed on: improving productivity and reducing complexity. Twenty years ago, the awesome coding methods were to save storage costs and operating costs, but now, storage costs, operating costs and labor costs are basically not worth mentioning. The cost of others spending an extra half an hour to understand the code has far exceeded the storage cost of the few bytes you saved, not to mention the losses caused by inexperienced developers' misunderstandings.

3. Have a certain spirit of dedication and be willing to lead everyone to grow

Being a leader of a software project requires a great spirit of dedication, because in traditional industries there is a saying that goes, "Once a teacher, always a father." However, in the IT industry, I have never seen such a thing as becoming a teacher. Just a joke.

Leaders need to be aware of this and work hard to cultivate and educate the development team to help them grow. However, there are not many people who are grateful to you and understand your goodness. However, you still have to do this and find ways to help the team grow, because the more important goal is to make the project and product better. There are many ways. For example, we have tried to organize book clubs in the past. At that time, we found the book "Code Complete", which was explained twice a week in turns. We also organized PPT learning and public reviews, which have achieved relatively good results.

4. Strong desire and ability to control

I think a person without a desire for control is not capable of taking on important tasks. Only with a desire for control can one talk about control ability. As a leader of a software project, facing a complex external and internal environment, the test of control ability is great.

The risks in the external environment may include higher expectations from the company or customers, the timing of the most challenging issues, and uncertain target requirements. As a leader, you must be able to resolve these risks.

The risks in the internal environment mainly come from personnel, such as staff shortages and teams with uneven levels of competence.

I once led a team that was basically composed of novices. The software product that the client wanted had to meet high design indicators and had strict deadlines. At this time, the desire for control and control played a basic role. The software was highly modularized, and all the core functions were designed and written by myself. I organized the team to the conference room to teach them how to write plug-ins while looking at the projector, and found a representative function to implement. I made mandatory requirements for the implementation method and coding style, and asked them to copy it, and required them to achieve a high degree of uniformity in the code style. All the details of the UI part were highly mandatory, and a UI DEMO was specially made to explain the layout method, spacing, margins, etc. of the elements on the UI. In addition to several project meetings per week, there are at least two code reviews. Considering the actual level of the team members, I will help them rewrite during the review at the beginning, and discuss line by line, telling them how to analyze, how to design, and how to write. If it is not compliant after several times, they must rewrite it even if they work overtime. After a period of running-in, everyone gradually got into the state and formed a strong cohesion and combat effectiveness.

5. Be sincere to others

Although it is placed at the 5th point, it is the most important point. If this cannot be achieved, all the above are just empty words.

As a team leader, you must be honest with your team members, help them if you can, and don't talk about other things when you are not particularly good at something, or put down your team members. Many people can't do this. In addition, you must have a basic understanding of the work and life of your team members, whether they have a lot of pressure in their family life, whether they have family members to take care of, whether they live far or near, and whether the company's salary is too low. As for how to do it, I think it's unnecessary for an adult to say more.

6. Other basic qualities will not be elaborated on here.