Meeting Culture – Khi nào họp là lãng phí, khi nào là cần thiết

Xin chào, mình là Khoa — và hôm nay trên Fx Studio, mình muốn nói về một thứ mà ai đi làm cũng từng khổ: họp.

Thông tin trong bài được cập nhật đến ngày 05/06/2026. Các số liệu khảo sát và nghiên cứu được trích dẫn có thể thay đổi theo thời gian.

Đây là bài tiếp theo trong mạch Developer Culture của mình. Trước đó, chúng ta đã bàn về văn hóa đọc, văn hóa review code và văn hóa viết tài liệu. Lần này là một mảnh ghép khác — cũng quen thuộc, cũng dễ bị làm sai: văn hóa họp hành.

Đôi lời tản mạn

Bạn đã bao giờ nhìn vào lịch buổi sáng và thấy thế này chưa? 9h standup, 11h sync với team khác, 2h planning, 4h một cái meeting mà bạn còn chẳng nhớ vì sao mình được mời. Giữa các khoảng đó là những mẩu 45 phút, 1 tiếng. Vừa đủ để mở IDE lên, đọc lại code, rồi tới giờ đứng dậy đi họp tiếp.

Cuối ngày, bạn mệt. Nhưng nhìn lại thì… chẳng viết được dòng code nào ra hồn. Cảm giác bận rộn thì có, còn cảm giác làm được việc thì không.

Mình từng trải qua những ngày như vậy nhiều lần. Điều khiến mình suy nghĩ không phải là “họp nhiều quá”, mà là một câu hỏi khó hơn: cuộc họp nào trong số đó thật sự cần thiết? Có cái mình bước ra với một quyết định rõ ràng. Có cái chỉ là ngồi nghe người khác đọc status, điều mà một tin nhắn Slack làm được trong 30 giây.

Đó là lý do mình viết bài này. Không phải để cổ vũ “xoá hết meeting đi” — kiểu khẩu hiệu nghe sướng tai nhưng hời hợt. Mình muốn cùng bạn phân biệt hai thứ. Khi nào một cuộc họp tạo ra giá trị, và khi nào nó chỉ đang đốt thời gian của cả team mà ai cũng ngầm hiểu nhưng không ai nói ra.

Meeting Culture là gì? – Không phải “họp ít” hay “họp nhiều”

Khi nói Meeting Culture, nhiều người nghĩ ngay đến số lượng: team họp ít là văn hóa tốt, họp nhiều là văn hóa tệ. Mình thấy cách hiểu này chưa đủ.

Meeting Culture là tập hợp những quy ước ngầm trong team. Khi nào thì nên họp, họp để làm gì, ai cần có mặt, và một cuộc họp thế nào thì được coi là thành công. Nó không nằm ở con số, mà ở chất lượng những quyết định mỗi cuộc họp mang lại.

Nói đơn giản: Meeting Culture lành mạnh không phải là họp ít nhất có thể, mà là mỗi cuộc họp đều có lý do tồn tại rõ ràng.

Có một hiểu lầm khá phổ biến mình muốn đính chính sớm. Nhiều người cho rằng cứ họp là mất thời gian, còn làm việc một mình mới là năng suất. Thực tế, một số quyết định kỹ thuật bắt buộc phải có sự đồng bộ thời gian thực. Tranh luận về kiến trúc. Gỡ một bug mà ba người đang hiểu khác nhau. Thống nhất về một thay đổi ảnh hưởng nhiều team. Những lúc đó, cái giá của việc né họp mới là đắt nhất.

Vậy nên vấn đề không phải họp hay không họp. Vấn đề là kẻ thù vô hình đứng sau phần lớn các cuộc họp tệ.

Kẻ thù vô hình: họp để cảm thấy đang làm việc

Trong bài về văn hóa đọc, kẻ thù là đọc nông. Ở bài review code, kẻ thù là review để bắt lỗi thay vì để hiểu. Còn ở bài viết tài liệu, kẻ thù là doc viết xong rồi bỏ đó, không ai cập nhật. Với họp hành, mình nghĩ kẻ thù là: họp để cảm thấy đang làm việc, thay vì họp để ra quyết định.

