No matter what we're building — whether it's a habit, a tool, a company, or a culture — we need to pay very close attention to what the defaults are. If someone follows our process and accepts all the defaults, what kind of outcome does that create for them and the people around them?
Even the most well-intentioned people have a finite amount of energy to fight against a system that pushes toward bad outcomes. If we provide bad defaults, we're setting ourselves, our users, and our teams for failure.
People have a tendency to accept default options. At Walt Disney World, changing the menu defaults to healthy sides resulted in roughly half of all orders making healthier choices — by default.
We need to make sure the defaults are carefully designed to create a desirable outcome. If someone takes the path of least resistance, it should create the ideal outcome.
When presented with choices, people tend to choose the easy thing. Defaults are the easy thing. We need to make the right thing the easy thing.
When I set out to change habits, I look at the outcome I'm trying to create and see what I can do to make that outcome automatic.
When I decided to cut back on snacking, I stopped bringing snacks into my house. I'd get peckish, wander around my kitchen looking for something to munch on, find nothing, and realize that I definitely didn't want a snack bad enough to leave my house for it. This made the default outcome (me being lazy, not wanting to work too hard for food) the right outcome: I dropped my snack intake drastically.
I used a similar technique when my phone time felt like it was getting out of hand: no phones in the bedroom. I would plug my phone in downstairs before bed, and my only entertainment in the bedroom was a book. This led to significantly less time wasted on my phone and significanly more books read — all because the default choice was to read since I didn't want to get out of bed to get my phone.
I avoid relying on willpower or "making good choices" because I know my brain is a traitorous asshole that will rationalize eating an entire block of cheese when I'm tired or sad.
By requiring more effort to do the wrong thing, I put my laziness and inertia to work. Being lazy becomes my path to success: I've made the right thing the easy thing.
In software, there's a balance to be struck: we don't want to create a "magic box" that people can't understand or debug, but we also don't want to create a pile of raw utilities that can't be used effectively without deep understanding of how and why they all work.
My preferred approach to writing software is progressive disclosure of complexity: start with defaults that put best practices in place, then let someone opt in to deeper layers of customization as needed.
Too many tools implement defaults that have performance, security, usability, and other problems. They treat the defaults as a "quick learning example that's not production-ready", which then gets shipped to production by — according to the research — about half their users.
When you build a tool, create defaults that start someone at a production-ready outcome. They should be able to initialize with all defaults, ship it, and see great results.
On teams, we need to shape the path so people have everything they need to be productive. This requires us to look at our processes and tools to ensure that we're clearing the path for our team instead of inadvertently putting up roadblocks.
Building a strong foundation of trust is the most critical step toward building successful teams. This means a few things:
- Be clear about what the team is expected to do. Have a clear roadmap and metrics and make sure these are communicated over and over again.
- Establish outcomes, then trust the team to get there. Don't micromanage or hover over your team. Provide a definition of done and get out of the way.
- Treat organizational health as a top-line metric. Don't ignore people problems and pay close attention to the mental health of your team. If organizational health suffers, productivity, engagement, and retention will suffer.
In addition to trust, giving the team the right technical foundation plays a huge role. A company's tech stack and architecture have a huge effect on how productive a team can be, so make sure you're choosing tools with great defaults and guard rails to give your team the strongest baseline productivity possible.
When designing any new process or system, we should assume that — at least half the time — we're going to be taking the path of least resistance. This means that the defaults we create will account for around half the success of our new process or system.
Good defaults are the difference between a huge success and a humbling "what went wrong" meeting.
If we only focus on creating excellent defaults, we can ensure that we'll see success the majority of the time. This is the magic behind "zero config" solutions: they spent all of their time on defaults and decided not to allow changing them. If we start there and allow progressive disclosure of complexity as needed, we set ourselves up for success without sacrificing flexibility.
Make the right thing the easy thing.
Set good defaults.