Giving Empowerment or Taking Autonomy

Part One

I’ve been working as an agile mentor for a few years now. (This is a mentor of agile software development teams, not a mentor of all things bendy – just so we’re clear.) In this role, I’ve built up a fair amount of experience in helping teams overcome technical /process problems and I’ve recently become interested in the softer side of agile software development teams – the psychology behind agility.

It all started when I watched a video on YouTube “The Surprising Truth of What Motivates Us” http://www.youtube.com/watch?v=u6XAPnuFjJc which is a summary of the book of the same name by Dan Pink.  By pure coincidence, on the same day I watched the Youtube video, I read  some review comments on a paper that debated whether the term “empowerment” or “autonomy” should be used when talking about the goals for true agility. It was an interesting discussion and it made me question some of my previous assumptions.

The first question is – what is the difference between autonomy and empowerment? A colleague said that in the simplest terms empowerment is given whereas autonomy is taken. If you look at definitions of the two words in the simplest form, they are:

Autonomy - the power or right of self-government

Empowerment - the giving or delegation of power or authority; authorization

The definition of autonomy implies that the right to self-govern is yours for the taking. How you go about taking it is certainly dependent on the context. It may have to be wrestled from a dictatorship in a region of political unrest; or, in context of a team striving to try a more agile approach in an open and forward thinking organisation it’s less of a wrestle from a dictatorship and potentially more of a memo to an appropriate member of a leadership team. Far less bloody, hopefully.

So why do we always use the term empowered when we talk about a self-organising, agile team? This implies, from the definition, that empowered individuals don’t have a choice and that power is delegated down to them, whether team members want it or not.

Clearly this isn’t so much of a problem when an individual actually wants some level of self governance. If autonomy is available they will take it or if they are empowered and the authority is delegated to them then conceptually this will result in the same behaviour.  Even here though there needs to be some definition as to the extent of the empowerment and/or the scope of the autonomy otherwise a completely autonomous software team could theoretically build whatever they want, whenever they want.

Next Post - Giving Empowerment or Taking Autonomy in a Team


1 Comment