Một cuộc họp kiểu này có vài dấu hiệu nhận diện. Không ai biết rõ mục tiêu cụ thể. Phần lớn thời gian dành để cập nhật thông tin một chiều. Kết thúc xong, không ai chắc bước tiếp theo là gì. Nhưng mọi người vẫn thấy “ổn” — vì đã dành một tiếng cho công việc, đúng không?

Đó chính là cái bẫy. Cảm giác bận rộn dễ bị nhầm với hiệu quả. Và khi cả team cùng nhầm, nó trở thành văn hóa.

Một cuộc họp lấy đi những gì?

Trước khi bàn cách họp đúng, mình muốn bạn thấy rõ một cuộc họp tốn của developer những gì. Vì cái giá thật lớn hơn nhiều so với “một tiếng trên lịch”.

Maker’s Schedule và Manager’s Schedule

Năm 2009, Paul Graham viết một tiểu luận mà đến giờ vẫn được dẫn lại đều đặn: Maker’s Schedule, Manager’s Schedule. Ý tưởng cốt lõi khá đơn giản nhưng đáng suy ngẫm.

Có hai kiểu lịch làm việc. Manager’s schedule chia ngày thành các ô một tiếng, mỗi ô làm một việc. Đây là kiểu lịch của người quản lý. Với họ, đặt thêm một cuộc họp chỉ là tìm một ô trống rồi điền vào, gần như không tốn gì.

Maker’s schedule thì khác. Người làm sản phẩm — lập trình viên, người viết — cần những khối thời gian dài, ít nhất nửa buổi, để đi sâu vào một vấn đề khó. Theo Graham, bạn khó mà code hay viết tốt trong một đơn vị chỉ một tiếng. Nó vừa đủ để bắt đầu.

Một cuộc họp đặt giữa buổi sáng không lấy của bạn một tiếng. Nó cắt cả buổi sáng thành hai mẩu, mỗi mẩu quá nhỏ để làm được việc khó.

Đây là điều người đặt lịch hiếm khi thấy. Với họ, gửi một lời mời họp chỉ tốn 30 giây. Nhưng phần thiệt lại đổ lên người maker có buổi sáng vừa bị chia đôi. Sự lệch pha này càng rõ khi làm việc từ xa. Chỉ một cú click là đặt được cuộc họp online — dễ đến mức người ta đặt mà ít khi đắn đo.

Attention residue – cái đuôi mà cuộc họp để lại

Có một lý do khoa học giải thích vì sao chuyển ngữ cảnh lại tốn kém đến vậy. Nhà nghiên cứu Sophie Leroy gọi hiện tượng này là attention residue — phần chú ý bị bỏ lại ở công việc trước đó.

Khi bạn rời một việc để nhảy sang việc khác, một phần não bộ vẫn còn vương vấn ở việc cũ. Bạn ngồi vào họp nhưng đầu còn nghĩ về đoạn code dang dở. Họp xong quay lại code, trong đầu lại lởn vởn nội dung cuộc họp. Cái “đuôi” đó khiến bạn không bao giờ thật sự toàn tâm — cho cả việc đang làm lẫn việc vừa rời đi.

Cái giá này đáng lưu ý ở chỗ nó vô hình. Không hiện trên lịch, không ai cộng vào “một tiếng họp”. Nhưng chính nó giải thích một nghịch lý quen thuộc: một ngày có bốn cuộc họp rải rác lại mệt và kém hiệu quả hơn hẳn một ngày dồn cả bốn tiếng họp vào một buổi.

Còn về con số thì sao?

Có không ít khảo sát cố gắng đong đếm sự lãng phí này. Theo báo cáo State of Work Innovation 2024 của Asana, một tỷ lệ đáng kể nhân viên cho biết họ thiếu thời gian tập trung liền mạch vì họp quá nhiều. Một nghiên cứu khác được University of California, Irvine dẫn lại còn cho thấy phần lớn cuộc họp diễn ra mà không có nội dung định sẵn.

