cliches until you get them

  When it comes to software development and teamwork in general, a lot of very useful rules often sound like cliches. That’s because we look at them superficially. But with new experiences we get to realise what they mean in depth and only then they become useful. The guys that coined this one aren’t superficial by any means.

  One time when I met with my friend Lesha over a beer, I began to tell him how frustrated I was about the decision that was made related to a problem I had been working on. Because of that decision I had to rewrite a big chunk of code and I was all unhappy. We started talking about responsibility in software projects and he began telling me how it was my own fault and that I should read a book titled “Extreme Ownership: How U.S. Navy SEALs Lead and Win”. And he was right.

The Book

  Two Navy Seal commanders go to Iraq to fight insurgents. After coming back home, they gather their leadership experience from the combat zone, build a consultancy company and start mentoring leaders of large companies. On Leadership off course.

  You may think that doesn’t make sense. How difficult could it be to tell soldiers what to do? Well if you thought that, you’d be damn wrong. The level of self-awareness they have is amazing! But it all boils down to one simple rule - “own it”. Be responsible for every aspect of your work. Never put the blame on somebody else, or on external factors.

  The reasoning is simple. If you failed because of external factors - maybe you should have anticipated these factors and mitigate them. If you failed because of an order you got - maybe you didn’t spend enough time to make sure the person giving the order had enough context to make the right call.

  If you’re not that much into leadership guidelines, the realities of war described in this book should be interesting enough to read it. The multitude of problems that need to be solved immediately in any situation is overwhelming. If these guys were blaming others for their failures, they would be long dead already.

  But if you are - these guys are also great at translating what they learned in the battlefield into useful tips for managing big companies. There is a great chapter on a CEO of a large corporation that fails to meet his goals. There are a lot of problems, but they all boil down to his subordinates not executing on his orders as he intended them to. The board is very unhappy about the overall performance and there are rumours they might fire the CEO. The advice he gets is incredible: be extremely honest with yourself and admit that it’s your fault that you didn’t make the subordinates do what was necessary to do to meet the goals. Admit it to the board, say what exactly should have been done differently and how you are going to mitigate such situations in the future. Because only then you will regain their trust.

The fight at the office

  When working for a software company we have the comfort of not having to doge bullets or risk our lives. But jokes aside, a lot of what they are telling us works great for a software project as well.

  Don’t tell people your product doesn’t work correctly because the specification wasn’t good enough. Plan aside time to work with the client to correct the specification in the first place.

  Don’t blame your subordinates or teammates for not doing a good job. Spend time to teach them what they are missing instead.

  Don’t blame the CTO for making you redo your work - talk to them and explain what problems their decision creates for you. Either convince them to agree with you, or allow them to change your mind. As long as you have a similar mindset, you will always find a middle ground.

  Don’t tell people the designs you got were bad and that’s why your work looks bad. Make the designer correct their work. Or learn how to design stuff yourself and fix it.

  It’s that simple!