Why Having Extreme Ownership Mindset is the Best Skill for Your IT Leadership Career
Tags: career, discuss, productivity, agile
Published: 2019-09-19 12:01:40

__Is there something you do not like in your life? Either in a personal aspect or a professional one? Yes? Think about it.__
- Is it a bad habit you can’t shake from your daily routine?
- Is it a sense that your work is not perceived as you want it to be? 
* Is it a feeling you are not working on the right project for you? 
* Is it that you want to finally start your own project and develop a software product that you are passionate about?
* Is it dissatisfaction with your relationship with the people in your life that you consider important?

Wanting to make adjustments to our lives is natural. It is thanks to this sense of dissatisfaction that we grow. We know what we want to change and we actively take steps towards achieving our goals. 

Especially when it comes to the dynamic world of software development, that seems to have higher and higher requirements just to stay on top, taking any opportunity to grow and evolve is a must. From my experience working for an [angular software development company] (https://dreamix.eu/technologies/angularjs-application-development-outsourcing), the biggest difference that you can make for optimal results, both on a personal level and working with the team, is changing your mindset. 

Ask yourself this: **“How do I currently address failure and missteps?”**

###Do you Blame Others for Your Failure or Take Extreme Ownership (EO)?
Growing a project as a developer requires you to be particularly active with resolving issues and implementing different solutions. You need to have a good enough understanding of the work process that allows you to prevent you from making a big mistake, that can wreck the project, that could potentially hurt the business. 

And in doing so, it is easy to start looking at things that have gone wrong by looking for the one who messed up. Especially in the software development world, where to develop a single product a team of various specialists must come together and chip in, each with their own expertise. It is easy to start looking for the person who caused the misstep and assume that if you scold them, and demand them to change their practices the issue would be resolved and not re-occur, all the while validating your thought process by telling yourself something similar to the following.

>*The other developers did not program the software correctly.*
>*The quality assurance team missed a bug.*
>*The designers did not create a good enough interface.*
>*The marketing team did not advertise the product well enough.*

This is what many fail to understand - this leadership mindset is the reason their project follows a path that disrupts the team’s efficiency. Creating an environment where the norm is to single out any given member and scold them for the overall performance in their department is detrimental to the overall productivity. They will start pointing at each other every time a situation arises, instead of directing their efforts to resolve it.

As a leader, if you willingly pass over the responsibility to the rest of the team, you set yourself up for having to deal with each of them approaching the project from their own perspective - often reducing the chances for having a well thought- out and overall coherent product.

In addition, when it comes to approaching and resolving issues, who is to blame should be irrelevant - all efforts should be focused on developing a solution, that extracts the best results in a small timeframe.

#The Benefits of Extreme Ownership Mindset and how to Adapt It

This is where the principle of Extreme Ownership steps in and makes all the difference. The concept originated and earned its name from a [book](https://www.amazon.de/Extreme-Ownership-Navy-Seals-Lead/dp/1250183863/ref=sr_1_1?hvadid=214411030761&hvdev=c&hvlocphy=1001448&hvnetw=g&hvpos=1t2&hvqmt=e&hvrand=10156032334122119481&hvtargid=kwd-301351891132&keywords=extreme+ownership&qid=1568816588&s=gateway&sr=8-1), developed by retired navy seals who wanted to take their leadership experience from the battlefield and adjust it to benefit business leadership strategies.

The core belief is that any and all possible outcome, when analyzed can be traced back to a decision you made - hence taking Extreme Ownership of anything even remotely connected to you. It is the principle of accepting accountably of the end result and analyzing how you could have approached your involvement to extract better results in future instances. 

You have no one to blame but yourself, the only one responsible for extracting success is yourself! By doing this, when encountering setbacks, it is your duty to analyze and adjust your own behavioural patterns, to fit the outcome you want, when opposed to the results you are achieving with your current practices.

##Here is the difference in examples:
####Instead of thinking…
>*“The other developers did not program the software correctly.”*

An Extreme Ownership (EO) oriented project development leader would consider: 

>>*“ I did not give the development team clear enough assignments, deadline and the vision of how the end result functional software is expected to perform. I should have outlined the tasks and deadlines in a better way that minimizes the opportunity for grey area and misunderstanding”.*

####Instead of thinking…:
>*“The quality assurance team missed a bug.”*

An EO oriented project development leader would consider: 

>>*“I did not encourage and demand clear enough documentation or set up the necessary meetings to establish what needs to be tested and in what order to confirm excellent functionality. I should have established a proper feedback line for debugging purposes that allow for bugs to be noticed and resolved in a more timely manner, before the release date”.*

####Instead of thinking…:
>*“The designers did not create a good enough interface.”*

An EO oriented project development leader would consider: 

>>*“I did not describe clearly enough how I want the user interface to complement the software’s functionality. I should have demanded more detailed documentation on how the software would perform, and demanded to review the stages of interface development, as mock-ups are created. This would have allowed for flexible changes on time without having to rework big parts at the end of production, or delaying release date”*

####Instead of thinking…:
>*“The marketing team did not advertise the product well enough.”*

An EO oriented project development leader would consider:

>>*“I did not provide clear requirements on how I want the final product to be presented, what clients I want to target. I should have overseen the initial marketing planning meetings for campaigns to confirm advertisement is headed in the right direction.”*
 
#Find Your Mistakes and Extract Definitive Corrections to be Made
As far as leadership principles go, this one is fairly simple. Everything that could potentially go wrong, is considered from the perspective of **“How could I approach this situation to extract the best results from my teammates?”.**

Once you have accepted the responsibility that you can affect on a large scale not only your own but the performance of those around you, you are entirely the person in control to make the most of any future projects. And once you realize that, the weak spots that can turn into a business or development failure immediately becomes something you can personally strengthen by adjusting your mentality and your leadership methods.