开发人员第一次担任技术主管一职可能很困难。 经验丰富的开发人员的技能和经验不会自动转换为技术主管角色所需的技能。 实际上,在这种新角色中,如果开发者的习惯应用得不好并且拥有更多的权限,那么他们的某些习惯弊大于利。
在本文中,我们探讨了三种常见的陷阱,这是第一次技术主管的经历,以及如何避免这些陷阱。
1.全职编码
第一次技术主管将错过编写代码的机会。 实际上,对于他们来说,很容易假设他们需要一直通过编写代码来展示自己的领导才能。 尽管有效的技术负责人需要花费一些时间来编写,阅读和检查代码,但是当他们花费太多时间编写代码时,其他职责就无法实现,例如创建技术愿景并确保团队了解关键的系统质量属性。
缺乏技术远见可能会导致三种不同的实现方式,因为开发人员会分别决定自己的最佳感觉,或者部署可能会因为开发人员不了解生产中的操作限制或环境差异而失败。 更糟糕的是,由于开发人员选择以不同的方式进行某些工作而不考虑维护或系统可能随着时间的发展而必须不断重新编写代码的时候。
经验更丰富的技术主管了解他们必须在编码时间和其他职责之间取得平衡。 他们每天或至少每周一次分配时间,以确保他们花时间处理其他职责,包括建立共同的架构愿景,确定和解决技术风险,参与计划会议以及关注团队和代码的凝聚力和一致性。
2.做出所有技术决策
第一次担任技术主管有时可能是团队中经验最丰富的开发人员,或者感到需要做出所有技术决定以展示其权威或影响力的压力。 当技术负责人做出所有技术决策时,它们会成为团队的瓶颈,并且如果技术负责人不在身边,团队就无法进步。 当技术负责人做出所有重要决定时,其他团队成员可能会感到沮丧,因为他们的贡献被否决了,这可能会导致怨恨。
经验更丰富的技术主管意识到做出决策的方式不同,通常,最好的决策来自使用整个团队的经验和知识的广度。 他们可能会采用以下技术,具体取决于决策的关键程度,必须快速做出决定以及他们希望团队成员做出多少承诺:
- 仅委派–技术负责人无需其他任何互动即可将决定权交给其他人
- 提供建议–技术负责人将决策委托给其他人,但提供他们的意见和建议供考虑
- 查询–技术负责人将决策委托给其他人,但随后查询导致决策的结果和因素
- 建立共识–他们将所有团队成员召集在一起,找到每个人都满意的解决方案
- 与团队协商–他们邀请团队成员的意见,综合信息,但最终做出最终决定
- 独裁–他们使用决策所必需的信息,选择让团队成员参与或不参与,但将结果告知所有人。
3.忘记培养团队文化
团队是一群为实现同一目标而共同努力的人。 第一次,技术主管可能会错误地看到他们在所有技术方面都处于领导地位,而忘记了团队如何合作。 尽管可以与其他角色(例如团队负责人或项目经理)分担责任,但是技术负责人还必须引导团队朝着相同的技术方向发展。
第一次,技术主管忽略两个开发人员之间的激烈讨论,或者忽略技术团队成员与非技术团队成员之间的不良互动或不尊重他们,都太容易了。
经验更丰富的技术主管意识到他们角色中的领导部分与技术一样重要,并不断寻找在团队中建立信任和人与人之间关系的方法。 他们以团队架构白板为例,与团队建立编码或架构原则,以指导个人决策或定期进行改进措施或回顾。
结论
Tech Lead第一次很容易陷入很多陷阱,这通常是由于他们在开发时就养成了习惯。 为了克服这些陷阱,他们必须找到在技术和领导职责之间取得平衡的方法。
翻译自: https://www.javacodegeeks.com/2018/04/three-common-mistakes-of-the-first-time-tech-lead.html