ToC:
- Tech Lead
- Tech Lead Model
- Tech Lead in the project lifecycle
- What does Tech Lead care about?
- Improve Tech Lead Ability
- Tech Lead Toolbox
- Summary
From January 19, 2019 to January 20, 2019, I attended my company's (ThoughtWorks) training in Tech Lead conducted by two senior Tech Leads from ThoughtWorks China and another senior Tech Lead from ThoughtWorks Australia. Thanks to the three coachs' hard work, I learned a lot from the short two-day training. The content can only be entered, and some days will be forgotten.
So, I wrote this article both to record what I have learned and to summarize it based on my own "experience."
The article is relatively long, long, long and long, and it is divided into six parts (PS: Fortunately, the Phodit editor supports title folding :). The agenda:
- Define Tech Lead
- What capabilities does Tech Lead need?
- Tech Lead in the project lifecycle?
- What does Tech Lead care about?
- Be better Tech Lead
- Tech Lead Toolbox
Perhaps, you noticed: We are talking about Lead, not Leader. Because when we say Leader, it often refers to the person who has an official leadership position and shoulders the responsibility of leading the team and organizing the organization. And when we say Lead, we are talking about someone who leads us forward. This person can be a leader or another person. Therefore, Tech Lead is a role, not a real position. The significance of this role is to lead other people forward. The definitions of the two are shown below:
Then think about it, who are you working with in your team? When you are doing related technical work, who are you more willing to listen to, is it your leader, or?
As a developer, we hope that someone who will work with us is better than us. We can learn something useful from him/her. As a technician, we serve people who are better than themselves. Given the same feature that takes us a day to implement, he/she might only need one hour - efficiency is higher and quality is better. Such a person is equivalent to Tech Lead in the project. He/she might not a true leader, but technically, we listen to him/her. With his/her help, we can improve our skills and build better applications.
If you have ever been in a hierarchy of pyramidal relationships, try to recall the person in your project or team who your manager often praises with good skills? In a sense, that person is equivalent to the project's Tech Lead. Your manager will ask him/her about some technical issues, and the results of the discussions will often be used in your project.
For Tech Lead, the most important thing is leading not management. Then the question is, what is Tech Lead?
As a result, those who claim to be “Tech Lead” are often not necessarily true technical leader. They undertake the development of the project, just as a project manager, or the head of the team to manage this project; make some technical decisions on the project - what frameworks to use, what services to use, interface docking, no coding jobs. They are equivalent to the Tech Manager of the project.
Now, we have to mention the role of manager. There are four types of managers:
- Expert: a certain area of technical ability is very strong, is an expert in a certain field
- Manager: good at publishing tasks, setting goals, and ensuring goals are achieved
- Coach: ability to develop others, teams
- Leader: know how to achieve goals in the right way, motivate people
Tech Lead is constantly changing between these four roles. First, Tech Lead is a technical expert that solves complex technical problems on projects. Then, can be a Coach who needs help to grow members of the project. Also be a leader, lead by example and tell others/her how to do it. When needed, it will become the Manager on the project to complete the team's goals.
Limited by the organizational structure of different companies, Tech Lead often includes multiple roles - both project managers and technical leaders, and... At ThoughtWorks, Tech Lead can be a purely technical job, while others act as project managers. If you only look at the role of Lead with Tech, then it is:
- **Architect **, **Technologist **. Compared with the project manager and the technical manager, he/she not only focuses on the technical practice and progress of the project, but also has to solve the most complicated technical problems.
- Technical role model. Tech Lead is more like a spiritual “leader” who needs to let other people in the project see the way forward.
- Developer. He/she takes time to write code in the project, which, as defined in the training, takes at least 30% of the time to write. First, master a series of technologies related to the project; second, continue to improve technical capabilities, rather than become managers.
In addition to technical work, he/she also needs to understand the business in order to develop software that meets business needs. There is also a need to manage risk (mainly technology-related risks) in order to respond to changes.
This is the relevant model of Tech Lead.
First, by luck... The pits of each organization are limited - one pit cab only one radish. When I first time a become a Tech Lead, I was work there for about one year. The TL and PM on the project have successively left the company, them join a startup company. In the rest of the people, I am probably the most familiar with the business knowledge and technical knowledge related to the project. I have inexplicably assumed the relevant role. However, this is not important. What is important is that this pit suddenly came out to you. I'm do a poor performance, I'm young need to know what to do.
Second, show your temperament and technical expertise. No one knows what you are good at, except yourself. In this way, you are likely to become the 2nd Tier on the project (referred to as backup). Once people (leader) think you are a seeded player, then the chance to becom a Tech Lead will increase from 0.01% to 1%.
Finally, still by luck... If you are in your organization, there is always a person who is better than you, and this person has been with you in a project. God knows, when you are the second child, when can you turn over. You are still young, can long live longer than others. :)
However, these are not important. What we have to do is always be ready to Tech Lead. So, Improve the skills and master the Tech Lead skills.
In my option, a Tech Lead should have those skills:
- First, you are fast talk.
- Second, know how to draw a dream.
- Then, be proficient in PPT.
- Finally, you will also be proficient in markdown programming. (PS: it's say me - Phodal)
Oh, it doesn't seem right, the above are all jokes.
The chart below shows the scope of Tech Lead's responsibility by Patrick Kua (formerly ThoughtWorks Principal Technical Consultant in UK). In other words, it is the work that Tech Lead has to do.
The content on the map is mainly divided into three parts:
- Developer. As a developer, we should master programming-related skills: object-oriented programming, functional programming, pair programming skills, skilled use of various tools, iterative and incremental design, design patterns, refactoring, automated testing , class design.
- Architect. As architects in the project, we have to consider: cross-functional requirements, evolutionary architecture, buying or making decisions, system design, program evaluation, technology risk management, technology vision and cohesion, focusing on the entire life cycle, Extensive toolset, infrastructure, customer guidance.
- Leadership. As a technical lead, we need to improve these soft skills: feedback, communication, coaching, motivation, relationship building, commissioning, impact, risk management, conflict management, team management.
Ok, I admit that there are too many things to learn, especially for programmers whose goal is Tech Lead. In order to become a good developer, we must grow into an architect, and finally we must improve our leadership. First, we can be the best technical person of the technology, and then we can become Tech Lead. At least leadership, before the technical preparation is sufficient, take the time to pay attention to practice.
Corresponding to this, we also have our own (ThoughtWorks) Tead Lead assessment model. As can be seen from the figure below, it is based on the above figure:
(PS: Welcome to develop your Tech Lead model based on https://phodal.github.io/tla/. Self-test tools use: 1. From 1 ~ 5 Score your relevant abilities and connect the corresponding points one by one. 2. Draw a point on the score you want to improve, and then draw a circle)
In contrast, our Tech Lead model is relatively simple – there are fewer things:
- Leadership. Focus on emotional intelligence, continuous impact, actively develop his/her people, improve efficiency, actively build teams, active risk management, open communication
- Developer. Focus on good coding skills, full-stack development experience, pattern awareness, familiarity with code base, continuous improvement, clear problems, focus on business value, and bridge communication.
- Architect. Focus on architectural vision, focus on principles, systems, not software, support cross-functional needs, and think in the future.
However, from a technical point of view, each dimension is far more important than the above-mentioned responsibility boundary. From the perspective of Leadership, it is more focused – focusing on soft skills based on technology.
In this way, I did say a lot of things, but it was too abstract, but it did not seem to have any practical value. We still have a macro understanding of what Tech Lead is doing. Before that, let's go back to the project and take a look at the daily work of Tech Lead on the project.
In most organizations, what a Tech Lead does, everyone in the day, still sees it clearly. However, not everyone on the project is in this project from the very beginning. Some were added at the beginning, some were added early, and others were added midway.
Therefore, I will follow some of the things that Tech Lead has to do, and then follow the previously defined project three steps , draws a TODO Lists at different times in the project.
It should be noted that only the part that the author thinks is important is listed here (PS: because it is the first version, it may also lack some points). For some less important responsibilities, you can see it in the Tech Lead model above.
When ThoughtWorks start a project, there are two periods: Inception, iteration 0. They all need a senior programmer and architect to participate. His/her main responsibility is to design an architecture that meets the needs of the project. The so-called project needs, it's are not necessarily the most suitable technical solutions for this project. It may be affected by various factors such as stakeholders and organizational structure, resulting in the most suitable solution not being adopted. Like the biggest leader, like the A solution, not the best B solution.
Inception, mainly used to verify the feasibility of technology, business, operations, design, and products. The process requires a Tech Lead as an architect to design a software architecture that meets the needs of the project. According to my understanding, the related process is probably as follows:
In the process, we need to communicate with the stakeholders involved in the project, discuss with the developers... and finally compromise a framework that can barely meet the needs of all parties. We will also sort out the technical risks associated with the project from relevant discussions.
Interation 0. Iteration 0 is the official start of the other developers, the technical work we have to do. It contains the following:
- PoC architecture verification. Verify that the architecture of the system is truly reliable and make some minor adjustments
- Build CI/CD
- Write some pattern code. Write sample code in business functions in a way that conforms to the system architecture style and pattern, princinples, as a reference for others.
In addition, during the technical preparation period, we also need to:
- Technical training for project members
- Design and implement test strategies
- Deployment design and practice
This is a rather long period, because it's hard.
In addition, one of the most important things we have to do at this time is: Isolate the direct demand dialogue between other/her technicians and business people.
For the other members of the team, the source of any functionality and requirements should only come from the business person (from the business needs) or the technical leader (technical requirements) in the team. It should not be communicated directly to other/her developers by business people. Even when Tech Lead and business people are absent, you need to reduce this kind of thing.
Whether it was the previous period or this period, we had to compromise on the progress of business development, ignoring some technical pursuits. This has led to the lack of better implementation in technical practice.
Therefore, as a Tech Lead, we need to establish a series of specifications:
- Set up a whiteboard for technical debt. Begin to repay some technical debts step by step, such as the problem of insufficient test coverage.
- Create a technical culture of the team. Knowledge sharing, knowledge transfer, etc.
- Focus on the growth of team members.
In the process, the new version of the application is continuously released, thus stabilizing the system's deployment architecture.
At this stage, as a Tech Lead, we have to focus on two main parts:
- Architecture evolution. The system has been biased towards stability, but we can explore new ways to help us solve the current problems.
- Cultivation and growth of memberl. Most of the team members are already in the “boring” stage during this period and need some new elements to help him/her grow.
This does not mean that several other aspects of her/her are stable. There will still be some changes, but the scope of these changes is not that great. For example, if some key stakeholders are replaced, then it will take some time to re-sprue.
The last thing I have to mention is: Affected by many factors, the development rate of the project will first fall behind the standard...
As a Tech Lead, we focus on three parts of the project:
- Programming
- People
- Process
Similarly, different work will be performed during different project periods - some of which we have already introduced in the three-step music.
Programming is the basic skill of Tech Lead. No matter how busy we are, we always need to go deep into the code base to understand the problems in the code.
As a Tech Lead, if you want to improve the code quality of the project, ensure the maintainability of the project, and solve the complex problems in the project, then you must join the development of the project. A long time away from the front line, there is a lack of code-related context, and it is difficult to become a Tech Lead and become a Tech blabla. Promotion is a good thing, but programming is still important.
According to our training conclusions, the time to write the code should be >30%. I don't know the source of this value, but it's almost a 1/3 value, so you know.
Which language is the best? 2 spaces or 4 spaces? They have too much controversy. As a Tech Lead, we need to ensure the consistency of the code base in the process of running in, and reduce the diversification in this aspect as much as possible. Of course, there is a certain amount of diversification, such as allowing Vim/Emacs to exist. The debate between the editor and the IDE is a useful thing.
They are worth our time to discuss, rather than shelving the dispute.
As a Tech Lead, we have reason to maintain a good team culture. Try to answer these questions:
- How long does the build stay broken?
- Do people avoid conflict?
- Do people offer new ideas?
- Do people feel okay to admit being wrong?
- Do people flag when they need help?
Then think about where the problem lies.
We need a good technical vision, ahead of the industry, or staying at the top level.
People, is an important factor in a project.
At different times of the project, they have different feelings for different people. This is the flow of heart:
At the beginning of the project, for most people, it is a level of high level of challenge and general level of technology (unfamiliar with the project). In the middle and late stages of the project, for most people, the project is in a state of boring or insensible. In the anxiety period, guide new people; in the boring period, create some technical challenges...
As a Tech Lead, you need to help other people grow up at different times. Consider different dimensions of Interests, Skills, Strengths, Goals, etc., to understand the different stages of each person and help them grow.
In a sense, we need to understand the current position of each team member and then help him/grow. At the start of the project, you can also brainstorm together to understand each of the four appeals of everyone on this project.
A sentence that has to be mentioned:
Group ability = average individual ability + diversity
If there is no objection in the team and it is replaced by silence, then the team is problematic. So, let the voice of opposition be allowed. Even if it is wrong, you need to wait for him/her to finish.
As a Geek, we always think about trying to constantly improve our technology and want to work with those who are good. Often due to a variety of factors, excellent people will always go to new projects. You can only become a good person and lead other people to become good people, so you can work with good people.
To this end, we need to introduce relevant knowledge sharing cultural technology writing, reading sharing, pair programming, code review, technical review meetings and so on.
One key to Tech Lead's assurance of technology implementation is that everyone trusts you. Once everyone doesn't trust you, or if you don't trust yourself, then this project will have problems. It requires us to build a sense of trust step by step.
In addition, when you are airborne to a new team, you face many challenges as a Tech Lead. Unfamiliar code base, test the members of your ability...
Different projects have various processes and have their own time. Here you need Bruce Tuckman's Tuckman Stages of Team Development Model:
which is:
- Formation period. Project team enlightenment stage.
- Storming period. Forms various concepts, fierce competition and collision.
- Norming period. Rules, values, behaviors, methods, tools have been established.
- Performing period. Interpersonal structure becomes a tool for performing mission activities. Team roles are more flexible and functional, and team energy is integrated.
- Adjourning period. The mission is completed and the team is disbanded.
It helps us to have a clear understanding of the team and then take action to help team members clear their goals.
For different people, we also need the Scenario Leadership Model:
Corresponding to different people, you need different ways to lead them to complete the task:
- Directing, informing, giving detailed guidance to the roles and goals of the members, and closely monitoring the effectiveness of the work of the employees, in order to give regular feedback on the work results.
- Coaching, explaining the work content and working methods to team members, while continuing to guide members on how to complete the task.
- Supporting, working with team members to solve problems, develop solutions, and provide encouragement and support;
- Delegating, providing appropriate resources, fully convinced the members' ability, and assigning the task to the employee's full responsibility and independent operation.
In fact, this is a summary of some methods, which are used in our daily lives.
Then, we still need to master and how to effectively express:
- Direction: Determining the direction, clarifying the purpose and importance of communication, why is there this communication conversation?
- Situation: rationalize the situation, clarify the current facts, what problems, doubts, exchange of information
- Solution: Think about the solution, what solutions are there for the current problem, what kind of support is needed, what resources are needed, etc.
- Plan: develop an action plan, how to follow up, how to respond to changes
- Action: Make a summary, summarize the main points of this communication, give confidence / encouragement
The methodology is very much.
Now that we have set the three dimensions of Tech Lead, the corresponding improvement is placed on the improvement of the three dimensions.
For Developer: object-oriented programming, functional programming, pair programming skills, proficiency in a variety of tools, iterative and incremental design, design patterns, refactoring, automated testing, class design..., one can not be less.
Therefore, 10,000 words are omitted here. We will talk in future, in future, in future.
Regarding the architecture-related part, we have already delineated some of the key points to be learned in the above section. Here is an emphasis on evolutionary architecture and cross-functional requirements.
Evolved architecture is an architecture that supports incremental, guided changes as the first principle across multiple dimensions.
Probably, this is an important structure that our company emphasizes.
Cross-functional requirements, which can also be called non-functional requirements, refer to the condition of the system or its characteristics based on some conditions, rather than the requirements for system-specific behavior. They generally end in "xx", that is, English ends with "ility", such as stability (portability). On Wikipedia, there is a related list: List of system quality attributes These requirements can be further divided into two categories 1:
- Execution qualities, qualities that can be observed while the system is operating, such as security and ease of use.
- Evolution quality, quality related to software system structure and development process, such as software testability, maintainability, scalability, scalability, etc.
These cross-functional requirements are that when we start an Inception, we need to constantly consult stakeholders to get what we want. For example, ask the customer for their current number of users to calculate the number of concurrent supports. Understand the customer's availability requirements for the website, ie the downtime allowed by the website within one year:
Description | Popular name | Availability level | Annual downtime --------|------------|-----------| Basic availability | 2 9 | 99% | 87.6 hours High availability | 3 9 | 99.9% | 8.8 hours Availability with automatic failover capability | 4 9 | 99.99% | 53 minutes Extremely high availability | 5 9 | 99.999% | 5 minutes
Higher availability means higher input costs to reduce server downtime.
Recommended books:
- Clean Architecture
Obviously, for a Geek, soft skills are the biggest exam.
In order to properly motivate yourself and his/her people, you need to identify the factors that really affect the inner driving force. The CHAMPFROGS Model mentioned in the book Management 3.0 is 10 intrinsic motivations:
- Curiosity: I have a lot of things to investigate and think about.
- Honor: My personal value is reflected in the team, which greatly enhances my loyalty.
- Acceptance: People around me can prove what I did, who I am.
- Mastery: My work is a challenge to my ability, but this challenge is still within my ability.
- Power: I have enough room to influence what is happening around me.
- Freedom: I am independent of other people. I have my own work and responsibilities.
- Relatedness: I have a good social relationship with people around me.
- Order: There are enough rules and policies to build a stable environment.
- Goal: The goal of my life is reflected in the work I do.
- Status: My location is very good and I am recognized by my colleagues.
Each person sorts according to their own motives and then helps them in a targeted manner:
In the project, it is inevitable to encounter a variety of conflicts, such as conflicts between business people. It relies on us adopting certain patterns to resolve these conflicts.
At this time, we need Thomas-Kilmann Conflict Theory (TKI):
Then take the appropriate strategy:
Negotiations are divided into soft negotiation, hard negotiation, and principled negotiation. For Principled Negotiation:
- Maximize overall interests (pursue common goals and interests behind both parties)
- Be good at creating an open, fair and just competitive situation (with a win-win goal)
- Clear goals, be good at compromise (know and make good use of your relative strength)
- Pay attention to credit
- Seeking common ground while reserving differences (strategy for making concessions and choosing space)
- Use objective criteria (try to understand each other, empathy)
- Apply facts
- People and things are different (do not be right; communicate properly)
To this end, before the negotiations, a series of preparatory work must be done.
Not preparing, it is preparing to fail.
From the initial stage, the project is full of various risks and also contains a lot of technical risks. As a Tech Lead, managing these risks is also our responsibility. Some of these uncertainties will continue to decrease as the project progresses. That is, the cone of uncertainty** describes the evolution of the uncertainty in the project, that is, the uncertainty not only decreases with the passage of time, but also decreases with the risk management, especially the establishment of the decision. . As shown below:
With more research and development, more information about the project is learned, and then the uncertainty tends to decrease, reaching 0% when all remaining risks are terminated or transferred.
To do this, we need to assess how to deal with such risks, and there are four dimensions of presentation:
- Avoid: What benefits will it bring to you when the description is not accepted?
- containment: estimate the possibility
- Moderate: Describe what steps you will take
- Avoidance: Describe the full cost of risk becoming a problem
The corresponding following are the respective effects:
| Cost | General Time | Expected Results | |
|---|---|---|---|
| ︎ Avoid | Future Benefits | Future | ⬇ Possibilities |
| Concession | Opportunity Cost | Now, Future | ⬇ Impact |
| mitigation | time, energy, resources | now | ⬇ possibility ⬇ impact |
| Circumvention | 0 | - | - |
Related information, the article "The cone of uncertainty" tells you why the difficulty of the project has a gap of 16 times: https://zhuanlan.zhihu.com/p/32033094
Project stakeholders include project parties whose actions can influence the planning and implementation of the project, as well as individuals and organizations whose interests are affected (beneficiary or damaged) by the project; they can also be referred to as project stakeholders.
From his/her level of support and approval, we can mark his/her position on the axis:
Correspondingly, different communication strategies are required.
In team conversations, you need to pay attention to some conversation-related styles. Here are four different conversation styles:
You can try to build the relevant influences by using the six principles of influence introduced in the book "Influence: Science and Practice", namely:
- Reciprocation
- Commitment and consistency
- Social proof
- Liking.
- Authority.
- Scarcity.
Everyone has a part that they are good at, starting from the part they are good at.
When we airborne to a new team and become a Tech Lead, it is not an easy task to convince others/hers. To do this, we can try to do this:
- Foreign -> Inclusion: Excellent self-introduction, quickly familiar with the project information, understand and listen to current project issues, quickly familiarize yourself with the team, demonstrate your abilities and commitments
- Inclusion -> Influence: Understand the relevant technical details, clearly show action, initiative, empathy, lead by example, start with small success
- Influence -> Openness: Collect worries, ask/give feedback, talk about gossip, show our weaknesses, admit mistakes, promote meetings/sharing, make a meal together, social activities
These are just some methodologies, first go to prove yourself, and then draw closer to other/her people.
Next, we'll introduce some tools to help us better work on Tech Lead. It is worth noting that they all need constant maintenance.
Path to Production is a visual way to show how an application is online. As shown below:
(PS: related visualization tools are available at: https://phodal.github.io/path/ )
In the process, we focus on the Process, People, Tooling, Artifacts four parts to understand what processes, people, tools and products are needed for a project.
In addition to the purpose of the demonstration, we can find the Pain of the project by finding the duration of each process.
It needs to be continuously updated.
C4 Model is a very good architecture visualization tool. It introduces the system architecture from top to bottom from system level, container Container, component Component and code Code:
Their relationship is similar to:
It needs to be continuously updated.
The ADR architecture decision record is a short text file similar to the Alexander mode (ie: design mode). (Although decisions are not necessarily models themselves, they share the balance of power.) Each record describes a set of forces and a decision to respond to them.
(PS: related tools are adr-tools and https://github.com/phodal/adr for Chinese and Windows)
It needs to be continuously updated.
Technical debt is something you owe and needs to be returned. If you only remember it, you may forget it sooner or later, so you have to visualize it:
As shown in the figure, not all technical debts are worthy of repair. High-cost, low-paying jobs can be done later (long and long, until all people forget).
Technical radar is a very good quarterly technical summary. We can get some of the technical experts' judgments on technology trends and some new technologies that may be used. Rather than spending your time on a lot of different technologies, you can focus on the part you need:
Of course, you can also build your own internal technical radar. As I have tried in a long time ago project, I tried:
It’s been a long time, and the difference between this aesthetic and today is a bit big.
What are your tools recommended?
- Risk-storming
- Six thinking hats
The versatile coordinate axis method allows you to perform related analysis as long as you can design each dimension.
- Slide "What I want to know when I first become Tech Lead": https://www.slideshare.net/thekua/what-i-wish-i-knew-as-a-first-time-tech- Lead
- Article "Tech Lead Responsibility Ring": https://www.thekua.com/atwork/2015/06/tech-lead-circles-of-responsibility/
- Slide "Technical Lead Skills for Developer": https://www.slideshare.net/thekua/tech-lead-skills-for-developers
- Slide "Create Lasting Influence": https://www.slideshare.net/sumeet.moghe/create-lasting-influence