Menu
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Đang tải...

Bài 46 — Remote/Hybrid Work: Operating Manual

Scaling Teams and Processes Bài 46/60

Mở đầu — vì sao bài này quan trọng

Sau đại dịch COVID-19, cách con người làm việc đã thay đổi vĩnh viễn. Trước 2020, làm việc từ xa (remote) ở Việt Nam gần như chỉ dành cho freelancer hoặc một vài công ty outsource nhỏ. Đến 2026, hầu hết các công ty công nghệ tầm trung trở lên đều phải trả lời một câu hỏi không thể né tránh: nhân viên của chúng ta sẽ làm việc ở đâu, và theo cách nào?

Vấn đề là rất nhiều đội nhóm khi mở rộng (scale) lại xử lý chuyện này theo bản năng thay vì theo thiết kế. Họ nói "công ty mình linh hoạt lắm, ai muốn lên văn phòng thì lên", rồi ba tháng sau phát hiện: người ở nhà bị bỏ quên trong các quyết định quan trọng, người lên văn phòng thì bực bội vì thấy mình "chăm chỉ hơn" nhưng không được ghi nhận, quản lý thì mất kiểm soát về tiến độ. Sự mơ hồ chính là kẻ thù lớn nhất.

Đây chính là lý do một đội nhóm ở quy mô lớn cần một Operating Manual cho remote/hybrid — một tài liệu vận hành viết rõ ràng, chỉ ra chúng ta hoạt động theo chế độ nào, ai được kỳ vọng làm gì ở đâu, quyết định được đưa ra như thế nào, và văn hóa được duy trì ra sao. Bài học này không bàn về công cụ giao tiếp bất đồng bộ (đó là bài riêng) mà tập trung vào việc thiết kế mô hình vận hành cho làm việc phân tán khi đội nhóm scale lên.

Khái niệm cốt lõi

Phổ các chế độ làm việc (Modes Spectrum)

Đừng nghĩ remote/hybrid là một công tắc bật/tắt. Nó là một dải phổ (spectrum) với ít nhất bốn điểm chính:

1. Fully co-located (Cùng văn phòng hoàn toàn): Tất cả mọi người làm việc tại cùng một địa điểm vật lý. Đây là mô hình truyền thống, ưu điểm là giao tiếp tức thời, dễ xây văn hóa, nhưng giới hạn tuyển dụng trong bán kính di chuyển của một thành phố.

2. Hybrid 3+2 (hoặc các biến thể): Ví dụ 3 ngày lên văn phòng, 2 ngày ở nhà. Đây là mô hình phổ biến nhất tại Việt Nam hiện nay. Nhưng nó cũng nguy hiểm nhất nếu làm sai — vì nó dễ tạo ra hai tầng lớp nhân viên: người có mặt và người vắng mặt.

3. Remote-first (Ưu tiên từ xa): Văn phòng vẫn tồn tại nhưng mặc định (default) mọi thứ được thiết kế cho người ở xa. Cuộc họp mặc định online, tài liệu là nguồn sự thật, quyết định được ghi lại bằng văn bản. Ai lên văn phòng thì tốt, nhưng không lên cũng không thiệt thòi.

4. Fully remote / Remote-only: Không có văn phòng, hoặc văn phòng chỉ là nơi gặp gỡ định kỳ. Tuyển dụng toàn quốc hoặc toàn cầu.

Điểm mấu chốt cần hiểu: không có mô hình nào "đúng" tuyệt đối. Cái đúng phụ thuộc vào giai đoạn công ty, tính chất công việc, và văn hóa bạn muốn xây. Nhưng có một nguyên tắc bất di bất dịch: bạn phải chọn một điểm rõ ràng trên phổ này và viết nó ra, thay vì để nó lơ lửng.

Nguyên tắc "Same-mode" — công bằng trong cuộc họp

Đây là khái niệm quan trọng nhất của làm việc hybrid mà rất ít công ty Việt Nam làm đúng. Nếu trong một cuộc họp có ít nhất một người tham gia từ xa, thì tất cả mọi người nên tham gia ở cùng một chế độ — nghĩa là mỗi người ngồi trước một màn hình riêng, một micro riêng.

