Part of 15 in the series
Let’s talk about the A from RAMPS today: Autonomy.
Autonomy is "simple not easy," just like the rest of the motivating forces. Autonomy is the sense of an individual that she is free to work the best way she knows how to achieve the tasks in front of her. We call self-driving cars "autonomous". We do that to contrast them with cars that are controlled by humans: machines. If I say an individual doesn’t feel he has autonomy, I’m saying he feels like he’s just a machine at work, controlled entirely by others.
In my experience, autonomy is always set lowest on the slider in the IT departments of large organizations (VBCAs). The classic definition of non-autonomy is that of totalitarianism: Everything not expressly required is expressly forbidden. Notice that this is a game of boundaries. Organizations always have boundaries, rules drawing lines, beyond which we don’t go. As we’ll see when we get to interaction effects later, boundaries are best situated carefully with respect to purpose. Almost every restriction on my working freedom removes motivation from me. BUT, if it balances with other sliders, it’s worth it, net +.
The most disastrous boundaries I see are usually the ones justified by "efficiency" (the scare quotes are intentional.) And the second class of disastrous boundaries are those justified by what we call asteroid worries. "What if an asteroid strikes the company’s campus?" is an asteroid worry. It simply doesn’t bear any weight of concern at all. Because if an asteroid strikes, the comment blocks you require before every method JUST WON’T HELP.
How can managers affect autonomy? In ways big and small, actually.
We increase autonomy by reducing the set of boundaries to the smallest set we can live with. By rigorously connecting them to purpose. In already-demotivated teams, by strongly encouraging step-wise experimentation around pushing and probing and meeting those remaining rules. The biggest known bang for the autonomy buck, the one that gets the most press, is quite largescale, and it has to do with time. Companies reduce or eliminate fixed hours and fixed locations for their workers. Many companies have run many such experiments, from killing time clocks, to offering X days a week of "work from home", and even completely eliminating every requirement that a worker be present.
Here’s a fascinating thing: Almost none of these companies have abandoned their experiments, and many have made them firmest policy. I’m gonna ask a bitter question: Do you think these orgs do this because they love their employees more than their stockholders? No. I’m sorry. They don’t. They do this because their employees get more work done without the rule than with it.
The range of moves towards autonomy are hardly limited to hours and location, tho. There are myriad opportunities large and small. Almost anything that makes me more of a human and less of a machine increases my sense of autonomy. Let’s look at some small ones.
Almost all "standard process" efforts reduce autonomy. Try making every such standard fit on one page. Got a coding standard? Make it fit on one page. Got a database normalization standard? Make it fit on one page. And so on and so forth. I should be able to hand my new geek ALL of what she’s required to do as a geek on three or four pages. How laborious are your rules for checking in code? I’ve a client whose teams take half-an-hour FOR EVERY PUSH. Lose that fast.
As orgs grow, there’s a huge pressure to standardize. Resist that pressure with great ferocity. The rationale is that we must have every team work the same way to work together. It’s simply bogus. I’m sorry, but it is. What we must have is every sub-team interacting with every sub-team in their view in a way that works for both sub-teams. The idea that that means they all work the same way is a boundary too far, and a classic instance of Idols of the Schema.
I’ll drop one more note. Remember my starting question was about how do I get my team to feel a sense of urgency? By the time we ask that, we’re in trouble. And much of it comes from over-bounding, from loss of autonomy. We’re in recovery mode.
There’s a special technique here. "Catch them doing something wrong, then bless it." A team eschews the standard manual check-in and rolls a script where they ask the user two questions and automate all the rest. Bless it. A team rolls code that is excellent and needed but not part of the standard process? Bless it. After-the-fact blessing of individuals pushing boundaries, small and large, that’s how you bring them back to a sense of autonomy.
When I meet a new team, they’re almost all wondering what kind of random crappy new system I’m going to force them to use. "What fresh restrictive hell is this?" I find the easiest-to-fix owwie that they feel, and I say, this is stupid, let’s fix this. Rinse, lather, repeat. After a few of these, they start to get it: My early big mission is to free them to take control over their work life. I don’t care about method or system. I don’t care about rules. I care about whether they are gaining control over their work-life.
Sometimes, I go to the grandboss and say, "They want to try this, and they’re scared of you. Don’t notice it for two weeks, then bless it." (I’m corrupt.) A few weeks later, the grandboss comes by and says, "I see that you’re not doing X, you’re doing Y. How is it?"… she says, "Great! You folks are rocking." and walks out the door.
This is the granting and encouraging of autonomy. It’s resisting standards for the sake of standards. It’s resisting asteroid rules. It’s telling trusted people that we trust them to help us solve problems, without telling them how. Teams that feel in control of their work out-perform teams that don’t by orders of magnitude.
People want to succeed. People don’t want to be machines. Hold those two ideas close, and autonomy can drive your urgency-blues away.