Summary
- Traditional work is meeting-driven
- It involves holding discussions and reaching conclusions in a "spontaneous" manner during meetings
- It's easy because you just follow the schedule (even a child can do it)
- Meeting-driven approaches don't allow for asynchronous work, necessitating a new model
- Adopt a task-driven approach
- View all work and actions as tasks, manage them through a system, and update the task pages
- You might already be familiar with this format through GitHub Issues
Background
We Seek Asynchronous Work but Fail to Implement It Due to Meeting-Driven Culture
As engineers, we understand the marvels of asynchronous work. It's delightful to work seamlessly in one's preferred environment without interruptions, office noise, or commotion. Occasional meetings or gatherings can replenish solitude or enable thorough discussions.
However, despite knowing this, it seldom works smoothly, and many organizations are reverting to in-office work. Even those claiming to support remote work often depend on online meetings.
Why can't we escape synchronous work? The blame lies with the work model. It's because we're meeting-driven.
A New Model is Needed
Meeting-driven work refers to the reliance on meetings to conduct business.
It has two main features:
- 1: In order to resolve matters during meetings, communication, discussions, and decision-making are done spontaneously
- 2: Work is conducted passively, following meetings scheduled in the calendar
It's akin to a school timetable. You merely attend according to the schedule and follow the facilitator or mood of each meeting. Even a child can do this. It's an extremely easy way to work.
But since this approach depends on meetings, it can't accommodate asynchronous work. We must fundamentally change our mindset.
Task-Driven Approach
A task-driven approach views all work as tasks, manages them through a system, and aims to close them.
Key features include:
- View all work (including activities and actions) as tasks
- Tasks are managed in a system, allowing individuals to access these tasks (indicated by a workspace) asynchronously
- Ticket-based formats like GitHub Issues are straightforward
- Tasks have "statuses" and are completed when they're closed
As engineers, you're likely already familiar with GitHub Issues, making this concept relatable. In a broad sense, it's akin to turning everything into an Issue.
Skills Needed for Task-Driven Work
Traditional meeting-driven work required communication skills, especially the "social skills" to coordinate meetings and interact quickly during them.
Task-driven work is different. What's important are task management skills. Specifically, the ability to engage with dozens (possibly hundreds) of tasks and manage them well through self-management and reading and writing skills for documenting tasks (indicated by a workspace).
Before/After
Let's see how a manager's day changes from meeting-driven to task-driven.
Before
Here's a morning schedule for Manager M:
- 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
This schedule is meeting-driven, with four meetings between 9:30 and 11:30. Each meeting has a 30-minute window for spontaneous discussion and decision-making.
Of course, since meetings are scheduled commitments, they must be adhered to. While easy by sticking to the timetable, the work is inflexible and entails considerable effort in arranging and holding meetings.
After
Consider the following example:
- 9:30– Daily meeting for Project P1
Suppose the agenda of this daily meeting is:
- Sharing what was done yesterday and what will be done today (10 minutes):
- With A, B, C, and D
- Discussion (20 minutes):
- Someone raises a topic, and it is debated. This is repeated.
In a task-driven approach, it might look like this:
- 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. You might use GitHub Issues or, as described in QWINCS, wikis or notes. Any system that splits tasks into separate pages, operates smoothly, and incorporates concepts of open and closed statuses will suffice. You might even use creative representations like adding checkmarks to titles.
Once tasks are on the system, they only need to be updated asynchronously. If a reminder is necessary, simply send a mention.
Can Work be Accomplished in the After Scenario?
Ans: Yes, it can.
If you think it can't, it's likely you're still very meeting-driven.
As mentioned before, task-driven work requires skills in self-management and documentation. You need to be adept enough to easily handle the After mentioned above. These have often been underestimated soft skills, and shortcomings in even engineers, managers, or senior engineers are common.
That's why I initiated Soft Skills Engineering.
Top comments (0)