下面的内容是我在作为一名程序员入职之前阅读的由Gergely Orosz写的The Software Engineer’s Guidebook。我将将阅读时得到的重要的信息总结成中文以供大家分享。
作为技术负责人，你可以对塑造团队的动态和流程产生巨大的影响。但你如何利用这种影响力来创建一个健康且运作良好的结构呢？
你的团队如何运作？谁负责哪些职责？最终，团队经理需要确保这些职责分工明确。作为技术负责人，你需要了解团队中职责是如何定义和分配的，包括你自己的角色以及其他团队成员的角色。
头衔 为持有者赋予了合理的期望。例如，拥有“新毕业软件工程师”头衔的软件工程师不太可能被期望在复杂项目中发现隐藏的风险。但拥有“高级工程师”头衔的人则被期望能够识别这些风险。对于资深工程师来说，这通常是一个基本的期望。
团队中的 职责 通常是临时性的职位，例如某项工作的“项目负责人”，某个功能的负责人，或者某次会议的主持人。
在一些工作场所，技术负责人是高级工程师之后的头衔和职业级别。领导团队中的关键项目并作为其他工程团队的联络点通常是这一职位的期望。在其他公司，“技术负责人”意味着“项目负责人”或“工程负责人”。在这些地方，这更多是一种角色而非头衔，通常用于长期项目或产品的某些部分。例如，结账系统的技术负责人很可能就是工程负责人。
当角色是显性时，会直接传达给团队成员以避免混淆。明确谁是某个项目的负责人，谁是某个功能的联络点，谁负责每周的值班任务。
一个角色明确的团队可能会这样定义：
实际上，角色通常是隐性的。工程师直接承担某个角色的情况很常见，而这可能不会被广泛传达。这种方式在沟通良好的团队中运作良好，但在某些情况下，隐性角色会引发混淆。例如：
作为技术负责人，首先从你自己开始，弄清楚团队中哪些角色是显性的，哪些是隐性的。至少，要明确你的经理对你的期望。
练习：通过与经理和团队成员沟通，绘制并列出团队中的角色。谁负责哪个角色？这些角色是否有重叠？角色是否存在混淆？某些重叠是否引发了冲突？
我看到的一种一贯有效的方法是，无论项目多小，都将项目负责人角色明确告知整个团队。这为领导项目的人创造了责任感，并为其他人提供了清晰的指引。在有许多项目的团队中，每个人都有机会领导一个项目。
一个团队应该采用哪些流程？
实际上，这是一个错误的起点。流程并不是团队存在的原因；团队的存在是为了完成事情。流程可以帮助实现这一点，也可能成为障碍。随着团队的成长，团队会从中学习到如何更好地运作、更快地交付、更可靠地提供更高质量的成果，以及如何更快速地迭代。一些经验教训会引导团队制定实践和流程，以帮助工程师实现目标，而这些目标几乎总是与速度、质量、可靠性、服务客户和业务相关。
有些流程对工程团队有帮助，就像一些常见的工程实践通常是有意义的一样，比如代码审查和测试。但并不是所有流程都是有帮助的。
判断某个流程（比如值班轮换）是否真正解决了痛点的最佳方式是亲身体验。以下是一些值得了解和尝试的常见团队流程的精选。一旦掌握了这些工具，你就可以根据需要决定哪些流程值得实施。
规划
构建
发布
维护
工程效率
团队健康
大多数团队都会随着时间的推移引入新的流程。毕竟，团队会犯错误，从中吸取教训，并制定新的流程以避免未来犯下相同的错误。作为技术负责人，你是最适合推动移除冗余流程的人之一。这一点很重要，因为高效的工程团队通常灵活敏捷，默认情况下流程较少。
当你发现某个流程的附加价值存疑时，考虑将其移除。如果有一个流程消耗了大量时间和精力，是否可以部分或完全自动化？记住，流程从来不是目标。不要问你的团队应该实施哪些流程，而是问团队如何能够更好、更快地完成工作！
在对流程进行更改时，你可能需要获得经理的支持。作为技术负责人的一部分职责是为每个人创造更好的工作环境，因此你的经理可能会支持这样的举措。只需向他们解释精简流程带来的生产力和士气提升即可。
作为技术负责人，你的主要职责之一是帮助团队成员专注于正确的事情。如果人们在做错误的事情，或者不断被干扰，他们就无法按预期执行任务。
为了帮助团队专注，要明确他们的优先事项是什么，或者项目的优先事项是什么，最重要的事情是什么，接下来要完成什么，等等。
确保专注于正确事情的一个有效方法是将其书面记录，并定期与管理层确认。
要经常提醒团队当前的重点，因为适度的重复能加深印象。比如在每周站会上，简要回顾当前阶段的核心目标。对于新人、初级同事和较易分散注意力的团队成员来说，更频繁的提醒尤其重要。
要抵制对团队首要任务的突然变更，即使这些变更来自上级。如果一个团队频繁切换重点，很容易变得不健康，而优秀的技术负责人会保护团队免受这种情况的影响。当你的经理或利益相关者想要改变团队的首要任务时，可以通过以下几种方式进行抵制：
影响。 询问新任务的影响。如果影响不明确，就拒绝开始。毕竟，为什么你的团队要去做一些价值存疑或者影响力低于团队当前首要任务的事情？
书面规范。 要求提供一份解释“为什么”和“是什么”的工作规范。这可以是产品需求文档（PRD）或一个摘要，并且应包括影响。如果试图打断团队的人无法连贯地解释问题，那么很可能你的团队会因没有充分理由而被打扰，并且会花费数天时间来弄清楚要做什么。如果没有规范，就拒绝开始工作。或者，你可以提出共同撰写规范，但要明确在所有利益相关者签署之前不会开始任何工作，因为跳过这一步可能会导致后续的工作浪费。
工程规划和可行性分析。 假设规范已经清晰，你知道为什么新任务很重要，它的影响是什么，以及你被要求做什么，仍然不要开始工作，直到团队进行一些基本的工程规划和估算。可能存在使工作不可行的风险。此外，一个预计只需几天完成的项目在规划完成后可能需要数月时间。
让上下文切换的代价变得痛苦明显。 当利益相关者、其他团队或你的经理要求团队立刻开始新的工作时，他们通常并不了解完全切换上下文的实际代价。如果团队停止当前的工作，需要时间来结束当前任务并适应新的任务。这通常需要几天时间，但根据当前工作的复杂性可能需要更长时间。如果人们被告知放弃当前的工作，团队士气肯定会下降。
提供替代方案以在不打扰整个团队的情况下启动新工作。 假设影响以及“为什么”和“是什么”已经清楚，并且工程工作大致估算完毕，提供一些不需要整个团队停止当前工作的替代方案。是否可以让正在完成主要项目的某个人接手新工作，或者新工作可以在当前项目接近尾声时开始？新工作是否需要更多的用户反馈，或者需要先解决利益相关者之间的分歧？
我的经验是，如果你的经理或利益相关者带着需要立刻完成的紧急任务来找你，那么这项工作很可能过于模糊，影响不清楚，且紧急性没有根据。作为技术负责人，要尽职调查，并谨慎对待允许团队从当前工作中分心的情况。
你可能会合理化认为一次打断没关系。但接下来会有第二次、第三次、第四次。这是一条滑坡路，因此越早为保护团队设定边界，大家的处境就会越好。