Một cuộc trò chuyện ít hơn một chút

Khi nào lần trước bạn đã lên lịch một cuộc họp và mời tám người thay vì ba người thực sự cần thiết ở đó chỉ vì bạn không muốn ai đó cảm thấy bị bỏ rơi?

Lần cuối cùng bạn gửi một e-mail toàn công ty có nội dung như: 'Này, những người uống cà phê chú ý: Nếu bạn uống hết bình, hãy pha thêm bình khác!' mặc dù thực sự chỉ có một người vi phạm quy tắc này (và cô ấy là người đồng sáng lập của bạn)?

Lần cuối cùng bạn thảo luận dài về bảng màu cho tập tài liệu mới với một lập trình viên, người không liên quan gì đến tập tài liệu này nhưng chắc chắn biết rằng anh ta không thích màu cam?

Đây là những triệu chứng của một căn bệnh thông thường: giao tiếp quá nhiều .

Giờ đây, tất cả chúng ta đều biết rằng giao tiếp là rất quan trọng, và nhiều vấn đề trong tổ chức là do không giao tiếp được. Hầu hết mọi người cố gắng giải quyết vấn đề này bằng cách tăng lượng giao tiếp: gửi email cho mọi người, tổ chức các cuộc họp dài và mời toàn bộ nhân viên, đồng thời yêu cầu mọi người nhận hai xu trước khi thực hiện quyết định.

Nhưng chi phí liên lạc tăng nhanh hơn bạn nghĩ, đặc biệt là đối với các nhóm lớn hơn. Những gì đã từng làm việc với ba người trong một nhà để xe, tất cả đều nói chuyện với nhau về mọi thứ chỉ không hiệu quả khi số lượng đầu của bạn lên đến 10 hoặc 20 người. Tất cả những ai không cần tham gia cuộc họp đó đều giết chết năng suất. Tất cả những ai không cần đọc e-mail đó đều bị phân tâm bởi nó. Tại một số thời điểm, thông tin quá mức không hiệu quả.

Đó là một vấn đề đặc biệt tối kỵ đối với các công ty khởi nghiệp đang phát triển nhanh chóng. Khi bạn thực sự nhỏ và bạn chỉ mới bắt đầu, bạn không có nhiều người như vậy, vì vậy việc giữ cho mọi người nắm rõ mọi thứ không thực sự mất nhiều thời gian. Nhưng khi bạn lớn hơn, số lượng người có khả năng tham gia vào bất kỳ cuộc thảo luận cụ thể nào sẽ tăng lên và số lượng công việc bạn đang làm trong một công ty tăng lên, và lượng thời gian bạn có thể lãng phí để phổ biến quá mức sẽ trở thành một vấn đề nghiêm trọng.

Khi các công ty mở rộng, những người trong họ bắt đầu chuyên môn hóa. Tại thời điểm đó, một số nhà quản lý sẽ kết luận rằng họ có vấn đề 'giữ mọi người trên cùng một trang'. Nhưng thường những gì họ thực sự có là 'ngăn mọi người can thiệp khi đã có đủ những người thông minh đang giải quyết một vấn đề nào đó'.

Không phải là Bob trong Kế toán không có bất cứ điều gì hữu ích để nói về việc chụp ảnh cho chiến dịch quảng cáo mới. Vâng, Bob có bằng thạc sĩ mỹ thuật. Vâng, Bob là một nhiếp ảnh gia nghiệp dư. Và có lẽ anh ta thậm chí còn có khiếu thẩm mỹ tốt hơn những người làm trong lĩnh vực tiếp thị. Tuy nhiên, Bob không nên nói với giám đốc tiếp thị phải làm gì, bởi vì nó không hiệu quả. Trên thực tế, nó rất kém hiệu quả.

Cái giá của việc truyền thông tin quá mức trong các tổ chức đã được Fred Brooks kể ra trong cuốn sách năm 1975 của ông, Tháng đàn ông thần thoại . Brooks đã giúp điều hành dự án OS / 360 tại IBM, xây dựng một hệ điều hành khổng lồ cho các máy tính lớn của công ty. Vào những ngày đó, máy tính là những cỗ máy làm mát bằng nước, kích thước lớn, đôi khi có bộ nhớ chính lớn 256.000 byte. OS / 360 có lẽ là dự án phần mềm lớn nhất từng được thử nghiệm cho đến thời điểm đó. Và nó đã tượng đài muộn.

Mỗi khi một số khía cạnh của dự án bị chậm tiến độ, IBM đã chỉ định thêm một số người làm nhiệm vụ. Và điều mà Brooks nhận thấy, điều vẫn khiến mọi người ngạc nhiên, là điều này không thành công. Quan sát của ông được gọi là Định luật Brooks: Thêm người vào một dự án muộn có xu hướng khiến nó vẫn chạy muộn hơn.

Đọc lại câu đó, vì nó không trực quan. Brooks phát hiện ra rằng việc thêm người vào một dự án sẽ đưa nó chậm hơn nữa so với kế hoạch .

