Skip to main content
  1. Posts/

Making Async Communication and Team Autonomy Work

· loading · loading ·
Jared Lynskey
Author
Jared Lynskey
Emerging leader and software engineer based in Seoul, South Korea

The slowest part of most projects I’ve worked on wasn’t the code. It was the queue: decisions stacked up behind one manager’s calendar, waiting for a nod that took three days to arrive. Async communication and autonomous teams are the standard fix, and I’m a believer, but the shift is mostly a trust problem dressed up as a tooling problem.

Why everything needs a sign-off in the first place
#

It’s worth being fair about where approval culture comes from. Control feels like precision — if every decision crosses the manager’s desk, nothing drifts off course. A bad call doesn’t just dent the project, it dents the manager’s reputation, so fear does a lot of the work. Sometimes there’s genuine doubt about whether the team has the experience to decide well. And sometimes it’s pure residue: the org chart has always worked this way, so it keeps working this way.

Notice that only one of those four reasons is actually about the team. The rest are about the manager.

What autonomy actually requires
#

Autonomy without alignment is just chaos with better morale. If people genuinely understand the objectives, their independent decisions mostly point in the same direction — that’s the whole trick. Training matters too, because a well-equipped person is easier to trust than an enthusiastic one. And keep some boundaries: certain decisions genuinely should stay with management, and saying which ones out loud prevents the worst surprises. After that, let the feedback loop run and treat the inevitable mistakes as tuition rather than evidence.

If trust has already been damaged — and in teams crawling out of approval culture, it usually has, in both directions — there’s no shortcut. Name the problem in an open conversation, let management own its share of the mistakes first, and then be boringly consistent for months. Clear roles and regular check-ins do more repair work than any grand gesture.

The async part is the easy part
#

Tools first, but briefly: Slack or Microsoft Teams will do fine. The real work is documentation — when nobody’s in the same room or the same timezone, written decisions become the team’s memory. Set response norms so async doesn’t quietly become unresponsive; “within a day” beats “whenever”. And actually teach people to write a good async update, because the skill isn’t innate: enough context to decide, the decision needed, and a deadline.

You can roll out Slack in an afternoon. The trust takes months, and it’s the part that decides whether any of this works. Get the objectives clear and make mistakes cost a lesson instead of a career — the async part mostly takes care of itself after that.