{
    Adam Ard
}

Autonomy: The Right to be Wrong

I recently picked up an older (1987, revised in 2013) management book called Peopleware by Tom DeMarco and Timothy Lister; and man where have you been all my life! I haven’t finished reading it yet, but so far, I am highlighting whole pages at a time. It is getting ridiculous. A couple days ago, I came to one of the greatest passages I have ever read on management and autonomy. I couldn’t help but write a few words about it. Here is what it said:

If you’re the manager, of course you’re going to feel that your judgment is better than that of people under you. You have more experience and perhaps a higher standard of excellence than they have; that’s how you got to be the manager. At any point in the project where you don’t interpose your own judgment, your people are more likely to make a mistake. So what? Let them make some mistakes. That doesn’t mean you can’t override a decision (very occasionally) or give specific direction to the project. But if the staff comes to believe it’s not allowed to make any errors of its own, the message that you don’t trust them comes through loud and clear. There is no message you can send that will better inhibit team formation.

Most managers give themselves excellent grades on knowing when to trust their people and when not to. But in our experience, too many managers err on the side of mistrust. They follow the basic premise that their people may operate completely autonomously, as long as they operate correctly. This amounts to no autonomy at all. The only freedom that has any meaning is the freedom to proceed differently from the way your manager would have proceeded. This is true in a broader sense, too: The right to be right (in your manager’s eyes or in your government’s eyes) is irrelevant; it’s only the right to be wrong that makes you free.¹

Drop the mic! Type ‘the end!’ Walk in slow motion towards the camera as the edifice of faulty management principles explodes in the background! Managers everywhere weep and fall to the ground!

Isn’t it beautiful when someone cuts directly to the heart of the matter? In this case, the heart seems to be a red, pulsating ball of fear. Specifically, a manager’s fear of failure and what they do to smother that fear. We shouldn’t be too hard on our managers though. They are in a tough spot. While they have little direct control over what their team is doing, they feel a great weight of responsibility for how they perform. It’s like when you tell your kids not to stick their hands in the toilet, but you can’t watch them all the time; and you know what they are going to do as soon as you aren’t around. It is almost the definition of anxiety. When an engineer get stressed, they have the benefit of being able to go to their computer and bang out some code. Making progress always makes you feel better. Managers don’t have that luxury. All they can do is stare at tasks in Jira or write a memo that no one will read.

In an effort to manage this inevitable anxiety, managers reach into their tool box of implementation strategies — the things that worked for them when they were in your shoes. And that’s a good thing, as long as they don’t start forcing people. Compulsion transforms good advice and helpful training into commandments that make the way forward increasingly difficult for well meaning employees.

Let me paint the picture a little more specifically to the software profession. Here are some of the software commandments that many of us are laboring under today: test driven development, continuous integration, deployment, or delivery, pair programming, branching models, approved languages, approved operating systems, approved cloud providers, approved libraries, approved design patterns, mandatory code reviews, deployment checklists, coding standards, test coverage percentage requirements or even formal development methodologies like Scrum or XP. These are only a few of the constraints that many software developers are currently operating within. These initiatives are innocently presented as “best practices”, but we know what they really are — efforts to prevent employees from ever making a mistake (an impossible and neurotic undertaking). Don’t get me wrong, there is some good stuff in that list; good stuff for engineers to discuss, digest, pilot and integrate into their processes. But it is not good stuff to force on people regardless of their preferences and without allowing them to consider the context around their specific projects. See the difference? It is a bit like trying to force a girl (or guy ) to like you. Even if they would have, forcing them kind of ruins it.

What is the way out of this mighty quandary? First, one must reach for that Zen place where they can trust their people enough to let them do their own thing. Even if that means they screw up sometimes. In fact, according to DeMarco and Lister, that is precisely what freedom is: the “right to be wrong,” plain and simple. If you can mess it up, then you are probably operating with sufficient latitude to be creatively engaged. People never intentionally make mistakes, but being able to experiment and learn from missteps is the way to knowledge and competency. And being able to proceed “differently from the way your manager would have proceeded”² is the essence of true autonomy.

“But wait!” you say. You can almost hear your manager’s response right now, “I trust people that show they deserve it. Trust is earned.” But I say this is a dangerous position to take. Starting from a position of low trust is all too often a self fulfilling prophecy. If you expect people to be unreliable, they will usually prove you right. But giving people the benefit of the doubt instead will give them the best chance to succeed. Letting go of that sweaty, shaking grip on implementation practices and methods is the first step to liberation — focusing on the ‘what’ instead of the ‘how’ and creating an environment where success is possible.

Lastly, if you are a manager, take heart, this isn’t as scary as it may sound. As DeMarco and Lister aptly explain earlier in their book, good management is never about getting the technology right anyway, but about managing the people related problems:

Whatever you name these people related problems, they’re more likely to cause you trouble on your next assignment than all the design, implementation, and methodology issues you’ll deal with…

The major problems of [a manager’s] work are not so much technological as sociological in nature.³

If you can get your people taken care of, it doesn’t matter so much what language they use or what process they follow. They will work that out naturally for themselves. If you don’t know how to take care of your people, read Peopleware by Tom DeMarco and Timothy Lister — that’s what I’ll be doing.

Sources:

1,2,3. Peopleware by Tom DeMarco and Timothy Lister