Làm thế nào mà có thể được? Khi bạn thêm một người mới vào nhóm, người đó cần giao tiếp và phối hợp với tất cả những người khác trong nhóm. Điều này nghe có vẻ không phải là một vấn đề lớn, nhưng nó là. Đứa trẻ mới lớn không biết chuyện gì đang xảy ra, vì vậy, một số người khác trong nhóm - một người nào đó mới tuần trước đang làm việc hiệu quả - phải dừng công việc của mình và chỉ cho người mới này các sợi dây.

Đội càng lớn thì càng tệ. Khi bạn có một nhóm gồm một người, bạn không có yêu cầu giao tiếp. Không ai.

Thêm người thứ hai, và bây giờ bạn có một kết nối duy nhất: Adam và Mary phải nói chuyện với nhau một lần.

Bây giờ, hãy thêm một người thứ ba, chẳng hạn như Srinivas, và đột nhiên chúng ta đã chuyển từ một kết nối thành ba, vì Srinivas phải nói chuyện với Adam và Mary.

Thêm người thứ tư. Tôi không có tên ở đây để giúp tôi - OK: Britney. Nếu chúng tôi thêm cô ấy và cô ấy cần phối hợp với tất cả họ, bạn sẽ có sáu kết nối.

Đối với khuynh hướng toán học, công thức là nếu bạn có n người trong nhóm của bạn, thì có (n^hai-n) / 2 kết nối. Biểu đồ này minh họa cách điều này trở thành vấn đề:

Như bạn có thể thấy, chi phí liên lạc bắt đầu tăng lên khá nhanh chóng cho đến khi, trong các nhóm lớn, tất cả những gì bất kỳ ai có thời gian làm là phối hợp với mọi người khác - và không ai hoàn thành công việc. Vào năm 2006, Moishe Lettvin, một cựu lập trình viên tại Microsoft, đã viết một bài đăng trên blog mô tả năm anh ấy đã dành để điều phối danh sách các mục sẽ được hiển thị trên một menu trong Windows Vista - menu bạn sử dụng để tắt máy tính của mình. (Xem Windows Shutdown Crapfest .) Lettvin tính ra rằng 43 người đều có tiếng nói trong việc thiết kế một thực đơn này. Bốn mươi ba! Theo công thức của Brooks, điều đó có nghĩa là quản lý 903 kết nối. Lettvin nói rằng anh ấy đã dành rất nhiều thời gian cho các nhiệm vụ điều phối, đến nỗi trong 12 tháng, anh ấy đã tạo ra ít hơn 200 dòng mã.

Với tư cách là ông chủ, bạn cần thiết kế các cách để giảm bớt các đường truyền thông tin liên lạc. Loại bỏ các danh sách gửi thư trên toàn công ty - hoặc ít nhất là tính phí $ 1,50 để đăng lên chúng. Ngừng tổ chức các cuộc họp lớn. Bạn cần một nền văn hóa mà ở đó mọi người không quá căng thẳng vì họ không có mặt trong cuộc họp, điều đó có nghĩa là bạn cần một nền văn hóa thưởng cho mọi người vì họ đã hoàn thành công việc của mình và không quan tâm đến việc can thiệp vào công việc của người khác.

Và trong mỗi dự án, hãy chỉ định một người để đảm bảo rằng giao tiếp diễn ra - nhưng chỉ giao tiếp phù hợp. Nếu không, nhóm sẽ chỉ bắt đầu có những cuộc họp dài với mọi người ở đó và thành thật mà nói, mọi người sẽ giao lưu, chia sẻ, phát biểu và tranh luận về những điều họ không thực sự quan tâm chỉ để nghe tiếng nói của chính họ.

Tôi nghĩ đây có lẽ là một trong những trường hợp mà phong cách quản lý cũ của những năm 1950 vô tình có một cái gì đó đúng đắn. Trong các công ty theo phong cách General Motors đó, ít nhất họ đã có ý tưởng về cách thông tin cần thiết để di chuyển lên và xuống các biểu đồ tổ chức gọn gàng, phân chia, cho thấy một phương thức công nhận rằng câu trả lời đúng không phải là mọi người trong tổ chức đều cần chú ý đến mọi thứ.

Khi bạn thành lập công ty, có lẽ bạn đã giao tiếp rất tốt. Mọi người kể cho nhau nghe mọi chuyện. Và khách hàng của bạn yêu thích nó, bởi vì khi họ gọi đến để hỏi về đơn đặt hàng của họ, mọi người đều biết nó ở đâu. Nhưng khi bạn lớn hơn, bạn không thể tiếp tục nói với mọi người về mọi đơn đặt hàng, vì vậy bạn phải phát minh ra các hệ thống thông tin liên lạc cụ thể để những người phù hợp tìm ra chính xác chứ không ai khác. Không phải vì nó bí mật. Vì rất lãng phí thời gian.

Joel Spolsky là người đồng sáng lập kiêm Giám đốc điều hành của Fog Creek Software và là người chủ của blog nổi tiếng Joel on Software. Để có kho lưu trữ các cột của anh ấy, hãy truy cập www.inc.com/author/joel-spolsky .