Do we really believe in autonomy at work?

How autonomous should knowledge workers be?  A lot?

If we believe this, where does this lead us?  That’s the theme of this post.

---

Earlier the subject line of this post included ‘freedom.’  This word carries more emotional energy, and requires discussion of other issues.  Hence, the change.

And do we, the workers and the managers really believe in that level of autonomy? (What level of autonomy is needed?)

Can the Team be left alone, to be fairly autonomous?

Is the Team mature enough to act in a way that justifies autonomy?

To me, these are four important questions.  And I think people often have not thought them through well.

How autonomous?

Clearly, if we join an organization, we agree, to some degree, with its agenda, with its vision and with its direction.

But, wow, that leaves lots of room for questions and discussion.

Imagine a specific case.  You are in one Scrum Team (7 people) dedicated to one mission.

So, right away – you have ‘signed-up’ for that mission. Or you should have.

Managers: I recommend people on the Team clearly ‘sign up’ for the mission.  The Team does not create the mission – they must understand it, value it, and agree.  Make sure they want to accomplish the mission.  Don’t volun-tell them.

Let us assume that the mission of the Team will support the company’s customers and its overall company mission (not always true, but I think usually it is and should be).

So within that Team mission, how much autonomy does the Team have?

In my view, fairly complete autonomy.  Well, if doing Scrum or something similar.

That is, managers can decide only a few things for the Team.

Managers can ask questions about which stories are going into each Sprint (eg, ‘are these the most valuable stories?’).  They can give feedback at the end of the Sprint.

A case that seldom happens: Imagine where the Team’s productivity were very low for a couple of Sprints. Then management might stop the Team, at least for this work.  And perhaps give them more appropriate work.  When we say autonomy, we do not mean complete autonomy.  Management must give them a lot of rope. But at some point must intervene. If only to help the Team.

Can the Team change their process?

Can the Team change ‘scrum’?

In Scrum, the Team must  improve (change) their work approaches.  This is part of continuously fixing impediments.  Every Sprint.

And if these improvements included changing ‘scrum’?  (Or what we call ‘scrum’ at company X.)

Side Note: As a minor point, the Team should not say they are doing Scrum if it is not Scrum as defined by the Scrum Guide.

Well, that becomes a bit more problematic.

The Team needs to own their own way-of-working.  But, often the Team has misunderstandings or fears that are not rational (in the present situation).  So, in my opinion, an experienced Scrum person should talk with them if they want to change something fundamental to Scrum.  The talk assures that they are not losing value (help) by ‘mistake.’ (Ex: “Looking back, we did not understand Scrum well enough.”)

Still, ultimately, the Team must own their way-of-working.

One could imagine the Team moving to  ‘waterfall’, thus having much lower transparency and no working product at the end of every short sprint. Thus management has no mechanism through which to judge if the Team is making progress or not.  There are very few teams that seek this kind of thing, but some do.  So, certainly for its own needs, management needs to discuss significant changes with the Team.

Aside from a few basics (a short sprint, a DOD, a Sprint demo…you can come up with your own list), I think the Team should have the autonomy to change their work approach.  The company might require that they reasonably prove things have improved (after X sprints). The autonomy and responsibility need to be clear.

I hope it is clear that we never said exactly how autonomous: maybe ‘mostly autonomous, but not completely.’

Why is autonomy important?

Peter Drucker defined it as important for knowledge workers years ago.  The research Daniel Pink pulled together in his book Drive proves to me that more autonomy means more productivity.  At least as a generality, for knowledge workers.  It should be our strong bias in managing knowledge workers.  Mostly letting the knowledge workers manage themselves.

More autonomy = more productivity.

The illusion

The illusion many people have is that they are slaves.  When they join a company, they become a slave to the boss.  Not unlike the monster communities in Peter Jackson’s films.  It is a hierarchy; the top dog is master of all.

It is surprising how many of us follow this illusion.  (Of course, it is also true that many of us ignore the ‘power’ and do the right thing anyway. Power is an illusion, mostly, in the modern world of work.)

Many of us do not prefer to use the ‘slave’ word, so we use the military hierarchy metaphor; the ‘chain of command.’  As if any fast-changing battlefield could ever be managed this way.