Mình sẽ không sa đà vào việc trích từng con số tỷ đô. Chúng dao động khá nhiều giữa các nguồn và dễ bị dùng sai ngữ cảnh. Điều mình muốn bạn nhớ không phải là một thống kê cụ thể, mà là hướng chung: chi phí thật của một cuộc họp luôn lớn hơn thời lượng của nó. Cộng thêm attention residue, cộng thêm buổi sáng bị băm nát, con số thật khó mà nhỏ.

Mổ xẻ ba buổi họp Agile: Standup, Planning, Retro

Phần lớn cuộc họp định kỳ của developer đến từ Agile. Điều thú vị là cả ba buổi họp quen thuộc nhất đều có một mục đích gốc rõ ràng. Nhưng đi kèm là một phiên bản biến chất mà nhiều team vẫn sống chung hằng ngày mà không nhận ra.

Daily Standup – từ đồng bộ thành điểm danh

Daily standup sinh ra để team tự đồng bộ với nhau. Theo Scrum Guide, mục tiêu của nó là xem tiến độ so với Sprint Goal và điều chỉnh kế hoạch cho 24 giờ tới. Và quan trọng nhất: standup là của team, do team tự chạy — không phải buổi báo cáo cho cấp trên.

Phiên bản biến chất thì khác hẳn. Mỗi người lần lượt trả lời ba câu hỏi kinh điển: hôm qua làm gì, hôm nay làm gì, có vướng gì không. Giọng đều đều. Thực chất là báo cáo cho Scrum Master hoặc manager. Theo phân tích trên Age-of-Product, đây là anti-pattern phổ biến nhất của Daily Scrum — biến nó thành một buổi điểm danh trá hình.

Dấu hiệu nhận ra standup đã hỏng: bạn đang nói với manager, chứ không phải nói với đồng đội.

Có một chi tiết nhiều người không biết. Bộ ba câu hỏi đó vốn không thuộc về Scrum, mà đến từ Extreme Programming (XP). Và mục đích ban đầu của standup, theo mô tả gốc của XP, là để cả team giao tiếp về vấn đề và giải pháp — không phải để chứng minh ai cũng đang bận. Khi standup chỉ còn là đọc to ba câu trả lời, nó mất đúng cái lý do nó tồn tại.

Sprint Planning – từ cam kết thành nghi thức

Planning sinh ra để team hiểu rõ sẽ làm gì trong sprint tới và vì sao. Đây là lúc tốt để tranh luận về độ ưu tiên, làm rõ yêu cầu mơ hồ, và cùng cam kết một mục tiêu.

Phiên bản biến chất: planning thành một buổi ước lượng story point máy móc. Mọi người vội vàng gán số để cho xong, còn câu hỏi quan trọng nhất — tại sao chúng ta làm cái này — thì không ai hỏi. Khi đó planning chỉ còn là nghi thức điền backlog. Team rời phòng họp mà không thật sự đồng thuận về điều gì quan trọng.

Retrospective – từ cải tiến thành xả van

Retro là buổi mình thấy có giá trị nhất nếu làm đúng, và đáng tiếc nhất khi làm sai. Mục đích của nó là nhìn lại sprint để tìm ra điều cụ thể có thể cải thiện.

Phiên bản biến chất có hai kiểu. Một là buổi xả van cảm xúc, mọi người than phiền rồi về, không có hành động nào theo sau. Hai là buổi hình thức, ai cũng nói “sprint ổn” cho nhanh. Vì họ biết rằng có nêu vấn đề thì sprint sau cũng chẳng đổi gì. Cả hai đều dẫn đến cùng một kết cục: retro mất uy tín, và lần sau không ai buồn nghiêm túc nữa.

Một retro tốt kết thúc bằng một đến hai hành động cụ thể, có người chịu trách nhiệm. Một retro tệ kết thúc bằng cảm giác “lại họp cho có”.

