Từ kỹ sư thành quản lý: những điều thích và không thích
(thoughtspile.github.io)- Sau 7 năm làm lập trình viên frontend, rồi trở thành team lead và engineering manager toàn thời gian, mức độ ảnh hưởng lên sản phẩm và đội ngũ tăng lên nhưng tính chất công việc thay đổi rất nhiều
- Quản lý có thể can thiệp vào những vấn đề khó thay đổi khi còn là IC, như viết test, cải thiện quy trình, điều chỉnh bầu không khí trong nhóm, bằng quyền hạn chính thức và phi chính thức
- Về sự nghiệp dài hạn, vai trò này có mức đãi ngộ cao hơn các cấp kỹ sư thông thường, cơ hội rộng hơn staff+ IC, và mang lại kỹ năng có thể chuyển đổi để dễ dịch chuyển sang lĩnh vực kỹ thuật khác, quản lý dự án, quản lý sản phẩm hoặc khởi nghiệp
- Ngược lại, cũng phải thực thi các thủ tục kiểu doanh nghiệp như đánh giá hiệu suất, deadline vô lý, chính sách tổ chức, đồng thời trực tiếp gánh xung đột, bất an tâm lý và áp lực luôn phải sẵn sàng
- Công việc quản lý khó cho thấy kết quả trong vòng một tháng, và ngay cả những thay đổi đúng đắn như tách nhóm hay tuyển người cũng có thể làm tình hình xấu đi trong ngắn hạn, nên phải chịu được vòng phản hồi dài
Quá trình chuyển từ kỹ sư sang quản lý
- Khoảng 2 năm trước đã chuyển sang vai trò team lead, và sau khi nhóm mở rộng thì trở thành engineering manager toàn thời gian
- Trước đó đã làm lập trình viên frontend 7 năm, ban đầu chọn lộ trình sự nghiệp IC cấp cao rồi mới chuyển sang quản lý
- Quá trình chuyển đổi có nhiều gập ghềnh nhưng thú vị, và công việc hiện tại có cả điều thích lẫn điều không thích
Những điều thích ở vai trò quản lý
-
Quyền thay đổi sản phẩm và đội ngũ
- Khi trở thành quản lý, sẽ có quyền hạn để cải thiện tình trạng tổng thể của sản phẩm và đội ngũ
- Khi còn là IC, có thể rất khó thay đổi những vấn đề như buổi standup quá sớm, chất lượng code thấp, hay các tính năng mới khó hiểu
- EM có thể dùng quyền lực chính thức lẫn phi chính thức để điều chỉnh cách đội ngũ và bản thân làm việc theo hướng tốt hơn
- Cùng là câu “cần viết test”, nhưng trọng lượng sẽ khác giữa lời của một IC và lời của một EM, và lời của EM có thể thực sự dẫn tới việc viết test
-
Cơ hội sự nghiệp rộng hơn
- Engineering manager mang lại cơ hội sự nghiệp rộng hơn so với lộ trình kỹ sư thông thường
- EM thường có mức đãi ngộ cao hơn các cấp kỹ sư cơ bản theo đơn vị nhóm như junior, middle, senior
- Các cấp IC cao hơn như staff, principal cũng tồn tại ở dải đãi ngộ ngang hoặc trên EM
- Tuy nhiên, trong khi công việc staff+ IC tập trung nhiều ở các công ty công nghệ lớn với các bài toán kỹ thuật khó hơn, thì gần như mọi đội phần mềm ở mọi công ty đều có vị trí lãnh đạo
- Nấc thang sự nghiệp quản lý cũng đi cao hơn so với IC
- Dù khả năng trở thành CTO là thấp, vẫn có những lựa chọn mà một IC thuần túy không có kinh nghiệm quản lý sẽ không có
- Nhu cầu với EM ổn định hơn nhu cầu với staff+ engineer, và mang lại nhiều cơ hội hơn ở giai đoạn sau của sự nghiệp
-
Kỹ năng dễ chuyển sang lĩnh vực khác
- Kỹ năng quản lý có thể được áp dụng rộng hơn so với một vai trò kỹ sư IC cụ thể
- Một frontend engineer có kinh nghiệm React có thể chuyển sang framework frontend khác, hoặc chấp nhận giảm nhẹ về cấp bậc để chuyển sang backend hay mobile
- Nếu đã có kinh nghiệm engineering manager, sẽ dễ đảm nhận các nhóm có trọng tâm khác như đội mobile, đội hạ tầng, hay đội ML engineer
- Sẽ cần thời gian để hiểu những khó khăn kỹ thuật lớn của đội mới, nhưng nhiều công ty có thể chấp nhận kiểu chuyển đổi này
- Nếu không muốn tiếp tục làm EM, đây cũng là vị trí thuận lợi để chuyển sang quản lý dự án hoặc quản lý sản phẩm
- Ngay cả khi toàn bộ thị trường công nghệ suy thoái, nhiều kỹ năng quản lý vẫn có thể phát huy trong các ngành khác
- Kinh nghiệm tham gia vào con người và quyết định kinh doanh cũng hữu ích như sự chuẩn bị trước cho khởi nghiệp
-
Kiến thức ít lỗi thời nhanh hơn
- Nếu cảm thấy mệt mỏi vì phải theo kịp framework và công cụ frontend mới nhất, vai trò quản lý có thể giúp giảm bớt gánh nặng
- Những phương pháp agile, kanban, scrum từng được xem là “mới” thực ra đã là các khái niệm có từ 20–30 năm trước, và các kiểu họp cơ bản như demo, daily, 1:1 cũng đã được phát triển qua thời gian dài
- Cốt lõi của quản lý là làm việc nhóm và tương tác giữa con người, mà những điều này không thay đổi nhiều từ thời kỳ đầu của loài người
- Vẫn cần tiếp tục theo dõi biến động công nghệ, nhưng tương đối ít phải lao vào tìm hiểu thật sâu trong trạng thái gấp gáp
-
Thử thách mới ngoài các vấn đề kỹ thuật quen thuộc
- Sau 4–5 năm làm việc trong một lĩnh vực kỹ thuật cụ thể, thường có thể xử lý được phần lớn các vấn đề thực tế
- Cách để một kỹ sư giàu kinh nghiệm tìm kiếm thử thách lớn hơn có những giới hạn nhất định
- Việc chỉ thay đổi nhẹ stack, như chuyển sang một framework frontend mới, thường khó giữ được hứng thú lâu dài
- Một cú chuyển đổi lớn hơn như từ frontend sang backend có thể đem lại vài năm thú vị, nhưng thường xảy ra ngẫu nhiên hoặc có thể ảnh hưởng đến đãi ngộ
- Nếu tự tạo vấn đề bằng cách rewrite toàn bộ bằng thư viện mới hoặc cố xử lý 9000 RPS cho tương lai, thì dù vui vẫn thường gây hại cho đội ngũ và doanh nghiệp
- Với kỹ sư đã có kinh nghiệm, chuyển sang quản lý là cách mang lại nhiều điều mới để học nhất mà không làm giảm đãi ngộ
Những điều không thích ở vai trò quản lý
-
Phải thực thi các thủ tục kiểu doanh nghiệp
- Khi còn là kỹ sư, tác giả ghét những trò nhảm kiểu doanh nghiệp như đánh giá hiệu suất cá nhân, deadline vô ích, hay các quy trình và giới hạn tech stack bị công ty áp đặt
- Khi thành quản lý, dù có tin vào những cách làm đó hay không, bạn sẽ trở thành người thực thi chúng
- Trong tổ chức có cơ chế hiệu chỉnh đánh giá, team lead cứ mỗi 6 tháng lại phải chỉ ra 1 người không làm việc đủ chăm chỉ
- Nếu không đưa ra một thành viên để “hy sinh”, thì ở giai đoạn sau có thể sẽ có ai đó bị chọn ngẫu nhiên, nên rất khó loại bỏ thủ tục này
- Một số thủ tục có thể thương lượng hoặc lách được, ví dụ như luân phiên gán mức “hiệu suất dưới kỳ vọng” theo kiểu round-robin
- Từ góc nhìn của đội ngũ, đôi khi quản lý có thể trông như một con quái vật doanh nghiệp
- Tác giả vẫn chưa trải qua những tình huống còn khó hơn như sa thải, đóng cửa, hay tái cấu trúc tổ chức
-
Phải xử lý căng thẳng giữa con người với nhau
- Điểm xuất phát để trở thành engineering manager là khả năng tạo ra thứ gì đó tốt, và tác giả từng nghĩ công việc sẽ là hỗ trợ quyết định kỹ thuật, tư vấn sự nghiệp, điều chỉnh quy trình, xây dựng tự động hóa
- Thực tế, một phần lớn công việc là debug những căng thẳng xã hội và bất an tâm lý của con người
- Ví dụ:
- Một kỹ sư junior muốn triển khai bản xem trước của tính năng nên comment out vài test
- Người phụ trách QA cảm thấy nhóm không tôn trọng vai trò và giá trị của QA nên nổi giận lớn
- Quản lý phải khôi phục lại sự tin tưởng
- Ví dụ khác:
- Một project manager nói đùa thất bại, khiến một designer bị tổn thương và bật khóc
- Quản lý phải khiến PM xin lỗi
- Vì không phải nhà tâm lý học và cũng không đặc biệt giỏi xử lý con người, phần này rất khó, gần như là phải chịu đựng cho đến khi quen dần
-
Cấu trúc công việc khó thực sự offline
- Cuộc sống của kỹ sư có thể tương đối thong thả hơn
- Nếu không có việc gấp, có thể ra ngoài nửa ngày để nghĩ về tương lai của dự án, và việc đột ngột vắng mặt ở vài cuộc họp đôi khi cũng không thành vấn đề lớn
- Nhưng nếu EM vắng mặt vài tiếng, vấn đề sẽ chồng đống trong messenger
- Intern quên cách
npm installnên không làm được việc - Senior manager muốn bàn về một tính năng tiềm năng
- Bản phát hành gặp trục trặc
- Intern quên cách
- Những cuộc họp mà bản thân phải chủ trì hoặc sắp xếp thì rất khó bỏ qua mà không chuẩn bị trước
- Khi đội ngũ trưởng thành hơn và quy trình tốt hơn thì tình hình có thể cải thiện, nhưng nhìn chung quản lý sẽ cảm nhận giờ hành chính rõ rệt hơn nhiều
- Work-life balance sẽ phụ thuộc trực tiếp vào khả năng hoàn thành công việc của chính mình
-
Vòng phản hồi dài và phi tuyến tính
- Phần lớn công việc kỹ thuật cho thấy kết quả tương đối nhanh
- Tính năng mới thường cho ra kết quả trong vài tuần đến vài tháng, và khi sửa bug thì hôm sau có thể thấy phản ứng của người dùng
- Với refactoring, chỉ trong vài giờ đã có thể xác nhận mức độ giảm độ phức tạp
- Hành động của quản lý thì rất hiếm khi tạo ra kết quả nhìn thấy được trong vòng một tháng
- Nếu nhóm quá lớn và cần tách ra, phải đi qua nhiều bước
- Xác định cơ cấu kỹ sư phù hợp cho nhóm mới
- Trò chuyện với những người liên quan về cảm xúc trước thay đổi
- Thiết lập các cuộc họp định kỳ mới
- Thiết lập quy trình và giao tiếp
- Xử lý các công việc liên quan đến Jira
- Trong một số trường hợp, tách riêng codebase của sản phẩm con
- Nếu nghĩ có thể làm xong những việc này trong một tuần thì là nhầm
- Ngay cả thay đổi đúng đắn cũng có thể khiến mọi thứ tệ hơn trước khi tốt lên
- Nếu quyết định tuyển thêm người vì thiếu nhân lực, thì trong ngắn hạn sẽ tốn rất nhiều thời gian cho phỏng vấn, còn thành viên mới cũng cần thời gian onboarding nên không thể bắt nhịp ngay
- Thay đổi trong quản lý giống một đợt refactoring quy mô lớn hơn là giải quyết vấn đề nhanh, và vì không thấy cải thiện tức thì nên có thể rất dễ nản
Dành cho những kỹ sư đang cân nhắc chuyển đổi
- Việc chuyển từ IC engineer sang quản lý là một trải nghiệm như tàu lượn, có cả mặt sáng lẫn mặt tối
- Ưu điểm là có thể tạo ảnh hưởng rộng hơn lên sản phẩm và đội ngũ, có nhiều cơ hội và sự linh hoạt hơn như một lộ trình sự nghiệp dài hạn, đồng thời đem lại thử thách mới khi đã chán lĩnh vực kỹ thuật hiện tại
- Nhược điểm là phải thực thi chính sách doanh nghiệp, xử lý căng thẳng xã hội và bất an tâm lý, làm việc trong cấu trúc khó offline, và chấp nhận cảm giác thỏa mãn đến rất chậm cùng vòng phản hồi dài
- Nếu thích thử thách và trách nhiệm, đồng thời có cơ hội, thì đây là điều đáng thử
- Quản lý không phù hợp với tất cả mọi người, nhưng đây có thể là trải nghiệm giúp mở rộng phạm vi kỹ năng và nhìn công việc kỹ thuật từ một góc độ mới
- Nếu hoàn toàn không hợp, vẫn còn đủ thời gian để quay lại viết code
1 bình luận
Các ý kiến trên Hacker News
Tôi đã làm quản lý bốn lần, trong đó có hai lần ở FAANG, nhưng có nhiều điểm tôi không đồng ý với bài gốc
Nấc thang quản lý thực ra cũng không cao hơn, và phần lớn engineering manager tập trung ở mức tương đương L6/staff engineer. Việc thăng chức lên senior manager trở lên phụ thuộc rất nhiều vào hoàn cảnh và khá hiếm, trong khi các đồng nghiệp theo track kỹ sư, khi đã sẵn sàng, được thăng chức mà không phải chờ “đúng thời đúng vận”
Những người bị sa thải khi đang là engineering manager thuần túy thường vẫn đang tìm việc và gần như sắp bỏ cuộc, nhưng những người không ngại quay lại làm IC thì không gặp vấn đề lớn khi xin việc. Văn hóa quản lý ở mỗi công ty rất khác nhau nên khó chuyển giao trực tiếp, và tôi cho rằng kỹ năng có tính chuyển đổi cao nhất trong ngành này là cấu trúc bên trong của Linux
Ý nghĩ rằng với 5 năm kinh nghiệm thì có thể giải quyết hầu hết vấn đề cũng rất lạ. Đã làm 18 năm mà tôi vẫn còn nhiều điều chưa biết và nhiều điểm cần cải thiện, còn những kỹ sư xuất sắc có 40 năm kinh nghiệm vẫn tiếp tục học hỏi
Điều hay nhất khi làm quản lý là dành nhiều thời gian suy nghĩ về tương lai và có nhiều khả năng được bước vào “căn phòng đó” để nói chuyện với cấp C. Đồng thời, đó cũng là điều tệ nhất vì bạn sẽ thấy quá rõ các quyết định được hình thành như thế nào
Tôi đồng ý với những điểm bài gốc không thích, nhưng theo thời gian sẽ khá hơn. Tuy vậy, nếu là quản lý mới, có thể bạn vẫn chưa trải qua điểm rồi sẽ ghét nhất: ở nhiều công ty, tầng lớp quản lý cấp cao hành xử như các phe nhóm thời trung học, và các vấn đề hành vi của VP, cấp C, đôi khi cả director, dù nếu là nhân viên thường thì đã đủ mức bị sa thải, vẫn được dung thứ
Phần lớn kỹ sư phần mềm bị kẹt ở senior, đặc biệt là tại Google, nên việc tập trung ở L6 tự thân đã là tương đối đặc quyền. Thăng lên L6 không phải cực hiếm, nhưng cũng không phải đa số đều đạt được, còn L7 trở lên thì khó. Nếu bạn cảm thấy hầu hết đồng nghiệp đều tự nhiên đi tới đó, có thể bạn đã loại khỏi quan sát những người rời đi vì không được thăng chức, hoặc ít có cơ hội thân với những người ở cấp thấp hơn mình
Tôi đồng ý rằng con đường engineering manager không mở ra nhiều cánh cửa như người ta từng nghĩ, nhưng cơ hội thăng tiến của nó cũng không có vẻ hẹp hơn IC
Việc xây dựng từ 0 lên 1 gần như không liên quan gì đến quản lý kỹ thuật. Quan trọng nhất là khả năng viết code nhanh và nói chuyện thoải mái với khách hàng tiềm năng, mà cả hai đều không liên quan trực tiếp đến vai trò engineering manager. Cũng không có gì đảm bảo rằng bạn sẽ tuyển được người để quản lý
Về mặt cấu trúc, số vị trí quản lý ít hơn rất nhiều so với vị trí kỹ thuật, và ranh giới giữa lead engineer với quản lý tuyến đầu khá mờ theo cả hai chiều, nên tập ứng viên cạnh tranh thực tế cũng không nhỏ đi tương ứng
Nói là có thể chuyển đổi được nghĩa là đó là kỹ năng hữu ích cả bên ngoài bong bóng Big Tech. Có thể tiền tốt nên bạn không muốn ra ngoài, nhưng cũng nên biết rằng ngoài việc làm cho máy tính kêu bíp bíp, bạn còn có thể làm những việc khác
Ví dụ là ý nghĩ rằng khi engineering manager nói “cần kiểm thử nhiều hơn” thì sẽ được xem trọng hơn so với khi IC nói
Thật ra, khi tôi mới được thăng lên IC cấp staff, tôi cũng từng cảm thấy mình thiếu uy tín, nên có phần muốn chuyển sang quản lý vì nghĩ ẩn sau chức danh sẽ có ích. Thực tế là không cần như vậy, và hiện nay, với tư cách IC ở một công ty khác, các ý tưởng và phản hồi của tôi được tổ chức và đồng nghiệp xem xét nghiêm túc
Cơ chế mỗi nửa năm bắt buộc xếp hạng để chọn ra người hiệu suất thấp là một cách làm hỏng. Quản lý hiệu suất ở nhiều nơi có thực tế đáng buồn như vậy, nhưng đó không phải chân lý phổ quát rằng đã là quản lý thì nhất định phải làm thế. Những cuộc trò chuyện khó khăn về vấn đề hiệu suất thực sự là điều về mặt thống kê không thể tránh khỏi, nhưng cũng có những công ty nơi bạn không cần phải nói kiểu “nửa năm này mọi người trong nhóm đều làm tốt hơn bạn” hay “phải chọn một ai đó nên lần này là bạn”
Tôi thích giải quyết vấn đề và nhìn bức tranh lớn, thích tìm ra giải pháp để tháo gỡ trở ngại. Vai trò hợp nhất với tôi là “kiến trúc sư”, nhưng có vẻ chức danh đó đang dần biến mất. Dù vậy, sự thật là công việc đó vẫn cần thiết thì không thay đổi
Tôi cũng từng làm team lead/manager, Scrum Master, product manager; kỹ năng cần ở một manager giỏi rất khác với kỹ sư. Cốt lõi là mức độ dễ bị kích động thần kinh cực thấp, tức khả năng đưa ra quyết định tốt trong căng thẳng kéo dài, đồng thời duy trì vẻ ngoài bình tĩnh và lý trí
90% quản lý cấp dưới không có đặc tính này, và khi bị stress họ làm hỏng cả đội lẫn công ty. Nếu muốn trở thành manager, bạn phải đánh giá trung thực mình phản ứng thế nào với stress kéo dài. Những yếu tố tưởng chừng nhàm chán như bạn có trút giận lên người xung quanh không, có trốn tránh hoặc đờ ra không quyết định được không, có đổ lỗi cho người khác để giữ danh tiếng của mình không — đó mới là khác biệt thật sự giữa một manager hiệu quả và phần còn lại
Thường bao gồm những việc chẳng vui vẻ gì: lôi ra những vấn đề ai cũng né tránh, để mọi người tập thể than phiền về quyết định của mình, và tiếp tục tham gia dù đối phương disengage và đẩy mình ra xa
Với tôi, quản lý giống như công việc đòi hỏi toàn bộ số “thìa” mình có rồi vẫn đòi thêm. Tuy nhiên tôi nghĩ đây gần với vấn đề mức độ phù hợp với bản thân hơn là bản chất của quản lý. Theo các bài khảo sát trên Internet, mức dễ bị kích động thần kinh của tôi ở khoảng trung bình, nhưng tôi yếu ở việc dừng lại ở mức “đủ tốt”, và tôi cảm thấy phạm vi trách nhiệm mở rộng của quản lý tạo ra vấn đề về khả năng mở rộng mặt cảm xúc
Chìa khóa để giải quyết crunch và burnout có lẽ là tạo ra môi trường pháp lý để toàn bộ sinh kế của người lao động — sức khỏe, tiền thuê nhà, trả nợ học phí đại học công lập, v.v. — không chỉ phụ thuộc vào việc giữ được một công việc
Nếu là IC, bạn có thể phát triển sự nghiệp bằng cách học công nghệ hoặc domain mới, nhưng với manager, phát triển sự nghiệp ngày càng phụ thuộc vào sự trưởng thành, góc nhìn, sức bền cảm xúc — tức sự phát triển cá nhân. Có lẽ đó cũng là lý do sự quan tâm đến seniority và những thứ như thiền chánh niệm tăng lên cùng nhau
HN sẽ ghét điều này, nhưng dù tôi độc thân, tôi cũng tự hỏi liệu các bậc cha mẹ có trở thành manager tốt hơn không. Có thể vì họ ít có khả năng mất góc nhìn và bị stress vì những chuyện không quan trọng trong bức tranh lớn. Kỳ lạ là dường như tôi quản lý tốt nhất khi giữ được một bước lùi về mặt cảm xúc
Hóa ra về khí chất tôi khá nhạy cảm, nên cá nhân tôi lo rằng mình có thể không hợp về mặt bản chất với vai trò quản lý. Kiểu tính chất đôi khi đạo đức giả như “không phải điều khiển mà là tạo động lực” cũng khó chịu. Tôi chỉ muốn lang thang trong tổ chức để sửa vấn đề, đơn giản hóa quy trình, và thiết kế lại hệ thống làm việc
Tôi đã làm kỹ sư phần mềm 12 năm nhưng hoàn toàn không muốn trở thành manager. Tôi chỉ muốn tạo ra thứ gì đó, không muốn quản lý
Tôi làm việc gần với các manager và thấy công việc đó là gì, nhưng hoàn toàn không thấy hấp dẫn. Là senior engineer, lời nói của tôi cũng thường có ảnh hưởng, nhưng tôi thích việc không phải gánh trách nhiệm khổng lồ đi kèm với manager. Tôi không muốn tăng thêm stress trong đời
Có lẽ 30 năm sự nghiệp tới của tôi cũng sẽ ở vị trí như hiện tại
Vài năm trước tôi cũng tương tự. Sếp thích tôi, có nhiều quan hệ nên chia sẻ mọi thông tin, cho tôi ngồi vào các cuộc ra quyết định, hỏi ý kiến tôi về định hướng, và nói rằng nếu cần tôi có thể thay mặt ông ấy hoặc các manager khác phát biểu, ông ấy sẽ chống lưng phía sau
Giờ thì một cấu trúc quản lý hoàn toàn mới đã vào, rất top-down, cái tôi cao và không muốn tiếp nhận phản hồi. Các manager cấp dưới hoặc kỹ sư lên tiếng đều liên tục bị đẩy ra ngoài, và quyền tự chủ cũng như tiếng nói mà tôi từng có gần như biến mất
Rất nhiều thứ tôi tưởng là quyết định kỹ thuật cũng bị lấy mất. Dịch vụ tôi xây cần X, nên tôi tạo một giải pháp tự động hóa và nó hoạt động tốt; vài tháng sau tôi bị bảo rằng X có kế hoạch khác và tôi đã làm sai, rồi bị chỉ đạo xóa giải pháp hoàn toàn tự động đó và chuyển sang quy trình doanh nghiệp thủ công của đội khác. Công việc đó thường xuyên bị bỏ sót, làm giảm độ ổn định của dịch vụ của tôi
Tôi mừng vì mình không phải là manager phải đấu với những người này. Nếu thế, có lẽ giờ tôi đã mất việc và bị thay bằng bạn bè của họ. Tuy nhiên, ảnh hưởng của senior engineer có thể thay đổi rất lớn về dài hạn, ngay cả trong cùng công ty và cùng đội
Cũng có các vị trí kỹ thuật cao hơn không có hoặc có rất ít trách nhiệm quản lý. Senior principal engineer, architect, v.v.; tùy vào việc công ty đánh giá bạn có giá trị đến đâu
Trường hợp tốt nhất tôi từng thấy là một kỹ sư có bằng tiến sĩ và vài chục năm kinh nghiệm làm guru về nghiên cứu/kiến trúc, dùng nhiều Matlab, không có đội hay cấp dưới trực tiếp, và là “VP of technology” trong một công ty quy mô hàng trăm người
Điều khó không chỉ là bản thân việc học hay con người, mà là bối cảnh xung quanh nó. Khi có góc nhìn quản lý, bạn sẽ hiểu rất tốt mình đang xây cái gì và vì sao, tại sao công việc trông kém hiệu quả và đổ vỡ. Bạn cũng có insight về giải pháp và những bối cảnh không được truyền đạt đúng cách
Hiện tại tôi là lập trình viên senior và đang phỏng vấn cho vị trí team lead ở một startup. Tôi tự cho rằng năng lực kỹ thuật của mình khá cao, nhưng điều khiến tôi bức bối nhất hằng ngày lại là các vấn đề liên quan đến teamwork
Thiếu niềm tin, các thành viên không muốn nói chuyện với nhau, những senior khác làm việc dưới chuẩn rồi vẫn cho qua, thiếu mục tiêu đội nhóm và tầm nhìn sản phẩm rõ ràng, thiếu đồng thuận về các thực hành engineering chung. Nếu trở thành people manager, dù tốt hay xấu thì những vấn đề này sẽ nằm trong phạm vi tôi phải gây ảnh hưởng và chịu trách nhiệm
Nhưng khi thực sự trở thành team lead, tôi nhận ra phạm vi mình có thể tạo ảnh hưởng nhỏ hơn tưởng tượng rất nhiều. Có nhiều người, kể cả sếp của tôi, muốn trực tiếp vận hành mọi thứ, còn tôi thì được kỳ vọng chỉ đóng dấu thông qua
Ngược lại, tôi còn rơi vào thế khó hơn vì phải thay mặt team nói ra những điều mọi người sợ nói. Chẳng hạn như “để story sẵn sàng thì API phải được định nghĩa trước”. QA làm sao có thể tạo automated test song song khi còn chưa biết cần test cái gì
Scrum Master, product owner, manager, architect thì mỗi ngày nói điều phù hợp với họ như thể đó là chân lý hiển nhiên, rồi hôm sau lại phàn nàn vì sao test bị chậm
Rốt cuộc mọi chuyện trượt sang chính trị về việc ai phải chịu trách nhiệm cho tình trạng hiện tại, còn những người chọn hướng đi và chiến lược đó thì quan hệ rộng và rất giỏi đổ trách nhiệm
Trước đây, tôi từng đứng trong văn phòng khi sếp lúc đó vừa gọi điện thành công để nhờ một người ở bộ phận khác làm việc
Sếp ngước nhìn tôi từ bàn làm việc, mỉm cười nhẹ và nói với giọng hơi ngơ ngác: “Chức danh đổi từ ‘Specialist’ sang ‘Manager’ đâu có làm tôi xinh đẹp hơn, nhưng rõ ràng nó giúp việc được thực hiện”. Đó là khoảnh khắc sức mạnh của chức danh thực sự phát huy tác dụng
Manager dễ bị phớt lờ nếu không đe dọa hậu quả thực tế, mà lá bài đó thì phải dùng thật tiết kiệm
Vài năm trước tôi bắt đầu làm engineering manager với vai trò CTO của một startup nhỏ, và cuộc sống thay đổi rất nhiều. Tôi có cùng cảm nhận về mọi điểm mà bài gốc nói là yêu và ghét
Lời khuyên bổ sung là hãy thật sự thiền. Trước khi đưa ra những quyết định quan trọng, có sức ảnh hưởng và có thể gây hại cho người khác, bạn cần ngồi yên đủ lâu đến mức bộ não như tắt đi
Ban đầu, nó trở thành một kiểu quan hệ thiên tài giữa cha mẹ và con cái. Bạn phải chấp nhận con người của họ và hiểu cách họ làm việc. Bạn càng đặt nhiều kiểm soát thì quyền kiểm soát thực sự càng giảm. Họ sẽ tìm cách đi vòng qua và chống lại bộ máy quan liêu không cần thiết, và nói thật là tôi cũng sẽ làm vậy
Lời khuyên thứ hai là hãy luôn hành động như thể ngày mai mình sẽ rời đi. Khi đó team và đồng nghiệp sẽ được chuẩn bị, và lối sống của chính bạn cũng tốt hơn
Họ trưởng thành rất nhanh, và việc xác nhận rằng tổ chức vẫn vận hành khi không có tôi đem lại cảm giác yên tâm kỳ lạ. Đồng thời, vì họ có vẻ phát triển nhanh hơn khi tôi vắng mặt, tôi cũng tự hỏi liệu đó có phải tín hiệu rằng mình đang làm sai điều gì không
Có những ngày tôi cảm thấy mình đang quản lý gia đình bằng các kỹ năng học được ở nơi làm việc
Nền tảng của tôi thì ngược lại. Tôi là một software engineer bình thường, nhưng khả năng làm việc với con người khá tốt
Tôi có đủ kinh nghiệm để biết việc gì mất thời gian, phần nào của hệ thống quan trọng hơn. Có vài senior engineer mà tôi thực sự lắng nghe, trao rất nhiều niềm tin và quyền hạn
Quyết định thiết kế không phải do tôi đưa ra mà do họ đưa ra, còn tôi góp ý. Nếu thất bại, tôi chịu trách nhiệm và học hỏi; nếu thành công, tôi quy công lao cho team. Nói khiêm tốn thì tôi nghĩ vai trò manager trước hết là công việc về con người
Chỉ có một lý do duy nhất khiến tôi muốn chuyển từ vai trò coder/IC sang nhánh quản lý: phỏng vấn whiteboard mỗi lần đổi việc
Hầu như lần nào cũng phải chuẩn bị lại từ đầu đến mức đau khổ, và tuy cũng có những vai trò không có quy trình đó nhưng rất hiếm. Mỗi khi nghĩ đến việc chuẩn bị ấy, tôi thường chỉ ở lại công ty hiện tại với suy nghĩ “ôi, làm ơn, lại nữa à?”
Một engineering manager tồi có thể gây hại lớn hơn nhiều so với một IC tồi. Tôi nghĩ câu chuyện này chưa được nói đến đủ thường xuyên
Trong suốt sự nghiệp dài, tôi từng gặp 1 manager xuất sắc, vài manager ổn, và rất nhiều manager tệ. Manager tệ khiến công việc khó khăn hơn rất nhiều, đôi khi còn biến nó thành hoàn toàn khốn khổ
Sự kết hợp giữa engineering manager tồi và junior IC có thể đặc biệt xấu. Khi lớn tuổi hơn, tôi hiểu rằng mình có thể làm việc với manager tồi và cố đẩy tình hình sang chỗ tốt hơn, hoặc rời đi nếu thấy không còn hy vọng
Dạo này trách nhiệm quản lý của tôi tăng lên nên tôi muốn biết
Có một thời tôi từng dẫn dắt một team gồm các IC trình độ tiến sĩ. Tôi phải tìm việc cho họ, chặn các kẻ mộng mơ, và giữ họ hạnh phúc
Không đùa đâu, tôi từng nói chuyện riêng với từng người suốt sáu tiếng một lần, đóng vai cố vấn nghề nghiệp và người an ủi. Tôi không ngờ những việc như vậy lại trở thành công việc của mình
Một thành viên trong team đã giúp giành được hai hợp đồng riêng biệt trị giá 1 tỷ USD, nên thời gian của tôi coi như đã được đền đáp