For many people, including workers and managers, these metaphors still have power.  (Small pun alert.)

Some resolution

In virtually all organizations, there is some sort of hierarchy.  To some degree, perhaps, it is useful.  Although most organizations are mostly hurt by the hierarchy.

(Note: There are some alternative approaches, eg, Holocracy.  Maybe a topic for a later post.)

So, we can say the Team still ‘reports’ to management.  And management can make suggestions, and management must help the team remove impediments.  And management can stop the Team if there is insufficient progress.

Management needs some reasonable means to track the progress of the Team (eg, with a larger release of a product). (The bare framework of Scrum provides for that.)

Otherwise, the Team should be highly autonomous, if management wants maximum productivity from the Team. (This assumes several reasonable things, among them that the Team has the skills and knowledge to be successful.)

If the Team thinks they need anything to be successful, they can ask ‘management’ for help.  In fact, they must.  And management can make suggestions (which are best as only suggestions) along the way.  So, the Team is never totally isolated.

Note to some: If you start with a culture with a strong belief in ‘I’m just supposed to do what I’m told to do’, and move too quickly to autonomy, you might have problems. Be careful about that transition.

The bigger issue

To me, the bigger issue is not the autonomy of the Team, but the autonomy of the group of people who together are evolving.

Do we really imagine that each person is smart and ‘free’.  And that each one can contribute?

Then, the immediate issue becomes – let’s assume that the evolution is in the direction of agile.  How do they agree on what agile will be for them now?  (I imagine that agile is always improving, or changing.)

One option: Management could impose agile on them.  Again, this reminds me of a Peter Jackson movie, with the same kind of dark results in those animalistic evil communities. Or certainly some demoralized people.

Who knows how many other options or directions in which that group could evolve.

An alternative:  We think Open Space Agility (OSA) is one better approach.  After some initial experimentation (eg, a pilot team), management sets some business goals, says ‘I think agile might help us get there’, and then asks the group for help in filling in the details.  Management sets the Mission. The group figures out how to accomplish the Mission.

Open Space Agility respects the autonomy of each person.  It invites and allows each person to participate in creating the change.  And, so, the change will happen faster and better than it otherwise would have.

Does that mean things will go well? Honestly, not necessarily.  Sometimes organizations have some intractable issues.  Sometimes there have been ‘hidden’ things that come to light.  It could be ‘hard.’  But in fact, again, what usually happens is that the change is better and faster.

During OSA, everyone gets to speak and voice his opinions, share his or her knowledge, and raise questions.  This includes management and the agile advocates that management might have hired (eg, agile coaches).  But, there should be no sense that anyone is imposing their will on the group.  The minority who may want to do waterfall may not impose, management will not impose, and the agile coaches cannot impose.  But all can discuss, and offer suggestions.

Where do we start?

This all starts with a recognition that that people are important and they are free.  And that this freedom still fundamentally applies in a work situation.  And should apply (from a managers’ viewpoint), since autonomy makes them more productive.

Believing in freedom does not mean that one believes that suddenly mankind is perfected. No, no, no.  They are free to be imperfect.  (They were always going to be imperfect.)

But even their imperfect freedom will be better than the ‘perfect’ slavery you could devise for them (or that they devised for themselves before).

If you are a manager, perhaps it is useful to use the teenager metaphor about now.  Think of them as teenagers.  They are knobby-kneed, but eager.  Surely, like we ourselves even now, they will be imperfect.  We cannot suffer the illusion that they really listen to us much.  So, set a vision, hopefully grab their attention.  And exert a clever influence now and again.  And remember that the best result is not that they become who we want them to be, but who they are.  And if they do, truly do as adults, then what they will accomplish will be better than we have done.  This is good.

***

Note: The picture at the top is of one of the four unfinished ‘slaves’ by Michelangelo at the Academia Gallery in Florence.  This one is said to be ‘Atlas.’  Imagine how much energy was released when the Dark Ages were replaced by the Renaissance.

Note: If you want more information on Open Space Agility, you can search this blog, or go here.

 

« « Proposal: Learn about Open Agile Adoption || Sprint Planning Meeting – The Basics » »