Shulou(Shulou.com)06/03 Report--

This article mainly explains "how to be an excellent technical Leader". Interested friends may wish to have a look. The method introduced in this paper is simple, fast and practical. Now let the editor take you to learn "how to be an excellent technical Leader"!

Do you need a technical Leader?

First, the first question: do we need a technical Leader?

Some people may object to this role and feel that good developers can make their own decisions and do part of the technical Leader work.

Even with these perfect situations, the delicate balance of vs interests among team members talking openly about each other and discussing the pros and cons before reaching an agreed solution may require the role of technical Leader.

I don't think we should focus on whether this role should exist or not, but it is better to focus on the benefits that his or her responsibilities may bring.

Technical Leader is like every leadership position. A bad leader can make things worse.

What capabilities does technical Leader need to have?

One thing is clear: a qualified technical Leader has a responsibility to help the team make progress.

As a person in this role, he should have very good technical vision / experience and good communication skills. He is responsible for the technical direction of the project or product (or, to be exact, responsible for the results) and acts as the first choice for cross-team communication.

For large and medium-sized teams, the main responsibilities of Tech Leader include:

1) to guide the technical design and development specification of the project

For example. What technology we will use, how we will deliver the project, what patterns we will use, and so on.

2) Analysis of risks and cross-functional requirements

Analyzing risk means reducing it: we can choose a certain method, or there are too many unknowns.

When taking a certain risk, what is the impact on the project? For example. Introduce the new technologies you saw at the meeting.

3) inexperienced new coaches / coaches

Students who are likely to have different experiences in your team. When it comes to project cost, it makes sense when it comes to matching skills and experience. Therefore, we need to pay attention to the training of inexperienced newcomers.

4) focus on cross-team assistance and communication

A project team includes various related role groups, such as research and development, testing, product, operation and even business requirements, etc., other role students may not be as good as developers in technology, they will use different languages, technical Leader will need to focus on this point, and do a good job of coordination and communication.

How to make a qualified technical Leader?

As described in the position, technical Leader is a job that includes both technical and management responsibilities, which should be: technology first, leadership later.

In the actual work process, what points should be paid attention to?

1) advocating technological innovation and change

Advocate technological innovation and change and establish a positive mode of thinking. When a process is slow or cumbersome, try to change it to make it better. One way to do this is to use an OODA loop:

Observe (Observe)

Positioning (Orient)

Decision (Decide)

Action (Act)

In order to correctly observe the details of slow or tedious processes, the best way is to be part of them (for example, famous realism) and experience the same pain as the rest of the team.

You should adopt a mentality of constantly improving a certain situation. It is called "Kaizen" in Japan (improvement law, which originated from Toyota's continuous improvement in production, machinery and business management).

In our research and development process, we want to improve the efficiency and fun of the team, as well as the final delivery of the software project.

2) face failure and success calmly

Things are likely to fail, so don't worry too much about failure

The landing of the technical solution may fail, the development and construction of the project may fail, the deployment may fail, the important monitoring points of the system may be omitted, and the collapse of the system may occur.

If you are fully prepared for failure, it should be easier to deal with.

When things fail, don't look for people to blame! You are a technical Leader, and you have responsibilities and obligations.

Spend your energy solving the problem at hand and learning from it. Of course, don't fall twice in the same pit. If you need to go through the same failure twice to solve the same mistake, then you should have made the wrong decision.

Learning from failure will shape your direction and make better decisions in the future.

Learn to cheer for success

When the team has a sense of achievement, the members will feel happy, and positive emotions will make the rest of the work as good as possible. Small achievements in the celebration phase are very important, such as successful sprints or completed functions.

When someone comes up with a new idea, it may be a method or framework they see at the meeting, and if the idea is realized, it is important that anyone with a new idea should be recognized. This is very useful and will bring more cooperation, creativity and out-of-the-box thinking.

Form may not be so important, a small lunch, perhaps a team building is a good idea, can also unite a happy and positive team.

3) keep the technology

The technical lead has many non-coding responsibilities, but it is important not to ignore the practice of technical activities:

Write code, do proof-of-concept, define interfaces, etc., and your participation will vary depending on the maturity of the team.

Do the code CR and review your code. When newcomers participate in the project, I tend to do most code reviews, and I will be very strict: I will write tests that lead to NullPointerExceptions, I will ask them to follow conventions, use the principle of single responsibility, careful packaging and naming, and so on. I will also elaborate on the reasoning and choices made in these comments. This may challenge the existing way of working and increase the maturity of the code base. The changes they have to make (after review) will soon become fewer.

