How to Be a good technical leader

For programmers, most companies provide multiple career development directions: 1. Technical Route: programming experts, technical experts, architects 2. Management route: Project Manager, Department Supervisor, and President 3. Compound route: Technical Director, CTO 4. Special routes: Sales consultant and Training Instructor These routes seem clear and clear. However, for most 26-32-Year-Old programmers, there may be insides and confusions about how to develop and what path to take. Technology and Management, such as the fish and the bear's paw, cannot have both. This is a fable warning. However, in real work, both the fish and the bear's paw often have to be taken into account. In the above four routes, many positions can be further abstracted as technical leaders. How to Be a good technical leader? Below are some of my thoughts. On-demand service Serving the people is the highest level of government officials. This sentence seems very imaginary. Think carefully about it as a famous saying. However, as a technical leader, you need to be cautious not about service spirit, but about service enthusiasm. For example, when a new technical leader receives a task, he may be worried about what to do if his colleagues do not do well? Therefore, the most difficult part of the task is to work overtime, and the remaining part is handed over to colleagues. This kind of mandatory service is not a kind of help for subordinate colleagues, but an infringement. It will make you tired and make your colleagues feel less fulfilled: Everything seems to be done by leaders, and you just want to make a noise. A better solution is to give it to colleagues first, and inform them that they can discuss and solve the problem at any time. This makes it easier for you and your colleagues to grow. On-demand services, rather than wishful thinking mandatory services, will make the team grow better and faster. Delegation and authorization Many technical leaders often get used to this task. The first response to the task is: how to solve this task? Even within 10 minutes, the brain has split the requirements into code segments. This is not an effective leadership habit. A more appropriate and effective first response is: who is the most suitable team for this task? Delegate the task to appropriate colleagues. Analysis of task splitting, time evaluation, and so on. Trust your colleagues and let them report to you, instead of relying on your own experience. Instead of implementing the task itself Once encountered a scenario: the leader receives a task a and can use method B to implement it. Therefore, delegate the subordinate to complete method B. Result Method B cannot complete task a, resulting in task a being extended. As a leader, the task must be delivered truthfully. You can discuss the implementation method with your subordinates, but do not directly assign the methods you think of as the task itself. Sense of participation, belonging and achievement Streamlined operations, high efficiency, but not suitable for the software development industry. The main body of software development is people, and it is an emotional programmer. As a leader, do not take the initiative to hold various meetings for subordinates. In the early stage of a project, developers should be allowed to participate in demand discussion and analysis. Participation can help members of the project team form a sense of team as early as possible. In this way, you can write code as carefully as your child during development. After the project is released, this is the honor of the entire project team. Otherwise, when the leaders attend the meeting, their subordinates only write code and work in the pipeline. Everyone will have the idea of taking over the ticket. If they have the job, they will do it. If they have the job, they will not live on Google Reader. Lack of sense of belonging and achievement makes the products absolutely better. Trust and respect When explaining tasks, you must trust your colleagues to do well. For technical leaders, when explaining some important tasks, they may not be able to think about the expected solution, and expect that the solution of their colleagues will keep pace with what they think. When a colleague's solution is different from his or her own, pay special attention to it and never directly deny the solution. We must be respectful. Even if our solutions are better, we should give suggestions in a euphemism and reflect on why we didn't take the initiative to discuss our expected solutions with our colleagues when assigning tasks. Modest, honest, and open Keep modest about what you understand, and teach colleagues as much as possible to keep an open mind. Be honest with everyone you don't know. If you are not knowledgeable about it, it will only make your subordinates look down on it. Criticism Criticism of subordinates. You don't need to talk too much. Just click here. Don't praise and know how to celebrate When your subordinates perform well, they should give praise in public places. The team's achievements and advantages should be mentioned in weekly reports and emails. When important projects are completed, appropriate dinners are celebrated. In these aspects, sometimes the team's sense of honor can be cultivated inadvertently.