Leadership and software development

February 1st, 2016

Leadership is one of those tricky words where it can mean so many different things to different people it is hard to know what is meant by it.  I came across this definition several years ago and it is the first one that really resonated with me:

You know there is good leadership happening when you know the right decision will get made – when you aren’t in the room

Life is about more than what we can do as individuals, we achieve great things by working together.  When structures and trust are in place to enable people to handle decisions WITHOUT having to run it up the chain of command, that is not only good leadership, it is faster and a true differentiator.

I recently performed a architecture assessment / workshop for an software development effort.

Design Principles

Design Principles

One of the key exercises that we did together early on was set some Design Principles.  Lay out the qualities by which a solution or process would be judged.  In this way, the effort could become more than just “refactor this class here” to “how do we make this simpler for new developers to understand?”

 

Perhaps this is a function of developing more “gray hair”.  When I was younger I used to groan at the thought of spending a morning talking about “design principles”, and now I consider them a core portion of any serious effort.  As an interesting side note, at the end of the week a presentation on the effort was provided to senior leadership (including the director for the Ministry of Health EPI program).  These are all non-IT people.  On the way into the presentation room they walked past the conference room where we had done the workshop that was covered in sticky notes and whiteboard drawings.  They were so curious they wanted a tour of the workspace where we spent more time talking about the Design Principles and how it was for more than just software development.

Here they are:

  • The person closest to the problem is the person closest to the solution
  • Design for change – not longevity
  • We are more likely to get it right the 3rd time than the 1st time
  • Leave it (the code) better then when you found it
  • Stay focused on MVP (minimum viable product), this means documentation too!
  • Simple is better than complex
  • Follow principles over rules
  • Start small (corollary: small changes make small mistakes; big changes make big mistakes)

Any team that is doing things will produce a higher quality and more sustainable product over others.  And, it will be a lot more fun to work with.

Cheers,

 

 

0 Comments