Happy Labor Day, and welcome to the conclusion of my series on Extreme Ownership! For the past three months I’ve been taking a chapter from the book Extreme Ownership and reflected on how the principles in the book were exemplified (or should’ve been exemplified) in my past experiences. I’ve learned lessons on what it takes to be a good leader, and I hope my readers can learn some as well. Here’s the list of previous posts in case you missed them:

The last chapter in Extreme Ownership is called Discipline Equals Freedom. At first glance one would think that this would be a section on work ethic. In fact, here’s a super-short example brought up by the authors:

When you have the discipline to get up early, you are rewarded with more free time.

However, the chapter is really about navigating ideas that are seemingly contradictory. Discipline and freedom are often viewed as contradictory qualities, but when people have control over their own actions it enables them to be more flexible and more able to improvise. This chapter challenges the assumption that the ends of an axis are mutually exclusive, and it encourages the reader to flirt between two extremes. Extreme Ownership is a book about leadership, but the book says leaders must also be ready to follow.

Here are some examples of Discipline Equals Freedom that I’ve discovered in my life:

Work independently, but ask for help when you need it.

There have been conversations at work where I’ve compared myself to Batman. In the past I enjoyed doing detective work on codebases, figuring out how a feature worked and where a particular bug originated. This was absolutely necessary at my previous job after the original authors of the code left the company, and new engineers were brought onto completely different projects.

I think I developed this habit after realizing that I was The Load in college. For my capstone project, I was put on a team tasked with making improvements to a fabric drill. Everyone else had skills they developed from past internships, but I spent over half a semester trying to get a motor to work. Eventually the team was able to move forward, but it wasn’t because of anything I contributed to the project.

But this level of hyper-independence isn’t necessary when you have a team – or a Justice League – to tap into. On one hand there are coding tasks you just have to do your own; there isn’t anything other engineers can add to the experience so don’t make them tag along. However, when you enter a part of the codebase you’re not familiar with you should reach out to the people who have worked on it. By not doing so you’re actually dragging down the team because you’re not making the most efficient use of your time.

Be opinionated but not dogmatic.

Everyone has a bias, as my high school history teacher would say. If you write there’s a purpose behind it, and it will skew you towards a direction no matter what. Anyone who claims to not have a bias either lacks the self-awareness or is feigning neutrality to look more credible.

There are times at work where you’re going to have to make an argument for something. These could be discussions on how a feature should be implemented, the coding practices taken up by the team, or even which direction your company should take. The fact that you have a job meant you had to advocate for it at some point. So don’t feel guilty if you feel like you have to speak out sometimes.

Opinions, however strong, will form over time. I’m not going to argue against that. What I will say is that your views are the result of some desire, like getting your company to be successful or making sure your employees don’t get mistreated, and those objectives should remain in focus when you make decisions. It’s when your ideals contradict with your actual goals is when you should start reconsidering.

Be assertive but don’t become a loose cannon.

The previous point explored your relationship with your opinions; this one looks at when and how they should be expressed. It is perfectly okay to tell people how you feel in private conversations, with people you confide in. It’s in other situations when you need to consider how you conduct yourself and maintaining healthy communication habits.

In the previous chapter of Extreme Ownership, the authors state that publicly objecting to leadership is a bad look, as it casts doubt on everyone in the organization. At my previous job, I’ve been in video calls where I was told not to react when the head of our department had unreasonable plans for our team, like making a web version Makr when our team wasn’t equipped to do so. I’ve also stormed out of meetings when our offshore consultants launched Makr for Web and management found issues with the product. In my mind these developers took the wrong approach fundamentally and it was too late to course correct, so I stayed resentful instead of trying to find a solution. That behavior was detrimental to everyone in the organization – leadership, my peers, and myself.

That’s it for this book! Looking forward, I’m thinking of going back to writing about more technical topics. I’ll discuss my plans further in depth next week.