Ensure that the technology vision exists and is shared by the team. This vision needs to meet the needs of customers. Customer requirements will lead to important limitations, such as. About reuse (an one-off marketing project and years of enterprise efforts …... Note, however, that this type of constraint may also change. Sharing the way you and your team achieve this vision will have a huge impact on its adoption. Try to involve the team in the technology vision. And make sure they know how they can contribute to achieving that vision.

Pay close attention to the evolution of the code: over time, the actual amount of coding you do may be lower, but you need to keep abreast of the evolution of the code. You need to understand the system and its technical limitations.

Most, if not all, developers will be happy to define frameworks, promote certain methods, and so on. However, some non-functional requirements (also known as quality attributes) (such as network, security, deployment, and consistency) are often ignored.

4) good time management

As a technical Leader, you should always serve your team; ask questions, support, coach, or make decisions.

Technical design prepares the team (including you) to work. Make sure you are clear about what needs to be implemented and how. This usually takes into account many quality attributes, such as network, security, and so on.

Business: talk to customers, review their needs and goals, and match them to the technical vision of the project.

Project management: define user stories, estimate, and follow up.

Code: write code, conduct code review, etc.

For each person and each project, the percentage allocated will obviously vary. It is also important to look at the actual situation, because it can help you understand the time spent.

5) become a team mentor

Mediator: the technical supervisor should be a mediator for discussion. When people have different opinions, you should accept this. Because it means they care enough about something to talk about it. Finally, we work towards the same goal. Everyone can learn from the opinions of others. Get the team's opinion and try to reach a consensus. If reaching a consensus is really impossible and a decision needs to be made, make a decision. Indecision always leads to more discussion.

Mentor: the technical supervisor should be the mentor and teacher of the developer. When you look at the code or explain certain conventions, it is important to clearly explain why you perform certain actions in a particular way.

Effective authorization: after a period of time, your team will adopt some best practices and require less (rigorous) audits or more people will conduct reviews. At this point, you can also provide ownership of user stories to more developers. By transferring ownership to developers, they will be very active in doing a good job. The technical supervisor should not try to take full responsibility. The technical supervisor needs to make sure that someone is held responsible.

Match goals: match the developer's personal goals with the larger goals of the project and organization. This is specifically targeted dynamic guidance. Dynamic, because the goal can be changed. Communication is very important when matching goals: it makes people feel valued.

Optimize for the team: individuals on the team are very important, but when it is difficult to find consensus, you should focus on the team. The team that cooperates well will perform better, and the team members who perform well are happy members.

A good technology Leader:

Know when to give input

Know when to make a decision

Know when to step back and give the team more ownership.

Share responsibility and give ownership, but remain responsible at the same time.

6) learn to make an evaluation

Hofstadt's law: even if you take Hofstadt's law into account, it's always longer than you expect. -- Douglas Hofstadter

Project man-hour evaluation is difficult, if you do this often, you will get better, but you are still likely to make mistakes.

As a Tech Leader, you may need to estimate before the team's actual requirements are developed. It is easier to understand the arrangement and adjustment of implementation cost and priority.

To achieve this, I suggest using a three-point estimate, an optimistic (Optimism abbreviation: O), a best guess (Best Guess abbreviation: BG) and a pessimistic estimate (Pessimism abbreviation: P), and use this formula:

(O + 4BG + P) / 6 / / get the weighted average

It is estimated to represent the ability of the team to execute; it is not the ability to implement it yourself. Also make sure you know your deliverables. This may include more than just code and deployment tools, such as code CR, interface documentation, etc.

Mastering evaluation is a lifetime journey, and it will make you different. Partners will associate you with professional, stable and high-quality work.

7) be good at communication and docking with the outside

The language used by non-technical stakeholders may be different from that of the development team. Technical Leader must find a way to communicate ideas in a way that non-technical people can understand.

In the DDD (domain-driven design) world, this means establishing a common language for connection contexts.

Work closely with customers to try to detect requirements from them and constantly associate their needs with ongoing implementation.

As a technical Leader, as a key contact in external communication and cooperation, communication and cooperation with other technical Leader is also indispensable.

There are many reasons to associate yourself with other technology Leader.

At the personal level, it provides an opportunity to learn from their peers: how they advise the team and how they allocate time among the roles' different responsibilities.

At the organizational level, consideration should be given to whether there is a clearly understood overall goal. It is important to follow up on the landing of the technical architecture design to ensure that your product works well with other components and that larger systems are consistent. It is possible to rely on the products of other teams or members of other teams, so make sure that these factors are taken into account when preparing project scheduling.

This coordination is a real problem for larger organizations or customers. It is necessary to invest some time to avoid accidents beyond your control.

At this point, I believe you have a deeper understanding of "how to become an excellent technical Leader". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.