Trong quá trình làm việc trong lĩnh vực phần mềm, mình quan sát được một pattern lặp đi lặp lại nhưng rất ít người để ý — khi một Engineer chuyển sang vai trò Manager. Phần lớn họ vật lộn không phải vì thiếu năng lực kỹ thuật, mà vì còn nghĩ như Engineer.
Khi bạn switch sang một vai trò mới, hãy tự hỏi mình đã có kỹ năng gì, đang thiếu những kỹ năng gì cần có để làm tốt vị trí đó.
Dưới đây là một số kinh nghiệm mình quan sát và đúc kết được — nghe có vẻ ngược đời, nhưng khi qua làm Manager, nó lại đi ngược với bản năng của một Engineer giỏi.
Table of contents
Open Table of contents
- Some terms
- 1. EM là lateral move, không phải promotion
- 2. People first — team trước, mình sau
- 3. Trao việc đúng cách — buông tay nhưng không buông trách nhiệm
- 4. Gánh kết quả trong tình huống mơ hồ — Extreme Ownership
- 5. Thời gian là tài nguyên khan hiếm nhất — Eisenhower Matrix
- 6. Học liên tục — Thừa nhận giới hạn
- Tổng kết
Some terms
- IC (individual contributor) — Engineer đóng góp cá nhân, chỉ làm sản phẩm chứ không quản lý người. Tức Software Engineer thuần.
- EM (Engineering Manager) — quản lý kỹ thuật, chịu trách nhiệm cho cả team Engineer và việc team đó được giao.
- SME (subject matter expert) — chuyên gia mảng/lĩnh vực cụ thể. Người trong team hiểu sâu nhất một khu vực kỹ thuật nào đó.
- 1:1 — buổi nói chuyện riêng giữa hai người (Manager với một thành viên team). Thường lặp lại hàng tuần hoặc hai tuần một lần.
- P0/P1 — mức ưu tiên bug. P0 là cao nhất (đang ảnh hưởng production, phải fix gấp), P1 ngay sau đó.
- Blameless — văn hóa “không truy người để đổ lỗi” khi xảy ra sự cố. Mục tiêu là học từ lỗi, không tìm vật thế thân.
1. EM là lateral move, không phải promotion
Một Senior Engineer thông báo trong team chat “kể từ tuần sau mình chuyển sang vai trò Manager” — phản ứng phổ biến là “chúc mừng, lên chức à?”. Câu trả lời thực ra: không phải lên chức. Là đổi nghề ngang hàng.
Google, Microsoft, Amazon và phần lớn công ty tech lớn có hai thang nghề song song, cùng cấp bậc:
- Track IC: Engineer → Senior → Staff → Principal → Distinguished
- Track EM: EM → Senior EM → Director → VP
Một Principal Engineer (IC) có thể cấp cao hơn cả một Senior EM. Và đây là cửa hai chiều — bạn có thể quay về IC nếu phát hiện không hợp, miễn là kỹ năng code của bạn vẫn còn ngon.
Khác biệt cốt lõi không phải “EM giỏi hơn IC”, mà ở chỗ thành công được đo lường hoàn toàn khác:
| Khía cạnh | IC (individual contributor) | EM (Engineering Manager) |
|---|---|---|
| Ưu tiên | Output cá nhân là chính | Output cả team là chính |
| Thời gian | Phần lớn là code và ship | Phần lớn là họp, mentor, làm chiến lược |
| Đo thành công | Cụ thể, đo được cuối tuần (PR, ship) | Sức khỏe team, retention, velocity dài hạn |
| Vai trò | Doer / creator (người làm) | Coach / enabler (người trao) |
| Tầm nhìn | Sát mặt đất — task hôm nay | 50,000 mét — nhìn cả tổ chức, hàng quý/hàng năm |
Hệ quả: bạn sẽ có những tuần cảm thấy mình chẳng làm gì cả. Không PR nào merge, không feature nào ship — chỉ họp, 1:1, gỡ blocker. Nhiều EM mới phản xạ nhảy lại vào code để “cảm thấy năng suất”. Đó chính là dấu hiệu họ đang làm sai vai trò.
2. People first — team trước, mình sau
Tư duy này nghe sáo rỗng, nhưng nó định nghĩa gần như mọi thứ một EM làm.
Khi còn là IC, bạn tối ưu thời gian của mình để code hiệu quả. Khi thành EM, bạn tối ưu thời gian của team. Cụ thể: bạn dành thời gian không phải để giải quyết bug, mà để gỡ điểm tắc cho người trong team giải quyết bug. Bạn không tự ra quyết định kỹ thuật, mà tạo điều kiện để SME trong team ra quyết định. Bạn không tự đề xuất ý tưởng với leadership, mà đại diện cho ý tưởng của team.
Tháng đầu Engineer X làm EM (Engineering Manager), Engineer Y — Engineer mới trong team — vô tình đẩy một bug lên production. Bản năng đầu tiên của Engineer X (từ thời còn là Engineer giỏi) là tìm người chịu trách nhiệm: triệu hồi Engineer Y lên hỏi, có thể nhắn QA team “tại sao không bắt được?”. Nếu Engineer X đi theo bản năng đó, bug sẽ được fix nhanh — nhưng từ tuần đó trở đi, mỗi lần ai trong team định ship một thay đổi rủi ro, họ lại tự hỏi “nếu hỏng ai sẽ bị réo tên?” và bắt đầu trì hoãn, hoặc che chắn quá kỹ. Đó là culture of fear — âm thầm giết velocity của team chậm hơn nhưng chắc chắn hơn bất kỳ bug nào.
Engineer X dừng lại kịp, chọn cách khác. Anh ngồi lại cùng team fix bug, nhắc cả team rằng lỗi là điều bình thường trong môi trường ship nhanh. Sau khi production ổn, anh nói chuyện riêng với Engineer Y — không phải để mắng, mà để cùng tìm xem có thể đặt rào chắn nào để lần sau không lặp lại. Sau đó anh mở một cuộc họp team chia sẻ rằng “lỗi là OK — miễn là học được từ đó”, và khuyến khích Engineer Y nhìn sự việc như cơ hội học. Bug được fix, team biết Engineer X không truy người, lòng tin tăng.
Đoạn này nghe đơn giản, nhưng câu hỏi quan trọng để tự kiểm là: bản năng đầu tiên của bạn khi xảy ra sự cố là gì? Là tìm người chịu trách nhiệm, hay tìm cơ hội để team học? Nếu bản năng còn nghiêng về “truy người”, bạn chưa hoàn tất dịch chuyển tư duy này.
3. Trao việc đúng cách — buông tay nhưng không buông trách nhiệm
Tư duy này nghe đơn giản, nhưng nó là cái khó nhất mà gần như mọi EM mới phải vật lộn.
Khi còn là IC, gặp việc khó bạn nghĩ: “để tôi tự làm, vì tôi làm nhanh nhất”. Khi thành EM, suy nghĩ đó chính là điểm tắc của cả team — bạn càng giỏi, càng tự gánh nhiều; team càng phụ thuộc, càng không lớn được.
Engineer X vừa lên EM được tuần thứ hai. Anh có một task tích hợp API quan trọng. Đáng lẽ giao cho Engineer Y (junior trong team đang cần nâng cấp kĩ năng), nhưng Engineer X tính nhanh: “giao Engineer Y thì phải dạy cả buổi, rồi review, rồi sửa; tôi tự làm 2 ngày là xong.” Engineer X tự làm. Tuần sau lại có task tương tự. Lại tự làm. Ba tháng sau, Engineer X kiệt sức vì gánh việc IC + việc EM cùng lúc; Engineer Y vẫn ở đúng cấp độ junior; team vẫn phụ thuộc vào Engineer X cho mọi quyết định kỹ thuật.
Tháng thứ tư, Engineer X nhận ra mình sai và thử cách khác. Có task khó tương tự, anh dành 3 ngày ngồi với Engineer Y giải thích bối cảnh, hướng tiếp cận, các trường hợp biên. Thêm 1 ngày kèm cặp khi Engineer Y làm task đầu tiên. Mất 4 ngày cho task đầu — nhiều hơn 2 ngày nếu Engineer X tự làm. Nhưng từ task thứ hai trở đi, Engineer Y tự làm, không phải Engineer X. Sau 10 task tương tự, Engineer X chỉ tốn đúng 4 ngày đầu; 9 task còn lại chạy mà không cần anh động vào. Engineer X tiết kiệm 16 ngày so với phiên bản cũ của chính mình — chưa kể Engineer Y giờ đã lên được mid-level, có thể tự mentor người mới.
Phép tính này gọn nhưng đánh trúng cái bẫy lớn nhất: cảm giác “tự làm nhanh hơn” chỉ đúng cho task này, hôm nay. Với chuỗi việc dài hạn, tự làm luôn là lựa chọn tệ nhất.
Nhưng “giao việc” không phải chỉ là đẩy việc đi. Có ba kiểu giao việc rất dễ nhầm lẫn — và Engineer X giai đoạn đầu, trước khi học, thực ra đã chuyển từ “tự làm” sang kiểu đầu (kiểu sai nhất):
| Khía cạnh | Allocation (phân công) | Delegation (ủy thác) | Substitution (thay thế) |
|---|---|---|---|
| Mục đích | Việc được làm xong, hết | Việc xong + người làm học skill mới | Người khác thay bạn hoàn toàn |
| Cách làm | ”Giao rồi quên” | Coaching liên tục, check-in, feedback | Bàn giao toàn bộ |
| Thẩm quyền | Trao toàn bộ | Trao quyền vừa đủ; bạn vẫn chịu | Trao hết, không còn dính |
| Cơ hội dài hạn | Không quan tâm | Trọng tâm — phát triển nghề người làm | Hoàn toàn chuyển giao |
Khi Engineer X giai đoạn đầu nhắn Engineer Y “em làm task này nhé, deadline thứ 6” rồi biến mất, đó là allocation — và nó vô tình gửi tín hiệu “việc này tôi không quan tâm bạn học được gì, chỉ cần xong.” Engineer X sau khi học bài học dành thời gian check-in giữa kỳ, phản hồi từng bước, rút kinh nghiệm cuối kỳ — đó là delegation đúng nghĩa. Và quan trọng nhất: Engineer X vẫn là người chịu trách nhiệm cuối cùng với kết quả. Engineer Y là người làm (responsible); Engineer X là người đứng trước tổ chức nếu task thất bại (accountable).
Sau khi đã trao quyền, kỷ luật lớn nhất là không xen vào. Mỗi lần Engineer X “ghé qua sửa nhanh” để Engineer Y khỏi bí, anh vừa phá vỡ mạch làm việc của Engineer Y, vừa gửi thông điệp “tôi không tin bạn làm được”. Engineer X học cách chấp nhận Engineer Y đi đường vòng dài hơn — vì anh biết qua mỗi đường vòng, Engineer Y tự khám phá được một thứ mà anh không dạy được bằng lời. Một dấu hiệu rất rõ team đã chuyển từ phụ thuộc sang tự chủ: câu hỏi của họ từ “em nên làm thế nào?” chuyển dần sang “đây là cách em đang nghĩ, anh thấy sao?” — bạn không còn là người đưa phương án nữa, mà là người xác nhận.
Câu hỏi tự kiểm: tuần vừa rồi, bạn giao bao nhiêu việc cho team theo kiểu “giao rồi quên”, và bao nhiêu việc bạn thật sự dành thời gian hướng dẫn? Nếu tỷ lệ là 9:1, bạn đang làm Engineer X giai đoạn đầu — chưa học bài học.
4. Gánh kết quả trong tình huống mơ hồ — Extreme Ownership
Hình dung một tình huống điển hình. Bạn vừa được giao một team. Tuần thứ ba, có sự cố production. Bạn không phải người viết đoạn code đó, không phải người duyệt PR đó. Bạn vào điều tra, phát hiện một Engineer trong team đã bỏ qua code review để ship gấp một bản sửa khác — và chính bản patch đó kéo theo cái sự cố hôm nay.
Phản ứng đầu tiên của bạn là gì?
- (a) Báo lên sếp ngay: “Engineer Z đã bỏ qua quy trình review, đó là nguyên nhân gốc.”
- (b) Triệu hồi Engineer Z họp, yêu cầu giải thích trước cả team.
- (c) Nhận với sếp: “Quy trình team mình đang có lỗ hổng. Tôi sẽ tìm hiểu và sửa.” Rồi vào team không truy người, mà cùng nhau xem tại sao quy trình lại có lỗ hổng để bỏ qua được — và dựng rào chắn kỹ thuật để lần sau không ai bỏ qua được, dù muốn.
Phương án (c) là extreme ownership — chịu trách nhiệm không chỉ cho công việc của mình, mà cho mọi khía cạnh ảnh hưởng đến sứ mệnh. Trách nhiệm có hiệu ứng lan tỏa, kéo dài đến từng bước, từng giai đoạn.
Áp vào vai trò EM, tư duy này hiện ra trong những khoảnh khắc cụ thể:
Khi dự án trễ deadline, bạn không nói “team mình chưa đủ skill” — bạn nói “tôi chưa build được team đủ skill, hoặc chưa đào tạo đủ; đó là việc tôi sẽ sửa.” Khi team từ phòng khác không chịu phối hợp, bạn không nói “team kia khó làm việc” — bạn hỏi “tôi đã thiết lập quan hệ đó đúng cách chưa?” Khi sếp ra quyết định ngược ý team, bạn không xuống team than “sếp bắt thế” — bạn về team giải thích lý do và đứng sau quyết định đó. Đó là gánh.
Đối lập là một cái bẫy khác mà EM mới hay rơi vào: chủ nghĩa hoàn hảo — chờ đến khi có “đủ data” mới quyết. Trong vai trò Manager, gần như không bao giờ có đủ data. Đợi đủ là không quyết. Đây là analysis paralysis — tê liệt vì phân tích quá kỹ. Bạn quyết với 60-70% thông tin, nhận sai nếu sai, sửa nhanh.
Để extreme ownership có thể tồn tại, team phải có một thứ làm nền: văn hóa blameless — không truy người. Cụ thể qua mô hình blameless postmortem (phân tích sự cố không đổ lỗi): khi xảy ra sự cố, người tham gia review không có quyền nêu tên cá nhân làm vật thế thân, chỉ được mổ xẻ hệ thống và quy trình. Nghe có vẻ mềm, nhưng đó là điều kiện cần để Engineer dám báo lỗi sớm — và là điều kiện cần để EM dám gánh.
Hai mặt của cùng một đồng xu: bạn dám gánh kết quả vì team được bảo vệ khỏi việc đổ lỗi, và team dám báo lỗi sớm vì biết EM sẽ gánh chứ không đẩy.
5. Thời gian là tài nguyên khan hiếm nhất — Eisenhower Matrix
Hết ngày làm việc, bạn nhìn lại danh sách to-do và phát hiện ra đa số việc quan trọng đã không được động đến — vì cả ngày chìm trong các “cuộc họp gấp” của người khác và mấy chục ping trên Slack. Đây là cảnh phổ biến nhất khi Engineer trở thành EM. Lịch dày kín tưởng là dấu hiệu “đang bận đóng góp” — thực ra là dấu hiệu mất kiểm soát thời gian.
Lý do nằm ở một khái niệm rất hay: maker’s schedule vs manager’s schedule (lịch của người làm vs lịch của người quản lý). Engineer vận hành trên maker’s schedule — cần những khung thời gian dài, liền mạch, không bị ngắt, để chìm vào tập trung sâu. EM vận hành trên manager’s schedule — ngày bị chia thành ô 30 phút, đầy cuộc họp, đầy chuyển ngữ cảnh. Mà ngày vẫn chỉ có 24 giờ; nếu không có hệ thống, mọi giờ đều biến mất vào hư không.
Công cụ kinh điển nhất để lấy lại kiểm soát là Eisenhower Matrix — Eisenhower có câu nổi tiếng: “Tôi có hai loại vấn đề: cái gấp và cái quan trọng. Cái gấp thì không quan trọng, và cái quan trọng thì chẳng bao giờ gấp.”
Ma trận chia mọi việc vào 4 ô, dựa trên hai trục gấp (cần làm ngay không) và quan trọng (có ảnh hưởng đến mục tiêu dài hạn không):
| Gấp | Không gấp | |
|---|---|---|
| Quan trọng | Q1 — LÀM (làm ngay) | Q2 — XẾP LỊCH (lên kế hoạch) |
| Không quan trọng | Q3 — GIAO ĐI (delegate) | Q4 — XÓA (loại bỏ) |
Ví dụ từng ô — đọc qua bạn sẽ nhận ra ngay ô nào mình đang sống nhiều nhất:
- Q1 — Làm ngay: 1:1 với team, bug P0/P1, sự cố production, đồng bộ ưu tiên dự án quan trọng.
- Q2 — Xếp lịch: tổ chức team offsite, lên kế hoạch cải thiện on-call dài hạn, xây pipeline tuyển dụng.
- Q3 — Giao đi: họp review vận hành, bàn giao on-call, tổng hợp sprint report.
- Q4 — Xóa: lướt mạng xã hội, đọc tin về dự án của tổ chức khác không liên quan đến team mình.
Mấu chốt rất gọn: EM thành công sống chủ yếu ở Q2 — quan trọng nhưng không gấp. Đó là vùng của chiến lược dài hạn, tuyển dụng, kiến trúc, xây dựng quy trình. EM thất bại sống chủ yếu ở Q1 (suốt ngày chữa cháy) và Q3 (suốt ngày phản ứng với “việc gấp” của người khác).
Q3 là cái bẫy nguy hiểm đặc biệt vì nó ngụy trang thành công việc. Một yêu cầu đến từ bên liên quan, có deadline rõ, có vẻ phải làm — nhưng nhìn kỹ thì đó là việc gấp của họ, không quan trọng với sứ mệnh của team bạn. Cứ làm hết Q3, bạn không bao giờ có thời gian cho Q2. Câu hỏi phản xạ cần đặt cho mọi việc rơi vào Q3 là: “có ai khác trong team đang cần nâng cấp kĩ năng ở mảng này không?” Nếu có — chính là cơ hội delegate.
Sống được ở Q2 không tự nhiên đến. Có ba kỷ luật cần xây cùng lúc.
Đầu tiên là dọn lịch. Mỗi cuộc họp trên lịch, hỏi thẳng: “mình có thật sự cần ở đây không?” Nếu chỉ để nghe cập nhật, hỏi offline hoặc xin biên bản async là đủ. Cái lịch dày kín không phải dấu hiệu của bận quan trọng — nó là dấu hiệu thiếu kỷ luật từ chối.
Tiếp theo là học cách nói không. Và “không” không nhất thiết là từ chối thẳng. Phiên bản hay hơn là đề xuất ngược: “Để làm việc mới này, mình cần bỏ hoặc dời lại việc kia. Bạn muốn ưu tiên cái nào?” Câu đó dồn người yêu cầu tự đánh giá lại ưu tiên — và thường họ sẽ tự rút yêu cầu. Đặt ranh giới cho team không phải là không hợp tác; đó là điều sếp giỏi trân trọng. Bạn không bảo vệ thời gian team, không ai làm thay.
Cuối cùng là mặc định bất đồng bộ (async by default). Slack/email cho mọi việc không gấp; họp đồng bộ chỉ dành cho việc thật sự cấp bách về thời gian hoặc cần đồng thuận tức thời. Mỗi lần chuyển ngữ cảnh tốn 15-25 phút phục hồi — nghĩa là 10 lần bị ngắt một ngày sẽ ăn mất 2-4 giờ làm việc thật. Bảo vệ khung thời gian tập trung của bạn và của team là một dạng tôn trọng năng suất tối thiểu.
Ba kỷ luật này — dọn lịch, nói không, làm async — không phải kỹ thuật, mà là dịch chuyển tư duy. Người chưa dịch chuyển luôn cảm thấy “tôi quá bận để áp dụng những thứ này”. Đó chính là dấu hiệu họ cần dịch chuyển nhất.
6. Học liên tục — Thừa nhận giới hạn
Tư duy cuối là một câu rất đơn giản nhưng phản trực giác: EM giỏi không phải người biết hết, mà là người biết mình không biết gì.
Là Engineer, danh tính của bạn gắn với việc “biết câu trả lời”. Là EM, danh tính của bạn dịch sang việc “biết cách tìm ra câu trả lời thông qua team”.
Hình dung tình huống thường gặp. Engineer Y hỏi Engineer X về việc nên chọn caching in-memory hay Amazon ElastiCache (một dịch vụ cache của AWS) cho ứng dụng. Engineer X không biết câu trả lời. Có hai phản ứng phổ biến:
Phản ứng (a) — thừa nhận và tạo điều kiện: Engineer X nói thẳng “anh chưa rõ chỗ này”, gợi ý một khóa học online liên quan, kết nối Engineer Y với tech lead của một team khác có kinh nghiệm trong mảng đó, và đề nghị Engineer Y quay lại chia sẻ với anh sau khi đã học và quyết định.
Phản ứng (b) — né tránh: Engineer X chuyển Engineer Y thẳng đến tech lead mà không hiểu vấn đề kỹ thuật là gì, không theo dõi, không học gì từ tình huống.
Hai phản ứng nghe thoạt qua giống nhau (cả hai đều không tự trả lời), nhưng khác hẳn về chất. (a) là thừa nhận và tạo điều kiện. (b) là né. Học sinh giỏi nhất trong lớp là người chịu giơ tay nói “em không hiểu chỗ này”. EM giỏi nhất là người chịu nói “tôi không rõ chỗ này, để tôi tìm hiểu cùng anh em”.
Hai thói quen rất gọn để duy trì tư duy này:
“See one, do one, teach one” — học theo mô hình y khoa: quan sát người làm trước, tự làm, dạy lại người khác. Đến khi dạy được, mới thật sự hiểu. Áp vào hành trình EM: bạn quan sát một EM khác (see), tự thử trong một dự án vươn sức (do), rồi mentor người mới (teach). Vòng quay này không bao giờ kết thúc.
Có cả mentor lẫn mentee cùng lúc — mentor ở ngoài tổ chức để có góc nhìn ngoài và tránh thiên kiến nội bộ; mentee bên trong để truyền lại những gì mình mới học. Đó là vòng tròn duy trì tư duy phát triển: cứ nhận từ trên xuống và đẩy xuống dưới, bản thân ở giữa luôn ở trạng thái học và truyền.
Tổng kết
Sáu tư duy trên không phải danh sách kiểm tra cho một EM giỏi. Chúng là sự dịch chuyển tư duy — và mỗi dịch chuyển đều phản trực giác với bản năng của một Engineer giỏi:
| Tư duy trước (IC) | Tư duy sau (EM) |
|---|---|
| Lên làm sếp là thăng tiến | Đó là đổi nghề ngang hàng |
| Tôi tối ưu kết quả của tôi | Tôi tối ưu kết quả của team |
| Vấn đề khó → tôi tự làm | Vấn đề khó → tôi hướng dẫn người khác làm |
| Không quyết khi chưa đủ data | Quyết với 60-70% data, gánh kết quả, sửa nhanh |
| Thời gian của tôi tự sắp xếp | Thời gian là tài nguyên khan hiếm nhất — cần hệ thống |
| Tôi biết câu trả lời là điểm mạnh | Tôi biết cách tìm câu trả lời là điểm mạnh |
Điểm quan trọng nhất: không phải Engineer giỏi nào cũng nên làm EM, và không phải Engineer “thường thường” nào cũng không thể làm EM giỏi. Hai bộ kỹ năng chồng lấn ở phần mentoring và kỹ thuật, nhưng tách hẳn ở phần con người. Và “đặt con người lên đầu” là tính cách hoặc bạn có sẵn, hoặc không có — rất khó đào tạo từ con số 0.
Nếu sau khi đọc 6 tư duy trên, bạn cảm thấy chúng tự nhiên với mình — chào mừng đến với con đường EM. Nếu bạn cảm thấy chúng phản bản năng — đó cũng là một câu trả lời quý giá. Ở lại track IC không phải bị giáng cấp. Track IC ở các công ty tech hiện đại có thể đi đến Principal hoặc Distinguished Engineer, và đó là một con đường có sức nặng và sức ảnh hưởng không kém gì track EM.
Chọn vì mình hiểu những gì đang và sẽ xảy ra, đừng chọn theo quán tính.