Cộng tác là vô dụng

• 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