Sổ tay CTO cho startup

Sổ tay CTO cho startup

Những kỹ năng thiết yếu và thực tiễn tốt nhất cho một đội ngũ kỹ thuật hiệu năng cao

Giới thiệu

• Luôn học hỏi: Tác giả đã có niềm đam mê với máy tính và lập trình phần mềm từ khi còn nhỏ, và qua đó nhận ra tầm quan trọng của việc học hỏi liên tục. Để thành công với vai trò lãnh đạo kỹ thuật, việc không ngừng học hỏi và phát triển là rất quan trọng.
• Thế lưỡng nan của lãnh đạo kỹ thuật trong startup: Hầu hết các startup đều có đồng sáng lập phụ trách kỹ thuật, những người viết codebase ban đầu và tuyển những kỹ sư đầu tiên. Tuy nhiên, khi đội ngũ phát triển, lãnh đạo kỹ thuật phải chuyển sang vai trò quản lý, và trong quá trình này có thể thiếu các kỹ năng lãnh đạo.

Giới thiệu tác giả

• Tác giả đã tích lũy kinh nghiệm tại nhiều startup và đảm nhiệm vai trò lãnh đạo kỹ thuật. Thông qua trải nghiệm ở nhiều startup khác nhau, tác giả đã hiểu rõ các kỹ năng và thách thức đa dạng cần có trong lãnh đạo kỹ thuật.

Cách sử dụng cuốn sách này

• Cuốn sách này là tài liệu tham khảo dành cho các lãnh đạo quản lý đội ngũ kỹ thuật phần mềm, bao quát nhiều chủ đề dưới dạng các chương độc lập. Mỗi chương giới thiệu chủ đề, cung cấp cái nhìn tổng quan và đưa ra các thực tiễn tốt nhất.

Quy trình kinh doanh

• Mô tả các quy trình kinh doanh để cung cấp điểm khởi đầu cho việc giải quyết vấn đề. Cần điều chỉnh và mở rộng quy trình tùy theo quy mô của đội ngũ và công ty.

Con người và văn hóa

Các nguyên tắc cơ bản của quản lý

• Quy tắc vàng của quản lý: Hiệu quả của đội ngũ là tiêu chí để đo lường hiệu quả của người quản lý. Cần hỗ trợ để các thành viên trong nhóm có thể phát huy hết khả năng.
• Cây kỹ năng chuyên môn: Để làm tốt vai trò lãnh đạo kỹ thuật, cần đầu tư không chỉ vào kỹ năng kỹ thuật mà còn cả kỹ năng quản lý.

Cải tiến liên tục

• Kaizen: Cả đội ngũ lẫn từng cá nhân đều nên theo đuổi cải tiến liên tục. Cần xem sai lầm như cơ hội để cải thiện.

Coaching

• Người quản lý nên đóng vai trò như một coach, giúp các thành viên trong nhóm phát huy tốt nhất năng lực của mình.

Tìm mentor quản lý

• Việc tìm một mentor về quản lý là rất quan trọng để chuyển đổi sang vai trò lãnh đạo. Thông qua mentor phù hợp, có thể nâng cao kỹ năng lãnh đạo.

Buổi họp 1:1

• Các buổi họp 1:1 là cơ hội để xây dựng mối quan hệ với thành viên trong nhóm, hiểu rõ điểm mạnh và điểm yếu của họ để giúp họ phát huy tối đa khả năng.

Buổi họp skip-level

• Có thể cải thiện hoạt động kinh doanh bằng cách định kỳ gặp gỡ các báo cáo trực tiếp của quản lý cấp dưới để thu thập nhiều góc nhìn khác nhau.

Coaching cho quản lý

• Hiệu quả của các quản lý cấp trung có ý nghĩa quan trọng đối với hiệu quả của tổ chức. Cần phát triển đội ngũ quản lý thông qua đào tạo và hỗ trợ liên tục.

Buổi họp 1:1 với kỹ sư

• Các buổi họp 1:1 với kỹ sư là cơ hội để lắng nghe những vấn đề họ đang đối mặt và giúp họ tìm ra giải pháp. Cần làm rõ mục đích của buổi họp và dẫn dắt cuộc trao đổi một cách hiệu quả.

