Giao tiếp async: làm việc mà không phải chờ nhau

Trong một công ty bán hàng ở Mỹ, Anh, châu Âu, Úc và Canada, việc "đợi mọi người có mặt để bàn" là một thứ xa xỉ. Khách hàng ở múi giờ khác. Đối tác ở múi giờ khác. Và ngay trong nhóm, mỗi người có những khối thời gian tập trung không trùng nhau.

Async (asynchronous — bất đồng bộ) là cách làm việc mà bạn không cần người kia trả lời ngay thì việc mới chạy được. Nó không phải chuyện dùng công cụ gì. Nó là chuyện viết thế nào và đặt thông tin ở đâu.

Vì sao async quan trọng hơn người ta tưởng

Mặc định của nhiều nhóm là sync (đồng bộ): họp, gọi, nhắn qua nhắn lại. Sync có chỗ dùng của nó. Nhưng khi sync trở thành mặc định, ba thứ xảy ra.

Thứ nhất, tốc độ bị khóa vào lịch của người bận nhất. Một quyết định năm phút phải chờ ba ngày vì chưa xếp được lịch họp.

Thứ hai, thời gian tập trung bị băm nhỏ. Một người bị ngắt quãng liên tục thì không làm được việc cần suy nghĩ sâu — mà nghiên cứu ngách, phân tích dữ liệu, viết listing đều là việc cần suy nghĩ sâu.

Thứ ba, thông tin bốc hơi. Quyết định nằm trong một cuộc gọi không ai ghi lại. Ba tuần sau, không ai nhớ vì sao lại chọn phương án đó.

Async giải quyết cả ba. Nhưng nó chỉ hoạt động nếu bạn viết đủ rõ.

Bốn nguyên tắc viết async

1. Viết để người đọc không phải hỏi lại

Đây là nguyên tắc gốc. Một tin nhắn async tốt trả lời trước ba câu hỏi mà người nhận chắc chắn sẽ hỏi: chuyện gì, tại sao tôi cần biết, tôi cần làm gì.

So sánh hai cách nhắn:

• "Anh ơi cho em hỏi về giá sản phẩm A với ạ."
• "Về giá sản phẩm A: nhà máy báo giá vốn tăng, contribution margin ở giá bán hiện tại tụt xuống dưới ngưỡng mình đặt. Em đề xuất hai phương án: (1) giữ giá, chấp nhận margin thấp hơn trong hai tháng để giữ thứ hạng; (2) tăng giá và bù bằng coupon ngắn hạn. Em nghiêng về (2). File tính ở đây. Anh cho ý kiến trước thứ Sáu để kịp đặt hàng đợt tới."

Tin nhắn thứ nhất tạo ra một vòng hỏi đáp kéo dài một ngày. Tin nhắn thứ hai có thể được trả lời trong ba mươi giây, kể cả khi người nhận đang ở múi giờ khác.

2. Luôn kèm ngữ cảnh, đề xuất và hạn chót

Ba thành phần bắt buộc của một tin nhắn cần quyết định:

• Ngữ cảnh: chuyện gì đang xảy ra, số liệu nào dẫn đến việc này
• Đề xuất: bạn nghĩ nên làm gì, và vì sao
• Hạn chót: khi nào cần câu trả lời, và điều gì xảy ra nếu không có

Phần đề xuất là phần nhiều người bỏ qua. Nhưng đó là phần thể hiện bạn là builder (người kiến tạo) chứ không phải người chuyển tiếp vấn đề. Đưa vấn đề kèm đề xuất, kể cả đề xuất sai, luôn tốt hơn đưa vấn đề trần trụi.

3. Đặt thông tin đúng chỗ

Async chỉ hiệu quả khi người ta tìm được thông tin mà không cần hỏi bạn. Điều đó đòi hỏi kỷ luật về nơi lưu.

