The CEO of Airbnb doesn't believe in autonomy

So maybe engineering managers shouldn’t too?

Last month, Brian Chesky (Airbnb’s CEO) said:

“I don’t believe in autonomy... most people don’t actually want it.”

At first, I was confused. Isn’t autonomy what we’re supposed to want and give to our teams? But then I thought:

• What do people mean by autonomy?

• What do I mean when I ask for it?

• Do I actually want full autonomy?

For years, leaders have been told to give their teams more freedom and avoid micromanaging. But does that always work? Let’s explore the risks of too much or too little autonomy and how to have a balance as an Engineering Manager.

Consider supporting my work and subscribing to this newsletter.

As a free subscriber, you get:

• ✉️ 1 post per week

• 🧑‍🎓 Access to the Engineering Manager Masterclass

As a paid subscriber, you get:

• 🔒 1 chapter each week from the book I am writing “The Engineering Manager’s Playbook”

• 🔒 50 Engineering Manager templates and playbooks (worth $79)

• 🔒 The complete archive

---

When Autonomy Goes Too Far

Autonomy = the ability to make your own decisions.

When engineers make their own decisions, you risk sacrificing two things:

1. Alignment

2. Quality

Here’s what happened when I gave full autonomy to one of my engineers.

A mid-level engineer wanted to prove himself. He asked for a bigger project to lead on his own, and I thought, “Why not?” so we found an opportunity for him to do exactly that.

At the design review, I thought he started to go towards the wrong direction. I remember thinking that, but I didn’t want to take back my promise to him.

I wanted him to fully own it, and drive it forward the best way he knew. He was the subject matter expert after all, as he was closer to the codebase than me.

The project moved forward, and I hoped for the best.

A few weeks later, issues started arising. His design didn’t fit well with our existing systems, and fixing it would require major rework. The team felt frustrated, and he felt defeated.

Looking back, it is clear that I was not as involved as I should have been. On top of that, I didn’t make sure the rest of the team was close to this project either.

I had left too much autonomy altogether to this one person, setting him up for failure.

---

When There’s Too Little Freedom

Being too controlling as a manager might seem like a safe choice. After all, you will seemingly avoid all mistakes, keep everything on track, and keep the standards high. But as you might already think this approach discourages ownership and growth.

I was once deeply involved in every aspect of my team’s work. I would write all specs, review every ticket, and double-check our estimates every other day. No design was approved without my input, and no feature was released until I had personally reviewed the code.

I was stressed. That was a very critical project we were working on and looking back I didn’t trust my team enough to deliver it on time. So I thought the only solution was to be as involved as I was.

At first, this approach worked fine. I caught a few issues early and kept the project moving. But over time things started to go very wrong:

• Slower Delivery: The team got used to waiting for my decisions. If I was in meetings or out of office, progress slowed down significantly. The team didn’t feel empowered to make any decisions on their own.

• Low Motivation: Engineers felt like they were just “following orders”. They weren’t excited about their work because their ideas and problem-solving weren’t valued.

• Burnout: I became extremely overwhelmed, constantly juggling other responsibilities while actively being a bottleneck for the team.

One engineer told me in a one-to-one: “I don’t feel like I’m really growing here. I just execute your ideas.”

I can still feel in my body how that felt when I heard this.

When I finally started stepping back, I realized the damage. I made the team become completely dependent on me.

---

Finding the Balance

How much autonomy should we as managers give at different stages of a project?

1. Starting the Project (Low Autonomy)
In the beginning, you need to be hands-on. Set clear goals, define the scope, and get the right people involved. If this step goes wrong, everything else will too.

2. Planning (Some Autonomy)
Guide the team as they plan timelines, dependencies, and priorities. Stay close enough to catch mistakes but let them take ownership of the details.

3. Execution (More Autonomy)
Once the work begins, focus on support. Clear blockers, make progress visible, and help as needed. Trust your team to deliver, but stay available if things go off-track.

4. Wrapping Up (Moderate Autonomy)
During closure, help the team document lessons learned and celebrate wins. This allows the team to grow and improve with you for the next project. Some of the learnings should apply to you too.

Notice that full autonomy isn’t part of this framework. Leaders should always be close enough to the team to guide and step in when necessary.

---

TL;DR

Brian challenged me to rethink autonomy. Teams don’t need total freedom. They need:

1. Clarity about goals.

2. Support when they face challenges.

3. Trust to experiment and grow.

If you’re leading a team, ask yourself:

• Are you providing enough structure to keep everyone aligned?

• Are you staying involved enough to guide your team without micromanaging?

The right balance of guidance and freedom helps your team create great results, without getting stuck or frustrated.

---

My favourite posts of the past week

• Balancing Engineering Excellence with Business Value by

  Mirek Stanek
  and
  Tomasz Zaraś

• Navigating Your Job Search: What You Should and Shouldn’t Do by

  David Weiss
  and
  Jen DeLorenzo

• Why You Should Consider Becoming an Engineering Manager: My Story by

  Adler Hsieh

---

Useful links

• 📂 Get 50 Engineering Manager Notion Templates.

• 👨‍💻 Become a better Software Engineer with CodeCrafters (use my partner link to get 40% off and build your own Redis, Git, Kafka and more from scratch).

• 🎯 Book a mock interview with me (System design or Behavioural & Leadership) to smash your next real interview!

• 👋 Let’s connect on LinkedIn!