Autonomy comes from defaults
The Overlap #25
The Overlap is a biweekly newsletter somewhere between product development and organizational development. It comes out every other Wednesday morning.
I used to think that the goal of a self-managing organization was to maximize individual freedom of choice on every decision. Now, I think this produces decision fatigue. People don’t want freedom over every decision, they want freedom over the decisions that matter most. Defaults—“established” ways of solving trivial problems—help us maximize individual autonomy on decisions that matter.
In 1976, residents of a nursing home facility found happiness.
At least that’s what Ellen Langer and Judith Rodin concluded in their seminal social psychology study. Langer and Rodin were trying to understand whether residents would feel happier if they had more freedom and responsibility.
They split the residents into two floors:
On Floor 1, residents were asked to decide when movie night would take place. They also had to take care of the floor’s plants, and place them wherever they wanted.
On Floor 2, the staff decided when movie night happened and where plants belonged. They also took care of the plants themselves.
Floor 1—no healthier or happier than Floor 2—showed more alertness, more activity, and better well-being. A year and a half later, they were still doing better. While Floor 2’s death rate was two times higher than Floor 1’s.
Langer and Rodin concluded: if folks who typically don’t make decisions take on more responsibility, they might live happier and healthier lives.
Templates empower, rather than disempower
When I first learned about this study in my college psychology class, I concluded: “So, more freedom and responsibility fosters more happiness. To maximize happiness, people should have freedom and responsibility for every choice!”
More autonomy meant more happiness, right? After all, who wants to be told what to do?
I’ve learned that it’s a bit more nuanced than this.
When I started helping with new business in my first job, I wasn’t thinking “Let me decide how to write this contract myself!” I just wanted to get the contract out to a prospective client.
In theory, I had all the autonomy in the world to decide how to write a contract for a new client. In practice, I just wanted to copy a template. I wanted to get the damn statement of work into the inbox of a prospective client so that they can decide whether they want to work with us. A template was a tried-and-true way of how I can accomplish this goal. The last thing I cared about was whether to use Munito or Proxima Nova or using H1 or H2 on the headers.
Autonomy doesn’t happen without templates. A template didn’t reduce my autonomy. It freed me from decisions on details that didn’t matter. I felt empowered to get a statement of work out to prospects, because of these contract templates.
I still come back to this lesson as a lead strategist at Manhattan Hydraulics. No one feels comfortable with zero guardrails, zero structure, zero templates. People want to be responsible, but people also want to contribute toward a larger purpose. It’s tough to contribute and be responsible and be autonomous without having some knowledge of how we’ve tackled the problem in the past.
I wrote about how structure is freeing, not restricting:
Structure is a form of a constraint. And constraints free us from anything that gets in the way of our intent.
Defaults over conventions
Ruby on Rails, a server-side web app framework, suggests that conventions—established ways of doing things—helps us focus on the most important challenges.
One of the early productivity mottos of Rails went: “You’re not a beautiful and unique snowflake”. It postulated that by giving up vain individuality, you can leapfrog the toils of mundane decisions, and make faster progress in areas that really matter.
This statement gave me trouble, though. Emphasis mine:
The hard part is knowing when to stray from convention. When are the deviating particulars grave enough to warrant an excursion? I contend that most impulses to be a beautiful and unique snowflake are ill considered, and that the cost of going off the Rails is under appreciated, but just enough of them won’t be that you need to examine all of them carefully.
I used to think every project, every client, every problem merited its own, unique solution. If I used an off-the-shelf solution, I didn’t understand the problem hard enough. After all, best practices rarely work on a complex problem.
But perhaps I can be more discerning. Not every problem is complex. Not all problems are beautiful, unique snowflakes. Not every problem needs a custom solution. Many problems can be solved by… dare I say… convention.
I prefer the word default over convention, though. “Convention” implies a certain level of rigidity: “You must do it this way or else.” “Default” implies there is room to deviate: “Do it this way first. But change it later when it doesn’t serve you.”
You can deviate from the default when the problem deems it necessary.
But if you don’t know how to tackle the challenge, go with the default.
And if you don’t care how you do it, go with the default.
Defaults save us from making trivial decisions and give us the flexibility to adapt. We free ourselves from the tyranny of trivial decisions, while remain open to how we free ourselves from that tyranny.
Make defaults clear
Back to the nursing home residents in Langer and Rodin’s study. Both groups were presented the same challenge:
When should movie night take place?
How should we take care of our plants?
Floor 1’s default was to decide on 1) and 2). Floor 2’s default was for the staff to decide on 1) and 2).
What’s worth noting, though, was that both defaults were communicated. From the paper:
The major difference between the two communications was that on one floor, the emphasis was on the residents' responsibility for themselves, whereas on the other floor, the communication stressed the staff's responsibility for them.
In most organizations I’ve worked with, defaults aren’t explicitly communicated. Shawn from the dev team knows the different technologies that make up your product. You don’t know. Judy in finance knows how to figure out the profit and loss of your division. But you also don’t know. You might know the naming conventions (erm, defaults) of Figma files. Your colleagues may not.
Write these defaults down. Communicate them. Make them easily accessible.
Your colleagues, like you, want to focus their energy, time, and attention on real challenges. Not annoying minutia. Not writing defaults down puts your colleagues in a position to figure out the problem themselves.
And hey. If the default for a certain problem is “it’s your responsibility to figure it out”, at least make that clear. That’s what I’m learning. People want to know the difference between a) when to figure it out on their own and b) when to use the default template.
Identify the problems that keep coming up. Write down how you’ve solved them in the past. Then, frame these as defaults. This maximizes individual autonomy and reduces managerial overhead. Most importantly, this leaves room for you and your colleagues to change it. Believe me, it will inevitably need to change.
I wrote a thing on Sanctuary’s Substack!
Nudging your company to a more distributed model is… kind of like gardening.
I share Sanctuary’s, Hydraulics’, and XXIX’s journey in becoming a distributed org. (Yes, we are all one company.)
I conclude with three areas we’re excited to grow. Because every company blog post talks about their successes. Let’s get real. Let’s talk about where we can improve.
What I’m reading
Not all defaults serve us. When they don’t, we have to nudge them. Kevin Kelly put this well in Triumph of the Default.
One default that doesn’t serve us: whiteness. Friend Darin Buzon passionately wrote about this in Design Thinking is a Rebrand for White Supremacy.
Executives don’t decide if the company culture is good. Employees do. Currently my favorite take on Jason Fried’s and DHH’s decision to ban talking politics in their digital communication.
See you in two weeks,
–tim