Điểm chung của cả ba: buổi họp Agile không tự nó tạo giá trị. Giá trị đến từ việc team có giữ được ý định gốc hay không — hay chỉ đang lặp lại cái vỏ.

Meeting Culture trong thời đại AI

Giờ là lúc nhìn về phía trước. Các công cụ AI ghi âm, bóc băng và tóm tắt cuộc họp ngày càng tốt. Vì vậy nhiều người đặt câu hỏi: liệu AI có khiến họp hành bớt lãng phí, hay tệ hơn?

Theo mình, AI giải quyết được phần dễ và phơi bày phần khó.

Phần dễ là ghi chép. Trước đây, một lý do người ta phải ngồi họp là để không bỏ lỡ thông tin. Giờ thì transcript và bản tóm tắt tự động làm việc đó tốt hơn con người. Điều này mở đường cho async-first. Nhiều thứ trước kia phải họp giờ có thể chuyển thành một bản ghi ngắn. Người cần thì đọc, ai có câu hỏi thì comment.

Nếu một cuộc họp chỉ để truyền đạt thông tin một chiều, thì trong thời đại AI, nó gần như chắc chắn nên là một tin nhắn hoặc một bản ghi.

Nhưng AI không giải quyết được phần khó, và đây mới là điều đáng suy nghĩ. AI tóm tắt được những gì đã được nói ra. Còn cuộc họp giá trị nhất lại là nơi tạo ra điều chưa ai nói ra — một tranh luận làm lộ giả định sai, một câu hỏi khiến cả team đổi hướng. Phần đó là tư duy tập thể thời gian thực, và nó không nén được vào bản tóm tắt.

Có một rủi ro mới đáng để ý. Khi việc ghi chép trở nên đơn giản, người ta dễ đặt thêm họp hơn, vì “đằng nào cũng có AI ghi lại”. Một công cụ tốt nhưng dùng với tư duy cũ thì chỉ khiến lịch họp dày thêm. Vì vậy mình nghĩ AI không thay đổi câu hỏi gốc. Nó chỉ làm câu hỏi đó cấp thiết hơn: cuộc họp này có cần con người ngồi cùng nhau theo thời gian thực không? Nếu không, hãy để AI và async lo phần còn lại.

Xây dựng Meeting Culture lành mạnh

Phần này là những gì mình đúc kết được. Áp dụng được cho cả khi bạn là một thành viên trong team, lẫn khi bạn là người có tiếng nói trong cách team vận hành. Không có công thức chung cho mọi team, nhưng có vài nguyên tắc mình thấy đúng ở nhiều nơi.

Bộ câu hỏi trước khi đặt một cuộc họp

Trước khi gửi một lời mời họp, mình tự hỏi ba câu. Nếu cả ba đều “không”, cuộc họp đó nên là một tin nhắn.

Nguyên tắc cho cá nhân

Với tư cách một developer, bạn có nhiều quyền chủ động hơn mình từng nghĩ. Không phải để chống lại lịch họp, mà để cùng team làm việc hiệu quả hơn. Mình thường làm vài điều sau.

Đầu tiên, mình cố giữ vài khoảng tập trung trong ngày, và quan trọng hơn là cho team biết khung giờ đó — một dòng ghi chú trên lịch, hay một lời nhắn nhẹ trong nhóm cũng đủ. Khi mọi người biết bạn đang cần thời gian tập trung sâu, họ thường sẵn lòng tránh đặt họp vào đó. Mình cũng hay đề xuất — chứ không áp đặt — chuyện dồn các cuộc họp vào một khung cố định, để cả team cùng có những buổi làm việc liền mạch hơn.

Khi được mời vào một cuộc họp chưa rõ mục tiêu, cách nhẹ nhàng nhất là hỏi trước một cách lịch sự: “Mục tiêu cuộc họp này là gì, và mình nên chuẩn bị gì?” Câu hỏi này vừa giúp bạn, vừa khéo léo khuyến khích cả team chuẩn bị kỹ hơn trước mỗi cuộc họp.

