Cách startup đánh mất sức sống
(blog.johnqian.com)- Ở một startup giai đoạn seed vận hành tốt, kỹ sư tự mình tìm ra vấn đề của người dùng rồi trực tiếp triển khai và phát hành, nhưng khi công ty lớn dần, vòng lặp này trở nên chậm chạp và bị chia cắt thành các phần việc rời rạc
- Các đội dưới 10 người có tốc độ triển khai nhanh nhờ tiếp xúc trực tiếp với người dùng, tự chọn ý tưởng, nhận phản hồi từ đồng đội, codebase nhỏ và quy trình triển khai nhẹ
- Trong tổ chức trên 100 người, điểm chạm với người dùng bị tách sang PM, còn tốc độ làm việc giảm mạnh do chồng thêm kiểm tra bảo mật, CI, review PR và các thủ tục hạ tầng
- Đằng sau sự thay đổi là mức độ gắn lợi ích giảm đi, giao tiếp O(N^2) khi số nhân sự tăng lên, cùng việc khả năng chấp nhận rủi ro giảm khi số người dùng và quy định đều nhiều hơn
- Rất khó ngăn hoàn toàn việc niềm vui biến mất, nhưng có thể trì hoãn nó bằng cách không vội sao chép quy trình kiểu doanh nghiệp lớn, thiết kế các nhóm nhỏ độc lập cùng cơ chế khuyến khích phù hợp, và tuyển dụng chậm lại
Vì sao công việc ở startup nhỏ lại gây cảm giác cuốn hút như nghiện
- Trong một startup giai đoạn seed vận hành tốt, công việc cốt lõi của kỹ sư là hiểu vấn đề của người dùng, nảy ra ý tưởng, thảo luận với đồng đội, triển khai rồi phát hành và nhìn lại để tiếp tục lặp vòng
- Với đội dưới 10 người, từng bước trong vòng lặp đó đều có thể rất thú vị
- Có thể trực tiếp liên hệ với những người dùng mình quan tâm, ngồi uống bia và trò chuyện với họ
- Nếu tìm được một ý tưởng vừa có giá trị với công ty vừa khiến bản thân hứng thú, có thể dừng việc đang làm và bắt tay vào ngay
- Đồng đội có lợi ích gắn trực tiếp với thành công của công ty nên có động lực khuyến khích ý tưởng tốt và chỉ ra vấn đề của ý tưởng dở
- Đồng đội có thể chính là người dùng của ý tưởng đó, hoặc muốn cùng làm với bạn, và thường nắm phần lớn codebase nên dễ đưa ra góc nhìn hữu ích
Triển khai nhanh và kỳ vọng cao
- Trong đội nhỏ, tốc độ triển khai rất nhanh
- Có thể chọn công cụ mình muốn và không có bước kiểm tra bảo mật
- Codebase nhỏ đủ để giữ toàn bộ cấu trúc trong đầu, nên ngay cả refactor lớn cũng có thể thử khá thoải mái
- Nhờ hot reload nhanh, có thể lặp lại việc debug theo kiểu thử-sai rất nhanh
- Việc merge thay đổi cũng diễn ra nhẹ nhàng
- CI không có các bài test chậm, và với thay đổi an toàn thì có thể không cần PR review mang tính chặn luồng
- Trong một số trường hợp có thể push thẳng lên
master, hoặc với thay đổi rủi ro hơn thì chỉ cần vỗ vai đồng đội để nhờ review - Nếu chưa có nhiều người dùng, có thể chấp nhận downtime để đổi lấy các thay đổi backend hay cơ sở dữ liệu nhanh hơn
- Ở startup nhỏ, cảm giác mọi thứ đều có thể rất mạnh
- Một tính năng mới có thể làm tăng giá trị cổ phần, rồi sau đó nhiều người tiếp tục xây trên chính tính năng đó
- Bạn có thể chờ đợi khoảnh khắc người dùng nói: “Ý tưởng này là do bạn nghĩ ra à, nó đã cứu cuộc đời tôi”
- Vì cả đội cùng chia sẻ lợi ích, bầu không khí sẽ tự nhiên trở thành nơi mọi người cổ vũ thành công của nhau
Khi công ty lớn lên, cùng một vòng lặp đó thay đổi ra sao
- Trong tổ chức trên 100 người, tiếp xúc trực tiếp với người dùng giảm đi
- Việc nói chuyện với người dùng trở thành vai trò của PM, còn kỹ sư có thể chỉ nhận bản tóm tắt insight người dùng và danh sách ưu tiên
- Tệ hơn, bạn có thể nhận một danh sách việc mơ hồ dựa trên hiểu sai về người dùng hoặc tầm nhìn vị kỷ của quản lý, mà lại không có ai giải thích vì sao từng việc lại quan trọng
- Việc tự chọn ngay thứ mình muốn làm trở nên khó hơn
- Nếu ai cũng làm thứ mình muốn, sẽ xảy ra hỗn loạn giao tiếp O(N^2)
- Quản lý phải thiết kế kế hoạch cá nhân dựa cả trên các công việc khác trong tổ chức
- Ý tưởng của riêng bạn có thể phải chờ đến khi xong phần việc đã được giao, hoặc phải lén làm trong thời gian rảnh
- Vẫn có thể bàn ý tưởng với đồng đội, nhưng mức quan tâm và khoảng trống thời gian đều giảm
- Đồng đội thu được ít lợi ích hơn từ thành công của cá nhân, và thậm chí có thể là đối thủ trong cuộc đua thăng tiến
- Ai cũng có danh sách việc dài nên không còn tự do bỏ ngang việc đang làm để cùng bạn triển khai
- Họ cũng có khả năng thiếu ký ức hay bối cảnh liên quan đến phần code đó
Vì sao triển khai chậm lại trong tổ chức quy mô lớn
- Trong tổ chức trên 100 người, việc chọn công cụ thường đã được quyết định sẵn
- Dù có công cụ mới tốt hơn, người ta vẫn có thể cho rằng không đáng để dùng vì chi phí phá vỡ tính nhất quán
- Muốn dùng công cụ mới thì phải hỏi quản lý và gửi email cho đội review bảo mật
- Codebase lớn chủ yếu phình ra vì lý do legacy
- Có rất nhiều đoạn code khiến người ta ngại đụng vào, và cũng nhiều đoạn không còn ai thực sự hiểu nữa
- Test kỹ lưỡng trở thành cơ sở duy nhất để tin rằng bạn không phá hỏng toàn bộ hệ thống
- Việc debug kiểu thử-sai vẫn cần thiết, nhưng thời gian compile dài làm chu kỳ lặp trở nên chậm chạp
- Chỉ để merge một PR nhỏ cũng có thể mất 2 tuần
- Phải chờ 20 phút để CI chạy xong, và nếu test flaky thì lại phải chạy lại
- Trong lúc chờ review, các xung đột merge tiếp tục tích tụ
- Reviewer có thể không đủ bối cảnh hay động lực nên chỉ bắt lỗi vụn vặt thay vì đưa ra góp ý quan trọng
- Bạn sửa theo yêu cầu, push lại rồi chờ thêm 20 phút, và chu trình đó có thể lặp ba lần cho mỗi PR
- Thay đổi hạ tầng có thể trở thành quy trình 14 bước để tránh downtime hoặc mất dữ liệu của 10 triệu người dùng
- Kể cả sau 3 tháng âm thầm làm việc rồi phát hành, phần thưởng và sự ghi nhận vẫn có thể rất hạn chế
- Bạn có thể có cơ hội demo trong cuộc họp thứ Sáu để CEO xem, nhưng thực tế chỉ một phần đồng nghiệp chú ý
- Quản lý có thể nói việc này sẽ giúp ích cho kỳ đánh giá hiệu suất sau 5 tháng nữa
- Trường hợp tốt là bạn được tăng lương 20% và đổi chức danh; trường hợp xấu là 4 tháng sau tái cơ cấu, quản lý mới xuất hiện và dự án bị tụt ưu tiên hoặc bị hủy luôn
Cách trì hoãn cái chết của niềm vui
- Sự thay đổi này gần với bài toán trì hoãn hơn là ngăn chặn hoàn toàn
- Nguyên nhân gốc rễ là mức độ gắn lợi ích giảm đi, giao tiếp O(N^2), và xu hướng giảm chấp nhận rủi ro
- Việc lợi ích gắn kết giảm và vấn đề giao tiếp sẽ ngày càng khó tránh khi số nhân viên tăng lên
- Việc giảm chấp nhận rủi ro là hệ quả của số người dùng tăng, và một phần cũng liên quan đến quy định của chính phủ
- Startup có thể vô tình đẩy nhanh quá trình doanh nghiệp hóa bằng cách sao chép quy trình của công ty lớn
- Nếu tuyển quản lý từng làm ở tập đoàn lớn, rất có thể cả bộ playbook họ từng dùng cũng đi theo
- Nhiều startup dùng Jira chỉ vì các công ty lớn cũng dùng, nhưng ở đây quan điểm là nên tránh kiểu đó
- Có thể xem Y Combinator là bên đã góp phần phổ biến nhận thức rằng công ty lớn nên cố vận hành như startup
- Playbook của công ty lớn là để phục vụ công ty lớn; đến lúc startup bắt đầu lớn lên, có thể đã có những cách tốt hơn để xử lý bài toán mở rộng
- Khi gặp nỗi đau mở rộng quy mô, tốt hơn là giải từ nguyên lý đầu tiên hoặc lấy cảm hứng từ các startup cùng quy mô nhưng vận hành nhanh hơn
- Việc tổ chức công ty thành nhiều startup độc lập là hướng đáng thử trong phạm vi có thể
- Rippling thường được nhắc đến như một ví dụ phần nào làm được điều này
- Tuy vậy, sản phẩm thường có các thành phần gắn chặt với nhau, và đa số thành phần lại không thể tự tạo doanh thu riêng nên cách này thường có giới hạn
- Thiết kế cơ chế khuyến khích có thể trì hoãn đáng kể việc lợi ích gắn kết bị suy giảm
- Nhưng rất hiếm có cơ chế nào mạnh bằng sở hữu cổ phần lớn và quyền thực sự có thể làm thay đổi giá trị của nó
- Một trong những cách tốt nhất là tuyển ít hơn
- Nhiều công ty tuyển quá nhanh vì động cơ của quản lý bị lệch, áp lực từ nhà đầu tư muốn trông giống các startup tăng trưởng nhanh khác, và vì không hiểu chi phí thực của một nhân sự tăng thêm
- Khi công cụ, đặc biệt là AI, ngày càng tốt hơn, số người dùng mà một đội nhỏ có thể phục vụ cũng tăng lên
- Những nhà sáng lập trong tương lai có thể sẽ bớt lo hơn về nỗi đau mở rộng quy mô, và công việc có thể trở nên thú vị hơn cho tất cả mọi người
1 bình luận
Ý kiến trên Hacker News
Tôi rất thích cách Netflix vận hành 10 năm trước, khi họ còn nhỏ. Họ tuyển những người trưởng thành nên có thể loại bỏ quy trình, và thực tế là cố gắng phi quy trình hóa mọi thứ
Kết quả là công việc cứ thế chạy, và ở Netflix khi đó, người ta thường kỳ vọng mọi thứ “diễn ra tự nhiên mà không có sự kiện lớn”. Active-active region cũng làm xong chỉ trong vài tháng, công cụ triển khai dễ dùng Asgard cũng ra đời, và kế hoạch xây CDN riêng rồi hợp tác với ISP cũng được khoảng 12 người hoàn thành trong 6 tháng
Với tư cách kỹ sư, chỉ có một buổi họp nhóm hằng tuần; các manager và director tổ chức nhiều cuộc họp để đồng bộ bối cảnh giữa các nhóm, nhờ đó kỹ sư có thể thoải mái làm việc hiệu quả. Lúc đó tôi nghĩ chuyện ấy là tự nhiên, nhưng về sau mới thấy đó là một tiêu chuẩn rất cao
Cần những developer có thể hoàn thành việc mà không cần cầm tay chỉ việc, nhưng manager cũng phải biết điều phối chứ không phải cầm tay kiểm soát
Nhưng nếu là sản phẩm cần nhận đầu vào chủ quan từ hơn một người rồi cải tiến lặp đi lặp lại, thì giao tiếp và cộng tác phân tán là quan trọng và cần thiết. Điều đó không có nghĩa là nhất thiết phải đau khổ, nhưng mô hình Netflix ở trên không áp dụng được ở mọi nơi và không nên sao chép mù quáng
Những nơi tôi từng làm thì sản phẩm không được định nghĩa rõ, không phải vì bị bỏ mặc, mà vì nó mới và hình hài chưa rõ nên không ai biết nó nên là gì. Ngược lại, Netflix có mục tiêu rõ ràng là “đưa video lên màn hình hiệu quả nhất có thể”, nên gần với việc giải quyết một bài toán kỹ thuật thuần túy hơn
Tất nhiên vẫn sẽ có phát triển sản phẩm như quảng cáo hay back office, nhưng tôi tự hỏi liệu nhiệm vụ cốt lõi của sản phẩm đủ vững chắc nên họ ít phải tốn thời gian để kéo mọi người về cùng một hướng hơn hay không
Mỗi lần thấy kiểu bài này là tôi lại đảo mắt. Tôi có cảm giác người viết còn khá junior, hoặc là kiểu founder có kỳ vọng méo mó kỳ lạ về việc vì sao nhân viên làm việc cho công ty của mình
Phần lớn bắt nguồn từ nền văn hóa kỳ quặc của giới công nghệ ở SF, nhưng bên ngoài đó, mọi người không nghĩ về công việc của mình như vậy. Những developer giỏi nhất tôi từng làm cùng không “say mê đến mất lý trí” với công việc; họ là các chuyên gia biết mình đang làm gì, được trả công xứng đáng cho kiến thức đó, và có cuộc sống trọn vẹn ngoài công việc với bạn bè cùng những mối quan tâm cá nhân
Câu chuyện kiểu này gần giống tuyên truyền nhằm khiến các kỹ sư trẻ, dễ bị ảnh hưởng, cống hiến cho công việc nhiều phần đời hơn mức mà tiền lương có thể biện minh. Nếu bạn là kỹ sư trẻ thì đừng làm vậy. Có nhiều sếp lợi dụng sự hào hứng và ngây thơ để phá hỏng hoàn toàn đời sống cá nhân của bạn, nhưng cũng có nhiều nơi kỳ vọng một quan hệ chủ lao động - nhân viên bình thường
Khi ông ấy đề nghị hoãn lương cho đến khi sản phẩm ra mắt, những chiến thuật xây dựng lòng tin suốt nhiều năm cuối cùng cũng được đem ra đổi thành tiền, và tôi dần nhận ra mức lương tệ hại đó là có chủ ý. Họ có thể trả mức lương tử tế cho công việc ấy, nhưng khi tôi yêu cầu được đền bù đúng mức, thứ nhận lại chỉ là sự phản kháng, những lời hứa nhỏ giọt kiểu vụn bánh mì, và những bức tường dựng lên
Về sau khi tôi đòi khoản tiền còn nợ, họ nói “không có tiền để trả”, nhưng sau khi tôi tức giận nghỉ việc, họ lại thuê người khác làm lại từ đầu dự án thứ hai của tôi. Tôi không phải developer nhanh nhất, và người mới được thuê có vẻ cũng khá giỏi, nhưng theo tôi và một developer khác thì công việc của tôi đã đủ tốt
Kiểu tình huống như “ba đồng nghiệp bị sa thải nên giờ tôi đang làm việc của bốn người, nhưng nói là quá tải thì sếp không nghe”. Một người chuyên nghiệp có lẽ đã rời đi trước đợt sa thải, hoặc nếu tình huống đó xảy ra thì sẽ đặt ranh giới và đàm phán xem trong tuần làm việc bình thường họ sẽ làm gì và không làm gì
Công ty có thể sa thải người không cần nghĩ ngợi, vậy mà quá nhiều người bị tẩy não đến mức lo cho công ty hơn cả cuộc sống của chính mình, thật vô lý
Sau đó tôi chuyển sang startup và không hối hận. Tôi làm nhiều hơn nhưng vui hơn rất nhiều; chắc không thể làm mãi, nhưng phần thưởng tài chính cũng tốt hơn, nên có lẽ tôi sẽ không cần làm đến 65 tuổi như ở công việc ổn định và nhàm chán trước đây
Điều đó cũng không có nghĩa là họ không có cuộc sống trọn vẹn, hay là họ đang bị bóc lột. Ngược lại, những người nói không phải vậy trông như đang nhận được ít hơn từ công việc so với những gì có thể. Dùng 40 giờ mỗi tuần như thế thì hơi phí
Về cơ bản là đã uống Kool-Aid, và ở trạng thái không biết cả những gì mình không biết
Cũng có những yếu tố còn đi xa hơn một bước so với “ngọn lửa”, dẫn đến sự phá hủy hoàn toàn
Danh sách chưa đầy đủ mà tôi thấy cho đến nay là những yếu tố góp phần lớn làm các đội ngũ kỹ thuật và sản phẩm suy yếu hoặc sụp đổ: lãnh đạo quá thiên về kỹ thuật, lãnh đạo không có nền tảng kỹ thuật, kỹ sư có vấn đề, và quản lý vi mô
Khi startup lớn lên, các kỹ sư siêu sao thường chuyển sang vai trò lãnh đạo như VP Engineering, kiến trúc sư hoặc CTO, nhưng nếu họ không phải kiểu lãnh đạo thì đội ngũ dễ biến thành một sở thú không có tầm nhìn; ngược lại, lãnh đạo phi kỹ thuật gần như không có kinh nghiệm engineering cũng nguy hiểm tương tự
Nếu quy trình phỏng vấn hời hợt khiến các kỹ sư có vấn đề lọt vào, và việc sa thải cũng lỏng lẻo, thì chỉ cần 5–10% đội thuộc kiểu này cũng đủ cản trở tiến độ, né tránh trách nhiệm, chỉ xây dựng danh tiếng cho bản thân và thúc ép những sản phẩm rác rưởi, làm tinh thần đội ngũ tổn hại nghiêm trọng. Việc duy trì một đội ngũ kỹ thuật và văn hóa tốt trông khó như dựng cây bút chì đứng trên đầu ngòi vậy
Các nhà sáng lập non kinh nghiệm thường quá do dự trong việc đưa ra phản hồi tiêu cực, hạ cấp những manager quá thiên về kỹ thuật lẽ ra nên tiếp tục làm IC, hoặc để những nhân viên không phù hợp rời đi
Một startup địa phương từng đưa bạn là UI designer của một giám đốc cấp C lên làm VP sản phẩm; người này hoàn toàn không gánh nổi công việc, nhưng họ vẫn giữ trong 2 năm với lý do “cho cơ hội phát triển”. Tất cả mọi người dưới quyền VP đó đều biết ông ta bất tài và bàn với nhau cách đi vòng qua ông ta
Cuối cùng các sáng kiến sản phẩm thậm chí còn không khởi động được, và công ty phải pivot hoàn toàn sang công việc dựa trên dịch vụ. Tốt nhất là đừng ở lại một startup cứ tiếp tục giữ một lãnh đạo không đủ năng lực mà mọi người trong công ty đã từ bỏ
Cùng công ty đó, khi thu hẹp quy mô, họ có cơ hội hoàn hảo để dọn dẹp VP sản phẩm và đế chế gần như chẳng làm việc với ông ta, nhưng họ tránh làm vì mối quan hệ của ông ta với cấp C và thay vào đó cắt giảm kỹ sư. Họ bắt đầu giảm từ những kỹ sư được trả lương cao, rồi mất các kỹ sư chủ chốt; họ gửi đi tín hiệu rằng chỉ cần quen đúng người thì bất tài cũng được chấp nhận, và trong vài tháng sau đó thêm nhiều nhân sự chủ chốt rời đi
Ai cũng có thể mắc sai lầm tuyển dụng, nhưng cách phản ứng với sai lầm đó sẽ quyết định số phận công ty
Có thể nói những quy tắc kinh nghiệm như “nên trao cho IC mức tự chủ tối đa mà họ có thể xử lý”, nhưng quy tắc nào cũng có ngoại lệ. Trí tuệ được nén lại sẽ mất bối cảnh và dễ bị diễn giải sai, hoặc bị những người thiếu kinh nghiệm bắt chước như một kiểu sùng bái hàng hóa
Tôi từng thấy những động lực nhỏ nảy sinh từ khác biệt tinh vi về tính cách cá nhân và cấu trúc tổ chức dẫn đến rối loạn chức năng lớn và mất năng suất, dù mọi người đều có thiện ý và đang cố hết sức. Kỹ thuật tốt không thể được tạo ra bằng cách ra lệnh từ trên xuống và lập kế hoạch tập trung
Cần có đủ người hiểu sản phẩm và kinh doanh đến tận cùng, bao gồm cả các kỹ sư tuyến đầu, để các quyết định nhỏ được đưa ra phù hợp với bức tranh lớn và những mối lo đúng đắn có thể được đưa lên lãnh đạo. Phải cùng cân nhắc chi phí ngắn hạn và dài hạn của sản phẩm, thiết kế, pháp lý, tài chính, hỗ trợ, bảo mật và vận hành
Điều này chỉ khả thi khi có mức độ tin cậy và an toàn cao để các chuyên gia có thể nêu ý kiến và tìm ra điểm thỏa hiệp phù hợp; vì cái tôi và xung đột tính cách rất dễ cản trở, nên cần sự chín chắn của lãnh đạo. Ẩn dụ dựng cây bút chì trên đầu ngòi khá đúng
Người đó xem qua ứng dụng và bắt đầu gọi mọi quyết định không có bối cảnh là nợ kỹ thuật. Tôi đã thấy vài lần, và từng nói với một VP Engineering mới rằng việc không có mặt khi các vấn đề, quyết định và lịch trình ban đầu diễn ra mà lại nói đó là phán đoán tệ thì trông có vẻ thiếu hiểu biết
May mắn là sau đó ông ấy gọi riêng tôi ra cảm ơn và hỏi thêm nhiều bối cảnh. Sau khi nghe toàn bộ câu chuyện, ông ấy đồng ý rằng chúng tôi đã chọn đúng. Nhưng tôi cũng từng thấy những trường hợp đi theo hướng ngược lại, và khi đó thật sự rất khó khăn
Họ đưa tất cả đội vào bảng tính và cố tự động hóa quản lý bằng các chỉ số đồng nhất, thay vì tập trung quản lý và phát triển những người báo cáo trực tiếp cho mình
Ngược lại, tôi từng thấy một lãnh đạo ít kỹ thuật hơn đến, khiến các kỹ sư xung quanh đảo mắt kèm chút tư tưởng nam quyền, nhưng thực tế người đó đã cho những tuyển dụng tệ rời đi, tuyển các ngôi sao, căn chỉnh ưu tiên của mọi người và khiến họ làm việc hiệu quả. Lãnh đạo là một việc hoàn toàn khác với sự xuất sắc kỹ thuật, và quá thường xuyên những năng lực đáng lẽ nên được thưởng bằng tăng lương hoặc bonus lại được thưởng bằng thăng chức
Những người có kinh nghiệm lãnh đạo nhưng vẫn có năng lực thực chiến, và nếu được trao đủ thời gian thì có thể hiểu đến chi tiết của stack công nghệ mới hoặc các động thái tài chính, có thể được các siêu sao tuyến đầu tôn trọng nhờ đóng góp lãnh đạo dài hạn
Không đồng ý. Tôi từng khởi nghiệp một công ty nhỏ và cũng từng làm việc ở các tập đoàn khổng lồ, gồm cả FAANG và các ngân hàng lớn, nhưng một môi trường có độ nhập tâm cao như vậy có thể được tạo ra ở bất cứ đâu
Cốt lõi là một lãnh đạo năng động xây dựng một đội ngũ mà mọi người biết chính xác vì sao họ ở đó, giao cho mỗi người việc họ làm tốt, và để người giỏi hỗ trợ những việc người khác không giỏi. Sau đó cần làm rõ nhiệm vụ của đội có giá trị gì đối với sứ mệnh của công ty và mục đích của nó trong thế giới, rồi kiên trì loại bỏ các rào cản ngăn trở sản xuất và tác động
Những lập luận kiểu giao tiếp N² là giản lược và không chính xác. Không đội nào phụ thuộc vào mọi đội trong tổ chức; thông thường phạm vi nhỏ và số đội lân cận cũng hữu hạn. Đội lõi là ngoại lệ, nhưng một đội lõi vận hành tốt không tạo overhead N² mà hoạt động như một điểm tập trung, thành một cấu trúc N nơi các đội tìm đến
N có thể lớn, nên việc sàng lọc hiệu quả, tự động hóa, self-service, nền tảng nhất quán có khả năng tự tài liệu hóa, và các thành viên thực sự thích hướng dẫn người khác là rất quan trọng. Xây dựng những đội như vậy cực kỳ mệt mỏi về mặt quản lý, đến mức tôi đã kiệt sức, nhưng vốn dĩ quản lý phải là việc cực kỳ khó. Công việc tiếp theo của tôi sẽ là quay về vai trò distinguished engineer ở một startup giai đoạn sau, tạm thời trở lại với gốc rễ
Tuy vậy, đúng là một môi trường có độ nhập tâm cao như vậy có thể được tạo ra ở bất cứ đâu, và điều quan trọng là có một lãnh đạo năng động xây dựng đội ngũ biết vì sao họ ở đó. Dù vậy, tôi vẫn nghĩ nó có liên quan đến quy mô và các động lực khuyến khích tệ. Tôi từng nghe nói ngay cả ở FAANG, có bộ phận giống startup, còn bộ phận khác thì là sự nhàm chán hút cạn linh hồn
Phản ví dụ bạn đưa ra không phải là ví dụ cho thấy độ phức tạp N² không tồn tại, mà là ví dụ về việc quản lý tốt độ phức tạp đó
Nếu bạn nói rằng không phải đội nào cũng phụ thuộc vào mọi đội khác, thì trái lại, bạn đang đồng ý với bài viết. Vậy tôi không hiểu phần nào là sai
Cái gọi là hiệu quả theo quy mô mà các tổ chức lớn có được thực ra có cảm giác không phải là hiệu quả. Ý tôi là kiểu hiệu quả nhờ có các nhân sự chuyên trách như tuyển dụng, nhân sự, đảm bảo chất lượng, nghiên cứu người dùng
Thay vì tạo ra một cấu trúc tổ chức “hiệu quả” hơn, có lẽ nên phát triển tổ chức bằng cách lặp đi lặp lại việc sao chép đội ngũ nhỏ nhất từng vận hành hiệu quả. Tuy nhiên, làm sao để các “công ty mini” đó giao tiếp hiệu quả với nhau lại là một vấn đề khác
Khi giá trị công ty tăng lên và các cổ đông, nhà quản lý có khẩu vị rủi ro thấp tham gia, bạn phải chi rất nhiều tiền cho quản trị và né tránh rủi ro. Ở công ty cũ của tôi, đối thủ cạnh tranh công khai vi phạm luật để giải quyết nhu cầu người dùng, nhưng có vẻ họ vẫn thoát vì còn nhỏ và không có doanh thu
Ngoài ra, theo trải nghiệm cá nhân, hầu hết nhân viên không đầu tư năng lượng như nhà sáng lập, điều này hoàn toàn dễ hiểu. Khi tỷ lệ nhà sáng lập trên nhân viên giảm, bạn sẽ thuê ba người để hoàn thành ổn định và đúng hạn những việc một mình mình có thể làm
Những người được tuyển sớm gần gũi với nhà sáng lập và có nhiều thứ để được hưởng nếu công ty thành công, nên họ giống nhà sáng lập hơn; nhưng nhân viên thứ 213 bán 40 giờ lao động mỗi tuần và trên thực tế gần như chỉ nhận lương cố định. Ý tưởng lãng mạn về một công ty lớn gồm nhiều startup độc lập nghe rất hay, nhưng tôi chưa từng thấy nó vận hành trong thực tế và cũng khó hình dung
Tôi nghĩ cách mở rộng tốt nhất là tạo ra các quy trình củng cố những đặc tính mong muốn ở đội, và tuyển các quản lý hiểu rằng đội là tập hợp của những cá nhân khác nhau. Quản lý cần được tự do quản lý người của mình theo cách tối ưu hóa việc bàn giao và giảm nghỉ việc
Giữa các đội, tiêu chuẩn về giao tiếp và chất lượng đầu ra phải rất cao, còn văn hóa tổ chức phải được xây trên sự tôn trọng từng cá nhân được tuyển vào và sự tập trung bền bỉ vào việc đặt mỗi người vào đội nơi họ có thể làm việc hiệu quả
Thành quả lao động ngày càng bị treo cao hơn. Giai đoạn đầu của startup có không gian vấn đề phong phú, tác động mà một cá nhân có thể tạo ra lớn một cách bất thường, và số người phải chia sẻ thành quả đó là ít nhất
Khi công ty lớn lên, cả ba yếu tố đều bị gây áp lực. Không gian vấn đề trở nên hiếm hơn, sự ghi nhận cho tác động lớn ngày càng bị cấp trên trong hệ thống thứ bậc nhận lấy, số người chia sẻ tác động thì nhiều hơn, còn sự ghi nhận trở nên ngắn ngủi và mờ nhạt
Nhưng cuối cùng họ vẫn trở thành một tổ chức khổng lồ duy nhất. Cấu trúc tổ chức phẳng của Valve cũng tương tự. Khi đủ lớn, rốt cuộc thứ gì cũng sẽ vón thành một khối
Nghệ thuật quản lý tăng trưởng phần lớn nằm ở việc tìm cách giải phóng con người thay vì xiềng xích họ
Câu “Hầu hết startup sao chép quy trình của công ty lớn và đẩy nhanh quá trình doanh nghiệp hóa một cách không cần thiết. Thường là họ đưa về các quản lý xuất thân từ công ty lớn, và những người đó mang theo playbook của mình” chính xác đến đau lòng
Tôi đã trải qua chu kỳ này vài lần. Startup mà tôi thích nhất và cũng là startup thành công cuối cùng đã được một tập đoàn toàn cầu khổng lồ mua lại vào năm 2007, khi công ty được 4 năm tuổi, và tôi ở lại thêm 2 năm nữa
Sau khi ra mắt sản phẩm, công ty chắc chắn chậm lại vì nhu cầu hỗ trợ khách hàng và hỗ trợ bán hàng. VP Engineering rất giỏi trở thành CTO, rồi khi họ tuyển một gã quản lý cấp trung ngu ngốc làm VP, những ngày tốt đẹp kết thúc. VP mới tuyển “team player” thay vì kỹ sư giỏi, tưởng thưởng lòng trung thành hơn năng lực, và những chuyện nực cười bắt đầu xảy ra
Quãng thời gian vui vẻ kiểu startup của tôi thu lại còn đúng một tuần mỗi năm, giữa Giáng sinh và Năm mới. Tuần đó không có ai, nên tôi được tự do hơn nhiều để làm những việc tôi cho là quan trọng, và có thể tạo ra bản alpha của một tính năng mới hào nhoáng khiến tổ chức phải chạy theo
Trong nhóm ứng viên có nhiều người kiểu cá mập đến đáng kinh ngạc. Họ xuất hiện, nhận ra bạn còn mới, nói tất cả những điều bạn muốn nghe và hứa sẽ giải quyết mọi vấn đề. Họ khẳng định ở mọi công ty trước đây đều đã làm đúng thứ bạn đang cần, nịnh bợ và nói rằng họ đã chờ cơ hội được làm việc với một người như bạn
Hãy hình dung đây là phiên bản mạnh gấp năm lần và khó nhìn thấu hơn ứng viên IC trơn tru nhất mà bạn từng phỏng vấn. Họ có sức hút khó tin nhưng không mấy có ý định làm việc khó, rồi sau khi chui được vào công ty thì bắt đầu rút ruột
Họ moi ra đãi ngộ cho bản thân, headcount để tuyển bạn bè, đãi ngộ cho bạn bè, các hợp đồng thuê ngoài béo bở cho bạn bè bên ngoài, thậm chí có thể có cả hoa hồng lại quả. Vì họ tạo ra rất nhiều hoạt động, có thể mất nhiều năm mọi người mới nhận ra thực ra họ chẳng làm được mấy. Trong quá trình đó, nhân viên có năng lực cũng rời đi vì chán ngấy những chuyện nhảm nhí, hoặc bị gạt ra vì đã chỉ ra sự bất tài
Loonshots của Safi Bahcall giải thích hiện tượng này khá tốt. Quanh mốc khoảng 150 người, các động lực trải qua một “chuyển pha”, và điều đó có thể chí mạng với nhiều tổ chức
Bí quyết nằm ở việc startup vượt qua quy mô nhân sự này như thế nào. Nói thật, nhiều công ty phần mềm có thể không cần hơn 150 người
Số Dunbar là một khái niệm được đề xuất về giới hạn nhận thức đối với số người mà một người có thể duy trì các mối quan hệ xã hội ổn định. Ở đây, quan hệ nghĩa là biết mỗi người là ai và họ kết nối với nhau như thế nào
https://en.wikipedia.org/wiki/Dunbar%27s_number
Thế giới đã mở rộng vượt qua giới hạn này từ hàng nghìn năm trước, và công ty cũng có thể mở rộng vượt qua nó
Giá trị của khuyến nghị hãy tuyển ít hơn không thể được nhấn mạnh quá mức. Nói cách khác, chỉ tuyển khi không còn cách nào khác để giải quyết vấn đề, và ngay cả lúc đó cũng phải thận trọng
Cần chấp nhận rằng nguyên tắc này sẽ khiến lịch trình kéo dài đáng kể. Chi phí trung và dài hạn của việc tuyển quá nhiều tệ hơn rất nhiều so với chi phí chậm ra mắt. Đáng tiếc là môi trường gọi vốn và kỳ vọng tăng trưởng của startup thường khuyến khích hành động ngược lại
Tuy vậy, tôi đã đánh giá khá thấp việc tình hình tuyển dụng của các startup ở Thung lũng Silicon đã tệ đến mức này. Nhiều người đang dùng startup như một chỗ để ghi vào CV trong lúc hồi phục sau burnout ở FAANG hoặc chuẩn bị phỏng vấn
Trong cấu trúc như vậy, vì sợ bỏ lỡ một trong số ít người có thể xây dựng công ty, hiring manager rất dễ nghiêng về thái độ lạc quan quá mức. Cuối cùng, cần phải mạnh tay cho ra đi những người không phù hợp
Bài này có những phần tôi thích và có những phần tôi không đồng ý
Phần tôi đồng ý nhất là “đừng tuyển quá nhanh”. Tôi không dễ nghĩ ra startup hay công ty nào thất bại hoặc khổ sở vì tuyển quá chậm, nhưng các vấn đề do tuyển quá nhanh thì tôi nghĩ ra được rất nhiều, kể cả từ trải nghiệm cá nhân
Ngược lại, phần “đừng dùng Jira” khiến tôi phải trợn mắt. Cũng như mặt trời mọc ở phía đông, việc các kỹ sư chê Jira là thú vui yêu thích. Tùy loại startup, Jira có thể là một công cụ rất tốt cho việc đó
Nếu công ty có nhiều workflow cần hỗ trợ, khi việc theo dõi kém và quyền sở hữu issue không rõ ràng, sẽ có nhiều việc bị bỏ sót và lãng phí rất nhiều thời gian. Tất nhiên, nếu tạo ra cả triệu trạng thái không cần thiết và làm Jira phức tạp quá mức thì cũng rất dễ lãng phí thời gian, nhưng tôi nghĩ Jira ngày nay đã dễ để các nhóm nhỏ nhanh chóng dùng một cách hiệu quả hơn
Tôi không nói Jira là công cụ tốt nhất để bắt đầu; startup trước của tôi bắt đầu bằng Trello và vẫn ổn. Nhưng khi đã đi vào vận hành và phải quản lý, ưu tiên rất nhiều vấn đề vận hành song song với phát triển tính năng mới, nhiều khả năng bạn sẽ cần một công cụ như Jira để mọi người thống nhất và chia sẻ thông tin