Cộng tác là vô dụng
(newsletter.posthog.com)- Câu ngạn ngữ “đi một mình thì nhanh, đi cùng nhau thì xa” có thể làm startup sụp đổ
- Cộng tác hiệu quả chỉ nên ở mức như sự hỗ trợ của điều hướng khi lái xe, nhưng phần lớn công ty lại bị chậm lại vì quá nhiều phản hồi và phân tán vai trò
- Dưới giá trị “Bạn là người cầm lái (You're the Driver)”, PostHog nhấn mạnh tính tự chủ và quyền sở hữu cao, đồng thời giảm thiểu những cộng tác không cần thiết
- Nguyên nhân của tình trạng cộng tác quá mức được phân tích là do mong muốn được giúp đỡ, văn hóa bao trùm, yêu cầu phản hồi không rõ ràng, lạm dụng ‘let’s discuss’, né tránh trách nhiệm
- Giải pháp là cách tiếp cận thực tiễn gồm ưu tiên triển khai ngay, làm rõ người chịu trách nhiệm, chỉ xin phản hồi từ đúng người cần thiết, nhận phản hồi sau khi phát hành, và chặn ngay các cộng tác không cần thiết
Cái bẫy của cộng tác
- Câu “muốn đi nhanh thì đi một mình, muốn đi xa thì đi cùng nhau” đang từ từ giết chết công ty
- Đây là một cái bẫy dùng để hợp thức hóa việc cộng tác quá mức
- Cộng tác hữu ích chỉ nên ở mức chỉ đường hoặc cung cấp thông tin xung quanh khi đang lái xe
- Nhưng phần lớn tổ chức lại rơi vào kiểu cộng tác kém hiệu quả như thay nhau nắm vô lăng
- Phản hồi phù hợp giúp đến đích nhanh hơn, nhưng phản hồi quá mức làm chậm tốc độ và khiến bạn có nguy cơ không đến được nơi mình muốn đến
Nghịch lý của phản hồi: giỏi phản hồi nghĩa là biết khi nào không nên đưa phản hồi
- Khi PostHog phát triển, số lượng cộng tác không tạo thêm giá trị hoặc có giá trị quá thấp so với thời gian bỏ ra cũng tăng lên
- Trong cuộc họp toàn công ty gần đây, họ đã bàn về chủ đề “cộng tác là điều tệ hại”
- “Bạn là người cầm lái (You're the driver)” là giá trị cốt lõi của PostHog: “tuyển người giỏi và đừng cản họ”
- Không deadline, điều phối ở mức tối thiểu, quản lý không ra lệnh
- Đổi lại, điều đó đòi hỏi tinh thần làm chủ cực cao và khả năng tự mình hoàn thành rất nhiều việc
- Marketer tự deploy code, nhân viên sales trả lời câu hỏi kỹ thuật mà không cần backup, product engineer làm việc trên toàn bộ stack
- Gần như lúc nào cũng có người giỏi hơn bạn, nên rất dễ bị cám dỗ muốn cộng tác, nhưng cộng tác buộc người cầm lái phải chậm lại để giải thích bối cảnh, ngữ cảnh và suy nghĩ của mình
- Xu hướng này thường xuất hiện qua một vài cách nói điển hình
- “Tôi muốn biết X nghĩ gì”
- “Tôi muốn nghe ý kiến của Y”
- “Ta nên làm việc cùng Z”
- Những điều đó đôi khi dẫn tới insight có giá trị, nhưng luôn làm chậm người cầm lái
- Nó bào mòn động lực, sự tự tin và hiệu quả của người cầm lái, cuối cùng dẫn đến giảm số lượng sản phẩm được phát hành
Nếu cộng tác là điều tệ, tại sao mọi người vẫn làm vậy
- Ai cũng góp phần tạo ra vấn đề
- Mọi người muốn giúp đỡ: khi ai đó đăng công việc đang làm lên Slack, văn hóa phản hồi khiến người khác cảm thấy mình nên đưa phản hồi
- Ngược lại, họ ngại yêu cầu phản hồi từ một người cụ thể vì cảm thấy như vậy không đủ tính bao trùm, dù thực tế điều đó có thể hữu ích hơn
- Mọi người không nói đủ rõ mình cần loại phản hồi nào: điều này mở ra khoảng trống để cộng tác chen vào. Một cuộc bàn luận về việc xây một tính năng cụ thể có thể phình ra thành việc đánh giá lại toàn bộ roadmap sản phẩm
- Khi ai đó đưa ra ý tưởng hay, phản ứng mặc định không phải là “hãy làm đi” mà là “hãy thảo luận đi”
- Bằng chứng là cụm “let's discuss” bị lạm dụng vô số lần trên Slack
- Điều này chuyển trọng tâm từ thực thi sang thảo luận
- Mọi người quá bận để thực thi hoặc đơn giản là lười, nên chỉ muốn nói chuyện
- PR → issue/RFC → Slack (hiện tại chủ yếu dừng ở đây) → “hãy thảo luận”
- Không rõ ai là người sở hữu công việc (hoặc không ai muốn sở hữu thứ đang được đem ra bàn)
- Dù khó chịu, đôi khi cũng có trường hợp một người không thể tự mình ship từ đầu đến cuối với chất lượng đủ cao, nên không thể chỉ ship rồi lặp lại tiếp
- Code bị lỗi thì còn sửa được, nhưng newsletter thì không thể gửi lại lần nữa
Cách đánh sập cộng tác (và đi nhanh hơn, xa hơn)
- Nếu xem cộng tác là kẻ thù, vậy phải đánh bại nó như thế nào
- Mặc định là ưu tiên thực thi: Pull request > Issue > tin nhắn Slack
- Khi cộng tác trở nên quá mức, hãy vạch ranh giới rõ ràng: “Bạn là người cầm lái, bạn quyết đi”
- Với phản hồi, hãy tag rõ bạn muốn gì từ ai, đừng ném ra một cách mơ hồ
- Thay vì review trước khi phát hành, hãy ưu tiên phản hồi sau khi phát hành (trước vòng lặp tiếp theo): phản hồi trước có thể biến thành một quy trình gần giống phê duyệt
- Lãnh đạo nên kiềm chế phản hồi và giữ thái độ “cứ làm đi (you can just do stuff)”
- Mỗi người là một “thuyền trưởng được cung cấp đầy đủ thông tin (informed captain)”
- Có thể lắng nghe phản hồi, nhưng quyết định là do chính mình đưa ra
Kết luận
- Không thể nhổ tận gốc mọi cộng tác, và một số cộng tác thực sự hữu ích (newsletter này được Ian và Andy biên tập)
- Nhưng cần nỗ lực giảm cộng tác theo mặc định
- Nếu bạn không chủ động cắt giảm cộng tác, rất có thể mặc định bạn đang cộng tác quá nhiều
- Vì cộng tác về bản chất sẽ làm chậm tốc độ,
càng cộng tác ít, bạn càng có thể đi xa hơn và nhanh hơn
- Bài viết do Charles Cook, người ghét nước có ga vì bọt khí quá “hợp tác”, chấp bút
12 bình luận
Làm việc cùng nhau là đúng.
Nếu người đó vắng mặt (qua đời, bệnh tật, nghỉ phép) thì không phản hồi khách hàng sao?
Tôi đang làm ở một công ty rất nhỏ, đến mức chỉ có mỗi mình tôi là nhân viên. Vì vậy tôi một mình bảo trì và một mình phát triển... Nhưng đã ở trong tình trạng này quá lâu nên đôi khi tôi cũng thấy muốn được làm việc cùng người khác. Làm việc một mình thật sự quá cô đơn...
Đây đúng là một bài viết giật tít quá đà.
Có phải vì cá tính của tác giả quá nổi bật nên không hòa hợp tốt với người khác chăng?
Để tạo ra một tính năng
thường nhất định phải cần các vai trò như designer, lập kế hoạch, project manager, frontend, backend, QA, v.v.
Có vẻ như đây là một lập luận được đẩy quá mức nhằm làm lộ ra vấn đề mà bản thân người viết nhận thức.
Tuy nhiên, hợp tác chắc hẳn không có nghĩa là tiến hành theo kiểu như quảng trường công cộng.
Dù vậy, hai yếu tố là lạm dụng
let’s discussvà né tránh trách nhiệm thì rõ ràng là có vấn đề.Nhưng trong đa số trường hợp, điều này thường xảy ra vì thiếu những người lãnh đạo hoặc người phụ trách có insight.
Chính vì những chuyện như vậy mà người ta nghiên cứu, đào tạo con người, tuyển dụng, hoặc mua giải pháp.
Nếu chỉ xây dựng đội ngũ toàn những thành viên biết nghe lời thì điều đó còn dễ làm vấn đề bùng phát hơn.
Có vẻ đây không phải là vấn đề do hợp tác hay làm việc một mình tạo ra.
Hãy lưu ý rằng Posthog vốn luôn viết các bài với giọng điệu rất mạnh kiểu này.
Vì giọng điệu quá gay gắt nên đôi khi có cảm giác bài viết hơi đi chệch chủ đề.
(
Nước có gatuyệt đến thế cơ mà!!!)Nước có ga, chẳng phải là bệ phóng cho highball sao, khừm
Ý kiến Hacker News
Có lời khuyên rằng mỗi khi việc cộng tác xảy ra, hãy nói: “Có quá nhiều người tham gia, X là driver nên bạn hãy quyết định.”
Nhưng nếu quản lý nói “bạn quyết định đi” rồi không dự họp, sau đó quay lại bảo “nếu là tôi thì tôi đã làm khác” và yêu cầu sửa lại, nhân viên sẽ bỏ đi
Quản lý của quản lý tôi lúc nào cũng nói như vậy, nhưng mỗi khi tôi mở PR thì cuối cùng vẫn yêu cầu thiết kế lại toàn bộ
Rốt cuộc tôi bắt đầu sợ cả công việc, vì biết dự án nào rồi cũng sẽ phải viết lại từ đầu
Nếu sếp đảo ngược phán đoán quá thường xuyên, các thành viên sẽ cố tình đẩy mọi quyết định lên cho sếp
Cuối cùng chính sếp sẽ bị nhu cầu kiểm soát của bản thân làm nghẹt thở
Nhưng trong ngữ cảnh “quản lý không nên ra lệnh chỉ đạo”, nó lại nhất quán
Vì sau đó luôn là vô tận những chỉnh pixel, sửa bố cục, và đề xuất làm lại cả stack
Tôi nghĩ cốt lõi vấn đề không phải là cộng tác mà là cấu trúc ra quyết định
Phản hồi là cơ hội để học hỏi, nhưng nếu không rõ ai là người đưa ra quyết định cuối cùng thì tốc độ sẽ chậm lại
Muốn quyết định nhanh thì cần xác định rõ người có quyền quyết định, đồng thời nhận thức rằng phần lớn quyết định đều có thể đảo ngược
Nếu giảm cộng tác thì cơ hội học hỏi cũng giảm theo
Người có quyền quyết định phải được chỉ định rõ ràng, nhưng vẫn cần lắng nghe phản hồi
Ngoài ra, với quyết định có thể đảo ngược, tốt nhất là đưa ra thật nhanh
Người ta nói cộng tác làm chậm tốc độ, nhưng thực ra chính quá trình đó lại nâng cao chất lượng
Có người phản đối chỉ để phản đối, và cuối cùng tìm cách cướp quyền sở hữu ý tưởng
Dù người quyết định cuối cùng có được xác định rõ, nếu ý chí của họ yếu thì cuối cùng vẫn sẽ trôi theo đồng thuận số đông
Chỉ cần họ đặt “request changes” là mọi người đều phải làm theo, và cuối cùng chất lượng code lại giảm đi
Tôi nghĩ tuyển đúng người và ủy quyền quyết định sẽ tốt hơn nhiều
Họ cần đưa ra định hướng, ưu tiên và framework để đội ngũ có thể tự mình phán đoán
Tôi không đồng ý với ác cảm với nước có ga của tác giả, nhưng vẫn mừng vì vấn đề cộng tác được đem ra bàn công khai
Ở nhiều công ty, tôi từng tốn gấp 3 lần thời gian thực tế để code review chỉ vì những góp ý vụn vặt về style
Quan điểm của tôi là: “Nếu không thích thì tự sửa rồi báo lại cho tôi”
Cũng có chia sẻ video liên quan
Để tới giai đoạn code review mới xử lý thì đã quá muộn
Vấn đề là những người không tuân theo style của phần code xung quanh
Nên giải quyết bằng linter hoặc bằng văn hóa
Một tính năng được làm một mình, không có cộng tác, sẽ trở thành rủi ro lớn khi bảo trì
Nếu hệ thống nổ tung lúc tôi vắng mặt, thì đó là lúc sự thiếu vắng cộng tác lộ rõ thành vấn đề
Tác giả nhấn mạnh thiên hướng hành động, nhưng nếu loại bỏ cộng tác thì sẽ sinh ra silo và sự tự tin quá mức
Kiểu văn hóa Slack hỏi rằng “Tôi định làm X, có ai phản đối mạnh không?” từng tỏ ra rất hiệu quả
Nhờ vậy công việc thực sự được tiến hành
Trước đây khi phỏng vấn để viết sách về GitHub, tôi thấy một số team tạo PR rỗng trước khi viết code để xin duyệt thiết kế
Đây không phải là cộng tác trong lúc triển khai, mà là cộng tác ở giai đoạn lập kế hoạch
Nếu có kỹ năng viết và giao tiếp tốt thì cộng tác có thể vừa nhanh vừa hiệu quả
Trong thời đại AI, những năng lực này sẽ càng trở nên quan trọng hơn
Nếu không có họp hành và chia sẻ, công lao sẽ không được nhìn thấy
Nếu bạn ngăn được vấn đề từ trước thì chẳng ai biết, nên cũng có văn hóa cố tình “để vấn đề xảy ra”
Chỉ lên kế hoạch thôi thì rất khó hình dung được cách triển khai
Như câu cuối bài viết nói, “cộng tác tốt là có tồn tại”
Tiêu đề là clickbait, nhưng PostHog vốn nổi tiếng với kiểu này
Nó khiến người ta nhìn meme “cộng tác” với con mắt phê phán hơn
Đây là một phép thử tư duy sai lầm
Vấn đề không phải là cộng tác mà là sự thiếu vắng quyền quyết định
Cần có một người rõ ràng chịu trách nhiệm quyết định, và quyền đó càng được đẩy xuống thấp thì tốc độ càng nhanh
Những bài viết kiểu này bóp méo ngôn ngữ và có thứ độc tính làm cho các khái niệm cần thiết trở nên vô giá trị
Văn hóa cứ ai bị kẹt là lập tức bảo “đi hỏi Bob ấy” cũng là vấn đề
Ngắn hạn thì nhanh, nhưng dài hạn sẽ gây ra mất cơ hội học hỏi và quá tải công việc
Tôi thích việc đồng nghiệp quan tâm đến công việc của mình
“Bạn tự lo đi” thực chất gần như có nghĩa là “Tôi không quan tâm”
Vấn đề không phải cộng tác mà là cộng tác kém hiệu quả
PR thì có sản phẩm cụ thể nên cuộc thảo luận rõ ràng hơn
Tôi cảm thấy cộng tác hoạt động tốt nhất khi chỉ có hai người
Hai người có thể cùng hiểu codebase và review PR của nhau
Nhưng từ ba người trở lên thì độ phức tạp tổ hợp bùng nổ
Vì vậy tôi muốn thiết kế dự án theo cấu trúc đội 2 người
Liên kết tham khảo
Như phép so sánh trong bài, đua xe F1 là một môn thể thao có tính cộng tác cực cao
Tay đua liên lạc với huấn luyện viên trong suốt cuộc đua
Tôi tự hỏi trong phần mềm có ví dụ nào như vậy không
Mấy bình luận này lạ thật. Nhìn phần tóm tắt bài viết thì có vẻ không phải là bảo hãy làm việc một mình, không cần đồng đội, mà là nên giảm bớt sự hợp tác quá mức giữa các thành viên trong nhóm.
Tôi đồng ý.
Có vẻ như đây là kết quả của việc kết hợp giữa một tiêu đề câu tương tác và những độc giả chưa đọc kỹ.
Không chỉ những bài viết kiểu này, mà ngay cả trên YouTube cũng có rất nhiều người chỉ nhìn tiêu đề rồi để lại bình luận.
Khi bắt đầu một việc mới, vì muốn đi quá an toàn nên bạn có thể yêu cầu quá nhiều người xung quanh review. Thực ra, những người hay cả nhóm xung quanh có thể cũng không hiểu rõ nội dung đó nên khó đưa ra phản hồi tốt. Cuối cùng, câu chuyện dường như là cứ làm ra một thứ gì đó trước, rồi dù có thể đi sai hướng thì sau đó vẫn có thể nhận phản hồi cụ thể và làm lại, như vậy về tổng thể còn tiết kiệm thời gian hơn.