What extreme ownership means for software developers

What is Extreme Ownership?

Most of all, it’s a book. It provides a detailed leadership philosophy based on taking complete ownership of our tasks.

I will not attempt to summarise the book (please read it, as it is great), but the core message is that you should never shift the blame to others and should do whatever it takes to achieve the objective.

This doesn’t mean you must do everything yourself or that you need complete control over all actions taken to reach the objective. But it means you take responsibility for ensuring that the objective is reached.

What Extreme Ownership Means for Software Developers?

Although the mentioned book targets leaders, it applies well to individual contributors regardless of their seniority levels. Embracing it early in your career can greatly improve your leadership skills, positioning you well for a staff+ or manager role. As you will see below, ownership doesn’t require control or authority.

Below you can find a list of examples of how to apply extreme ownership principles to the job of a software developer. The goal is not to list all possible aspects but to help you build the understanding and mindset behind extreme ownership. You don’t need to embrace it to the letter. You might not have the space or freedom to do this. But you should at least try.

Disclaimer: The points are written in a provocative style. I am not in a position to tell you what your job is; this is just a way to showcase your mindset.

• You own your code. It’s your job to keep it clean, maintainable, and extensible. It’s your job to refactor parts that need refactoring. It’s your job to design, document, and test it. It’s your job to understand when those things don’t matter and shouldn’t be done. It’s your job to ensure you have the time and space required and that everyone understands the value of those activities.
• You own your tech stack. It’s your job to understand the tools you’re using, why you’re using them, and their pros and cons. It’s your job to stay up-to-date and propose new libraries, frameworks, and solutions when necessary. It’s your job to know what is out there and when not to reinvent the wheel. It’s your job to asses the cost of introducing new tools. It’s your job to know the trade-offs of using external libs vs building them in-house.
• You own your build pipeline. It’s your job to keep it always green. If someone else broke it, it’s your job to ensure they are aware and that it will be fixed. It’s your job to understand how it works. It’s your job to care about its execution time. It’s your job to improve it if needed.
• You own your software operations. It’s your job to keep system uptime as high as possible. If you integrate with external parties, it’s your job to put preemptive measures in place to mitigate their outages. If you have unreliable infrastructure, it’s your job to push for improvements. It’s your job to fix bugs as soon as they are spotted.
• You own your software observability. It’s your job to put metrics, logs, traces, and alerts in place. No one should need to tell you it has to be done.
• You own your tech debt. It’s your job to monitor it, identify points worth fixing, and act on them. It’s your job to ensure you have space to do that (e.g., by talking to your EM).
• You own your process. It’s your job to speak up when the process is slowing you down. It’s your job to speak up when you have too much or too little meetings. It’s your job to understand the differences between Scrum and Kanban and which might work better for you.
• You own your career. It’s your job to know what you want to learn and where you want to be in a couple of years. It’s your job to seek guidance or mentorship from your EM.
• You own your skills. It’s your job to know what you’re good at and what not. It’s your job to seek feedback. It’s your job to improve. It’s your job to push for resources from your company to enable that improvement.
• You own your requirements. It’s your job to understand what you do and why. If there is anything missing, it’s your job to clarify with the PM or stakeholders.
• You own your product. It’s your job to ensure your PM is making the right calls. It’s your job to understand your business. It’s your job to understand why you are implementing a given feature. It’s your job to push back on features you don’t find valuable.
• You own your management. It’s your job to ensure management has visibility into your work. It’s your job to ensure they have all the information needed to make good decisions. It’s your job to speak up when you think a wrong call is being made and to keep them to the highest standards. It’s your job to understand why management is making the decisions it is making. It’s your job to contact your skip manager (or CTO or whoever else is needed) when necessary.
• You own your communication. It’s your job to be understood. It’s your job to sell your ideas. It’s your job to ensure you’re being heard. It’s your job to foster your language, public speaking, and writing skills.
• You own your environment. It’s your job to push for changes in surrounding teams when you can’t cooperate effectively. It’s your job to raise issues with engineering culture. It’s your job to drive bottom-up initiatives to improve your workplace.
• You own your failures. It’s your job to recognize your bugs, your missed deadlines, and your missed requirements. It’s your job to make sure they don’t happen again.
• You own your commitments. It’s your job to assess the feasibility of tasks given and reject them if not doable. Once you commit to a task, it’s your job to see it through to completion.

If you ask me to summarize it further, these are my principles:

• Never hope that something will improve by itself.
• Never tell yourself, “it’s not my concern.”
• Never blame others.

Yes, but…

No, there is no but. You can either have excuses or results, but you cannot have both. If you want to embrace extreme ownership, excuses are out of the options set.

Still, let me answer a few points anyway.

• But I’m here for money. Yes, we all are, and this doesn’t change anything. You do your best and expect to be paid accordingly.
• But I can’t do everything myself. That’s correct, and you shouldn’t! The most important part is to let people do their job. Notice when they fail, and do not let that impact your work. You will never be in control of everything, but you can still take ownership and the blame.
• But not everyone can be an owner. Having multiple people with that attitude on the team is a good problem to have. And it’s not really a problem. Ownership doesn’t mean control. In this scenario, all people will ensure things go well and will try to take the blame if it doesn’t.
• But my company won’t let me act accordingly. Then push for it. Then push for it harder. Then quit. In the end, you’re also the owner of your life. If you believe in the extreme ownership philosophy and your company is against it, then you need to decide what is more important for you and change either the philosophy or the company.

Extreme Software Ownership was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.