Vì sao? Vì cảnh tượng "6 người ngồi quây quanh một cái laptop trong phòng họp, còn 2 người ở nhà nhìn qua webcam" luôn tạo ra bất bình đẳng. Người ở nhà nghe tiếng vọng, không thấy biểu cảm, không chen được vào cuộc trò chuyện, và bị bỏ quên khi mọi người bàn tán rôm rả trong phòng. Nguyên tắc same-mode san bằng sân chơi.

Đồng bộ vs Bất đồng bộ như một lựa chọn thiết kế

Trong Operating Manual, bạn cần xác định rõ cái gì cần đồng bộ (synchronous, real-time) và cái gì nên bất đồng bộ (asynchronous). Khi đội phân tán trên nhiều múi giờ hoặc nhiều tỉnh thành, càng nhiều thứ được xử lý async thì đội càng scale tốt. Ranh giới thường là: brainstorm sáng tạo, xử lý khủng hoảng, xây dựng quan hệ — nên sync; còn cập nhật tiến độ, review tài liệu, ra quyết định có thể chờ — nên async.

Core Hours và Quyền được ngắt kết nối

Core hours là khung giờ cố định mà tất cả mọi người phải online (ví dụ 10h–15h). Ngoài khung này, mỗi người tự chủ. Điều này cực kỳ quan trọng khi scale, vì nó cho phép làm việc linh hoạt mà vẫn có điểm giao thoa để phối hợp. Song song, Operating Manual phải khẳng định quyền được ngắt kết nối — không kỳ vọng trả lời tin nhắn lúc 22h, để tránh kiệt sức (burnout) trong môi trường không ranh giới.

Tình huống thực tế

Tình huống 1: Công ty fintech Sài Gòn và cái bẫy "hybrid mơ hồ"

Một công ty fintech ở TP.HCM (gọi là công ty A) có khoảng 80 kỹ sư, sau dịch áp dụng chính sách "linh hoạt": ai muốn lên văn phòng thì lên, không bắt buộc. Nghe rất nhân văn. Nhưng sau sáu tháng, họ đo được kết quả đáng lo:

  • Các trưởng nhóm có xu hướng thăng chức cho những người họ "gặp mặt thường xuyên" ở văn phòng.
  • Những quyết định kiến trúc quan trọng thường được chốt trong các cuộc trò chuyện ngẫu hứng ở pantry, người ở nhà không hề hay biết.
  • Khảo sát nội bộ cho thấy nhóm remote có điểm gắn kết (engagement) thấp hơn 22% so với nhóm hay lên văn phòng.
Diễn giải: Vấn đề không phải là "hybrid xấu", mà là công ty A đã không chọn một điểm rõ ràng trên phổ. "Linh hoạt" biến thành "văn phòng là trung tâm quyền lực ngầm". Họ đã tạo ra một chế độ hai tầng lớp mà không hề chủ ý.

Bài học: Họ sửa bằng cách chuyển hẳn sang remote-first có chủ đích: mọi quyết định kiến trúc phải được ghi lại trong tài liệu; mọi cuộc họp có người ở xa thì tất cả bật camera riêng; và một quy tắc vàng — "nếu nó không được viết ra, nó không xảy ra". Sáu tháng sau, khoảng cách engagement giảm còn 5%.

Tình huống 2: GitLab — hình mẫu remote-only vận hành bằng tài liệu

GitLab là công ty công nghệ với hơn 1.300 nhân viên trải khắp hơn 65 quốc gia, không có văn phòng trung tâm. Điều làm họ nổi tiếng là cuốn Handbook công khai dài hàng nghìn trang, trong đó ghi rõ mọi quy trình vận hành remote: cách chạy họp, cách ra quyết định, cách onboard người mới, thậm chí cả cách tổ chức gặp mặt trực tiếp định kỳ.

Diễn giải: GitLab chứng minh rằng remote ở quy mô lớn không phải chuyện may rủi, mà là chuyện kỷ luật tài liệu. Với họ, "handbook-first" nghĩa là: trước khi hỏi ai một câu, hãy tìm trong handbook; nếu không có, hãy viết câu trả lời vào handbook. Nhờ vậy tri thức không nằm trong đầu một vài người mà thuộc về tổ chức.

