Being a software engineer is quite a bit different than being a Navy SEAL. As software engineers, for the vast majority, we aren’t risking our lives every day at work. We aren’t dodging bullets and fighting insurgents in the 105°F desert heat. We don’t know the pain of seeing our team members being severely injured or killed. However, we do know about teamwork. We know about leadership. We know about striving to perform at our absolute best.
成为软件工程师与成为海军海豹突击队有很大的不同。 作为软件工程师，对于绝大多数人来说，我们并没有每天冒着生命危险。 我们不会在105°F的沙漠酷热中躲避子弹袭击，并与叛乱分子作战。 我们不知道看到我们的团队成员受到重伤或丧生的痛苦。 但是，我们确实了解团队合作。 我们了解领导力。 我们知道努力做到最好。
I just finished up Jocko Willink’s and Leif Babin’s masterpiece: “Extreme Ownership: How Navy SEALs Lead and Win.” While I was reading and admiring the courage, operational prowess, and leadership capabilities of SEAL teams, I found myself wondering how I could take these leadership lessons from the world of the SEALs and adapt them into my world as a software engineer.
我刚刚完成了Jocko Willink和Leif Babin的杰作：“ 极端所有权：海军海豹突击队如何领导和取胜。 ”当我阅读和欣赏SEAL团队的勇气，操作能力和领导能力时，我发现自己想知道如何才能从SEAL的世界中学到这些领导力课程，并使他们适应我作为软件工程师的世界。
Below is my take on how each of the Extreme Ownership principles translates into the field of software engineering. Several of these principles are interconnected and related so bear with me if certain parts seem redundant.
下面是我对每个“极端所有权”原则如何转化为软件工程领域的看法。 其中一些原则是相互联系和相关的，如果某些部分看起来多余，请与我联系。
- Own everything in your world. 拥有世界上的一切。
- No bad teams; just bad leaders. 没有坏队； 只是糟糕的领导者。
- Believe. 相信。
- Check your ego. 检查你的自我。
- Cover and move. 掩盖并移动。
- Keep it simple. 把事情简单化。
- Prioritize and execute. 确定优先级并执行。
- Decentralized Command. 分散指挥部。
- Plan. 计划。
- Lead up and down the chain of command. 上下指挥链。
- Be decisive. 果断。
- Discipline equals freedom. 纪律等于自由。
1.拥有世界上的一切 (1. Own Everything in Your World)
The world of software is a big one. With so many interconnected, moving, pieces that are orchestrated together to provide an application, service, or tool for millions of people are going to use, it’s very daunting to hear the words “own everything in your world.” It’s near impossible to ask one mobile engineer to maintain his codebase, develop the API that the mobile app depends on, and administer the database that the API depends on. Especially with other teams depending on those resources as well! However, it is much more realistic and productive to ask that mobile engineer to ensure that his code is the best it can be and that he accounts for, and mitigates, contingencies and risks while operating with the external dependencies. The phrase “own everything in your world” really means “assume responsibility.” For example: if the API that my mobile app depends on doesn’t return reliable data or accurate status codes, then it is my responsibility to validate the data and status code for errors and present a user-friendly view to give the best possible experience. Saying “well…the API team didn’t do their job” or “the API should be implemented differently” is not practicing Extreme Ownership. Extreme Ownership is looking inward and asking myself: “how could I, as the mobile engineer, mitigate the risk of faulty API data or an incorrect status code? Did I ensure that the API team fully understood my team’s needs and the overall mission of my team? Did I validate their work with them before integrating?” Perhaps if I would have done these things the end-user would have a better experience and my mission would have been accomplished? The onus is on me to ensure I have everything I need and that all my dependencies understand my mission and how I intend to use their system.
软件世界是一个很大的世界。 如此多的相互关联，相互影响的，相互协调的，为数百万人提供应用程序，服务或工具的组件将被使用，听到“拥有世界上所有的东西”这个词非常令人生畏。 几乎不可能要求一位移动工程师维护他的代码库，开发该移动应用程序所依赖的API以及管理该API所依赖的数据库。 尤其是与其他团队一样，也取决于这些资源！ 但是，要求移动工程师确保他的代码是最好的代码，并且在处理外部依赖项时考虑并减轻意外事件和风险，这是更加现实和有效的方法。 “拥有世界上的一切”一词的真正含义是“承担责任”。 例如：如果我的移动应用程序所依赖的API没有返回可靠的数据或准确的状态代码，那么我有责任验证数据和状态代码是否存在错误，并提供用户友好的视图以提供最佳的体验。 说“好吧……API团队没有完成他们的工作”或“ API应该以不同的方式实现”并不是在实践“极端所有权”。 极端所有权正在向内看，问自己：“作为移动工程师，我如何减轻API数据错误或状态代码错误的风险？ 我是否确保API团队完全了解团队的需求和团队的整体任务？ 在整合之前，我是否与他们一起验证了他们的工作？” 也许如果我会做这些事情，那么最终用户会获得更好的体验，而我的使命就已经完成了？ 确保自己拥有所需的一切以及确保我的所有依存关系都了解我的任务以及打算如何使用其系统是我的责任。
Owning everything in your world also correlates closely with software entropy (or “broken windows” for my Pragmatic Programmer fans.) If you see:
您所拥有的一切也与软件熵 (或对我的务实程序员迷来说是“破窗”)密切相关。如果您看到：
- Compiler warnings 编译器警告
- Absent unit tests 缺少单元测试
- Janky user experiences 垃圾用户体验
- Outdated documentation 过时的文档
or other items that just aren’t acceptable, then it is on you, as a leader in your team, to remedy these things and ensure that they are minimal going forward. Chances are if the rest of your team sees you fixing these broken windows they will follow suit as well.
或其他不可接受的项目，则作为团队的领导者 ，您有责任对这些问题进行补救，并确保将它们最小化。 如果您团队的其他成员看到您修复了这些破损的窗户，他们也会效仿。
2.没有坏队； 只有坏领导 (2. No Bad Teams; Only Bad Leaders)
John C. Maxwell put it best: “a leader is one who knows the way, goes the way, and shows the way.” When teams don’t perform the way that is expected, most of the time, the root cause lies with the team’s leader, Jocko says. Great leaders not only lead their team but, also, develop the leader inside of their teammates. They make more leaders. Great leaders don’t feel threatened when their subordinates take ownership and excel in a task that aids in the completion of the overall mission. Great leaders are also never satisfied. Embodying the Japanese business principle of Kaizen (translated as “continuous improvement”) great leaders never lets themselves, or their team, “rest on their laurels.” Great leaders keep pushing the team to ascend to new heights.
约翰·麦克斯韦(John C. Maxwell)最能说明这一点：“领导者是知道道路，走道路并展示道路的人。” 乔科说，当团队无法按预期的方式执行任务时，根本原因就在于团队的领导者。 伟大的领导者不仅领导团队，而且在队友内部培养领导者 。 他们使更多的领导者。 当下属拥有所有权并在有助于完成整体任务的任务中脱颖而出时，出色的领导者不会感到受到威胁。 伟大的领导者也永远不会满足。 伟大的领导人体现了日本改善 ( Kaizen)的商业原则(翻译为“持续改进”)，从来没有让自己或团队“为自己的桂冠而坐”。 伟大的领导者不断推动团队提升到新的高度。
In software engineering, this means that a great leader doesn’t accept substandard work. However, instead of ridiculing a junior developer for messy code, or putting the junior through an arduous Pull Request review, a great leader will find time to help the junior raise his level of performance to the team’s standards. A great leader will not compromise on quality; even on the small things. From writing unit tests to filling out descriptive Pull Request messages, to even requirements gathering and estimation, a great leader will push themselves, and their team, to perform at an elite level; Just like SEALs do.
在软件工程中，这意味着出色的领导者不会接受不合标准的工作。 但是，优秀的领导者不会浪费时间来嘲笑初级开发人员以获得混乱的代码，也不会让初级人员进行繁琐的“拉取请求”审查，而是会找时间帮助初级人员提高其绩效水平，使其达到团队的标准。 一个伟大的领导者不会在质量上妥协； 即使是小东西。 从编写单元测试到填写描述性的“拉取请求”消息，甚至是收集和评估需求，一位出色的领导者都将推动自己和他们的团队发挥出卓越的才能； 就像海豹突击队一样。
Being a great leader also means introspecting when things go wrong. Echoing the first principle, a leader must ask himself the hard questions: “did I communicate the mission clearly to my team? Did every team member understand his role perfectly? Did I plan for contingencies and setbacks?” A leader never places the blame elsewhere when the mission fails.
成为出色的领导者还意味着在出现问题时会进行自我反思。 领导者必须遵循第一条原则，向自己问一些棘手的问题：“我是否将任务清楚地传达给我的团队？ 每个团队成员都完全了解他的角色吗？ 我是否计划了突发事件和挫折？” 任务失败时，领导者永远不要将责任推卸到其他地方。
3.相信 (3. Believe)
Before going out on the battlefield, Navy SEALs must believe in the mission they are undertaking. The SEALs reach this belief by paying attention during briefs and asking questions of their leaders. No question is taboo and senior leaders take as much time as needed for the junior members to understand the “how” as well as the “why” of the mission. At the end of the brief, they understand their role and how it plays into the broader strategy of the mission. The “why” is important for when things get tough. When the bullets start flying and the question of “is this worth it?” pops into team member’s minds, the “why” is what fuels them with the right motivation to see the mission through.
在出战场之前，海豹突击队必须相信他们正在执行的任务。 海豹突击队通过在简报中给予注意并向其领导人提出问题来达到这一信念。 禁忌是毫无疑问的，高级领导人会花很多时间让下级成员了解任务的“方式”和“原因”。 简报结束时，他们了解了自己的角色以及它如何在更广泛的任务策略中发挥作用。 当事情变得艰难时，“ 为什么 ”很重要。 当子弹开始飞行时，“这值得吗？”的问题 突然出现在团队成员的脑海中，“ 为什么 ”正是以正确的动机激励他们完成任务的动力。
Software engineers should also believe. Whether their mission is to provide users with a great tool to increase their productivity, or to further the financial health of their users, or even to provide their users with security on the web, to many, many more; Software engineers who buy-in and believe in the mission will always outperform those who don’t believe. There are several ways for software engineers to strengthen their belief:
软件工程师也应该相信。 他们的任务是为用户提供提高生产力，增强用户财务状况的绝佳工具，还是为用户提供更多的网络安全性； 接受并相信任务的软件工程师将始终胜过不相信该任务的软件工程师。 软件工程师可以通过以下几种方法来增强自己的信念：
- Be present and attentive at the company/division all-hands meetings. Executives, in general, are champions of the mission for their companies. They will tell you the overall mission multiple times if you are paying attention. 出席公司/部门全体会议并专心。 高管通常是公司使命的拥护者。 如果您关注的话，他们会多次告诉您总体任务。
- Ask questions of your leaders. This applies to not just the “top-brass” but also your immediate manager or lead as well. If they don’t have an immediate answer to your questions, more often than not, they will find someone who does have the answer. 询问领导者的问题。 这不仅适用于“高层管理人员”，还适用于您的直接经理或主管。 如果他们经常没有立即回答您的问题，他们会找到确实有答案的人。
- Don’t be afraid to ask a question that might seem obvious. Everyone else in the audience is also afraid to look a certain way in front of the leaders. Your leaders will appreciate your willingness to ask and commitment to the mission while your peers will respect you for your courage and they will obtain the information they needed, but, were too afraid to ask for. 不要害怕问一个看起来很明显的问题。 听众中的其他所有人也害怕在领导者面前摆出某种方式。 您的领导者会赞赏您提出要求和对任务承担的责任，而您的同事会尊重您的勇气，他们会获得所需的信息，但他们却害怕要求。
When you understand the mission of the company and how your work plays into that mission you will not only gain more satisfaction from your efforts but, you will also know why you are undertaking a task when the going gets tough.
当您了解公司的使命以及您的工作如何实现这一使命时，您不仅会从自己的努力中获得更多的满足感，而且，您还将知道为什么在艰难的情况下仍要承担任务。
4.检查你的自我 (4. Check Your Ego)
Everyone has an ego. Period. It’s part of our psychological makeup as human beings. Ego is part of what drives us to excel and improve our skills. However, the ego becomes dangerous when we let it rule us and override our goal to accomplish the mission. Sometimes as a leader one must disregard their wants and agendas for the mission and the success of the team. In software engineering, a good example of this is work distribution. There are always some components that are more fun to work on than others. User stories are usually more fun than bugs or documentation. You might be wanting to work on a cool new chatbot feature for your team’s product but here is a mountain of refactoring for some legacy code in the product’s most popular feature that needs to be addressed. While you might want to work on the chatbot, your skills and product knowledge are better suited to refactor the tightly coupled and brittle legacy code. By checking your ego and allowing another member to work on the shiny, new, feature and you handle the legacy code, you are leading by example and benefitting the product and end-users. A win-win in any situation. While you might not get the direct spotlight of working on the “new feature” your team succeeds in the end by having both a new feature and a more stable product. When your team succeeds, you succeed. When your team fails, you also fail.
每个人都有自我。 期。 这是我们人类心理构成的一部分。 自我是驱使我们取得卓越和提高技能的一部分。 但是，当我们让它统治我们并超越完成任务的目标时，自我就变得很危险。 有时，作为领导者，必须无视他们的使命和团队成功的愿望和日程。 在软件工程中，工作分配就是一个很好的例子。 总有一些组件比其他组件更有趣。 用户故事通常比错误或文档更有趣。 您可能想为团队的产品开发一个很酷的新聊天机器人功能，但是这里需要重构产品最流行的功能中的一些旧代码，这需要解决。 尽管您可能想使用聊天机器人，但是您的技能和产品知识更适合重构紧密耦合且脆弱的旧代码。 通过检查您的自我并允许其他成员使用闪亮的新功能并处理旧代码，您将以身作则，使产品和最终用户受益。 在任何情况下都是双赢。 虽然您可能没有直接关注“新功能”的开发，但您的团队最终同时拥有新功能和更稳定的产品而成功。 当您的团队成功时，您就会成功。 当您的团队失败时，您也会失败。
5.掩盖并移动 (5. Cover and Move)
In a world as big and complex as software engineering it is inevitable, nay, a law of physics, that you will have to interface with other people to get the job done. The same is true with Navy SEALs. SEALs operate in teams. Each member of a SEAL team has a different role, a different job. SEALs often work with other teams from different branches of the military. Unfortunately, and this is true both in the military and the private sector, not everyone you interface with is going to synergize naturally with you and your team. Sometimes teamwork takes work. As a leader on your team, make sure that you are communicating clearly and effectively with all the dependencies the mission requires. The mission is what should unite the various teams to achieve the objective. Silos, personal agendas, and division can be catastrophic to the mission; to the point of failure. A few tips I have found for effective collaboration and communication between teams are:
在像软件工程这样庞大而复杂的世界中，物理定律是不可避免的，您必须与其他人交互才能完成工作。 海军海豹突击队也是如此。 海豹突击队分队作战。 海豹突击队的每个成员都有不同的角色，不同的工作。 海豹突击队经常与来自军队不同部门的其他团队合作。 不幸的是，这在军事和私营部门都是如此，并不是您与之互动的每个人都会自然地与您和您的团队协同合作。 有时团队合作需要工作 。 作为团队的领导者，请确保您与任务所需的所有依赖关系进行清晰有效的沟通。 任务是团结各个团队以达成目标。 筒仓，个人日程和部门划分可能会对任务造成灾难性影响； 到失败的地步。 我发现了一些在团队之间进行有效协作和沟通的技巧：
- Emphasize in person, face-to-face, interaction. If that is not possible or desired, then do a video conference. Seeing someone’s face while hearing their voice and reading their emotions goes a long way for forging bonds and breaking down barriers. 强调面对面，面对面，互动。 如果这是不可能或不希望的，则进行视频会议。 听到某人的声音并阅读他们的情绪时看到他们的脸对于建立联系和打破障碍是很长的路要走。
- Utilize advanced features of written communication tools like Outlook or Slack. Crafting your message to include images, code, emphasized text, and emojis can aid in the clarity and comprehension of your message. 利用书面沟通工具的高级功能，例如Outlook或Slack。 精心设计您的消息以包含图像，代码，强调的文本和表情符号可以帮助您使消息清晰明了。
- Validate each others’ work. Ensuring that everyone produces quality and everyone is helping each other to perform better creates a bond between team members. 验证彼此的工作。 确保每个人都能提高质量，每个人都在互相帮助以提高绩效，这在团队成员之间建立了纽带。
- Share findings with one another. New programming languages, design patterns, automation tools, etcetera. Anything that helps the team achieve the mission. This knowledge will create a feeling of unity that will increase the performance of all the team members. 彼此分享发现。 新的编程语言，设计模式，自动化工具等。 有助于团队完成任务的一切。 这些知识将创造一种团结的感觉，从而提高所有团队成员的绩效。
6.保持简单 (6. Keep It Simple)
“Simple” was perhaps my favorite principle from Extreme Ownership. Jocko recounted an Iraqi commander who was tasked with his first patrol in a combat zone. He and his men and never seen combat before. The commander had a very complex patrol route he wanted to execute. He wanted to showcase his unit’s capabilities and prowess on their first patrol. Jocko advised the commander to simplify. Jocko argued that when things go wrong, and they inevitably always do, that a simpler plan would be easier to comprehend by the unit, and therefore easier to remember under stress. Sure enough, on the patrol, the unit was engaged in a heavy firefight, however, due to the new simple plan that the commander adopted, he and his men made out alive, with zero casualties.
“简单”也许是我从“极致所有权”中最喜欢的原则。 乔科讲述了一名伊拉克指挥官，他在战区进行第一次巡逻。 他和他的手下从未见过战斗。 指挥官想执行一条非常复杂的巡逻路线。 他想在第一次巡逻中展示其部队的能力和实力。 乔科建议指挥官简化一下。 乔科认为，一旦出现问题，并且不可避免地总是会出错，那么一个简单的计划将更容易被单位理解，因此在压力下更容易记住。 果然，在巡逻中，该部队进行了猛烈的交火，但是由于指挥官采用了新的简单计划，他和他的士兵活了下来， 伤亡为零 。
Software engineering is a world that specializes in issues and “things that go wrong.” Consider your codebases. Are there certain parts of the code that bugs are easier to fix than others? Why is that? One word: complexity. Sometimes, complexity just can’t be avoided. But, oftentimes it most definitely can be and should be avoided. Refactoring code to best practices such as meaningful naming, loose coupling, single responsibility, and separation of concerns makes adding new features and fixing issues more complex and more predictable. It is a leader’s job within the team to reduce complexity when it is feasible to do so. By taking ownership and simplifying the code base, the leader invites and inspires other members to do the same.
软件工程是一个专门研究问题和“出问题的地方”的世界。 考虑您的代码库。 在代码的某些部分中，错误比其他部分更容易修复吗？ 这是为什么？ 一句话：复杂性。 有时，复杂性无法避免。 但是，通常绝对可以并且应该避免这种情况。 将代码重构为最佳做法，例如有意义的命名，松散耦合，单一职责和关注点分离，使得添加新功能和解决问题变得更加复杂和可预测。 在可行的情况下，减少复杂性是团队内部的领导者的工作。 通过取得所有权并简化代码库，领导者邀请并激励其他成员也这样做。
User stories and Sprint Goals should also be kept simple as well. Similar to the firefight story above, a complex Sprint Goal will compound and falter when things go wrong in the Sprint. If the whole team understands what is to be accomplished during a sprint, then when things go wrong, team members can take ownership of their piece and pivot, achieve victory, and accomplish the goal. “Complexity compounds issues that can spiral out of control into a total disaster.” I couldn’t agree more, Jocko.
用户故事和Sprint目标也应保持简单。 与上述“交火”故事相似，当Sprint中出现问题时，复杂的Sprint目标也会变得复杂而步履蹒跚。 如果整个团队都知道在冲刺过程中要完成的工作，那么当事情出错时，团队成员可以掌控自己的工作并取得成功，取得胜利并实现目标。 “复杂性可能使无法控制的螺旋式发展成为彻底的灾难。” 我完全同意，乔科。
7.确定优先级并执行 (7. Prioritize and Execute)
When things go wrong on the battlefield, SEAL leaders have to make a decision based on the information at hand. SEALs have to take a step back, analyze the situation, and address the highest priority issue before proceeding to the next. If the team tried to focus on all the problems simultaneously they will fail at all the tasks and likely all die. The same principle applies to Software Engineering. You can’t try to “boil the ocean” and solve everything at once. If you do, it will take you longer to reach your goals; if you ever reach them. If you have multiple issues, then decide which one is the highest priority. Remembering principle #4, it might be time to check your ego and put aside the objective that you want to resolve and tackle the most important issue instead.
当战场上出现问题时，海豹突击队领导人必须根据手头的信息做出决定。 海豹突击队必须退后一步，分析情况，并解决最高优先级的问题，然后再进行下一个。 如果团队尝试同时关注所有问题，那么他们将在所有任务上失败，并且很可能全部死亡。 同样的原则适用于软件工程。 您不能尝试“煮沸海洋”并立即解决所有问题。 如果这样做，您将需要更长的时间才能实现目标。 如果您到达他们。 如果您有多个问题，请确定哪一个是最高优先级。 牢记原则4，现在可能是时候检查自己的自我，放弃要解决和解决最重要问题的目标了。
Consider a common example of a difference of perspective from a technical lead and a product owner. When deciding the next goal, the next “mission”, for the engineering team to execute, the tech lead may insist that legacy code be refactored and technical debt be paid. The product owner might push for newer features that the market demands and that competitors are implementing. Both are leaders within the organization, however, both of the leader’s choices can’t be the highest priority. This situation requires both leaders to take a step back, analyze the situation, and decide what is truly the most important issue. It might be the health of the product and paying off technical debt, or conversely, the new features and beating the competition might be the most important thing. Making that choice requires humility, and that can be a struggle for any leader.
考虑一个与技术负责人和产品负责人观点不同的常见示例。 在确定下一个目标(即下一个“任务”)以供工程团队执行时，技术负责人可能会坚持要求重构遗留代码并支付技术债务。 产品负责人可能会寻求市场需求和竞争对手正在实施的更新功能。 两者都是组织内的领导者，但是，领导者的两个选择都不是最高优先级。 这种情况要求双方领导人退后一步，分析情况，并确定真正最重要的问题。 这可能是产品的健康状况，还清技术债务，或者相反，新功能和击败竞争对手可能是最重要的事情。 做出选择需要谦卑，而这对于任何领导者来说都是一场斗争。
8.分散指挥 (8. Decentralized Command)
Top leaders, such as admirals, commanders, directors, executives, and product owners, can’t live in the weeds. They can’t be bogged down with the details of a tactical nature. There is a reason for this! Their positions require them to take a birds-eye view of all the moving parts and their job is to orchestrate the various teams to achieve the shared mission. If they come down from that overview and focus on the implementation or execution of one team, they lose their command presence and real-time updates on the strategic mission as a whole. More specifically, the leader allows the other units to falter and the mission to suffer. In order to stay at the level of abstraction needed to coordinate several teams, the leader must implement decentralized command with his subordinate, lower-level, leaders. A decentralized command is when higher-level leaders, such as admirals and directors, dictate the mission and overall strategy of the teams while giving their lower-level leaders, such as lieutenants and tech leads, the autonomy to implement their role as they see fit. The lower-level leaders understand the Commander’s Intent: the mission and the criteria for success, so that their decisions, made autonomously, align and help advance the teams towards mission completion.
海军上将，指挥官，董事，执行官和产品负责人等高级领导人不能生活在杂草丛中。 他们不能被战术性质的细节所困扰。 有一个原因！ 他们的职位要求他们对所有活动部件都具有鸟瞰图，他们的工作是协调各个团队以实现共同的使命。 如果他们从该概述中落下来，而只专注于一个团队的实施或执行，则他们将失去指挥权，无法整体上了解战略任务的实时更新。 更具体地说，领导者让其他单位步履蹒跚，使任务受挫。 为了保持协调几个团队所需的抽象水平，领导者必须与下级的领导者一起实施分散的指挥 。 权力下放是指上级领导(例如海军上将和总监)规定团队的使命和总体战略，而下级领导(例如中尉和技术负责人)则拥有自主权，以行使自己认为合适的角色。 下层领导人了解指挥官的意图 ：任务和成功的标准，以便他们的决定可以自主制定，调整并帮助团队推进任务完成。
A concrete software engineering example is a director who might set an initiative to implement a new recommendation system to get users to purchase new products. The director explains the initiative to each of the tech leads and product owners. The director doesn’t care whether the mobile team uses the MVP or MVVM design pattern, or whether the API team uses Spring or .Net, he cares about the interoperability of all the pieces and the coordination between the teams. It’s up to the tech leads to determine the implementation and it’s the product owner’s job to set the priority of features that will be developed within their team’s components. They have the autonomy and authority to make those decisions, as long as their decision aligns with the Commander’s Intent.
一个具体的软件工程示例是主管，他可能会主动采取措施实施新的推荐系统，以使用户购买新产品。 主任向每个技术负责人和产品负责人解释了该计划。 主管并不关心移动团队是使用MVP还是MVVM设计模式，也不关心API团队是使用Spring还是.Net，他关心的是所有组件的互操作性以及团队之间的协调。 这取决于技术领导者来确定实施方式，而产品所有者的工作是确定将在其团队组件中开发的功能的优先级。 只要他们的决定符合指挥官的意图，他们就有自主权和权力做出这些决定。
As an operator, software engineer, or any role that is “in the fight/actually doing the work” it is your job to take ownership and understand your Commander’s Intent. “How does one do this?” Well, similar to principle #3 and believing in the mission, pay attention during briefs and meetings with your director. Ask questions if you don’t understand the intent of the mission. If you don’t have access to your high-level leader, then ask your immediate leader. It is their responsibility to understand the intent of the mission and relay that information to you in a clear, concise way. Knowing the Commander’s Intent will guide your tactical decisions and help propel the mission forwards towards success.
作为操作员，软件工程师或“在战斗中/实际上正在工作”的任何角色，获得所有权并了解指挥官的意图是您的工作。 “这是怎么做到的？” 好吧，与原则3相似，并相信自己的使命，请在简报和与董事会面时注意。 如果您不了解任务的意图，请提问。 如果您无权访问高层领导，请询问您的直接领导。 他们有责任了解任务的意图并以清晰，简洁的方式将信息传达给您。 了解指挥官的意图将指导您的战术决策，并有助于推动任务迈向成功。
9.计划 (9. Plan)
I know, I know, I can hear the groans from here. Many argue that planning is of little value in the world of software engineering. “Things change so much! We have to interface with black boxes! We have to adapt to market conditions!” Yes! So plan for contingencies and anticipate change. Situations change for SEALs all the time. In fact, SEALs anticipate problems on patrols and operations. That’s why it’s imperative to keep things simple, and that every team member knows their role and understands the Commander’s Intent so that when things go wrong, the team can pivot and make the right decisions to still accomplish the mission.
我知道，我知道，我可以从这里听到the吟。 许多人认为，规划在软件工程领域没有什么价值。 “事情发生了很大变化！ 我们必须与黑匣子进行交互！ 我们必须适应市场条件！” 是! 因此，应对突发事件进行规划并预测变化。 海豹突击队的情况一直在变化。 实际上，海豹突击队可以预见巡逻和作战方面的问题。 这就是为什么必须使事情保持简单，并且每个团队成员都知道他们的角色并理解司令员的意图的原因，以便在出现问题时，团队可以做出调整并做出正确的决定，以仍然完成任务。
Leif Babin had some truly profound advice regarding plans: “do the team and support elements understand it?” Simple. In my opinion, making sure the supporting elements (other teams) understand the plan is critical to success. Reflect on your own experience. How many times was a body of work assigned to you, as a software engineer, with no communication or coordination with a dependency (DBAs, APIs, other teams?) Ineveitalbey when you start cranking out the code and integrating with those dependencies, you run into issues. Chances are, if you had coordinated with them or even invited the dependency to participate in the planning process, the issues could have been mitigated.
Leif Babin对计划提出了一些真正深刻的建议：“团队和支持人员是否理解？” 简单。 我认为，确保支持人员 (其他团队)了解该计划对于成功至关重要。 反思自己的经历。 作为软件工程师，在没有依赖关系(DBA，API，其他团队？)的情况下，没有沟通或协调的工作分配给您多少次？Ineveitalbey当您开始编写代码并与那些依赖关系进行集成时，您可以运行问题。 如果您与他们进行了协调，甚至邀请了依赖者参与计划过程，则问题可能得到缓解。
Babin also had a brilliant suggestion of a standardized checklist that leaders should use when planning. I have added my interpretation of things in the Agile/Scrum world that apply each item.
巴宾还提出了一个明智的建议，即领导人在计划时应使用标准化的清单 。 我已经添加了对敏捷/ Scrum世界中适用于每个项目的事物的解释。
- Analyze the mission (Sprint Goal/Key Result/Key Performace Indicator.) 分析任务(冲刺目标/关键结果/关键绩效指标。)
- Identify the personnel, assets, resources, and time available (Product Backlog Grooming.) 确定可用的人员，资产，资源和时间(产品积压整理)。
- Decentralize the planning process (Individual Story Grooming.) 分散计划流程(个人故事整理)。
- Determine a specific course of action (Sprint Planning.) 确定特定的行动方针(冲刺计划)。
- Empower key leaders to develop the plan for the selected course of action (Self-organizing teams.) 授权主要领导制定针对特定行动方案的计划(自组织团队)。
- Plan for likely contingencies through each phase of the operation (identifying risks during Sprint Planning.) 在操作的每个阶段计划可能的突发事件(在Sprint计划期间确定风险)。
- Mitigate risks that can be controlled as much as possible (defensive coding.) 减轻可控制的风险(防御性编码。)
- Delegate portions of the plan and brief to key junior leaders (Self-organizing teams.) 将计划的一部分委托给主要的下级领导人(自组织团队)。
- Continually check and question the plan against emerging information to ensure it still fits the situation (Daily Scrum.) 不断检查和质疑计划是否出现新的信息，以确保它仍然适合情况(Daily Scrum。)
Brief the plan to all participants and supporting assets (Sprint Planning.)
向所有参与者和支持资产简要说明计划(冲刺计划)。
- Conduct post-operational debriefs after execution (Sprint Review and Sprint Retrospective.) 执行后进行操作后汇报(Sprint审查和Sprint回顾。)
I truly think that if an organization adopted Babin’s checklist for every team in the organization, the results would be exponential.
我确实认为，如果一个组织对组织中的每个团队都采用Babin的清单，那么结果将是指数级的。
10.上下指挥链 (10. Lead Up and Down The Chain of Command)
A team member doesn't have to have bars on his collar, or a title, to be a leader. Leadership is a lot like positivity; it’s contagious. You can lead those above you as well as those below you in a tactful way that will aid in the completion of your mission. You can lead below you by:
团队成员不必成为领导者就可以在衣领或头衔上打上杠铃。 领导力很像积极性。 它具有传染性。 您可以以机智的方式领导自己之上和之下的人，这将有助于完成任务。 您可以通过以下方法领先于您：
- Setting and embodying the standard of what is expected from the team. 设定并体现团队期望的标准。
- Explaining team members' roles and the Commander’s Intent with clarity and conciseness. 简洁明了地说明团队成员的角色和指挥官的意图。
- Cover and Move (principle #5.) You can aid your teammates in their tasks and instruct them to perform at a higher level. Be thorough in code reviews, teach new techniques to juniors, and help solve issues together. 掩护和移动(原则5)。您可以帮助队友完成任务并指导他们更高水平地表现。 彻底进行代码审查，向初级人员教授新技术，并帮助共同解决问题。
And as a leader, you can also lead above you by:
作为领导者，您还可以通过以下方法领先于您：
- Providing the right level of information and statuses to your superiors so that they understand the current situation and what you need from them. Don’t bog them down with technical details such as stack traces, error codes, etcetera. Rather, abstract the information to a level that is easy to consume for the superior. 向您的上司提供正确级别的信息和状态，以便他们了解当前情况以及您对他们的需求。 不要让他们陷入技术细节，例如堆栈跟踪，错误代码等。 而是将信息抽象到上级易于使用的级别。
- Understand that you may not be the highest priority for your leader. They, after all, are leading multiple teams with limited resources. Sometimes you must understand, strategically, where you fit in and make the best of it. 了解您可能不是领导者的头等大事。 毕竟，他们领导着资源有限的多个团队。 有时，您必须从战略上了解自己适合的位置并充分利用它。
- Support your leaders above you. Make their lives easier when you can. 支持您之上的领导者。 尽可能让他们的生活更轻松。
- When issues arise, and they most definitely will come up, offer solutions to the problem. When necessary, tell them what you are going to do, don’t ask what to do. 当出现问题时，肯定会出现问题，为问题提供解决方案。 必要时，告诉他们您打算做什么，不要问该做什么。
11.果断 (11. Be Decisive)
Eventually one must “cross the rubicon.” When Julius Caesar crossed the Rubicon river during the Roman Civil War, he knew that this was a final action; there was no going back. This sounds scary for a lot of leaders, especially engineering leaders. However, there are times when a decision, a plan, must be made and carried out. SEALs often have to make final decisions: do I pull this trigger? Do I clear that building? Do I tell my team to go to the right or to the left? All of their decisions carry the gravity of life and death. Yet, SEALs don’t make uninformed decisions. They use all the available intelligence at their disposal and they make a rational decision based upon that information. The same holds true for software engineering leaders as well. Deciding which technical debt to pay off first, which feature to send back to the backlog, or even which language to implement a component in. All of these decisions have far-reaching consequences (maybe not the same as life or death, but jobs, careers, and livelihoods could be at stake.) A leader must be able to take a pause, step back, analyze all the information at hand, and make a decision. The leader cannot succumb to “analysis paralysis” and fail to make a decision. They must make the best possible decision, one that helps the mission instead of hurting it.
最终，人们必须“越过图标”。 罗马内战期间，朱利叶斯·凯撒(Julius Caesar) 越过Rubicon河 ，他知道这是最后的行动。 没有回头路了。 对于许多领导者，尤其是工程领导者来说，这听起来很可怕。 但是，有时必须制定并执行一项决定，一个计划 。 海豹突击队通常必须做出最终决定：我会扣动扳机吗？ 我要清理那座建筑物吗？ 我要告诉我的团队去右边还是左边？ 他们所有的决定都承载着生与死的重心。 但是，海豹突击队不会做出不明智的决定。 他们使用所有可用的情报，并根据这些信息做出合理的决定。 软件工程负责人也是如此。 决定先偿还哪些技术债务，将哪些功能发送回待办事项，甚至决定采用哪种语言实施。所有这些决定都会产生深远的影响(也许与生死不一样，但工作，领导者必须能够停下来，退后一步，分析手头的所有信息并做出决定。 领导者不能屈服于“分析瘫痪”，也不能做出决定。 他们必须做出最好的决定，这一决定对任务有帮助，而不是伤害任务。
12.纪律等于自由 (12. Discipline Equals Freedom)
The Golden Mean is a maxim in Western philosophy that basically says virtue can be found in the middle of two extremes. Too little courage makes one a coward, much like Paris from The Illiad. Too much courage makes one foolhardy and reckless, like Achilles. True courage lies in the middle, as we see with Hector. Discipline and Freedom are the same in this regard. A leader must strike the balance between too much discipline, which stifles the team, and too much freedom, which makes the team wild and unable to focus on the mission.
“中庸之道”是西方哲学中的一种格言，基本上说美德可以在两个极端之间找到。 太少的勇气会使人胆怯，就像《伊利亚特》中的巴黎一样。 像阿喀琉斯一样，太大的勇气会使一个人变得顽强和鲁re。 正如我们在赫克托看来，真正的勇气在于中间。 在这方面，纪律和自由是相同的。 领导者必须在过多的纪律约束和过多的自由之间取得平衡，这些约束使团队窒息，而太多的自由则使团队疯狂并且无法专注于任务。
Jocko told of a time when had to strike that balance with his SEAL team. SEALs often times had to search the houses of suspected insurgents in Iraq and confiscated suspicious items. His team, at first, had too much freedom in this process and would ransack the homes. This lack of discipline made the search process inefficient and much time was wasted. Time equals life on the battlefield. Jocko knew this had to be remedied. So, as the leader, Jocko imposed discipline. He set forth standard search procedures and had the team delegate rooms amongst themselves (Decentralized Command) and bag and label items they needed to confiscate into bags with labels indicating the house and room they came from. Initially met with resistance from the lower team members, this discipline increased the efficiency of the searches dramatically. The SEAL team went from doing 1 house a day to 3 or 4 houses per day. This aided in the overall mission of stabilizing Iraq and liberating the populace from the insurgents' terror. The discipline the team adopted granted them the freedom to move faster and accomplish more.
乔科(Jocko)告诉他，何时必须与他的海豹突击队保持平衡。 海豹突击队常常不得不搜查伊拉克可疑叛乱分子的房屋并没收可疑物品。 起初，他的团队在此过程中拥有太多的自由，将对房屋进行洗劫。 缺乏纪律性使得搜索过程效率低下，浪费了很多时间。 时间等于战场上的生命。 Jocko知道必须对此进行补救。 因此，作为领导者，乔科施加了纪律。 他制定了标准的搜索程序，并让团队在他们之间分配了房间(分散指挥部)，并把需要没收的行李和标签物品放进了带有标签的行李中，这些标签标明了房屋和房间。 最初受到下级团队成员的抵制，这门学科极大地提高了搜索效率。 海豹突击队从每天一栋房子变成每天三到四栋房子。 这有助于稳定伊拉克并使平民从叛乱者的恐怖中解放出来的总体任务。 团队采用的纪律赋予了他们更快行动和更多成就的自由。
The same dichotomy can be applied to software engineering. As Robert C. Martin put it in Clean Code, “So if you want to go fast, if you want to get done quickly, if you want your code to be easy to write, make it easy to read.” Clean code is not something that most engineers can write quickly. It takes iterations of refinement. Some of my messiest code was written when I was in a hurry, or, even worse, I was undisciplined. By being disciplined and writing clean code, with the safety of unit tests, and the power of Continuous Integration, and the benefit of meaningful, current documentation, engineers gain the freedom to move quickly, ship more features, and accomplish their mission faster.
相同的二分法可以应用于软件工程。 正如罗伯特·C·马丁(Robert C. Martin)在“ 干净代码 ”中所说的那样：“因此，如果您想快一点，要快点完成，如果您希望代码易于编写，请使其易于阅读。” 干净的代码不是大多数工程师都能快速编写的。 它需要细化的迭代。 我匆忙编写了一些最混乱的代码，或者更糟糕的是，我没有纪律。 通过受纪律和编写干净的代码，单元测试的安全性以及持续集成的强大功能以及有意义的最新文档的好处，工程师可以自由地快速移动，发布更多功能并更快地完成任务。
In conclusion, we as software engineers can learn a great deal from the SEAL teams. I truly hope that everyone picks up a copy of Extreme Ownership: How Navy SEALs Lead and Win and adopts the principles of Extreme Ownership. Perhaps if we take ownership of our work, we work together, we believe, we plan, and we remain disciplined, we can build something truly great.
总之，作为软件工程师，我们可以从SEAL团队中学到很多东西。 我真正希望每个人都能获得一份“ 极端所有权”的副本：海军海豹突击队如何领导和取胜并采用“极端所有权”的原则。 也许，如果我们拥有工作的主人翁精神，我们会共同努力，相信，计划并保持纪律，那么我们可以打造出真正伟大的东西。
翻译自: https://medium.com/swlh/extreme-ownership-for-software-engineering-96daf6a2a774
705
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
