虽然《资深工程师》这本书的初衷是想让业界认同我对资深工程师角色的看法，但写作过程也从多方面改变了我的观点。最重要的是，它让我更加坚信，业界常常把工程师当作孩子一样管理，而不是当作成年人来对待；同时，我也意识到自己需要改变一些无意中养成的领导方式。
当我开始撰写这篇文章时，我已经改变了对汇报层级的看法，认为工程师直接向高层领导汇报比向基层经理汇报更为重要。但我当时并没有完全将他们纳入核心领导会议。然而，过去六年里，我的最高领导团队中一直有活跃的工程师，我很高兴当初采用了这种做法，并且打算继续沿用下去。
机械
这里的核心方法是：
- 每周与我的直接下属和关键跨职能合作伙伴召开一次会议。例如，在 Stripe，这包括我的直接下属、我们的人力资源业务伙伴 (HRBP) 以及与我们合作最密切的招聘人员。
- 提拔少数几位资深工程师直接向我汇报，我担任工程主管/首席技术官，他们自然而然就会开始参加每周例会。
- 所有讨论都包含所有人，例如，除非有非常特殊的原因（例如，将工程师排除在同级别同事的绩效校准会议之外），否则不会有任何管理讨论将工程师排除在外。
- 任何人，无论是工程师还是经理，如果违反了会议的信任，都会惹上大麻烦。
这虽然是个简单的公式，但过去十年对我来说非常有效。当然，有些话题可能有些人不太关心，但我会努力引导我的领导团队广泛关注，即使有些事情不会直接影响到他们。
优势
管理者很容易陷入一种模式，即他们只关注现实的表象，而忽略了现实本身。但如果公司软件的编写和维护工程师参与其中，这种情况就很难发生，这也是工程师参与的最大好处。同样，如果没有有效的工程师代表参与，许多决策和讨论就不得不转交给其他论坛。或许只有少数工程师在场，你无法最终确定复杂问题的技术方案，但至少可以更深入地评估各种方案。
另一个主要优势在于，这些工程师可以成为重要信息的第二道传播渠道。有时，管理者与团队的沟通效率低下，虽然从长远来看，这个问题必须直接解决，但有了这些工程师，信息就可以通过他们传递给团队。
最后，这给在场的管理人员设定了一个期望，即他们应该了解技术工作的细节，就像在场的工程师应该了解管理工作一样。
缺点？
这种方法的缺点相对较少，但它确实能起到一定的过滤作用，避免一些人对高层领导的职责产生误解。例如，有些工程师认为高层领导拥有否决权，却无需承担否决的后果。这些人在这种会议上待不了多久。有人可能会认为这是个缺点，但我并不这么认为。
虽然我能想象未来在某些岗位上，我可能无法运用这种模式，但除此之外，我真的无法想象不遵循它。它彻底改变了我的工作方式，让我更好地专注于我们工程师的实际工作，而不是像管理工作那样，疲于应付那些无关紧要的“工作”。
原文： https://lethain.com/should-include-eng-in-eng-leadership/