Con đường trở thành VP of Engineering
(honeycomb.io)- VP of Engineering đầu tiên của Honeycomb được thăng chức từ Director of Engineering vào tháng 2/2020, và con đường này gần với việc lấp vào khoảng trống nảy sinh khi công ty phát triển hơn là một lộ trình điều hành đã được hoạch định
- Ở giai đoạn đầu của Honeycomb, đồng sáng lập Charity Majors quản lý gần như tất cả mọi người, và hai người có triết lý tương đồng nhưng nền tảng và phong cách khác nhau đã cùng chia sẻ trách nhiệm quản lý R&D
- Việc thăng chức không phải một bước ngoặt lớn duy nhất mà là sự tích lũy của những lần mở rộng phạm vi nhỏ, và trong startup, việc tạo ra các quy trình và trách nhiệm mới trở thành con đường cốt lõi
- Việc chuẩn bị phù hợp với vai trò đòi hỏi tư duy nhìn toàn công ty, khuynh hướng generalist, khả năng di chuyển giữa nhiều mức độ trừu tượng, tinh thần trách nhiệm, tư duy hệ thống, hỗ trợ sự phát triển của đồng đội và các mối quan hệ rộng
- Hình mẫu của một VP of Engineering giỏi thay đổi tùy theo vấn đề hiện tại của công ty, cấu trúc lãnh đạo và IC sẵn có, thách thức kỹ thuật và giai đoạn tăng trưởng, chứ không theo một mẫu chuẩn cố định
Điểm khởi đầu không phải là một lộ trình điều hành được lên kế hoạch
- VP of Engineering đầu tiên của Honeycomb được thăng chức từ Director of Engineering vào tháng 2/2020
- Mục tiêu khi mới gia nhập Honeycomb là làm kỹ sư, với hiểu biết rằng nếu cần thì vẫn có thể quay lại vai trò quản lý
- Khi gia nhập, tác giả là khoảng nhân viên thứ 12, và hiểu rằng ở startup giai đoạn đầu, nếu công ty thành công thì sẽ phải đảm nhận nhiều loại công việc ở nhiều giai đoạn khác nhau
- Tác giả cho rằng việc bám chặt vào một chức danh cụ thể có thể cản trở nhiều hơn là giúp ích cho cả cá nhân lẫn công ty
- Lý do chọn Honeycomb là vì đội ngũ có vẻ thông minh và tử tế, có nhiều điều để học hỏi, và sản phẩm trông giống thứ mà tác giả từng muốn có nhưng không tìm thấy ở công ty trước
- Nếu muốn phát triển nhanh vào một vai trò cụ thể thì gia nhập startup sau Series B có thể hiệu quả hơn, nhưng tác giả đã vào Honeycomb ở giai đoạn Series A
Cách trách nhiệm quản lý được dịch chuyển
- Ban đầu, đồng sáng lập kiêm CEO khi đó là Charity Majors quản lý gần như tất cả mọi người, từ cấp điều hành đến từng kỹ sư cá nhân
- Hai người nhìn chung khá hợp nhau về triết lý quản lý, nhưng có nền tảng và thế mạnh khác nhau
- Charity Majors có kinh nghiệm sâu về hạ tầng, vận hành, cơ sở dữ liệu và backend engineering
- Người được thăng chức bắt đầu từ thiết kế, frontend và product engineering, đồng thời thích hợp tác với product management và UX design
- Cả hai đều có kinh nghiệm với công nghệ metrics và monitoring, nhưng thái độ lại khác nhau
- Charity Majors có xu hướng không thích mảng này
- Người được thăng chức thì đặc biệt yêu thích nó
- Khác biệt về phong cách làm việc cũng rất lớn
- Người được thăng chức coi trọng quy tắc và quy trình, đồng thời áp dụng nhiều kế hoạch và quản trị rủi ro trong cả công việc lẫn sở thích cá nhân
- Charity Majors có phong cách trực giác và ngẫu hứng, đặc biệt tỏa sáng trong khủng hoảng, ghét checklist và nhanh chóng nhận ra khi quy tắc hay quy trình không còn hữu ích
- Khi Honeycomb phát triển, khối lượng quản lý R&D tăng lên, và trách nhiệm dần được chia theo những mảng phù hợp hơn với nền tảng của mỗi người
Thăng chức là sự tích lũy của những lần mở rộng phạm vi nhỏ
- Con đường đi đến VP có nhiều bước nhỏ hơn là một cột mốc đơn lẻ rõ ràng
- Những lần đổi chức danh ở giữa chỉ hữu ích như các dấu mốc nhìn lại để thấy tiến triển, chứ thường không báo hiệu thay đổi lớn về phạm vi công việc ngoài việc có thêm các cuộc họp mới
- Trong một startup đang tăng trưởng, luôn xuất hiện các khoảng trống về quy trình và trách nhiệm, và những vấn đề trông như rò rỉ nhỏ có thể lớn dần thành thứ ngốn rất nhiều thời gian và sự chú ý
- Luôn có cơ hội nhận thêm vấn đề mới để nâng cấp bản thân, nhưng chuyện công ty có ghi nhận điều đó bằng chức danh và vai trò mới hay không lại là chuyện khác
- Hai đồng sáng lập của Honeycomb đã tích cực ủng hộ việc thăng tiến nội bộ và công nhận tầm ảnh hưởng, không chỉ với tác giả mà còn với những người khác
- Nếu sau này tìm một startup khác, tác giả nói sẽ tìm đội ngũ điều hành hoặc sáng lập từng có ví dụ nuôi dưỡng người hiệu suất cao bằng thăng tiến nội bộ và nhanh chóng ghi nhận, đền đáp những người đã tạo ảnh hưởng vượt ra ngoài phạm vi vai trò của họ
Chuyển từ quản lý IC sang quản lý manager
- Bước chuyển thú vị nhất trong cả hành trình là từ trạng thái chỉ quản lý IC sang quản lý cả manager
- Với những ai muốn thử bước chuyển này, tác giả cho rằng nên làm ở một công ty mà mình đã hiểu đội ngũ, công nghệ và bài toán kinh doanh thay vì thử ở công ty mới
- Nhiều kỹ năng line management hiện có vẫn được chuyển sang, nhưng cần thời gian để học cách “nhìn thấy” toàn tổ chức một cách hiệu quả thông qua lớp quản lý bổ sung
- Đặc biệt khó là việc nhận ra những điểm ma sát trong tổ chức hoặc những nơi cần được hỗ trợ nhiều hơn
- Nhờ đã trực tiếp trải nghiệm con người và vấn đề trong tổ chức engineering, tác giả có thể trụ vững cho đến khi cùng các manager xây dựng được thói quen và kỹ năng đánh giá tình hình các team
Tìm kiếm ứng viên VP bên ngoài và thăng chức nội bộ
- Ở một thời điểm công ty có phần chệch nhịp, phương án tuyển VP of Engineering từ bên ngoài cũng đã được cân nhắc
- Charity Majors chia sẻ điều này một cách thẳng thắn và cho tác giả tham gia vào quá trình tìm kiếm, lựa chọn người phù hợp
- Đã có trao đổi với một số lãnh đạo engineering rất xuất sắc, nhưng có người không phù hợp với Honeycomb khi đó, còn có người không chọn Honeycomb là bước tiếp theo của mình
- Sau đó công ty lại xuất hiện các vấn đề mới, và những vấn đề cũ từng trông như không thể giải quyết bỗng trở nên dễ xử lý hơn
- Dù chưa được thăng chức ngay lúc đó, việc tìm người bên ngoài đã dừng lại
- Những lần thăng tiến lãnh đạo ở một mức độ nhất định nên dựa trên điều công ty cần chứ không phải chỉ dựa vào cá nhân, và việc cùng hình dung ra một VP of Engineering phù hợp với Honeycomb trông như thế nào đã rất hữu ích
Những đặc điểm giúp trở thành người phù hợp với vai trò
- Tư duy toàn cục là một đặc điểm quan trọng
- Tác giả tự nhiên tập trung vào việc làm sao để toàn bộ Honeycomb thành công hơn, chứ không chỉ riêng team của mình
- Tác giả làm việc tốt trong môi trường khen thưởng cho hành động vì lợi ích chung của công ty hơn là lợi ích của bộ phận, team hay cá nhân
- Khuynh hướng generalist cũng giúp ích
- Tác giả hứng thú với gần như mọi vấn đề kinh doanh và mọi domain trong một công ty phần mềm
- Thích việc có thể nhìn thấy mọi mảnh ghép ăn khớp với nhau như thế nào trong startup
- Không ngại nhận những việc ít hào nhoáng, ít được chú ý khi cần
- Có thể làm việc ở nhiều mức độ trừu tượng khác nhau
- Có thể nhanh chóng nắm bắt các khái niệm tầng trên ngay cả khi chưa hiểu hoàn toàn các tầng dưới
- Đồng thời cũng thích đi sâu vào chi tiết khi cần
- Tinh thần trách nhiệm mạnh mẽ hữu ích trong startup nhưng cũng cần có giới hạn
- Nó có ích khi những việc quan trọng dễ rơi vào khoảng trống giữa các chức năng trong startup
- Tuy nhiên vẫn phải liên tục cố gắng khép lại công việc hoặc bàn giao cho người khác để tránh việc chất đống hay cản trở sự phát triển của team
- Tư duy hệ thống với cả con người lẫn hệ thống kỹ thuật cũng nằm trong danh sách quan trọng
- Thái độ thực sự thích thú khi chứng kiến đồng đội phát triển cũng rất quan trọng
- Tác giả lấy năng lượng từ việc kết nối những người đã sẵn sàng cho bước tiếp theo với những vấn đề quan trọng nằm ở rìa năng lực hiện tại của họ
- Các mối quan hệ tốt trên khắp công ty cũng cần thiết
- Những người trong và ngoài công ty cần phải hào hứng hơn với việc người này đảm nhận vai trò đó, thay vì đặt kỳ vọng vào một ứng viên bên ngoài
Kinh nghiệm công việc đã giúp ích
- Kinh nghiệm tại startup ở nhiều giai đoạn và quy mô khác nhau, đặc biệt là startup B2B SaaS, đã rất hữu ích
- Startup B2C và B2B xử lý các nhóm vấn đề tương đối khác nhau và mỗi bên đều đã phát triển các cách giải quyết riêng
- Việc nhìn cả hai phía đều tốt, nhưng xây dựng chuyên môn sâu trong một trong hai mảng B2B hoặc B2C cũng rất có giá trị
- Cách tiếp cận thị trường, cấu trúc tổ chức, vấn đề engineering và bài toán mở rộng có thể khác nhau giữa B2B và B2C
- Kinh nghiệm làm việc trên toàn bộ stack cũng hữu ích
- Kinh nghiệm engineering sâu nhất của tác giả nằm ở công nghệ frontend
- Tác giả tích lũy trải nghiệm ban đầu ở nhiều tổ chức thực hành pair programming và áp dụng tư duy DevOps
- Tác giả học hỏi từ các kỹ sư backend, hạ tầng, platform và vận hành để hiểu cách họ suy nghĩ và những vấn đề họ coi là quan trọng
- Không cần phải là chuyên gia ở mọi mảng engineering, nhưng sự đồng cảm với nhiều team và hiểu biết domain ở cấp độ cao là lợi thế lớn
- Kinh nghiệm trong mảng developer tools và monitoring cũng phù hợp với vai trò
- Tác giả đã làm liên tiếp ở ba công ty developer tools
- Thực sự yêu thích sản phẩm Honeycomb, đồng thời cũng yêu thích nhiều sản phẩm trong lĩnh vực observability, monitoring và developer tools
- Kiến thức domain và niềm đam mê với công cụ có thể giúp ích cho đồng nghiệp và trở thành nguồn năng lượng trong những tình huống dễ gây nản lòng
Sự phù hợp được tạo nên bởi may mắn và cấu trúc đội ngũ
- May mắn cũng đóng vai trò lớn trong việc tác giả trở thành người phù hợp với vai trò
- Chỉ việc có kỹ năng và kinh nghiệm mang tính bổ trợ cho Charity Majors là chưa đủ; việc các senior IC ban đầu xử lý tốt những thách thức engineering cốt lõi cũng rất quan trọng
- Một VP of Engineering có nền tảng frontend là trường hợp tương đối hiếm, vì các thách thức kỹ thuật cấp bách nhất của startup thường nằm ở mở rộng, độ ổn định và kiến trúc backend
- Nếu công ty vẫn đang liên tục gặp sự cố, vấn đề mở rộng và các bài toán kiến trúc lớn liên quan tới query và storage engine, rất có thể một người có kinh nghiệm backend và vận hành sâu hơn đã được chọn
- Nhờ Ben Hartshorne, Ian Wilkes, các IC xuất sắc khác và những quyết định thiết kế vững chắc từ đội ngũ sáng lập, công ty có đủ dư địa kỹ thuật, và mối quan tâm số một của lãnh đạo lúc đó là thực thi chiến lược sản phẩm cùng cải thiện trải nghiệm người dùng
- Trong ban điều hành đã có sẵn các lãnh đạo được tuyển từ bên ngoài với nhiều kinh nghiệm ở các chức năng go-to-market
- Christine và Charity, những người có thể được xem là các lãnh đạo trưởng thành từ bên trong công ty, cũng đã có kinh nghiệm sáng lập hoặc lãnh đạo ở công ty trước, và Charity đã nổi tiếng là một manager xuất sắc từ trước khi sáng lập Honeycomb
- Nếu ban điều hành đã nghiêng nhiều hơn về các lãnh đạo mới hoặc người vừa được thăng tiến nội bộ, có thể công ty đã không có đủ dư địa để tiếp tục nuôi dưỡng thêm một executive nữa
VP of Engineering thay đổi theo bối cảnh công ty
- Bài học quan trọng nhất là hình mẫu của một VP of Engineering giỏi phụ thuộc rất nhiều vào bối cảnh
- Trước đây tác giả từng nghĩ có thể liệt kê một bộ đặc điểm chuẩn để tạo nên một VP of Engineering xuất sắc, nhưng về sau thấy rằng ý tưởng về một khuôn mẫu gần như giống nhau ở mọi công ty là không chính xác lắm
- Những công việc nền tảng cần làm ở đa số công ty phần mềm là tương tự nhau, nhưng hình mẫu executive dẫn dắt chúng lại khác biệt lớn tùy theo vấn đề hiện tại của tổ chức và đội hình executive, manager, IC đã có sẵn
- Ngay cả sau khi bước vào vai trò này, các yêu cầu cũng không cố định
- Ở các công ty đang phát triển, giống như nhiều vai trò khác trong startup, vai trò VP of Engineering cũng có thể thay đổi hình dạng theo thời gian
1 bình luận
Ý kiến trên Hacker News
Đoạn này khá thú vị: câu “Charity có phong cách trực giác và ngẫu hứng hơn, tỏa sáng nhất trong khủng hoảng và ghét checklist” nghe gần như là một lời thừa nhận buột miệng
Nói cách khác, điều đó có nghĩa là nhà sáng lập không có những tư cách hay đặc điểm mà cấp dưới cho là cần thiết cho một vị trí lãnh đạo
Khi lập công ty thì tự động trở thành CEO, CTO các kiểu, và các nhà sáng lập của những công ty nay đã thành tập đoàn lớn cũng từng như vậy
Nhà sáng lập không cần bất kỳ tư cách cụ thể nào để biện minh cho chức danh, họ tự trở thành lãnh đạo rồi chọn bạn bè làm những nhân viên đầu tiên
Việc tuyển dụng chỉ được chính thức hóa về sau rất lâu, và dù người ta có muốn tin hệ thống thứ bậc đó trọng dụng thực tài đến đâu thì điểm khởi đầu của nó rõ ràng vẫn là hỗn loạn
Cách tư duy phân cấp và phục tùng lúc nào cũng khiến tôi thấy kỳ quặc, và tôi cũng chưa từng nghĩ các sếp cũ của mình “giỏi hơn” tôi
Việc leo thang trong công ty về bản chất gần với chính trị hơn, và những bài viết bất tận kiểu “kỹ sư senior là gì” cũng có vẻ xuất phát từ một kiểu tư duy doanh nghiệp hóa nhằm hợp thức hóa thứ bậc
Nhưng theo thời gian, bạn phải biện minh cho vị trí đó bằng cách giúp công ty thành công thay vì làm nó sụp đổ
Đây thường là một cách đo lường năng lực trung thực và khắc nghiệt hơn nhiều so với bất kỳ kiểu đánh giá nào
Một tập đoàn lớn như Google sẽ không phá sản chỉ vì một VP bất tài và lười biếng, nên họ cần hệ thống đánh giá
Có thể so sánh với https://gwern.net/backstop
Tôi hoàn toàn là kiểu thực thi, nhưng tôi đã sớm học được rằng những phẩm chất lý tưởng ở đồng sáng lập lại là những thứ đối lập với mình, và điều thể hiện ở đây chính là khác biệt đó
Người được mô tả là kiểu lãnh đạo phi điển hình điển hình: có thể ngẫu hứng, chạy khắp nơi và dễ phân tán, nhưng đồng thời cũng là một nhà đổi mới xuất sắc và người truyền động lực cho người khác
Một startup thành công cần cả người có tầm nhìn khác thường lẫn người thực thi
Tôi đề xuất Rocket Fuel: https://www.amazon.com/Rocket-Fuel-Essential-Combination-Bus...
Nó giống một sự thừa nhận chân thành và thân thiện rằng tồn tại hai phong cách khác nhau, và việc thừa nhận khác biệt như vậy là điều lành mạnh chứ không phải một lời kêu gọi ngầm cho thứ bậc
Ngược lại, việc dùng những từ như “cấp dưới”, “cấp trên” và đồng nhất việc lập công ty với việc thiết lập hệ thống thứ bậc lại khiến toàn bộ bình luận này củng cố thứ bậc, trái với lời nói rằng đang hoài nghi nó
Trong ngành công nghiệp tri thức, quản lý không phải là lãnh đạo mà là nhân sự hỗ trợ
Những quản lý phần mềm và giám đốc điều hành giỏi nhất hiểu rằng vai trò của họ là giúp những lãnh đạo và chuyên gia thực thụ, tức các cá nhân đóng góp trực tiếp làm công việc, có thể làm việc dễ dàng hơn
Một trong những chức năng hỗ trợ của ban điều hành là tự thiết lập kỳ vọng đó bằng chính hành vi của mình
Khi một startup được bán cho một công ty lớn, sẽ khá thú vị khi lộ ra rằng không ai trong startup đó có thể được tuyển theo tiêu chuẩn HR của bên mua
Rồi đột nhiên chính các thành viên startup đó lại thăng tiến nhanh hơn những nhân viên tập đoàn lớn có học vấn đẹp và đã được HR phê duyệt
Nhiều người đã bị hệ thống chuỗi mệnh lệnh kiểu doanh nghiệp Mỹ tẩy não, và quá nhiều người mặc định rằng nếu ai đó mang một chức danh nào đó thì họ thực sự có đủ tư cách cho chức danh ấy
Lạm phát chức danh ở khắp mọi nơi, và theo cảm nhận của tôi, chức danh thường được dùng như công cụ tăng lương và ghi nhận thâm niên hơn là công nhận năng lực
Tôi không định giới hạn câu chuyện này chỉ trong nước Mỹ
Theo kinh nghiệm của tôi, việc lấy các trường hợp thăng tiến nội bộ làm chuẩn là chuyện rất hiếm
Ở phần lớn startup, khi cần thêm một nấc mới trong hệ thống thứ bậc hoặc có chỗ trống vì người cũ rời đi, lựa chọn mặc định là tuyển từ bên ngoài
Có vẻ logic ở đây là nếu mọi người đều đang làm tốt việc cần làm thì tốt nhất đừng động vào, nhưng thành thật mà nói điều này làm tụt động lực rất mạnh
Nó còn khiến tôi nản hơn nhiều so với việc một đồng nghiệp được thăng chức còn mình bị bỏ lại, vì nếu tồn tại văn hóa thăng tiến và phát triển thì tôi có thể tin rằng lần sau mình sẽ có một cơ hội công bằng
Nhưng nếu lúc nào cũng tuyển từ bên ngoài thì sự nghiệp của tôi ở công ty này sẽ mãi dừng ở đúng vị trí ban đầu khi tôi vào làm
Logic ở đây dường như là giữ chân những người thông minh có thể tạo ra kết quả vượt xa chức danh của họ với chi phí rẻ nhất có thể
Việc chuyển việc có chi phí thực sự từ phía nhân viên, và kinh tế càng khó khăn thì chi phí đó càng lớn
Dù vậy vẫn có người rời đi, có người âm thầm buông xuôi, và cũng có người cứ thế chịu đựng
Theo kinh nghiệm của tôi, họ thường từ chối thích nghi rồi либо rời đi, hoặc bị cho nghỉ
Việc có thể quản lý một nhóm 10 người không có nghĩa là bạn có thể quản lý một tổ chức 100 người, chứ đừng nói 1000 người
Không phải trường hợp này chắc chắn như vậy, nhưng trong một số tình huống đó là lý do chính đáng để tránh định luật Peter
Bởi những người được thăng chức là những người đã chịu đựng được các khiếm khuyết đó, hoặc thậm chí không hề nhận ra chúng
Nếu có vài người tuyển từ bên ngoài hiếm hoi đủ trải nghiệm để nhận ra các khiếm khuyết ấy, họ rất có thể sẽ trải qua quãng thời gian khá khắc nghiệt
Phần lớn lãnh đạo cấp cao đều đi lên từ thăng tiến nội bộ, đôi khi từ cá nhân đóng góp trực tiếp lên đến VP, và có thể thấy rõ ảnh hưởng của điều đó
Có vẻ sẽ rất có ích cho tổ chức nếu có thêm người từng trải qua quy mô đó ở nhiều công ty khác nhau
Thật ra rất khó biết người đó đã làm gì và hiện đang làm gì trong vai trò VP
Có rất nhiều lời hay ý đẹp, nhưng lại không rõ phần lớn một ngày hiện tại được dùng vào việc gì
Câu như “xuất thân từ design, frontend, product engineering” cũng không cung cấp nhiều thông tin
Tôi cũng đúng kiểu người làm từ sketch, layout Figma, frontend/tầng trung gian SvelteKit cho tới xây API bằng FastAPI, nhưng không biết người đó đã làm tốt điều gì để trở thành VP, giờ đang làm gì khi đã rời xa hiện trường, và nhớ nhất điều gì
Bài viết thì cực kỳ dài nhưng tôi không rõ rốt cuộc muốn nói gì
Nếu muốn xem vai trò được kỳ vọng ở các công ty ngày nay nhỏ hơn FAANG và con đường để kỹ sư đi lên nhánh quản lý, thì “The Manager's Path” là tài liệu đáng tham khảo
Tôi cứ nghĩ càng lên lãnh đạo cấp điều hành thì công việc càng mang tính chiến lược hơn nhiều và hiếm khi trực tiếp thực thi, nhưng bài viết lại liệt kê rất nhiều kinh nghiệm và phẩm chất mang tính chiến thuật mà tác giả cho là đã giúp mình trở thành một VP giỏi
Với tư cách một người nghèo ở vùng rìa ngành kỹ thuật, tôi đã thấy nhiều trường hợp bị công ty ép phải viết gì đó, và lúc nào cũng kiểu như thế này
Đến mùa tuyển dụng campus, công ty lại để mỗi người viết một hai bài như vậy để khi tìm kiếm thì có bài mới hiện lên
Nó đồng thời phục vụ hai mục đích là nịnh vừa phải và nâng bi các ứng viên tiềm năng
https://www.honeycomb.io/blog/becoming-vp-of-engineering-pt2
Bài này về cơ bản là một ví dụ của survivorship bias và sự hợp lý hóa nó
Điều bị thiếu là góc nhìn thống kê giữa việc luân chuyển nội bộ lên ghế VP và tuyển từ bên ngoài
Dù là startup hay tập đoàn lớn, tôi cho rằng đi lên VP từ bên trong là cực kỳ khó
Startup thì phải thành công, còn công ty lớn thì phải trụ được nhiều năm và xây được quan hệ chính trị tốt
Con đường dễ nhất là đừng nghĩ mình sẽ bắt đầu từ đáy, mà hãy nhắm tới vai trò cao ngay từ sớm trong đời và cứ tiếp tục như vậy
Nếu không leo lên đỉnh ở công ty hiện tại thì tự mình tạo ra nó
Nếu bắt đầu từ đáy thì bạn sẽ cứ ở lại đó, vì những kỹ năng ấy không có giá trị trong vai trò lãnh đạo cao nhất
Có vẻ họ đã thử nhưng cuối cùng không thành, và cũng không có phán xét giá trị gì
Trông như họ không tìm được ứng viên xuất sắc nên cuối cùng tác giả được thăng chức
Ở startup trước của tôi cũng từng tìm VP rồi cuối cùng thăng chức nội bộ, và xét về thống kê thì rõ ràng chuyện đó thỉnh thoảng vẫn xảy ra
Tôi đoán tác giả sẽ không đồng ý với câu cuối “nếu bắt đầu từ đáy thì sẽ cứ ở đó mãi”
Tác giả nói rằng việc hạ tầng công ty vẫn ổn định ngay cả khi mở rộng là nhờ những “người ở tầng đáy” làm việc rất tốt, nên nhờ vậy mình mới có dư địa để suy nghĩ chiến lược nhiều hơn
Có vẻ đây không phải chuyện trên dưới, mà gần hơn với việc bạn giỏi giải loại vấn đề nào
Nếu bạn thích lập kế hoạch, quản lý và chiến lược, thì nên tìm vai trò ở bất kỳ cấp nào — trên, giữa hay dưới — nơi có thể dùng được năng lực đó
Ví dụ, nếu muốn trở nên xuất sắc thì đừng an phận với một vị trí JavaScript, mà hãy tự đẩy mình vào một không gian cạnh tranh hơn; và nếu muốn trở thành một lập trình viên thực sự giỏi thì phải viết thứ code bị nguyền rủa bằng OCaml
Với góc nhìn của một CTO tại startup có vốn đầu tư mạo hiểm, tôi thấy những người ở vị trí cao đa phần đều thông minh, và tôi cũng xếp cả sự khôn ngoan lắt léo vào cùng một nhóm
Nhưng cũng có rất nhiều người thông minh y hệt mà không ở vị trí cao, đơn giản vì họ không có cơ hội
Nếu tự khởi nghiệp thì cơ hội sẽ tốt hơn, và dĩ nhiên chẳng ai lập công ty chỉ để kiếm ghế VP ở công ty khác, nhưng đó là một con đường thay thế khá tốt
Hoặc bạn cần networking với đúng người, mà thường điều này đi cùng con đường khởi nghiệp nói trên
Một cách khác là làm ở công ty nổi tiếng như Google rồi chuyển sang nơi nhỏ hơn để thành con cá lớn
Hoặc phải lọt vào mắt sếp và cả sếp của sếp, để khi quản lý trực tiếp từ chức thì mình trở thành người được bổ nhiệm tiếp theo
Có một điều tôi học được là: nếu thấy công ty thăng chức và tuyển lãnh đạo không phải vì năng lực mà vì lý do khác, thì đã đến lúc bắt đầu tìm việc mới
Tôi không nhận ra khi đi phỏng vấn, nhưng ở công ty cũ, các vị trí từ VP trở lên gần như bị những người có liên hệ với CEO độc chiếm, bất kể năng lực
Có vài người được thăng tiến nhờ thực lực hoặc tự nhiên đi lên sau quá trình sáp nhập, nhưng theo thời gian họ liên tục bị thay thế hoặc giáng chức để nhường chỗ cho bạn bè, thậm chí cả người nhà của các lãnh đạo cấp C
Có một lãnh đạo cấp C mà tôi rất thích làm việc cùng đã bị giáng xuống VP, còn vị trí cấp C đó được giao cho một người bạn lâu năm của CEO
Vị lãnh đạo bị giáng chức ấy đã có nhiều năm kinh nghiệm ở những công ty hàng đầu ngành và còn đưa cả gia đình chuyển nhà xuyên quốc gia vì vị trí này, trong khi người kế nhiệm lại hoàn toàn không có kinh nghiệm trong ngành
Vị VP đó được yêu cầu ở lại để người bạn lâu năm của CEO học việc rồi tiếp quản, và còn được “cho phép” giữ các stock option
Việc đó khiến tôi mở mắt về cách gia đình trị và lòng trung thành vận hành ở một số công ty
Đoạn trích này đặc biệt gây chú ý với tôi
Lý do các VP Engineering xuất thân từ frontend tương đối hiếm là vì những vấn đề kỹ thuật cấp bách nhất ở startup thường nằm ở khả năng mở rộng, độ tin cậy và kiến trúc backend
Trước đây tôi từng làm ở những công ty nơi tất cả lãnh đạo đều từ phía backend/hạ tầng nên frontend bị đánh giá thấp, và tôi đã thấy không ít trường hợp chất lượng code của các lập trình viên backend khá khủng khiếp
Tôi tự hỏi liệu có tồn tại mối tương quan nghịch giữa tính đại diện trong lãnh đạo và tài năng kỹ thuật hay không
Tôi là người đi từ kỹ sư frontend lên tech lead, và tôi nghĩ lập trình viên chọn điểm tập trung tùy theo khuynh hướng cá nhân và những giá trị họ coi trọng
Người chọn frontend và lập trình viên backend thường có xu hướng khác nhau
Code khủng khiếp là gì
Là format không nhất quán hoặc không đẹp, tên biến không đủ mô tả, hay code không được chia tách và cấu trúc gọn gàng để dễ nhìn
Tôi cảm thấy các lập trình viên frontend có xu hướng đánh giá code theo những giá trị bề mặt
Đặc biệt trong các tổ chức lấy kỹ thuật làm trung tâm, người ta được công nhận bằng cách giải quyết vấn đề
Nhiều team vẫn vận hành ổn mà không cần người phụ trách frontend nòng cốt, nhưng nếu thiếu một kỹ sư hạ tầng hoặc backend giỏi, hoặc rộng hơn là vài người như vậy, thì thường sẽ chao đảo
Đó là thực tế
Công việc frontend thường bị mã hóa như thứ mang tính nữ và bị xem là kém quan trọng hơn
Ví dụ: https://thoughtbot.com/blog/tailwind-and-the-femininity-of-c...
Trong ngành công nghệ, người ta cũng có xu hướng gắn năng lực lãnh đạo với các đặc tính được mã hóa là nam tính
Vì vậy, việc xem lãnh đạo và xuất thân frontend như một sự kết hợp có gì đó không ăn khớp hoàn toàn không đáng ngạc nhiên
Các động lực giới tính tương tự cũng liên quan tới code
Với tôi, một phần của code tốt là code tốt cho người khác và tốt cho hợp tác
Nhưng nếu muốn hành xử kiểu macho, alpha nerd tech-bro, bạn có thể một mình cowboy coding và phô diễn sự thiên tài của mình
Khi đó mục tiêu không phải là cộng tác chặt chẽ với team để cùng xây dựng, mà là trở thành một cá nhân đóng góp xuất sắc gây ấn tượng mạnh với ban lãnh đạo
VP Engineering không phải là một vai trò có thể chuẩn hóa để so sánh giữa các công ty
Ở công ty hiện tại của tôi, director thường quản lý tổ chức lên tới 500 người, còn VP thường phụ trách từ hơn 1000 người, đôi khi là 3000~5000 người
Xem VP ở một startup 50 người giống với VP ở FAANG có hơn 1000 người là điều vô lý
Không phải bên nào tốt hơn, mà là kỹ năng cần thiết rõ ràng khác nhau
Trên thực tế, tôi đã thấy những người nhận title VP ở công ty nhỏ không hiểu sự khác biệt này, rồi ứng tuyển vào FAANG và bị sốc khi được đề nghị vị trí manager hoặc senior manager
Hoàn toàn vô lý
Theo kinh nghiệm của tôi, VP đó có mức kinh nghiệm cỡ thực tập sinh nếu so theo chuẩn tổ chức lớn, nhưng là người vào công ty sớm
Director thì còn tệ hơn, còn hai người báo cáo cho họ lại rất có năng lực
Tôi ước gì nhân viên Honeycomb dành chút thời gian để cải thiện sản phẩm theo cách dễ thấy hơn thay vì viết bài blog
Tôi từng có cái xui là phải dùng Honeycomb ở công ty, và với những hệ thống tương tác với nhiều hơn vài service thì đơn giản là không dùng nổi
Tôi không hiểu vì sao công ty này lại nhận được nhiều kỳ vọng thổi phồng đến vậy
Tôi đang đọc bài này với ý nghĩ rằng VP của Honeycomb thực chất tương đương với một senior manager ở các công ty công nghệ lớn
Theo chuẩn công ty lớn thì tương ứng với director
Theo kinh nghiệm của tôi, individual contributor xây sản phẩm, manager xây con người, director xây quy trình, còn VP xây chính sách
Tất cả những người ở trên mức đó là các bước phê duyệt yêu cầu ngân sách
Nếu cho rằng chính sách và chiến lược không phải là một
Hoặc nếu đây là một câu đùa tinh tế rằng chẳng ai làm chiến lược cả, thì đó là một câu đùa hay