If You Want to Embrace Asynchronous Work, Shift from Meeting-Driven to Task-Driven
Source: Dev.to
Summary
- Traditional work is meeting‑driven: discussions and conclusions happen spontaneously during meetings.
- It feels easy because you just follow the schedule (even a child can do it).
- Meeting‑driven approaches don’t support asynchronous work, so a new model is needed.
- Adopt a task‑driven approach: view all work and actions as tasks, manage them through a system, and update the task pages.
- Many are already familiar with this format through GitHub Issues.
Background
We seek asynchronous work but often fail to implement it due to a meeting‑driven culture. As engineers, we appreciate the freedom of working in our preferred environment without interruptions, office noise, or constant commotion. Occasional meetings can be valuable for deep discussions, but many organizations revert to in‑office work, and even those that claim to support remote work rely heavily on online meetings.
Why can’t we escape synchronous work? The blame lies with the work model: we are meeting‑driven.
A New Model is Needed
Meeting‑driven work relies on meetings to conduct business. It has two main features:
- Spontaneous communication – discussions and decision‑making happen on the spot during meetings.
- Passive execution – work follows the calendar schedule.
It’s similar to a school timetable—you attend according to the schedule and follow the facilitator’s mood. Even a child can do this, making it an extremely easy way to work. However, because this approach depends on meetings, it can’t accommodate asynchronous work. A fundamental mindset shift is required.
Task‑Driven Approach
A task‑driven approach treats all work as tasks, manages them through a system, and aims to close them.
- View all work (including activities and actions) as tasks.
- Manage tasks in a system that allows asynchronous access (e.g., a workspace).
- Ticket‑based formats like GitHub Issues are straightforward.
- Tasks have “statuses” and are considered complete when closed.
If you’re familiar with GitHub Issues, this concept should feel natural—it’s essentially turning everything into an Issue.
Skills Needed for Task‑Driven Work
Meeting‑driven work emphasized communication and “social” skills for coordinating meetings.
Task‑driven work, by contrast, requires strong task‑management skills:
- Ability to handle dozens (or hundreds) of tasks through self‑management.
- Proficiency in reading and writing to document tasks effectively.
Before / After
Before
Morning schedule for Manager M (meeting‑driven):
- 9:00 – Check chat, email, and other notifications
- 9:30 – Daily meeting for Project P1
- 10:00 – 1‑on‑1 with A
- 10:30 – Meeting 1
- 11:00 – Meeting 2
- 11:30 – Work
Four meetings occupy the 9:30 – 11:30 block, each providing a 30‑minute window for spontaneous discussion and decision‑making. While easy to follow, the schedule is inflexible and requires considerable effort to arrange and attend meetings.
After
Example of a task‑driven day:
- 9:30 – Daily meeting for Project P1
Agenda (10 min): share what was done yesterday and what will be done today (participants: A, B, C, D).
Discussion (20 min): topics are raised, debated, and concluded.
In a task‑driven approach, the same meeting could be broken into discrete tasks:
- Task: “Post today’s plans”
- Task: “Post opinions on Topic 1”
- Task: “Reach a conclusion on Topic 1”
- Task: “Post opinions on Topic 2”
- Task: “Reach a conclusion on Topic 2”
- …
These tasks are managed in a system such as GitHub Issues, wikis, notes, or any tool that supports separate pages with open/closed statuses. Creative representations (e.g., adding checkmarks to titles) also work. Once tasks are in the system, they can be updated asynchronously; reminders can be sent via mentions.
Can Work be Accomplished in the After Scenario?
Answer: Yes.
If you doubt it, you’re likely still operating from a meeting‑driven mindset. Task‑driven work hinges on self‑management and documentation skills. Being adept at handling the “After” workflow is essential—these soft skills are often underestimated, and gaps are common even among engineers, managers, and senior staff.
That’s why I initiated Soft Skills Engineering.