Và nếu bạn thấy mình không phải người thật sự cần thiết, hãy trao đổi sớm với người tổ chức — hỏi xem mình có cần tham gia không, hay đọc lại bản tóm tắt sau là đủ. Cách này nhẹ nhàng hơn nhiều so với việc ngồi cho có mặt, mà vẫn giữ được sự tôn trọng với mọi người.

Nguyên tắc cho team

Ở cấp team, vài quy ước nhỏ tạo khác biệt lớn. Không có mục tiêu thì không họp — một dòng ghi rõ trong lời mời cũng được. Cứ vài tháng, đem từng cuộc họp định kỳ ra soi lại một lần: nó còn phục vụ mục đích gốc không, hay đang chạy theo quán tính? Và mọi cuộc họp ra quyết định nên kết thúc bằng một câu rõ ràng: ai làm gì, đến khi nào.

Một mẹo nhỏ mình thích: thử “tuần không họp” mỗi quý. Bỏ hết họp định kỳ trong một tuần, rồi xem cái nào thật sự bị nhớ. Cái không ai nhớ thì có lẽ không cần tồn tại.

Checklist nhanh cho một cuộc họp lành mạnh

• Có mục tiêu rõ ràng, viết được thành một câu.
• Có nội dung gửi trước, dù chỉ vài dòng.
• Chỉ mời người thật sự cần.
• Có người dẫn để giữ đúng trọng tâm.
• Kết thúc bằng action items: ai, làm gì, khi nào.
• Tự hỏi sau cùng: cái này có thể là một tin nhắn không?

Tạm kết

Qua bài này, mình hy vọng chúng ta cùng đồng ý ở một điểm. Vấn đề chưa bao giờ là họp nhiều hay họp ít, mà là mỗi cuộc họp có xứng đáng với thời gian nó lấy đi hay không. Một cuộc họp tốt giúp team ra quyết định nhanh hơn và hiểu nhau hơn. Một cuộc họp tệ chỉ để mọi người cảm thấy đang làm việc. Cái giá của nó, cộng cả attention residue lẫn buổi chiều bị cắt vụn, lớn hơn ta tưởng.

Điều mình muốn bạn lưu ý là Meeting Culture hiếm khi xấu đi vì một quyết định lớn. Nó trôi dần vì quán tính. Một standup biến thành điểm danh. Retro thì thành buổi xả van. Và một cuộc họp được giữ lại chỉ vì “tuần nào cũng họp mà”. Giữ cho nó lành mạnh là việc phải làm đều, không phải làm một lần.

Nếu bạn muốn bắt đầu từ một việc nhỏ ngay tuần này, mình gợi ý thế này. Nhìn vào lịch của bạn, chọn một cuộc họp định kỳ mà bạn nghi ngờ giá trị. Rồi đặt câu hỏi “cái này có thể là một tin nhắn không?”. Chỉ một cuộc thôi. Văn hóa đổi từ những câu hỏi nhỏ như vậy.

Đây cũng là một mảnh trong mạch Developer Culture mà mình đang viết, bên cạnh văn hóa đọc, văn hóa review code và văn hóa viết tài liệu. Cảm ơn bạn đã đọc bài viết. Hẹn gặp lại ở các bài sau trên Fx Studio.

Tài liệu tham khảo

Maker/Manager schedule & sự tập trung

• Maker’s Schedule, Manager’s Schedule – Paul Graham
• Maker’s Schedule, Manager’s Schedule – Scrum.org

Dữ liệu & chi phí của họp hành

• State of Work Innovation 2024 – Asana
• Unnecessary Meetings Statistics 2026 – SpeakWise
• Meeting Statistics Guide – Noota

Agile / Scrum – Standup, Planning, Retro

• Daily Scrum Anti-Patterns: An Introduction – Hands-on Agile
• Daily Scrum Anti-Patterns: 24+2 Ways to Improve – Age-of-Product
• Daily Stand-up: Why it’s time to ditch the ‘3 questions’ – Zen Ex Machina
• The Three Daily Scrum Questions Won’t Die – Scrum.org

Written by Võ Trần Anh Khoa