[GN⁺]

Ý kiến trên Hacker News

• Khi xem những tài liệu kiểu này, tôi thường đi trước tới phần mình hiểu sâu để xem họ nói gì. Ở đây tài liệu nói rằng việc chuẩn bị và thực hiện kiểm toán PCI DSS hoặc SOC 2 thường mất 6–12 tháng, nên đừng chờ đến phút cuối mới đi lấy chứng nhận; nhưng với startup, tôi gần như muốn khuyên ngược lại
  Đặc biệt, chứng nhận SOC 2 khá dễ lấy, và việc chủ động chi tiền trước khi có đơn đặt hàng bị phụ thuộc vào nó là lãng phí. Tất nhiên, những thứ sau này sẽ làm nền tảng cho chứng nhận, như thiết lập đăng nhập một lần hoặc các nhánh Git được bảo vệ, thì nên làm sớm; nhưng đó gần như là các thực hành tốt cơ bản mà dù không có kế hoạch lấy SOC 2 thì vẫn nên làm. Nếu khách hàng lớn không yêu cầu, tôi nghĩ không cần làm SOC 2. Sẽ tốt nếu ai đó kiểm tra cả những phần khác của tài liệu này

  • Cách tiếp cận hay. Tôi đã tìm phần về cơ sở dữ liệu và nhìn chung thấy ổn. Tuy nhiên, vào năm 2025, startup có vẻ không cần tập trung vào SQL so với NoSQL. Các cơ sở dữ liệu SQL phổ biến đều hỗ trợ JSON tốt, nên cứ dùng PostgreSQL hoặc MySQL mà các kỹ sư quen thuộc hơn, và dùng CloudSQL hoặc RDS để lo sao lưu và nhân bản là được
    Gắn thêm một bản sao đọc cho BI và một công cụ trực quan hóa ổn là có thể trụ được khá lâu, đủ dùng trước khi phải chi số tiền 5–6 chữ số cho những thứ như Snowflake
  • Theo kinh nghiệm của tôi, các công ty sẵn sàng giao dịch với startup giai đoạn đầu nhưng muốn có báo cáo SOC 2 nhìn chung không gặp vấn đề gì với việc đưa điều khoản đạt SOC 2 Type 1 trong vòng 6 tháng vào hợp đồng và tiếp tục tiến hành, miễn là người phụ trách kỹ thuật có thể gọi điện với đội IT của họ và thuyết phục rằng năng lực là ổn
  • Tôi xin phép không đồng ý riêng trong trường hợp các quy trình kế toán và chuỗi cung ứng nằm trong ERP doanh nghiệp. Việc quay lại sửa các quy trình không thể kiểm toán về sau tốn quá nhiều thời gian và tiền bạc, trong khi doanh nghiệp vẫn phải tiếp tục vận hành; nên ở trường hợp cụ thể này, tôi nghĩ làm cho nó có thể kiểm toán ngay từ ngày đầu sẽ rẻ hơn và tốt hơn
  • Lời khuyên này có thể khác khá nhiều tùy ngành. Nếu bạn bán sản phẩm B2B xử lý thông tin định danh cá nhân, thì SOC 2 gần như là bắt buộc nếu không muốn bị cười nhạo trong buổi pitch
    Tùy tình hình tài chính, chi phí dùng một dịch vụ checklist tuân thủ SOC 2 tự động như Secureframe có thể chỉ ở mức vài nghìn đô la; nó không chỉ giúp bạn làm theo các thực hành tốt, mà còn sắp xếp mọi thứ theo cách đặc thù phù hợp với SOC 2 để việc kiểm toán dễ hơn. So với thời gian phát triển và quản lý dự án cần bỏ ra để đưa một tổ chức đã ăn sâu các quy trình không tuân thủ vào lộ trình SOC 2, đó không phải là khoản đầu tư lớn
  • Tôi không rành về tuân thủ, nhưng điều này nghe khá lạ. Đọc lướt SOC 2 thì thấy cần thu thập bằng chứng rất nhiều trong vài tháng trước kiểm toán; nếu không dành thời gian trước đó, tôi không hiểu làm sao biết sau này phải chuẩn bị những gì
    Việc nói chứng nhận SOC 2 dễ lấy cũng hoàn toàn trái ngược với những gì tôi nghe từ người khác về chủ đề này. Tôi thường nghe rằng nó rất khó và tốn nhiều thời gian, nên tôi tò mò mình đang bỏ sót điều gì. Nếu đúng là việc đó dễ thì tôi mong là mình sai

