Professional development of programmers: how to be a technical leader

For programmers, most companies offer a number of career development directions:

1. Technical route: Master of Programming, technical expert, architect
2. Management route: Project manager, department head, President
3. Complex route: Technical director, CTO
4. Specialty route: Sales consultant, training Instructor

These lines, it seems, are clear. But for most 26–32-year-old programmers, how to develop, the way to go, the heart may be wandering and entanglements. Technology and management, like fish and Bear's paw, can not be both, this is the parable of the warning. But in real life, fish and paws often have to be balanced. Of the top 4 routes, many positions can be further abstracted into technical leadership. How to be a good technical leader? Here are some of my thoughts.

On-demand service

The highest state of official is to serve the serving. This sentence looks very empty, think carefully is a word of wisdom. However, as a technical leader, the need to be cautious is not without the spirit of service, but the service is too enthusiastic. For example, a new technology leader, when received a task, may worry about what to do if a co-worker does badly? So the hardest part of the task to work overtime, the rest of the remaining part of the work to colleagues to do. This kind of compulsory service is not a kind of help to the subordinate colleagues, but an occupation. Will let oneself very tired, at the same time let the colleague lacks the achievement feeling: the matter as if all is the leadership to do, oneself just plays the handyman.

A better way to deal with it is to hand it over to your co-workers and tell them that they can discuss it and work it out if they are in trouble. This will make you more relaxed and allow your co-workers to grow. On-demand services, rather than wishful thinking, will make the team grow better and faster.

Delegation and authorization

A lot of technical leadership, usually used to the forefront, received the task of the first response is: How to solve this task? Even within 10 minutes, the brain has disassembled the requirements into code snippets. This is not an effective leadership habit. A more appropriate and effective first response is: Who on the team is best suited to accomplish this task? Delegate the task to the appropriate colleagues to be responsible. Task dismantling analysis, time evaluation and so on, trust colleagues, let colleagues feedback to you, rather than hands-on.

Account for the task itself, not the implementation

Encountered a scene: leading to a task A, thinking can be implemented using method B. So entrust subordinates to complete method B. Result Method B does not complete task A, causing task A to postpone. As a leader, to account for the task, must be faithfully passed, and subordinates can discuss the implementation of methods, but should not be directly to think of their own way as the task itself assigned.

Sense of participation, belonging and fulfillment

pipelined operation, high efficiency, but not suitable for the software development industry. The main body of software development is human, is the emotional programmer. As a leader, do not take the initiative to open various meetings for subordinates. A project early requirements discussion, research and analysis, to be as far as possible to involve developers. Participation enables team members to develop a sense of teamwork early on. In this way, the real development, just as their own children to write the code carefully. After the project is released, this is the honor of the entire project team member. Otherwise, leaders attend meetings, subordinates just write code, pipelining Division of labor, we will have a single thought, have to live on the dry, did not live on Google Reader. Lack of a sense of belonging and a sense of achievement, make the product is absolutely not good where to go.

Trust and respect

When you tell a task, trust your co-workers to do it well. For technical leaders, to account for certain important tasks, often can not help themselves in the mind to think about the expected solution, and expect colleagues to solve the solution and their own sorta. When the colleague's solution once and oneself not at the same time, should pay special attention at this time, must not the colleague's proposal direct negation. To know how to respect, even if their own solutions better, but also to give a tactful advice, and reflect on why the original allocation of tasks, did not take the initiative to find colleagues to discuss their own expectations of the program.

Modesty, frankness and openness

For what you know, remain humble, and teach colleagues as much as possible, keep an open mind.
For what you do not understand, be frank and outspoken. Pretending to be a cat's eye will only make subordinates despise.

Criticism

Criticism of subordinates, words need not much, point to can.

A generous compliment and a celebration

When subordinates perform well, they should give compliments appropriately in public places. In the weekly report, the Mail, should mention the team's achievement and the merit. When you finish an important project, a proper dinner party is celebrated. In these dribs and drabs, sometimes inadvertently can cultivate a team sense of honor.