初次做技术领导的3个陷阱
2016-03-31 08:49
381 查看
Don’t miss the author’s earlier post on the 5 Tips for Being an Effective Tech Lead.
不要错过作者之前发表的文章高效技术领导的5个锦囊妙计
The first time a developer steps into the role of a Tech Lead can be difficult. The skills and experience of a seasoned developer do not automatically translate into the skills necessary for the Tech Lead role. In fact, some of the habits of a developer can do more harm than good, when not applied well and with more authority in this new role.
开发人员初次走进技术领导（后文简称TL）这个角色的时候都是很困难的。即便经验再丰富的开发人员，他的技能和经验也是不能自动转换成一个TL必备的技能的。事实上，如果开发人员不能很好地运用已有的技能和经验，或者不能在这个新角色中树立更多权威，一些旧有的习惯不但没有帮助，反而会带来阻碍。
In this article, we explore three common traps a first time Tech Lead experiences, and what they can do to avoid them.
这篇文章，我们一起来探索一下初次做TL时容易踏入的三个陷阱，以及他们可以做些什么来避免绕过这些陷阱。
开发人员初次做TL往往会手痒痒想去写代码。事实上，他们很容易误认为自己需要通过一直不停地写代码来证明自己的领导力。的确，一个高效的TL是需要一些时间来编写、阅读以及检查代码，但一旦他们花太多的时间去编码，其他的职责就容易被忽略掉。例如，创造一个技术愿景，以及确保团队成员理解核心的系统质量属性。
A lack of technical vision might lead to three different implementations, as developers make decisions individually about what they feel is best, or a deployment might fail because developers are not aware of operational constraints or environmental differences in production. Worse yet is when the code must constantly be reworked because a developer chooses to do something differently without considering maintenance, or how the system may evolve over time.
缺乏技术愿景可能会导致三种不同的实现，开发人员会觉得他们自己想的是最好的，或者部署可能失败是因为开发人员不知道操作约束或者生产环境的差异。更糟糕的情况是，如果一个开发人员不考虑维护性而选择了非主流的方式，或者压根不知道系统是如何随着时间推移而演变，他们写出的代码就必须不断地被改写
The more experienced Tech Lead understands that they must balance their time to code with other responsibilities. They split their time daily, or at the very least weekly, to ensure that they spend time addressing other responsibilities including building a shared architectural vision, identifying and addressing technical risks, being involved in planning sessions and focusing on team and code cohesiveness and consistency.
稍微有些经验的TL知道他们必须平衡编码和其他职责的时间。他们将时间以天为单位或者至少以周为单位进行分割，这样就能确保关注到其他职责。比如，构建一个共享的架构愿景，识别和解决技术风险，计划会议以及关注团队和代码的内聚性和稳定性。
一个新的TL通常是团队中经验最丰富的开发人员，他或许会有种压力感导致他们要做所有的技术决定来证明他的权威和影响力。TL一个人对技术说了算意味着他成为了团队的瓶颈，此时团队离开了TL就无法取得进步了，团队其他成员也会失去动力，因为TL做了所有的重要的决定意味着他们的贡献都被否定了，而这只会让他们心生不满。
The more experienced Tech Lead realizes there are different ways of making decisions, and often, the best decision comes from using the breadth of experience and knowledge from the entire team. They might draw upon the following techniques, depending on how critical a decision is, how quick a decision must be made and how much commitment they want from team members:
有经验的TL知道他们可以有很多种方式去做决定。通常，最好的决定是源自于整个团队的经验和技能，而非某个个体。下面列出的一些值得借鉴技巧，而它们取决于决定的重要性、紧急程度以及他们想要从团队成员中获得多少的承诺：
Only delegating - A Tech Lead gives the decision to someone else without any other interaction
Offering advice - A Tech Lead delegates the decision to someone else, but offers their input and opinions for consideration
Inquiring - A Tech Lead delegates the decision to someone else, but inquires about the outcome and factors that led to the decision afterwards
Building consensus - They bring all team members together to find a solution that everyone is happy with
Consulting with the team - They invite opinions from team members, synthesise the information, but ultimately make the final decision
Being autocratic - They use the information they have to make a decision, choosing to involve or not involve team members, but inform everyone about the outcome.
仅仅委派 - 在没有任何沟通的前提下，TL将决定告知某个成员。
提供建议 - TL将决定委派给某个成员后，还提供了输入和自己的建议。
询问调查 - TL将决定委派给某个成员后，还对后续的产出和影响因素做了跟踪调查。
达成共识 - TL将团队所有成员召集起来，让大家对某个决定达成共识。
独裁专制 - TL运用自己已有的信息去做决定，至于要不要和团队成员商量完全看自己的意愿，最后将结果告知大家。
一个团队是一群有共同目标的人在一起工作。新的TL可能会误以为他们的角色就是在所有的技术方面做出表率，而忘了关心团队是怎么一起工作的。虽然像团队领导者和项目经理这样的角色也肩负这个责任，TL也要带领着团队像同一技术方向前进。
It is all too easy for the first time Tech Lead to ignore heated discussions between two developers, or to ignore how technical team members interact poorly with or disrespect non-technical team members.
同样，新的TL也很容易忽视了两个开发人员之间激烈的讨论，或者忽视团队技术成员对非技术成员的不理睬和不尊重。
The more experienced Tech Lead realizes that the lead part of their role is just as important as the tech, and constantly looks for ways to build trust and relationships between people in the team. They use practices like white-boarding architectural diagrams as a team, establishing coding or architectural principles with the team to guide individual decisions or running regular improvement katas or retrospectives.
而一个有经验的TL会意识到这个角色领导意义如同技术一样重要。他们会不断地寻找方法在团队中建立信任和良好的关系。一些好的实践，如将团队描述成一个白板架构图，建立编码和架构原则来指导个人决策，或者做定期改进提升以及回顾。
The first time Tech Lead can easily fall for a number of traps, often caused by habits developed from their time as a developer. To overcome these traps, they must find ways to strike a balance between their technical and leadership responsibilities.
初次做TL通常会容易掉进一些陷阱，这跟他们做开发是养成的习惯有密切关系。为了绕过这些陷阱，他们必须找到有效地方法来平衡技术和领导责任。
Find out more about the experiences of other Tech Leads in Patrick’s book ‘Talking with Tech Leads’. You can download a free sample of the book here.
在Patrick写的《Talking with Tech Leads》书里可以找到更多关于TL的经验。你可以下载一本免费的样本。
作者博客
不要错过作者之前发表的文章高效技术领导的5个锦囊妙计
The first time a developer steps into the role of a Tech Lead can be difficult. The skills and experience of a seasoned developer do not automatically translate into the skills necessary for the Tech Lead role. In fact, some of the habits of a developer can do more harm than good, when not applied well and with more authority in this new role.
开发人员初次走进技术领导（后文简称TL）这个角色的时候都是很困难的。即便经验再丰富的开发人员，他的技能和经验也是不能自动转换成一个TL必备的技能的。事实上，如果开发人员不能很好地运用已有的技能和经验，或者不能在这个新角色中树立更多权威，一些旧有的习惯不但没有帮助，反而会带来阻碍。
In this article, we explore three common traps a first time Tech Lead experiences, and what they can do to avoid them.
这篇文章，我们一起来探索一下初次做TL时容易踏入的三个陷阱，以及他们可以做些什么来避免绕过这些陷阱。
1. 所有时间都在编码
A first time Tech Lead will miss writing code. In fact, it is easy for them to assume that they need to demonstrate their leadership by writing code all the time. Although effective Tech Leads need to spend some time writing, reading and reviewing code, other responsibilities are left unfulfilled when they spend too much time writing code, - such as creating a technical vision and ensuring that the team understands key system quality attributes.开发人员初次做TL往往会手痒痒想去写代码。事实上，他们很容易误认为自己需要通过一直不停地写代码来证明自己的领导力。的确，一个高效的TL是需要一些时间来编写、阅读以及检查代码，但一旦他们花太多的时间去编码，其他的职责就容易被忽略掉。例如，创造一个技术愿景，以及确保团队成员理解核心的系统质量属性。
A lack of technical vision might lead to three different implementations, as developers make decisions individually about what they feel is best, or a deployment might fail because developers are not aware of operational constraints or environmental differences in production. Worse yet is when the code must constantly be reworked because a developer chooses to do something differently without considering maintenance, or how the system may evolve over time.
缺乏技术愿景可能会导致三种不同的实现，开发人员会觉得他们自己想的是最好的，或者部署可能失败是因为开发人员不知道操作约束或者生产环境的差异。更糟糕的情况是，如果一个开发人员不考虑维护性而选择了非主流的方式，或者压根不知道系统是如何随着时间推移而演变，他们写出的代码就必须不断地被改写
The more experienced Tech Lead understands that they must balance their time to code with other responsibilities. They split their time daily, or at the very least weekly, to ensure that they spend time addressing other responsibilities including building a shared architectural vision, identifying and addressing technical risks, being involved in planning sessions and focusing on team and code cohesiveness and consistency.
稍微有些经验的TL知道他们必须平衡编码和其他职责的时间。他们将时间以天为单位或者至少以周为单位进行分割，这样就能确保关注到其他职责。比如，构建一个共享的架构愿景，识别和解决技术风险，计划会议以及关注团队和代码的内聚性和稳定性。
2. 做了所有的技术决定
A first time Tech Lead may sometimes be the most experienced developer on the team, or feel the pressure to make all the technical decisions to demonstrate their authority or influence. When a Tech Lead is making all the technical decisions, they become a bottleneck in the team and the team cannot progress when the Tech Lead is not around. Other team members might feel demotivated when the Tech Lead makes all the important decisions, because their contributions are overruled and this could lead to resentment.一个新的TL通常是团队中经验最丰富的开发人员，他或许会有种压力感导致他们要做所有的技术决定来证明他的权威和影响力。TL一个人对技术说了算意味着他成为了团队的瓶颈，此时团队离开了TL就无法取得进步了，团队其他成员也会失去动力，因为TL做了所有的重要的决定意味着他们的贡献都被否定了，而这只会让他们心生不满。
The more experienced Tech Lead realizes there are different ways of making decisions, and often, the best decision comes from using the breadth of experience and knowledge from the entire team. They might draw upon the following techniques, depending on how critical a decision is, how quick a decision must be made and how much commitment they want from team members:
有经验的TL知道他们可以有很多种方式去做决定。通常，最好的决定是源自于整个团队的经验和技能，而非某个个体。下面列出的一些值得借鉴技巧，而它们取决于决定的重要性、紧急程度以及他们想要从团队成员中获得多少的承诺：
Only delegating - A Tech Lead gives the decision to someone else without any other interaction
Offering advice - A Tech Lead delegates the decision to someone else, but offers their input and opinions for consideration
Inquiring - A Tech Lead delegates the decision to someone else, but inquires about the outcome and factors that led to the decision afterwards
Building consensus - They bring all team members together to find a solution that everyone is happy with
Consulting with the team - They invite opinions from team members, synthesise the information, but ultimately make the final decision
Being autocratic - They use the information they have to make a decision, choosing to involve or not involve team members, but inform everyone about the outcome.
仅仅委派 - 在没有任何沟通的前提下，TL将决定告知某个成员。
提供建议 - TL将决定委派给某个成员后，还提供了输入和自己的建议。
询问调查 - TL将决定委派给某个成员后，还对后续的产出和影响因素做了跟踪调查。
达成共识 - TL将团队所有成员召集起来，让大家对某个决定达成共识。
独裁专制 - TL运用自己已有的信息去做决定，至于要不要和团队成员商量完全看自己的意愿，最后将结果告知大家。
3. 忘记培养团队文化
A team is a group of people working together towards the same goal. The first time Tech Lead might mistakenly see their role leading on all the technical aspects and forget about how the team works together. Although this responsibility may be shared with other roles such as the Team Lead or Project Manager, a Tech Lead must also shepherd the team to move in the same technical direction.一个团队是一群有共同目标的人在一起工作。新的TL可能会误以为他们的角色就是在所有的技术方面做出表率，而忘了关心团队是怎么一起工作的。虽然像团队领导者和项目经理这样的角色也肩负这个责任，TL也要带领着团队像同一技术方向前进。
It is all too easy for the first time Tech Lead to ignore heated discussions between two developers, or to ignore how technical team members interact poorly with or disrespect non-technical team members.
同样，新的TL也很容易忽视了两个开发人员之间激烈的讨论，或者忽视团队技术成员对非技术成员的不理睬和不尊重。
The more experienced Tech Lead realizes that the lead part of their role is just as important as the tech, and constantly looks for ways to build trust and relationships between people in the team. They use practices like white-boarding architectural diagrams as a team, establishing coding or architectural principles with the team to guide individual decisions or running regular improvement katas or retrospectives.
而一个有经验的TL会意识到这个角色领导意义如同技术一样重要。他们会不断地寻找方法在团队中建立信任和良好的关系。一些好的实践，如将团队描述成一个白板架构图，建立编码和架构原则来指导个人决策，或者做定期改进提升以及回顾。
总结
The first time Tech Lead can easily fall for a number of traps, often caused by habits developed from their time as a developer. To overcome these traps, they must find ways to strike a balance between their technical and leadership responsibilities.
初次做TL通常会容易掉进一些陷阱，这跟他们做开发是养成的习惯有密切关系。为了绕过这些陷阱，他们必须找到有效地方法来平衡技术和领导责任。
Find out more about the experiences of other Tech Leads in Patrick’s book ‘Talking with Tech Leads’. You can download a free sample of the book here.
在Patrick写的《Talking with Tech Leads》书里可以找到更多关于TL的经验。你可以下载一本免费的样本。
更多阅读
原文链接作者博客
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 