• Tôi thường thấy nói rằng khi trở thành VP hoặc CTO thì sẽ ngừng viết code. Tôi hiểu năng lực quản lý không phải là năng lực viết code, nhưng khó hiểu vì sao mọi người lại đặt bàn phím xuống và lãng phí siêu năng lực đầu tiên của mình
  Bạn có thể vẫn là một CTO thiên về kỹ thuật từ đầu đến cuối. Hãy đối xử với đội ngũ và công ty như một dịch vụ cần sự đóng góp chủ động, bảo trì và hỗ trợ on-call; đồng thời vẫn phải tự mình và cùng cả đội xắn tay xây dựng

  • Ở cấp VP/CTO thì không có thời gian đóng góp và bảo trì code. Nếu có thời gian, chức danh đó có lẽ chỉ mang tính biểu tượng. Ví dụ như “CTO” của một startup 3 người
    Vấn đề thực sự là nhận một vai trò không có thời gian viết code quá sớm trong sự nghiệp. Chẳng hạn nhận vai trò kiến trúc sư chỉ vẽ hộp trên bảng trắng và đi từ cuộc họp này sang cuộc họp khác, hoặc một vai trò thực chất là quản lý nhưng được gọi là “tech lead”. Bạn quen với việc không viết code, rồi vài năm sau khi phải tìm việc mới, bạn phải đi phỏng vấn vị trí lập trình trong khi đối mặt với sự thật rằng một phần đáng kể sự nghiệp lập trình của mình đã trôi qua mà không viết code. Với nhiều người, cảm giác nghề không quay lại nhanh được
  • Theo kinh nghiệm của tôi, vấn đề là mỗi ngày chỉ có chừng đó thời gian. Trong 7 năm, tôi trực tiếp hoặc gián tiếp chịu trách nhiệm cho khoảng 20–25 người, và thật sự thiếu thời gian để làm được việc hữu ích trong code
    Thời gian của tôi tốt hơn nhiều khi dùng để giải quyết những vấn đề mà người khác không giải được. Thỉnh thoảng tôi nhận một thay đổi rất đơn giản để tự đi qua quy trình của chúng tôi và xem có thể cải thiện ở đâu. Ban đêm hoặc cuối tuần tôi vẫn viết code, nhưng cảm giác không giống, và theo thời gian thì không tránh khỏi bị mai một một chút. Dù vậy, trong kỳ nghỉ sabbatical, được xắn tay viết code cả ngày thật sự rất vui
  • Nếu không phải là cá nhân đóng góp đơn thuần, bạn sẽ có những ưu tiên khác. Vì vậy công việc đóng góp cá nhân có thể bị gián đoạn bất cứ lúc nào. Khi đó bạn không thể nhận việc gần đường găng; nếu nhận thì sẽ chặn người khác hoặc phải bàn giao
    Review hoặc họp thiết kế thì được, nhưng nếu nhận việc cốt lõi thì cuối cùng sẽ có vấn đề
  • Tôi không nghĩ có một đáp án đúng duy nhất, nhưng từ một thời điểm nào đó, việc tuyển kỹ sư chủ chốt tiếp theo, xây dựng lộ trình công nghệ để vượt lên đối thủ, hoặc căn chỉnh tổ chức kỹ thuật với phần còn lại của công ty sẽ có đòn bẩy lớn hơn nhiều so với đóng góp code của VP/CTO
    Code mà VP/CTO có thể viết thì ai đó khác trong đội cũng có thể viết, thậm chí có thể viết tốt hơn. Ngược lại, những việc tôi liệt kê nhiều khả năng là những việc VP/CTO làm tốt nhất trong công ty. Việc buông phần lớn công việc kỹ thuật trực tiếp để làm những việc quan trọng hơn cho đội ngũ và công ty là một quyết định khá hợp lý
  • Vai trò CTO gần nhất của tôi là ở một đội 40 người, và ngay từ ngày đầu đã hoàn toàn quá tải. Tôi vốn quản lý thời gian khá tốt mà vẫn vậy. Nếu có thể, tôi muốn dành 50% thời gian để lập trình, nhưng không có thời gian làm vậy, cũng không có cấu trúc hỗ trợ để giao bớt việc, nên tôi phải tự vất vả xây dựng nó. Chính việc đó lại là một lý do khiến tôi không có thời gian
    Ý tưởng tiếp tục viết code thì hay, nhưng thường đó không phải là lý do bạn được trả lương. Tôi tự xem mình là một lập trình viên rất mạnh, nhưng kiểu lập trình viên đó có thể thuê với chi phí thấp hơn lương CTO. Để một CTO đắt hơn làm việc đó là kém hiệu quả. Nhân tiện, vài năm sau tôi đã quay lại làm cá nhân đóng góp, và dự định phần còn lại của sự nghiệp cũng sẽ đi theo hướng đó

