What is async work?

[#1]

Too many founders think async work is just about letting people work whenever they want.

But that's missing the point entirely.

The truth?

Async isn't about time - it's about empowering your team to make decisions and move projects forward without constant check-ins.

I've seen teams struggle with this transition.

Here's what I've learned works:

🟣Document every meaningful thing. Decisions, context, etc

🟣Use tools that create transparency. Think shared boards, not endless email threads.

🟣Set clear expectations. What needs a meeting? What can be handled async?

🟣Trust your team. Micromanaging kills the benefits of async work.

🟣Build in reflection time. Async doesn't mean non-stop work.

The most successful async teams I've seen don't just allow flexibility - they actively design their workflows around it.

They create systems where information flows freely, decisions are documented, and everyone can contribute meaningfully, regardless of when they're online.

Async isn't just a workplace trend.

It's a fundamental shift in how we approach work.

Huge urge to plug in how we solve async work for teams here😅☑️ but today, I am curious about how other founders are tackling this.

What's been your biggest async challenge?

[Stephen_Lugton]

For me personally, working asynchronously has meant taking meetings out of the calendar and letting people contribute when they have time.

For example, before I joined my current company we had a Change Advisory Board (CAB) process where every fortnight there was a meeting with all the engineering team leads, department heads, product owners, relevant developers and the CTO to look at any change that anyone wanted to deploy to a production environment. 

As you might guess this meant that even if something was completed 5 minutes after the meeting it couldn't even be considered for release until the next meeting, although there were provisions for emergency CAB (ECAB) meetings, but you still had to get a number of people into a meeting to discuss the deployment and get sign off from specific individuals.

When I joined the company I implemented a Change Request (CR) board in JSM which included custom fields to answer any of the questions that were typically asked at a CAB meeting (e.g. has this been tested, and if so where are the test results, or what is the consequence of not releasing this feature now?)  When something was ready to be released, all the developer had to do was go to a portal and fill in a few details then click submit. 

The process after that was automated; depending on which system the change was for relevant approver groups were added, a notification to a shared Teams chat was sent out and emails were sent to the approvers.  Depending on when people checked their notifications we could get an approval within minutes.

In fact an ECAB CR was raised just after I wrote this; the 3 necessary approver roles approved it and it was fully completed and verified within 27 minutes of us being aware there was an issue that needed fixing

We are in the process of automating this even further so that when a pull request is approved in Github the CR is automatically created in JSM, although the developer still has to fill in some of the fields before it can be submitted.

Unfortunately we are currently working with a supplier who uses weekly CAB meetings and is unable to comprehend going async for anything!