Developers not taking ownership, it’s your fault as a leader so stop bitching and take command

During my early days as SA, developers were coming to me regarding every small design issue which the leads or the senior developers should have been able to answer easily and design.

I was frustrated and annoyed because the lead and senior developers were not taking ownership and the initiative. At first, my frustration was at the developer’s until I came across the audiobook The Dichotomy of Leadership: Balancing the Challenges of Extreme Ownership to Lead and Win by Jocko Willink & Leif Babin.

I took away many points from this book, and during one of the many ah ah moments I had I realised that it was not the developers’ fault, but it was mine, as a leader it was my fault that the developers weren’t taking ownership. Why because I was micromanaging the developers and the architecture at a level which was stifling. I was inhabiting the growth of the developers and stopping them from taking the initiative and killing creativity.

Decentralise command and relinquish control

So I needed to stop micromanaging, but, how could I do this.
Well over the course of many weeks I ensured I did the following;

• I created checklists, ensured that standards and principles were written down and were clear
• I then had many workshops where I went through the guidelines and principles were writing down and shared and ran through and understood by the developers
• Wrote down the architecture Decisions which stated the reasons why we were using technology over another, using a pattern or a methodology. Stating why the architecture is designed the way it was.
• Ensuring the developers understood the why and the Architecture intent and vision
• Saying no to meetings where I knew no upfront designing had been carried out for the problem (unless I was the one who was required to run through the architecture designs)
• Delegated solution design to the lead and senior developers for changes which weren’t high complexity or high priority and not cross-team/system changes.

At first, the number of changes the developers needed to make to the proposed design was high, but after a short time, I was able to highlight and fill the gaps in the communication and the guidance which I was providing. Over a short time, the number of changes needing to be made was small and even better because the developers were able to exercise their creativity and more heads are better than one. Everyone has different experiences and brains work in different ways. Because they had a better understanding of the situation at a more detailed level than me, they were coming up with solutions which were better than what I would have designed.

It didn’t happen overnight, but as I learned and improved communication and giving direction, I was able to reduce the amount of detail and guidance I needed to provide to the teams.

I did with some teams and projects provide too little guidance which I needed to correct. But as the book Dichotomy of Leadership taught me being a good leader is about finding the balance between taking too much ownership and not taking enough.

Over the course of the many months, I am still trying new communication tools and reviewing and trying to improve how I communicate changes, objectives, decisions and strategic goals and intent of the architecture. One tool I am looking at the moment is recording videos along with the written documents to communicate to people (not just developers).

I would highly recommend reading or listening to the book The Dichotomy of Leadership: Balancing the Challenges of Extreme Ownership to Lead and Win by Jocko Willink & Leif Babi if you are a leader or a manager.

Remember once the seeds you sow, start growing you need to water and feed the tree to help it grow and occasionally prune parts of it back, or it will grow out of control, and this is the same for developing architecture and culture.