• Tôi muốn nói rằng không có cái gọi là chat đồng bộ
  Nếu cần đồng bộ thì không nên làm trong cửa sổ chat. Ít nhất là trừ khi hai bên đã thống nhất “hãy tập trung chat thời gian thực trong vài phút”. Nếu làm từ xa thì gọi điện, nếu tại chỗ thì nói chuyện trực tiếp. Đừng thả một tin nhắn vào chat rồi kỳ vọng được trả lời ngay

• Tôi tò mò liệu có ví dụ nào trong hệ thống “hai đội” mà không phát sinh oán trách không. Không rõ có trường hợp mọi người không tự nhiên muốn chuyển sang đội tương lai hay không
  Trên giấy thì nghe như một ý tưởng hay, nhưng khó tin là nó sẽ vận hành tốt trong thực tế. Dạng gần nhất tôi từng thấy có lẽ là một đội thư viện tạo ra các dịch vụ như design system và component để các đội khác dùng

  • Ở công ty cũ của tôi có một phiên bản sản phẩm on-premise mà công ty đã bán gói hỗ trợ gia hạn siêu dài hạn cho một phiên bản sắp hết hỗ trợ. Một đội nhỏ, có lẽ khoảng 3 người, chỉ chịu trách nhiệm đảm bảo phiên bản đó vẫn được hỗ trợ, pipeline vẫn chạy, và nếu cần thì có thể triển khai cả các bản sửa lớn
    Miễn là giữ được trách nhiệm đó, thời gian còn lại họ được tự do làm những việc mà họ cho là có giá trị cho công ty. Đó là một thỏa thuận khá tốt. Những người khác biết ơn vì đội nhỏ đó nhận phần việc bẩn, còn đội bảo trì thì thích vì có thể dùng thời gian dư để sửa những thứ luôn gây khó chịu hoặc nghiên cứu. Tôi quên chi tiết rồi, nhưng nhớ là đã có vài cải tiến và kết quả nghiên cứu khá hay. Việc các thành viên trong đội rất giỏi và tự chủ cũng giúp thành công, nhưng chi phí cũng cao hơn
  • Có vẻ trong cuốn sách, giải pháp cho vấn đề này là luân chuyển định kỳ. Bài blog của Microsoft khuyên mỗi tuần đổi một số thành viên giữa hai đội, và định nghĩa đội khách hàng là một đội tạm thời
    Thực tế tôi từng trải qua vài nơi mà các đội được tách biệt hoàn toàn vẫn vận hành tốt. Trong game, có thể nghĩ đến đội engine và đội game. Ở một vai trò trước đây, ngay trong đội game chúng tôi cũng nhận một tính năng mất 6–12 tuần để phát hành, rồi xử lý bảo trì, cập nhật và nợ kỹ thuật. Thứ vừa phát hành là trọng tâm chính, nhưng vẫn có thời gian quay lại công việc trước đó; các đội khác cũng ở cùng vòng quay như vậy rồi sau 6–8 tuần lại onboarding vào tính năng mới, cứ thế lặp lại
  • Trước đây tôi từng thử nghiệm hệ thống kiểu hai đội. Red Team phụ trách phát triển tính năng, Blue Team phụ trách ổn định và sửa lỗi
    Chúng tôi không coi đó là đội cố định, mà coi là luồng công việc nơi mọi người qua lại mỗi sprint, tức mỗi 2 tuần. Nó chạy ổn khoảng 3 tháng, nhưng sau đó không còn phù hợp nữa; đến lúc đó tổ chức đã lớn hơn và chúng tôi tái cơ cấu đội theo năng lực kinh doanh hoặc domain
  • Tương tự, tôi từng áp dụng chế độ luân phiên trong đó kỹ sư xử lý support và bug report mỗi người một tuần. Cách này tránh được khá nhiều cạm bẫy của mô hình “hai đội” tách biệt hoàn toàn. Tôi đã viết thêm một chút ở https://news.ycombinator.com/item?id=43337703#43339972
  • Nếu “đội khách hàng” có đủ tài nguyên và được đãi ngộ phù hợp, có lẽ không nhất thiết ai cũng muốn chuyển sang “đội tương lai”. Nhưng ngay cả khi không tách ra, bảo trì thường vẫn bị bỏ đói còn tính năng mới lấy hết sự chú ý và tài nguyên. Chia thành hai đội có vẻ còn dễ làm tình hình tệ hơn

