Extreme Ownership for Software Engineering
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.
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.
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. 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.
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. 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.
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. 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. 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. 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.
- 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. 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.
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.
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. 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.
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.
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.
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.
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.
- 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.)
- 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.)
- Brief the plan to all participants and supporting assets (Sprint Planning.)
- Conduct post-operational debriefs after execution (Sprint Review and Sprint Retrospective.)
I truly think that if an organization adopted Babin’s checklist for every team in the organization, the results would be exponential.
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.
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. 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.
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.
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.
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.
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.
