文档结构  
翻译进度:已翻译     翻译赏金:0 元 (?)    ¥ 我要打赏

在一个有很多 小团队 的工程组织里面,培养技术主管是非常重要的,因为他们既可以成为成功的工程师,又能成为有效的导师。实际上,对于不同的公司、团队或个人,一个技术主管具体是什么样子有很大的变数。在HubSpot,我们对技术主管(Tech Lead,TL)的定义明确表示出这样的意思:他们应该把大多数时间花在产品上,而不是在人员上。

TL负责新工程师入职培训,并帮助他们完成好他们的职责。但仅仅这一点不应当成为一个TL的全部责任。那么,为什么新的TL经常抱怨他们没有足够的时间来写代码呢?

第 1 段(可获 1.4 积分)

在成为仆人式领导(Servant Leadership,一种无私的领导哲学)和保持原来的多产的个人贡献者之间把握平衡是非常困难的。我花了不少时间来适应这一点。在我第一年的TL生涯中,下面这句指导性的“咒语”帮了我很大的忙:努力成为其他人的力量倍增器(Force Multiplier)。这意味着随着时间的推移,找到办法来大幅增加你的同事的工作效率,来偿还你自己的工作份额。当你激励了你的团队,你不仅仅能够回收作为个人贡献者的时间,而且能让你的团队独立完成令人惊异的事情。(转发至推特

第 2 段(可获 1.24 积分)

没有一种银弹(Silver Bullet)是能够适用于所有团队的情况。下面是对我来说行之有效的一些经验,或许能帮助你们回到成为一个成功的个人贡献者和一个有效的领导的道路上。

授人以渔

成为一个TL不久之后,我发现我要面对团队遇到的所有问题,就好像为这些问题找到答案是我个人的责任一样。我有点过度采纳了“仆人式领导”的做法。正如你能想象到的,这样卷入每一个问题会花费很多时间。

第 3 段(可获 1.25 积分)

为什么你要默认地花费自己的时间,来调查那些你本来能够指导你聪明的队友自己完成的事情呢?

如今,我试图成为街道地图,而不是做司机。我会很快承认我对某个问题完全不清楚——这经常发生——但我会描述我下一步会做什么来弄清楚这个问题,或者团队里还有哪个人能够帮忙。我很可能会介绍这两个人认识,或者就一个新的工具对他们进行一次即兴的速成培训,帮助他们解决问题。

第 4 段(可获 1.31 积分)

我喜欢这种策略,因为这让提出这个问题的人为自己的问题和解决方案负责。这种方法对团队人员的好处会随着时间的推移指数级增长:

  1. 他们会学到如何使用工具来解决他们自己的问题(指标、监测、调试、内部工具等)
  2. 他们会学到如何查阅新的资源,这些资源可能会为很多未来的问题提供答案(源代码搜索,内部wiki,知识库,外部文档等)
  3. 他们会在公司里结识他人,建立新的联系

现如今,我的队友有很多我不具有的技能和知识。比起我自己学习这些要花费的时间来说,目前我们的团队和产品情况好得多,因为我没有坚持在他们学习这些之前学习同样的内容。授团队以渔,并授权他们自由支配工具来解决问题,对于帮助团队扩展和取得更大成就非常重要。

第 5 段(可获 2.14 积分)

放弃Atlas的角色

在希腊神话中,Atlas是被惩罚来背负地球与天堂分开的神。从一个很小范围的视角,我看到了Atlas与像我这样的团队技术主管(TL)的角色之间的相似性。

作为一个TL,看着我的团队全力投入开发激动人心的新特性,解决有趣的技术挑战,表达他们的职业志趣,我很开心。对于我来说,当我们演示了新特性,或者获得了一个巨大的性能提升,并且我的组员独立完成了100%的代码时,我会非常激动。(这就是我希望我们团队能到达的“天堂”。)

第 6 段(可获 1.3 积分)

实际上,我负责的产品内容涵盖了大部分每周的中断性的任务。这些任务未经计划,可能对时间敏感,而且经常没有一个明确的解决方案。他们可能是顾客提交的支持问题,可靠性的顾虑,或者是公司其他团队的内部请求。(这些正是我为了保护团队成员,要主动承担的问题,正如Atlas要背负的地球一样。)

我的一位团队成员最近告诉我,她特别开心能够全心全意有机会学习使用一个新的框架,并把它应用在一个重要的重新设计上。这正印证了一个当下流行的生产力准则:生产者需要一段很长的不被打断的时间来提供最高的效率。

 

第 7 段(可获 1.59 积分)

听了她的话,谁忍心为了一个bug来打断这个人呢?但这种方法终极的缺点就是,你需要独立承担这些中断性的、琐碎的工作,而这些工作很快就会让你应接不暇。或许你应该为你的团队提供集中解决更重要问题的完整时间,但你自己又如何能有充分的时间来解决你自己的项目,策略性地思考,并帮助你的组员成长呢?

我仍在思考这个事情,但我发现将到来的问题与每个组员的技能和专业知识进行匹配是非常有效的。如果组员已经对于相关的代码非常熟悉,你可以很容易地让他们在方便的时候暂停主要项目,来解决这个问题。如果时间和工作量允许,我甚至会把问题交给一个不熟悉这个问题的工程师来解决,从而拓展他们的技能。

第 8 段(可获 2.01 积分)

如果我在JIRA(Atlassian公司出品的项目与事务跟踪工具)上点击“指派”时产生了犹豫,我会直接去问“喂,你有时间在接下来的1-2天处理一下这个支持问题吗?”我这么问的目标是开始一个关于优先级、紧迫性的透明写作式的讨论,为下面要做什么设定期望。

我的主要目标是将维护工作的痛苦与每个团队成员的责任进行对齐,从而实现高质量的工作。团队成员会为他们做的改变而负责。他们也会被求助到他们做过的工作,因此花时间来仔细理解相关代码,而不仅仅是为了解决bug而解决bug对所有人都有好处。

第 9 段(可获 1.61 积分)

最后,我想强调偶尔体会一下这类压力对整个团队都有好处。当有大量的bug需要处理,或是积压了大量技术债的时候,让团队里的所有人一起负责这些问题,会给他们带来清理掉旧账的满足感和主人翁的感觉。

团队需要时间来建立技能和信心,来合作解决任何可能发生的中断性问题。然而,如果团队的工程师从没有被要求对自己的工作负责,或切换工作内容,或是解决他们不熟悉的问题的话,这对于TL来说会是一个巨大的教训。从长期来看,试图扮演Atlas的角色是一个不值得承担的重担。把这个责任分享到整个团队是更好的方式。

第 10 段(可获 1.78 积分)

分享你的宠物石

作为工程师,我们喜欢解决谜题。主动发现一个谜题,并且花时间秘密地思考如何解决它是一件很有吸引力的事情。尽管这能愉悦头脑,但这不是很好或很快解决问题的方式。下面的例子说明了一个有趣的谜题对其他人来说是一个多大的激励。

在过去的几个月,我们注意到 Java 工程编译消耗的时间越来越长。即使在我们将工程编译从Jenkins转移到了 Blazar上面——这么做应该能给我们带来很大的提速——项目的编译时间还是有地方不正常。在漫长的等待问题最为重要的情况下,我们反而致力于解决手头的问题而不是去仔细研究编译时间的问题,因此它很讽刺地没有得到它需要的关注。

第 11 段(可获 1.7 积分)

我现在没有时间来解决这个问题,但希望编译能快一点,因此我总结了所有能想到的细节,并把这些细节丢到了我们组GitHub代码仓库的一个issue(事件)里面。我回过头来继续做自己的工作,并想着我会在一个雨天回来思考这个问题。

但那一天不会到来了,因为我们组的一个工程师很快注意到了这个问题。两周后,在没有任何指派的情况下,他花时间调试了这个问题,并将编译时间缩短了整整10分钟。这为他赢得了团队的感谢,而且编译速度的提升让我们更加有生产力。

如果我自己雪藏了对于这个问题的知识,问题的解决可能不会这么自然地发生。在这个例子中,激励这个人解决问题所需要的唯一条件,是他详细了解到了一个具有很大影响的问题。最重要的是,比起我把它闷在心里,这个问题被更快地解决了。

第 12 段(可获 2.1 积分)

我确保把问题的细节记录到整个团队都能看到的地方,比如GitHub或者是我们的Trello面板里面。在我最近与整个团队沟通的工作中,我开始为团队发送一份简短的本季度我们最大的项目和为什么我们要关注他们的回顾和预告。当我要为团队成员布置新任务时,我经常发现他们已经对这个任务很熟悉了,而且可能已经思考过如何完成这个任务。

自由而开放地分享关于团队面临的挑战的知识,帮助了团队做好准备,并更及时地完成工作。而且,你知道吗?我一点都不怀念这些“宠物石”。

第 13 段(可获 1.64 积分)

写更多的程序,担更少的心

在最开始,平衡技术主管的职责和个人的贡献可能是一个巨大的负担。最重要的是,想想怎样投入你的时间,能够让你成为一个“力量倍增器”。通过集中前期的精力在自治的培养、责任感的培养以及团队的沟通上面,我希望随着时间的推移,你会发现自己把更多的时间花在写代码上,更少的时间花在日常的管理团队的开销上。

第 14 段(可获 0.85 积分)

文章评论