• Những tài liệu như thế này hay ở chỗ chúng không phải để dùng như kinh thánh, mà giúp quét rộng các trách nhiệm và mối quan tâm
  Nếu bạn không có một cố vấn tốt, hoặc chưa từng làm dưới quyền một người thật sự xuất sắc, thì khi bước vào vị trí này sẽ không có ai ngồi cạnh đưa cho bạn danh sách những thứ cần để ý. Mỗi phần đều giúp đặt câu hỏi: “Câu trả lời của chúng ta là gì?”, “Chúng ta có đồng ý không?”, “Quy trình của chúng ta có tốt hơn không?”, “Mình đang bỏ sót điều gì?”, nên rất hữu ích

• Không ngờ việc tách “hai đội” lại được ghi rõ như vậy. Đây là một cách tuyệt vời để khiến người ta tiếp tục phát hành cho đến khi chi phí để phát hành thứ gì đó ổn trở nên quá lớn
  Nếu cắt đứt vòng phản hồi quay về với những người ban đầu tạo ra phần mềm, những người đó sẽ hạnh phúc hơn trong chốc lát, còn những người khác sẽ khổ hơn trong chốc lát. Rồi đội tính năng sẽ không bao giờ muốn bị làm phiền nữa, còn đội khách hàng sẽ không được cấp tài nguyên để sửa bất cứ thứ gì cho đúng nghĩa
  Tệ hơn nữa là đội tính năng chẳng học được gì ngoài cách đẩy các dòng code ra ngoài. Lý do mọi thứ ngày càng chậm và đắt đỏ là vì bạn đã loại bỏ hàm thích nghi duy nhất của phát triển phần mềm tốt: tích hợp phản hồi tiêu cực trở lại nguồn phát triển. Một cuốn sổ tay lãnh đạo CTO thật sự nên nói rõ rằng: “Trách nhiệm của bạn là giúp nhà phát triển cải thiện ngay cả khi họ đang phát hành, và không phải lúc nào nhà phát triển cũng thích điều đó”

  • Câu “giúp đội tính năng tập trung 100% vào tương lai mà không bị công việc hỗ trợ khách hàng làm gián đoạn” gần như có nghĩa là cho phép đội tính năng tiếp tục mà hoàn toàn không biết đến thảm họa họ đã thả ra, cho đến khi con tàu đâm thẳng vào tảng băng
    Cũng sẽ xuất hiện xung đột merge giữa đội tính năng được sales thúc đẩy và đội bảo trì được người phụ trách khách hàng thúc đẩy. Miễn là “đội khách hàng” được mô tả như một giai đoạn để sau này thoát ra, thì bên nào sẽ thắng trong cuộc chiến ưu tiên là điều quá rõ. Cụm “một con đường khác để từng kỹ sư, đặc biệt là junior, học hỏi và trưởng thành” rốt cuộc nghe như “senior không muốn dọn đống bừa bộn nên giao cho junior làm”
  • Liên quan đến chuyện này, trong các công ty tôi từng làm mà có đội nền tảng, nhìn chung họ bị nhiễm bệnh over-engineering. Ở đây đội nền tảng có nghĩa như một đội hỗ trợ thứ ba quản lý công cụ, thực hành và mã dùng chung
    Những đội như vậy có xu hướng thu hút những người xem thường việc phát hành tính năng và sửa lỗi, đồng thời muốn trừu tượng hóa vấn đề quá mức. Thay vì sửa bug, họ tạo ra các abstraction ngày càng phức tạp với lý do sẽ ngăn bug xuất hiện ngay từ đầu, và kết quả thì có thể đoán được
  • Đó là việc của PM. Cần một hoặc vài người làm việc với khách hàng và dựa trên phản hồi để xác định tầm nhìn về cách mọi tính năng khớp với nhau
    Khách hàng, đặc biệt là khách hàng không có nền tảng kỹ thuật, thường không có tầm nhìn sản phẩm nhất quán, và nhiều khi chỉ muốn sửa ngay vấn đề trước mắt bất kể các kế hoạch khác. Khách hàng cũng không giao tiếp với nhau nên phản hồi có thể mâu thuẫn. Nếu đặt gánh nặng này lên nhà phát triển, ngoài năng lực kỹ thuật là hiểu codebase và duy trì nó tốt, nhà phát triển còn phải quản lý toàn bộ giao tiếp; và mọi nhà phát triển đều phải có cùng một tầm nhìn nhất quán mới có thể đưa ra quyết định thấu đáo. Nếu vai trò của nhà phát triển ngày nay còn bao gồm cả quản lý hạ tầng, thì thực chất một người đang làm hai hoặc ba việc
  • Để bù lại, chúng tôi đổi đội mỗi sprint hoặc sau vài sprint. Mọi người có được trải nghiệm đa dạng hơn, và nếu tạo ra tính năng nhiều lỗi thì cuối cùng chính họ phải sửa, nên phản hồi cũng tiếp tục quay lại
    Có vẻ mọi người thích cách này hơn nhiều. Vì họ không bị kiệt sức do lúc nào cũng chỉ sửa bug, đồng thời tránh được sự đứt gãy phản hồi mà bạn đã chỉ ra rất sắc sảo
  • Nhà phát triển phải vận hành và bảo trì phần mềm do chính mình tạo ra. Nguyên tắc đơn giản là vậy