Bài học: Một đội remote scale được hay không phụ thuộc vào việc tri thức có được ghi lại và truy cập được không. Bạn không cần công khai handbook như GitLab, nhưng bạn cần có một handbook nội bộ sống động. Một startup Việt Nam 20 người hoàn toàn có thể bắt đầu bằng một trang Notion đơn giản mô tả "cách chúng ta làm việc".

Tình huống 3: Đội sản phẩm xuyên biên giới Việt Nam – Singapore

Một công ty SaaS có đội kỹ thuật ở Hà Nội và đội sản phẩm ở Singapore (chênh nhau 1 tiếng, không nhiều nhưng đủ gây ma sát). Ban đầu mọi cuộc họp đều cố ép vào một khung giờ chung, dẫn tới lịch dày đặc và nhân viên Hà Nội thường xuyên họp lúc trễ chiều mệt mỏi.

Diễn giải: Họ nhận ra vấn đề không phải múi giờ mà là thói quen mọi thứ phải sync. Đội chuyển sang mô hình: chỉ giữ một khung core hours 4 tiếng chồng lấn (14h–18h giờ Hà Nội) cho những việc thực sự cần bàn trực tiếp; mọi cập nhật tiến độ, feedback thiết kế, và phê duyệt đều chuyển sang async qua tài liệu và video ghi sẵn.

Bài học: Khi đội phân tán qua nhiều địa điểm, đừng cố chống lại khoảng cách bằng cách nhồi thêm họp. Hãy thiết kế lại để giảm phụ thuộc vào thời gian thực. Số cuộc họp của họ giảm 40% mà tốc độ ra quyết định lại nhanh hơn.

Hướng dẫn từng bước

Đây là cách xây dựng một Operating Manual cho remote/hybrid khi đội bạn đang scale:

Bước 1 — Chọn một điểm rõ ràng trên phổ. Ngồi lại với ban lãnh đạo và trả lời dứt khoát: chúng ta là fully co-located, hybrid có cấu trúc, remote-first, hay remote-only? Viết ra một câu tuyên bố. Ví dụ: "Chúng tôi là remote-first; văn phòng là tùy chọn, tài liệu là bắt buộc."

Bước 2 — Định nghĩa kỳ vọng có mặt. Nếu là hybrid, nói rõ: ngày nào lên văn phòng, ai được miễn, quy tắc cho ngày "anchor day" (ngày cả nhóm cùng lên để phối hợp). Tránh câu "tùy bạn" — nó chính là nguồn gốc bất công.

Bước 3 — Thiết lập core hours và múi giờ tham chiếu. Chọn khung giờ chồng lấn mà mọi người online. Ghi rõ múi giờ chuẩn của công ty để tránh nhầm lẫn khi lên lịch.

Bước 4 — Đặt quy tắc họp same-mode. Viết thành luật: hễ có một người từ xa, tất cả tham gia bằng thiết bị riêng. Đặt quy tắc mỗi cuộc họp phải có agenda trước và biên bản ghi quyết định sau.

Bước 5 — Phân định sync vs async. Lập một bảng: loại hoạt động nào bắt buộc real-time, loại nào mặc định async. Dán bảng này vào handbook.

Bước 6 — Thiết kế nghi thức gắn kết. Remote dễ khiến con người xa cách. Lên kế hoạch offsite/gặp mặt trực tiếp định kỳ (ví dụ mỗi quý một lần), coi đây là khoản đầu tư bắt buộc chứ không phải chi phí xa xỉ.

Bước 7 — Viết tất cả vào một handbook sống. Một trang Notion/Wiki duy nhất, có người sở hữu (owner), được cập nhật khi có thay đổi. Đây là nguồn sự thật.

Bước 8 — Đo lường và lặp lại. Mỗi quý khảo sát: nhóm remote và nhóm office có cảm nhận công bằng như nhau không? Nếu có khoảng cách, đó là dấu hiệu Operating Manual của bạn đang lỗi.

Lỗi thường gặp & mẹo

Lỗi 1 — Để chế độ làm việc mơ hồ. "Ai muốn thì lên văn phòng" nghe thoáng nhưng tạo ra sự bất bình đẳng ngầm. Mẹo: luôn viết ra một tuyên bố rõ ràng, dù nó có vẻ cứng nhắc.

