ABriefGuidetoTechnicalLeadershipofFoursquareTeams——灵感来自BenHorowitz的文章《好产品经理，坏产品经理》。团队合作一个好的技术领导者必须是团队的一份子，他们相信只有当整个团队都成功时，他们才会成功。他们不仅完成了繁琐且吃力不讨好的工作，而且还消除了项目中的障碍，使整个团队能够以100%的效率运作。一个好的技术领导者会努力拓宽团队的技术可能性，以确保对关键系统的理解和实现不局限于一两个想法。一个糟糕的技术领导通常会一手承担所有重要任务，以便获得完成工作的荣誉。他们的理念是部分优先于整体，这样只允许团队成员以牺牲整个项目社区为代价来完成项目中最有益的部分。技术视野一个优秀的技术负责人对产品的技术方向有一个整体的把握，同时也保证了团队中的每个成员都能知道。技术负责人将不同的功能分配给其余的团队成员，由成员自己确定该功能所需的技术和方法。他们相信他们的成员很聪明，因此足够信任他们，让他们自己处理项目的重要部分。一个糟糕的技术领导者直接向其他成员宣布已经决定采用的技术方向，而不是解释或澄清技术方向。技术领导者本身具有关键系统的知识，但不会通过编写和传播实用文档来增加这些知识。讨论与辩论优秀的技术领导者会倾听并鼓励团队内部的讨论。当团队成员就某个问题争论无果时，会简单描述一个解决方案的步骤和框架，帮助成员解决问题。优秀的技术领导者从不带着结论参与团队讨论，而常常被其他成员异想天开的想法说服。一个糟糕的技术领导，让毫无结果的争论无休止地进行下去，显然会阻碍团队生产力的发展。一些领导人过早地结束了讨论，以“已解决”的回应拒绝新的讨论。对于一个糟糕的领导者来说，赢得争论比做出正确的决定更重要。项目管理一个好的技术领导者是积极主动的。他们确保项目的技术方向保持在正轨上。他们与团队成员合作进行预测并制定中间里程碑。他们预见到自己关注的领域可能出现的问题，并确保在问题出现时不至于不知所措。他们确定技术障碍并帮助团队克服这些障碍。他们识别项目中的重叠工作并让成员一起工作，此外还识别和解决项目中没有得到足够关注或资源的领域。一个糟糕的技术领导者是被动的。他们通常只分配任务，但从不跟进以确保进度。他们从不设定里程碑，他们只希望在项目结束时将各个部分很好地集成在一起。对于复杂系统的开发，他们通常会在系统发布前的端到端测试阶段跟进进度。它们甚至允许玩家将时间浪费在有趣但不重要的事情上。实用主义一个好的技术领导者追求实用主义，他们会权衡是做对还是不做。对他们来说，一些简化有时是权宜之计，但他们并不偷懒。相反，他们鼓励团队成员使用临时简化或回退系统来处理整个开发过程中的问题，以便在发布时具有可用的基本功能。对于一个好的技术领导者来说，细节很重要。代码质量、代码审查和测试对他们来说与按时发布软件一样重要。一个糟糕的技术负责人只会走捷径暂时节省时间，但导致后期维护需要更多时间。他们分不清哪些情况需要权宜之计，哪些需要完美。沟通与交流一个好的技术领导知道他的作用不仅仅是写出好的代码，与团队成员进行有效的沟通也是他们工作的重要组成部分。为了让团队更有效率地工作，花更多的时间是值得的。他们明白团队内部沟通和沟通的必要性，并牺牲个人时间来换取团队效率。一个糟糕的技术领导者认为他们只有在编码时才最有效率，并将沟通视为一种干扰。他们不把团队效率放在第一位，提倡个人主义。当他们不得不花时间领导团队时会感到沮丧。与产品的关系优秀的技术主管会与产品经理和设计师讨论产品的工作原理。他们不怕提出异议，也会为了产品目标做出适当的妥协。他们通过提出技术要求较低的替代产品创意来解决技术限制，并帮助产品经理和设计师了解技术挑战，以便他们做出明智的权衡。一个糟糕的技术领导把产品的决策权扔给了“应该做决定的人”，而不是以产品主角的态度对待它。他们也会因技术限制而否决一些产品决定，但不会提供替代技术方案或向他人解释技术问题。工作灵活性优秀的技术领导者以灵活的态度对待产品规格的变更，对产品完成过程中的意外从容应对。他们预测可能发生规范变更的地方，并设计高度灵活的代码来处理这些变更。糟糕的技术负责人通常会因产品规格的变化而分心，并在他们认为不会再次改变的地方过早地编写不灵活的代码。具有良好性格的技术负责人总是随和且自信。糟糕的技术领导总是狡猾和咄咄逼人。良好的技术领导能力自然而然，通过技术能力和项目经验赢得尊重。糟糕的技术领导者认为尊重和声望来自于他们的头衔。优秀的技术领导者总是在提升自己。糟糕的技术领导力会抵制其他人的反馈。好的技术领导不仅谦虚，还能鼓励团队成员增加自信心。糟糕的领导者不仅傲慢自大，还愿意让队友感到自卑。原文链接：https://medium.com/p/948b2b806d86翻译链接：http://blog.jobbole.com/58681/