• Ở thời điểm này tôi đã phỏng vấn nhiều đến mức không còn đếm nổi, nên hơi khó đồng ý. Một điểm khó là ở giai đoạn tiếp nhận hồ sơ, số lượng ứng viên có thể rất nhiều, và ở bước này thường đội tuyển dụng sẽ tương tác với ứng viên
  Đưa các câu hỏi ví dụ vào thì ổn, nhưng để lọc ra những ứng viên không đủ năng lực, cần các câu hỏi không phải dạng có/không hoặc thang đo. Tôi thích những câu hỏi rất đơn giản nhưng có đáp án rõ ràng. Có nhiều người đến mức đáng ngạc nhiên tự nói rằng họ “rất thoải mái” với JavaScript nhưng lại không biết === là gì. Vì vậy tôi hỏi những câu như “toán tử so sánh bằng nghiêm ngặt trong JavaScript là gì”. Bất kỳ lập trình viên JavaScript nào cũng biết, nhưng chỉ một câu hỏi như vậy đã lọc được 50% nhóm ứng viên và tiết kiệm rất nhiều thời gian cho tổ chức

• Có nhiều bàn luận về phù hợp văn hóa, nhưng phần lớn trong số đó trông như đang kéo lên một lớp phân biệt đối xử ngầm gây hại cho công ty. Tôi cho rằng sự cởi mở về văn hóa là yếu tố dẫn đến thành công, còn phân biệt đối xử thì kéo theo hướng ngược lại
  Khi đọc câu “những lãnh đạo giỏi nhất theo dõi tỷ lệ thành công, không sợ thừa nhận sai lầm tuyển dụng, tuyển chậm và sa thải nhanh”, tôi lại muốn đăng hình ảnh mà JWZ (Jamie Zawinski) hiển thị khi phát hiện referrer header trỏ tới trang này. Chỉ cần tìm trên Google xem Jamie Zawinski đã nói gì về Y Combinator là được. Ông cũng là người có công trong quyết định của Netscape đưa Netscape Navigator thành mã nguồn mở, cũng như phần lớn công việc dẫn tới browser rendering engine đó. Vì vậy mà chúng ta có Firefox

  • Xem “phù hợp văn hóa” là phân biệt đối xử ngầm là một cách diễn giải hoài nghi, và trong những trường hợp tôi từng thấy, nó thường được dùng nhiều hơn để bảo vệ ứng viên khỏi phải nhận những việc họ sẽ ghét
    Ở một trong những nơi làm việc đầu đời của tôi, công ty đã cố cấm toàn bộ những gì có thể được gọi là phù hợp văn hóa trong tiêu chí tuyển dụng. Kết quả là vài người vừa vào đã ghét công ty và nghỉ sau vài tuần hoặc vài tháng. Một ứng viên nhấn mạnh việc lập kế hoạch và tính dự đoán được, đồng thời phàn nàn rằng các công ty trước đây di chuyển quá nhanh. Chúng tôi là startup, và đúng như dự đoán, anh ấy ghét công ty. Nhưng trong quá trình ra quyết định tuyển dụng, chúng tôi không thể nêu mối lo đó, vì nó bị xem là “phù hợp văn hóa” và có thể dẫn tới phân biệt đối xử. Sau vài chuyện tương tự nữa, chính sách đó lặng lẽ biến mất, và chúng tôi lại có thể đánh giá mức độ tương thích với văn hóa kỹ thuật
  • Mọi quy trình tuyển dụng đều phân biệt. Điều quan trọng là nó ưu ái và bất lợi cho những đặc điểm nào, và nó loại trừ điều gì
    “Phù hợp văn hóa” phần lớn là một sự đánh đổi: lấy hiệu quả giao tiếp và mức độ tin cậy cao để chấp nhận mất đi một phần đa dạng trong tư duy. Vì mọi người đã biết phải hành xử thế nào và kỳ vọng gì ở nhau nên không cần đặt ra nhiều hướng dẫn, nhưng lại dễ tổn thương hơn trước tư duy bầy đàn và các thiên kiến nhận thức liên quan. Kiểu như “con tàu này có đủ mọi màu sắc của cầu vồng, nhưng ngay cả người Klingon chúng ta cũng nghĩ Klingon là xấu xa”
  • Tôi đã thử đi theo nhánh rẽ này và tìm kiếm, nhưng kết quả trang đầu toàn là các bình luận trên Hacker News nhắc tới Jamie Zawinski, nên tôi bỏ cuộc ở đó. Vì vậy nếu có thể cho biết đang nói về chuyện gì thì tốt

• Tôi không chắc lời khuyên “hãy tạo thư viện video giải thích” có hay không. Với một số thứ cụ thể như UI hoặc animation thì có thể hợp lý
  Nhưng nhìn chung, đọc văn bản hiệu quả hơn xem video. Khi đang gấp, việc nhảy tới phần quan trọng trong văn bản cũng dễ hơn video rất nhiều

  • Có người thích video, có người thích văn bản. Cả hai đều là khoản đầu tư cần công sức và đem lại hiệu quả. Giờ đây nhờ AI tạo sinh, việc làm cả hai đã dễ hơn