好的技术领导,不好的技术领导

本文是翻译,版权归原作者所有


受Ben Horowitz的《Good Product Manager, Bad Product Manager》启发,一个简短的技术领导力的指南。

团队合作

好的技术领导就像团队成员之一,他们认为只有团队成功了,才是自己的成功。他们分担脏活、扫清障碍,便于团队100%地运转。他们设法扩大团队的技术能力,确保关键系统的了解不局限在一两个人的脑子里。

不好的技术领导为自己做广受关注的工作,带有动机地做能为自己带来好处的工作。他们局部优化,普遍使团队成员做一些 以高的工程师组织代价给团队带来好处 的项目。

技术愿景

好的技术领导有一个总体的、产品的技术方向愿景,确保团队理解它。他们授权其他团队成员的特征区域(feature areas),让他们自己做决定。他们认为团队成员是聪明的、信任他们、依靠他们来处理项目的重要部分。

不好的技术领导抵制澄清技术方向,并代替团队做决定。他们把关键的经验知识保留在脑袋里,而不能通过创作和传播有用文档来扩大效果。

讨论和辩论

好的技术领导倾听和鼓励辩论。当团队辩论没有结果时,他们描述一个过程或思考框架来帮助团队自己解决。他们不会介入已有结果的讨论,常常让他们折服于伟大的想法。

不好的技术领导放纵辩论持续很长时间而没有解决方案,妨碍团队生产效率。其他领导贸然地终止辩论,或者说事情“已经搞定了”而解散讨论。不好的技术领导相信 他们自己赢得辩论 比 团队找到正确的结论 更重要。

[caption id=”attachment_260” align=”alignnone” width=”900”]Amazing comic courtesy @blackmad Amazing comic courtesy @blackmad[/caption]

项目管理

好的技术领导具有前瞻性。他们确保技术进程处于正确的轨道。他们和团队成员一起评估、建立中间的里程碑。他们深入关心的区域,确保在问题出现之前搞定。他们甄别技术路障,帮助团队绕过它们。他们识别出工作能够被共享的重叠区域,相反地,找到那些没有引起足够重视的地方,然后投入相应的资源。

不好的技术领导是被动型的。他们可能授权,但不会将 保证进度完成 贯彻到底。他们不会设立中间目标,希望一切最终会OK。他们会等到午饭前去做复杂系统的衔接测试。他们允许成员把时间浪费在有趣的、而不重要的工作上。

务实主义

好的技术领导务实,在做对事情和完成事情之间找到平衡。为了权益他们会砍掉不重要的东西,但是从来不会偷懒。他们鼓励团队找到阻碍整个进度的问题的临时捷径或变通方案,为了午餐构建最小的可行方案。对于好的技术领导,注重细节。代码质量、代码review以及测试,与按时发布一样重要。

不好的技术领导短期内寻求捷径缩短时间,但长期看浪费时间,堆积技术债务。他们不能区分 何时寻求权宜之计 和 何时追求完美。

沟通

好的技术领导知道他们的角色不仅仅是写代码,知道有效的沟通是他们工作的重要部分,知道花时间使团队更有效率是值得的。他们承认一些沟通成本对于团队运作是必要的,他们为了团队整体效率而牺牲个人效率。

不好的技术领导相信他们写代码最有效率,认为沟通分散精力。他们优化工作不是为了团队总体效率,而是为了自己更好地工作。当他们不得不花时间领导的时候,会感到沮丧。

与产品的关系

好的技术领导与产品经理和设计师沟通产品应当如何运行。他们不惧怕推倒刚才通过的决定,但是心里牢牢把握产品目标,知道何时顺应他们。他们建议可替代的、技术要求少的产品规划,以找到技术约束的创新性应对方案,帮助产品经理和设计师理解技术挑战,以便于他们自己权衡。

不好的技术领导把产品决定“抛之脑后”,不能取得产品所有权。他们因技术约束而推后,不会提供可替代的方案或解释。

应对变化

好的技术领导适应产品需求的变化,从容应对。他们预先在变化发生的地方,设计好相应的代码。

不好的技术领导面对需求变化感到悲观,或者过早地在事实上不可能发生变化的地方推广他们的设计。

个性

好的技术领导容易相处却坚定自信。不好的技术领导喜欢反抗且好斗。好的技术领导表现自然,靠技术竞争和经验赢得尊重。不好的技术领导认为,他们的职位授予了尊重和权力。好的技术领导总是寻找提高的方法。

不好的技术领导收到反馈会处于防守。好的技术领导谦虚,增加团队其他人的信心。不好的技术领导骄傲自大,以使队友感到自卑为乐。

原文地址:https://medium.com/p/948b2b806d86/

译文:好的技术领导,不好的技术领导 》| 腊八粥