Lỗi 2 — Proximity bias (thiên vị người ở gần). Quản lý vô thức ưu ái người họ gặp mặt thường xuyên khi đánh giá và thăng chức. Mẹo: đưa đánh giá về dựa trên kết quả và tài liệu, không dựa trên "mức độ nhìn thấy".

Lỗi 3 — Phòng họp một laptop. Kinh điển của hybrid làm sai. Mẹo: áp dụng nghiêm nguyên tắc same-mode.

Lỗi 4 — Coi remote là "giống office nhưng qua Zoom". Sai lầm gốc rễ. Remote đòi hỏi thiết kế lại quy trình quanh tài liệu và async, không phải bê nguyên văn phòng lên online. Mẹo: bắt đầu bằng câu hỏi "việc này có thực sự cần một cuộc họp không?".

Lỗi 5 — Bỏ qua gắn kết con người. Remote hiệu quả nhưng dễ cô đơn, dẫn tới burnout và nghỉ việc âm thầm. Mẹo: đầu tư offsite định kỳ và các nghi thức xã giao có chủ đích (cà phê ảo, kênh trò chuyện phi công việc).

Lỗi 6 — Không có core hours hoặc core hours quá rộng. Nếu không có khung chung, phối hợp sụp đổ; nếu quá rộng, mất luôn tính linh hoạt. Mẹo: giữ core hours ở mức 4–5 tiếng.

Mẹo vàng: Khi nghi ngờ, hãy nghiêng về remote-first ngay cả khi bạn là hybrid. Thiết kế cho người ở xa thì người ở gần vẫn ổn; ngược lại thì không.

Bài tập thực hành

Bài tập 1 — Định vị công ty bạn trên phổ. Viết ra công ty/đội của bạn hiện đang thực sự ở điểm nào trên phổ (co-located / hybrid / remote-first / remote-only), và điểm đó có phải là điểm được tuyên bố chính thức hay không. Nếu có khoảng cách giữa thực tế và tuyên bố, hãy mô tả nó.

Bài tập 2 — Soạn tuyên bố mô hình. Viết một đoạn 3–4 câu tuyên bố mô hình làm việc lý tưởng cho đội bạn, kèm lý do. Bao gồm: kỳ vọng có mặt, core hours, và một nguyên tắc về công bằng remote/office.

Bài tập 3 — Lập bảng sync/async. Liệt kê 10 hoạt động thường ngày của đội (standup, review code, brainstorm, cập nhật tiến độ...) và phân loại mỗi cái nên sync hay async, kèm lý do ngắn.

Bài tập 4 — Audit một cuộc họp. Chọn một cuộc họp hybrid gần nhất bạn tham gia. Nó có vi phạm nguyên tắc same-mode không? Có ai bị bỏ quên không? Viết một đề xuất cải thiện cụ thể.

Tóm tắt

Remote/hybrid ở quy mô lớn không phải chuyện để tùy hứng — nó là một quyết định thiết kế vận hành. Những ý chính cần nhớ:

  • Chế độ làm việc là một phổ: từ fully co-located, hybrid có cấu trúc, remote-first, tới remote-only. Hãy chọn một điểm rõ ràng và viết nó ra.
  • Kẻ thù lớn nhất là sự mơ hồproximity bias — chúng âm thầm tạo ra hai tầng lớp nhân viên.
  • Nguyên tắc same-mode giữ cho cuộc họp hybrid công bằng: một người ở xa thì tất cả tham gia bằng thiết bị riêng.
  • Đội scale được nhờ kỷ luật tài liệu và tư duy async-first, không phải nhờ nhồi thêm họp.
  • Core hours cho phối hợp, quyền ngắt kết nối chống burnout, offsite định kỳ cho gắn kết con người.
  • Tất cả gói gọn trong một Operating Manual/handbook sống, có chủ sở hữu, được đo lường và lặp lại mỗi quý.
Khi nghi ngờ, hãy thiết kế cho người ở xa nhất. Nếu người ngồi xa nhất vẫn cảm thấy mình là một phần bình đẳng của đội, bạn đã làm đúng.