• Thảo luận nhanh, hỏi han → kênh chat của nhóm, không phải tin nhắn riêng
• Quyết định, số liệu, quy trình → tài liệu hoặc bảng chung, có tên rõ ràng
• Trạng thái công việc → nơi theo dõi việc, cập nhật ngay trên đầu việc đó

Sai lầm phổ biến nhất: quyết định quan trọng bị chôn trong một đoạn chat riêng giữa hai người. Ba tháng sau, người thứ ba tiếp quản và không có cách nào biết được. Chi tiết về việc mỗi loại thông tin nên sống ở đâu nằm trong bài công cụ cộng tác của team.

4. Cập nhật chủ động, không đợi bị hỏi

Nếu quản lý phải hỏi "việc đó đến đâu rồi", hệ thống async đã hỏng. Một cập nhật ngắn, đều đặn, đúng chỗ sẽ tiết kiệm cho cả nhóm rất nhiều thời gian.

Cấu trúc một cập nhật tốt gồm bốn dòng: đã xong gì, đang làm gì, đang vướng gì, cần ai giúp gì. Không cần dài. Cần đều và thật.

Đặc biệt, hãy báo sớm khi trễ. Một việc trễ được báo trước ba ngày thì còn xử lý được. Một việc trễ được báo vào ngày đến hạn thì chỉ còn là thông báo thiệt hại.

Async không phải viết nhiều hơn. Async là viết một lần đủ rõ, để không phải giải thích ba lần.

Khi nào thì vẫn nên gặp trực tiếp

Async không phải tôn giáo. Có những việc mà cố làm async chỉ tốn thời gian hơn.

• Bất đồng đã qua hai vòng trao đổi mà chưa hội tụ. Gọi nhau năm phút, xong.
• Brainstorm ý tưởng mới. Va chạm trực tiếp tạo ra thứ mà văn bản không tạo được.
• Phản hồi khó, chuyện cá nhân, đánh giá hiệu quả. Những việc này cần giọng nói và ánh mắt.
• Khủng hoảng cần xử lý trong vài giờ. Listing bị gỡ, tồn kho về không, quảng cáo cháy ngân sách — lúc đó thì tập trung xử lý, viết lại sau.

Nguyên tắc đơn giản: async là mặc định, sync là ngoại lệ có lý do. Và mọi cuộc sync đều phải kết thúc bằng một bản ghi async — ai quyết gì, ai làm gì, khi nào xong.

Async là một kỹ năng, không phải tính cách

Nhiều người nghĩ viết rõ là năng khiếu. Thực tế nó là một kỹ năng luyện được, và luyện khá nhanh.

Ba bài tập đơn giản:

1. Trước khi gửi, đọc lại và tự hỏi: người nhận có phải hỏi lại câu nào không? Nếu có, trả lời luôn trong tin nhắn.
2. Cắt câu dài thành câu ngắn. Mỗi câu một ý. Câu dài là nơi hiểu lầm sinh sống.
3. Bỏ phần mở đầu vòng vo. Đặt kết luận lên đầu, chi tiết xuống dưới. Người bận đọc ba dòng đầu là đủ.

Kỹ năng này có giá trị vượt ra ngoài công việc hiện tại. Người viết rõ được coi trọng ở mọi tổ chức, vì họ làm cho người khác nghĩ nhanh hơn.

Vì sao Equarus coi trọng chuyện này

Bốn giá trị của Equarus đều dựa vào giao tiếp async để hoạt động. Data-driven cần số liệu được ghi lại và chia sẻ, không nằm trong đầu một người. Speed and Result cần công việc chạy tiếp cả khi người ra quyết định đang ngủ. Day 1 cần bài học được viết ra để lần sau không lặp lại. Và Builder nghĩa là bạn chủ động đưa thông tin đến người cần, không đợi được hỏi.

Nếu bạn quen với cách làm việc chỉ tiến khi có người đứng sau nhắc, đây sẽ là một thay đổi. Nếu bạn thích tự chạy và chịu trách nhiệm cho kết quả, đây là môi trường của bạn — xem thêm văn hóa Equarus và các vị trí đang tuyển.