Quản lý kỹ thuậtEngineering Manager19 Th7, 2026Jul 19, 202628 phút đọc19 min read

Giới thiệu về Engineering ManagementIntroduction to Engineering Management

Thuộc bộ kiến thức Engineering Manager Roadmap.

Tổng quan

Engineering management thường bị mô tả một cách sai lệch là “chuyện xảy ra với một senior engineer khi họ ngừng viết code.” Cách mô tả này tồn tại dai dẳng vì nó đúng một nửa nhưng lại gây hiểu lầm toàn bộ. Đúng là phần lớn engineering manager (EM) xuất thân từ nền tảng individual contributor (IC) vững chắc, và đúng là nhiều EM viết ít code production hơn trước. Nhưng bản thân công việc này không phải là một phiên bản “kém hơn” của kỹ thuật — nó là một ngành nghề khác, chỉ là ngành nghề đó đòi hỏi sự am hiểu kỹ thuật như một điều kiện tiên quyết.

Đầu ra thực sự của một EM không phải là code. Đó là một team có thể ship đúng thứ cần ship, một cách bền vững, với những con người đang phát triển và muốn ở lại. Đầu ra đó được tạo ra thông qua ba đòn bẩy đan xen với nhau:

Con người (People) — tuyển dụng, coaching, feedback, quản lý hiệu suất, phát triển sự nghiệp, và trạng thái cảm xúc/động lực hằng ngày của từng người trong team.
Quy trình (Process) — cách công việc được lên kế hoạch, ước lượng, giao tiếp và triển khai; cách chất lượng được đảm bảo; cách xử lý sự cố; cách team học hỏi từ cả thành công lẫn thất bại.
Định hướng kỹ thuật (Technical direction) — khả năng đánh giá kiến trúc, quản lý rủi ro kỹ thuật, và khả năng đặt ra một tiêu chuẩn chất lượng kỹ thuật mà không nhất thiết phải tự tay viết ra thứ đáp ứng tiêu chuẩn đó.

Không cái nào trong ba đòn bẩy này là tùy chọn, và cũng không cái nào là “công việc thật sự” trong khi hai cái kia chỉ là phụ. Một manager chỉ chăm chăm vào 1:1 mà không bao giờ động đến kiến trúc thì sớm muộn cũng sẽ đứng đầu một team ship ra một mớ hỗn độn. Một manager chỉ soi kiến trúc mà không bao giờ đưa feedback thì sớm muộn cũng sẽ mất những người giỏi nhất. Một manager ám ảnh với quy trình mà bỏ qua cả con người lẫn kỹ thuật sẽ xây nên một bộ máy quan liêu mà chẳng ai muốn làm việc trong đó. Công việc EM nằm ở giao điểm của cả ba, và phần lớn kỹ năng thường trực của một EM là quyết định, ngay tại thời điểm đó, đòn bẩy nào trong ba đòn bẩy này đang cần sự chú ý của mình.

Bài viết này là điểm khởi đầu cho toàn bộ knowledge base về chủ đề này. Nó định nghĩa công việc thực sự là gì, khác với các vai trò lân cận (tech lead, IC) ra sao, cần nền tảng kỹ thuật nào, điều gì thay đổi khi bạn chuyển sang vai trò này, và các chủ đề tiếp theo trong roadmap này liên kết với nhau như thế nào.

Kiến thức nền tảng

Công việc không phải là “senior engineer cộng thêm admin”

Mô hình tư duy “senior engineer cộng thêm admin” thất bại vì nó giả định rằng khả năng đánh giá kỹ thuật của manager vẫn được áp dụng theo cách giống hệt như khi còn là IC — tự tay viết đoạn code quan trọng, tự tay review từng pull request, tự tay đưa ra mọi quyết định thiết kế — chỉ là có thêm meeting và giấy tờ chồng lên trên. Trên thực tế, ngay khi bạn chịu trách nhiệm cho khối lượng công việc vượt quá những gì bản thân có thể tự tay tạo ra hoặc tự tay kiểm tra, khả năng đánh giá kỹ thuật của bạn buộc phải thay đổi hình dạng. Thay vì áp dụng trực tiếp lên sản phẩm (code, thiết kế, tài liệu), nó được áp dụng gián tiếp, thông qua những con người và hệ thống tạo ra các sản phẩm đó: bạn tuyển ai, bạn thiết lập tiêu chuẩn như thế nào, bạn chọn review kỹ cái gì và giao phó (delegate) cái gì, bạn đặt câu hỏi gì trong một buổi design review, và bạn xây dựng văn hóa postmortem như thế nào sau khi có sự cố xảy ra.

Đây chính là sự chuyển dịch tư duy trung tâm của engineering management: từ tự làm việc sang tạo điều kiện cho việc được làm (from doing the work to enabling the work). Đây không phải là sự giảm sút vai trò kỹ thuật — những EM giỏi vẫn giữ được sự sắc bén kỹ thuật trong nhiều năm — mà là sự thay đổi về cơ chế mà qua đó khả năng đánh giá kỹ thuật ấy chạm được đến codebase. Một cách diễn đạt hữu ích: công việc của một IC là trực tiếp tạo ra kết quả tốt; công việc của một EM là xây dựng và vận hành một hệ thống (con người, chuẩn mực, quy trình) có thể liên tục tạo ra kết quả tốt mà không cần EM tự tay động vào từng mảnh của nó.

EM vs Tech Lead vs IC

Một nguồn gây hiểu lầm phổ biến — nhất là với các engineer đang cân nhắc chuyển hướng, và với các tổ chức đang thiết kế career ladder — là coi “IC → Tech Lead → EM” như một hệ thống cấp bậc nghiêm ngặt, trong đó mỗi bước là “senior hơn” và “trách nhiệm hơn” bước trước. Cách hiểu này gây ra thiệt hại thực sự: nó đẩy những người sẽ hạnh phúc và hiệu quả hơn khi tiếp tục làm kỹ thuật vào con đường quản lý, và nó đánh giá thấp mức độ senior và độ khó của một vai trò principal-level IC. Cách hiểu lành mạnh hơn là coi đây là ba công việc khác nhau, được đo lường thành công theo ba định nghĩa khác nhau, và các kỹ năng giúp ai đó xuất sắc ở vai trò này không tự động chuyển hóa sang vai trò khác.

Khía cạnh	Individual Contributor (IC)	Tech Lead	Engineering Manager
Đơn vị đầu ra chính	Code, thiết kế và sản phẩm kỹ thuật do chính họ tạo ra	Hình hài kỹ thuật của một dự án hoặc hệ thống; đầu ra kỹ thuật tổng thể của team	Kết quả về con người, quy trình và delivery tổng thể của team
Thời gian dành cho	Viết code, viết design doc, review code, debug	Kiến trúc, design review, gỡ vướng cho các quyết định kỹ thuật, mentor về các vấn đề kỹ thuật, thường vẫn viết code	1:1, tuyển dụng, quản lý hiệu suất, lập kế hoạch, phối hợp liên team, roadmap và ưu tiên công việc
Bộ kỹ năng chính	Chuyên môn kỹ thuật sâu, khả năng giải quyết vấn đề, khả năng thực thi	Khả năng đánh giá kỹ thuật ở quy mô lớn, khả năng đưa ra và truyền đạt quyết định kiến trúc, mentor kỹ thuật	Coaching, feedback, thiết kế tổ chức, giải quyết xung đột, ưu tiên hóa, hiểu bối cảnh business
Cách đo lường thành công	Chất lượng và tác động của những gì họ tự tay xây dựng; sự mở rộng phạm vi kỹ thuật cá nhân	Định hướng kỹ thuật của hệ thống có đúng đắn không, team có thực thi tốt không; rủi ro kỹ thuật được quản lý ra sao	Team có delivery đều đặn không, con người có phát triển và ở lại không, tổ chức xung quanh team có vận hành tốt không
Thẩm quyền	Đối với công việc của chính mình, và ảnh hưởng thông qua chuyên môn	Ảnh hưởng lên các quyết định kỹ thuật; thường không có thẩm quyền chính thức đối với con người	Thẩm quyền chính thức đối với các quyết định về con người (tuyển dụng, đánh giá hiệu suất, đề xuất lương thưởng, cơ cấu tổ chức)
Chịu trách nhiệm cho thất bại nào	Không hoàn thành cam kết cá nhân, chất lượng code/thiết kế kém	Một quyết định kiến trúc sai lầm, technical debt không được quản lý, định hướng kỹ thuật mơ hồ	Team không delivery đúng hẹn, tỷ lệ nghỉ việc cao, tinh thần đội nhóm thấp, quyết định tuyển dụng sai, quy trình yếu kém
Áp lực sự nghiệp thường gặp	”Mình có còn thích tự tay xây dựng mọi thứ không?"	"Mình có muốn có thẩm quyền với con người song song với thẩm quyền kỹ thuật, hay muốn giữ nguyên vai trò thuần kỹ thuật?"	"Mình có sẵn sàng bị đánh giá bằng những kết quả mà mình không trực tiếp tạo ra không?”

Có vài điểm đáng được nói rõ hơn, vì bảng trên một mình nó chưa lột tả hết phần “tại sao.”

Thứ nhất, tech lead không phải là một manager cấp thấp. Vai trò tech lead là một vai trò có thẩm quyền kỹ thuật nhưng không có thẩm quyền về con người: họ là người mà team tin tưởng để đưa ra hoặc phân xử các quyết định kỹ thuật, nhưng họ thường không thực hiện đánh giá hiệu suất của ai, không quyết định ai được tuyển hay bị cho nghỉ, và không chịu trách nhiệm về các cam kết delivery của team với business. Nhiều tech lead xuất sắc hoàn toàn không có hứng thú trở thành EM, và những tổ chức mặc định “tech lead” là bước đầu tiên của con đường quản lý sẽ đánh mất những nhà lãnh đạo kỹ thuật giỏi vì ép họ vào giả định đó.

Thứ hai, thẩm quyền của EM khác biệt về bản chất, không chỉ về mức độ. Một IC hay tech lead giành được ảnh hưởng nhờ chất lượng đánh giá kỹ thuật của họ — người khác nghe theo đề xuất của họ vì đề xuất đó tốt. Một EM cũng có loại ảnh hưởng “kiếm được” này, nhưng họ còn nắm giữ thẩm quyền tổ chức chính thức (tuyển dụng, sa thải, đề xuất lương thưởng, đánh giá hiệu suất) mà IC và tech lead không có. Thẩm quyền chính thức đó là một trách nhiệm, không phải một đặc quyền: nó có nghĩa là lời nói của EM mang trọng lượng khác trong một cuộc họp ngay cả khi họ không cố ý, và nó có nghĩa là EM phải chịu trách nhiệm cho những kết quả — như tỷ lệ nghỉ việc hay một quyết định tuyển dụng sai — mà tech lead không phải chịu trách nhiệm theo cách tương tự.

Thứ ba, và quan trọng nhất: đây là những bộ kỹ năng khác nhau, không phải một chiếc thang cấp bậc nghiêm ngặt. Một người có thể là một IC phi thường nhưng lại là một manager kém, hoặc là một manager phi thường nhưng chỉ từng là một IC trung bình. Việc chuyển từ IC sang EM là một sự thay đổi sự nghiệp, không phải một sự thăng tiến theo nghĩa đen, dù nó thường được thực hiện thông qua cùng một quy trình thăng tiến và cùng một dải lương. Coi nó là “bậc thang tiếp theo” là một trong những lý do phổ biến nhất khiến người ta trở thành manager vì lý do sai — vì nó trông như con đường duy nhất để đi lên — rồi sau đó hoặc kiệt sức, hoặc làm team tệ hơn.

Nền tảng kỹ thuật mà một EM cần

Nếu thẩm quyền của EM không chủ yếu nằm ở kỹ thuật, vậy tại sao nền tảng kỹ thuật lại quan trọng? Vì EM vẫn phải đưa ra hoặc phê duyệt những quyết định có hệ quả kỹ thuật sâu sắc — phê duyệt một kiến trúc, phản biện một timeline giả định một phạm vi công việc phi thực tế, quyết định xem một khoản technical debt có đáng để trả ngay bây giờ không, đánh giá xem đề xuất của một engineer có hợp lý không. Không điều nào trong số này đòi hỏi EM phải là người viết code giỏi nhất phòng. Nhưng tất cả đều đòi hỏi đủ sự am hiểu kỹ thuật để đặt đúng câu hỏi, nhận ra một câu trả lời tồi khi nghe thấy nó, và giữ được sự tin tưởng của team khi họ phản biện điều gì đó.

Có một ngưỡng hữu ích, dù không chính xác tuyệt đối: một EM cần đủ nền tảng kỹ thuật thực chiến để từng tự mình cảm nhận hậu quả của những quyết định mà giờ đây họ giám sát — cảm giác sống chung với một hệ thống thiết kế kém, một timeline gấp gáp ảnh hưởng thế nào đến chất lượng code, technical debt thực sự gây ma sát hằng ngày ra sao — ngay cả khi họ không còn tự tay tạo ra công việc đó nữa. Đây chính là ý nghĩa thực tế của “uy tín kỹ thuật” (technical credibility). Nó không phải là “vẫn viết được thuật toán khó nhất team” — mà là “đã từng làm công việc này, hiểu được kết cấu của nó, và có thể phân biệt được một engineer đang thận trọng hợp lý với một engineer đang cố tình ước lượng thấp.”

Uy tín này sẽ mai một nếu bị bỏ bê hoàn toàn, đó là lý do tại sao hầu hết các EM giỏi chủ động giữ lại một phần diện tích tiếp xúc kỹ thuật: đọc design doc và diff ngay cả khi không bắt buộc, tham gia các buổi review kiến trúc và sự cố, thỉnh thoảng pair hoặc tự tay làm một chút việc nhỏ, cập nhật các công cụ và ngôn ngữ mà team đang thực sự sử dụng. Mục tiêu không phải là tiếp tục làm engineer giỏi nhất team — cố làm điều đó chính là một kiểu thất bại phổ biến, sẽ được bàn ở phần dưới — mục tiêu là giữ đủ uy tín kỹ thuật để các quyết định của bạn được tin tưởng, và đủ cập nhật để bạn không vô tình đưa ra quyết định dựa trên cách codebase vận hành từ ba năm trước.

Khái niệm chính

Giữ tiêu chuẩn chất lượng mà không tự mình review tất cả

Một nỗi lo lắng thường thấy ở các EM mới là: “nếu mình không review từng pull request và không tự mình đưa ra mọi quyết định thiết kế, làm sao chất lượng không bị tuột dốc?” Câu trả lời là chất lượng trở thành thứ EM thiết kế vào trong hệ thống, thay vì thứ họ tự tay thực thi từng dòng một. Cụ thể, điều này xảy ra thông qua một số cơ chế phối hợp với nhau:

Tiêu chuẩn và chuẩn mực được nói ra rõ ràng thay vì để tồn tại như kiến thức truyền miệng — coding guideline, definition of done, “production-ready” nghĩa là gì đối với team này, khi nào cần design doc trước khi viết code.
Review được phân quyền và phân tán, trong đó các senior IC và tech lead đảm nhận phần lớn việc review code và thiết kế hằng ngày, còn EM lấy mẫu (sample) sâu thay vì kiểm tra mọi thứ một cách hời hợt — đọc kỹ một tập con các pull request hoặc tài liệu đủ để phát hiện sự trôi dạt khỏi tiêu chuẩn, thay vì lướt qua tất cả.
Các cổng chất lượng mang tính cấu trúc không phụ thuộc vào phán đoán của một cá nhân tại một thời điểm: CI check, yêu cầu design review bắt buộc với các thay đổi trên một mức độ nhất định, triển khai theo giai đoạn (staged rollout), lịch trực on-call giúp phát hiện vấn đề nhanh chóng.
Retrospective và postmortem, chuyển hóa các sự cố cá nhân (một bug, một lần outage, một deadline bị lỡ) thành bài học ở cấp độ hệ thống — mục đích không phải là đổ lỗi cho người liên quan, mà là hỏi xem điều gì trong quy trình hoặc tiêu chuẩn đã cho phép chuyện này xảy ra, và sửa nó.
Tuyển dụng và phát triển con người, đòn bẩy chậm nhất nhưng mạnh mẽ nhất: một team gồm những người vốn đã có bản năng kỹ thuật tốt cần ít sự thực thi chất lượng trực tiếp hơn nhiều so với một team không có điều đó.

Điểm chung xuyên suốt là công việc của EM là xây dựng một hệ thống mà kỹ thuật tốt là con đường ít trở ngại nhất, và nhận ra — thông qua việc lấy mẫu, thông qua các chỉ số như tỷ lệ sự cố hay thời gian review, thông qua những gì xuất hiện trong các buổi 1:1 — khi nào hệ thống đó đang thất bại, thay vì tự mình làm tuyến phòng thủ cuối cùng cho mọi sản phẩm mà team tạo ra. Xem ./09-technical-decision-making-and-architecture.md để biết điều này diễn ra cụ thể như thế nào trong các quyết định kiến trúc.

Chuyển đổi từ IC sang manager, và những cạm bẫy kinh điển

Việc chuyển đổi sang quản lý là một trong những chuyển đổi có tỷ lệ thất bại cao nhất trong ngành công nghệ, không phải vì công việc bất khả thi, mà vì chính những bản năng từng giúp ai đó trở thành một IC giỏi lại tích cực chống lại họ trong những tháng đầu làm quản lý. Có vài cạm bẫy xuất hiện thường xuyên đến mức đáng được nêu tên trực tiếp:

Vẫn muốn tự tay code mọi thứ. Các manager mới thường giữ lại một khối lượng lớn công việc code trực tiếp “vì mình làm nhanh hơn” hoặc “vì mình không muốn mất kỹ năng.” Làm điều này ở mức độ vừa phải thì ổn, thậm chí lành mạnh; làm quá mức có nghĩa là manager đang dành thời gian quý giá của mình cho đúng thứ không đòi hỏi thẩm quyền riêng biệt của họ (bất kỳ ai đủ năng lực cũng có thể viết đoạn code đó), trong khi những thứ thực sự đòi hỏi thẩm quyền của họ — coaching, feedback khó nói, tuyển dụng — bị bỏ bê.
Loay hoay với việc delegate. Liên quan đến điểm trên: nhiều manager mới giao việc (task) nhưng không giao quyền quyết định (decision), nghĩa là họ phân phát công việc nhưng vẫn khăng khăng phê duyệt từng chi tiết, cách này vừa chậm hơn tự làm vừa kìm hãm sự phát triển của người được giao việc. Delegate thực sự nghĩa là trao cho ai đó một vấn đề cùng thẩm quyền để giải quyết nó, chứ không phải một tập hợp chỉ dẫn để thực thi.
Đo lường giá trị bản thân bằng đầu ra cá nhân thay vì đầu ra của team. Đây có lẽ là cạm bẫy sâu sắc nhất, vì nó nằm ở cấp độ bản sắc (identity) chứ không phải cấp độ kỹ năng. Cảm giác về “một ngày tốt lành” của một IC được xây dựng quanh những gì họ tự tay ship. Một EM phải xây dựng lại cảm giác đó quanh những gì team đã ship, liệu có ai đó đạt được bước đột phá trong buổi 1:1 không, liệu một cuộc trò chuyện khó khăn có diễn ra suôn sẻ không — những kết quả mà manager có ảnh hưởng nhưng không tự tay tạo ra. Những người không thể thực hiện sự chuyển dịch này có xu hướng hoặc âm thầm tiếp tục làm công việc IC với cái giá là bỏ bê công việc quản lý, hoặc mang một cảm giác dai dẳng, mơ hồ rằng mình “không thực sự đang làm việc,” ngay cả khi team đang phát triển tốt.
Né tránh feedback khó nói. ICs hiếm khi phải nói với đồng nghiệp rằng công việc của họ chưa đủ tốt. Manager phải làm điều này thường xuyên, và sự khó chịu đó khiến một số manager mới làm mềm feedback đến mức mơ hồ, điều này không giúp được ai. Xem ./02-one-on-ones-feedback-and-performance.md để biết cách xây dựng kỹ năng đưa feedback trực tiếp, tử tế và có thể hành động được.
Quá coi trọng việc được yêu thích. Manager mới đôi khi đánh đồng việc làm manager tốt với việc được lòng mọi người, dẫn đến né tránh những va chạm cần thiết — các cuộc trò chuyện khó về hiệu suất, các quyết định ưu tiên không được lòng ai, việc giữ vững tiêu chuẩn chất lượng. Sự tôn trọng là một loại “tiền tệ” bền vững và hữu ích hơn sự yêu thích, và nó thường được kiếm được thông qua sự nhất quán và công bằng chứ không phải thông qua việc né tránh xung đột.

Không cạm bẫy nào trong số này là lỗi đạo đức — chúng là dư âm tự nhiên của nhiều năm được khen thưởng vì đầu ra kỹ thuật cá nhân, xuất hiện trong một công việc thưởng cho một thứ khác. Chỉ cần nêu tên chúng một cách rõ ràng thường đã đủ để giúp một manager mới nhận ra và tự điều chỉnh.

Chuyển đổi sang manager-of-managers, sơ lược

Một chuyển đổi tiếp theo xảy ra khi một EM bắt đầu quản lý các manager khác thay vì trực tiếp quản lý IC. Sự thay đổi ở đây có nhịp điệu tương tự chuyển đổi từ IC sang EM: thay vì coaching từng engineer về code và sự nghiệp của họ, manager-of-managers coaching các manager khác về các quyết định về con người, các lựa chọn quy trình, và chính khả năng đánh giá kỹ thuật của họ — lùi thêm một bậc nữa khỏi công việc trực tiếp. Cạm bẫy kinh điển lặp lại dưới một hình thức mới: một manager-of-managers không cưỡng lại được việc “nhảy vòng qua” các manager của mình để tự mình giải quyết vấn đề của một IC sẽ làm suy yếu chính những manager đó, giống hệt cách một EM mới không cưỡng lại được việc tự code mọi thứ làm suy yếu team của mình. Chuyển đổi này cũng đưa thiết kế tổ chức (organizational design) trở thành một mối quan tâm hàng đầu — ranh giới team, tuyến báo cáo, phạm vi quản lý (span of control) — được đề cập trong ./06-hiring-and-organization-design.md.

Bản đồ những gì tiếp theo trong roadmap này

Bài giới thiệu này nằm ở đỉnh của một roadmap mở rộng từng đòn bẩy trong ba đòn bẩy (con người, quy trình, định hướng kỹ thuật) thành chiều sâu thực tế, cộng thêm các kỹ năng theo tình huống được xây dựng trên nền đó:

Quản lý con người (chủ đề 02–04) bao gồm các cơ chế nền tảng của việc quản lý từng cá nhân: 1:1, feedback, và quản lý hiệu suất (./02-one-on-ones-feedback-and-performance.md), cùng với lập kế hoạch phát triển và các cuộc trò chuyện về sự nghiệp.
Tổ chức (chủ đề 05–06) chuyển từ cá nhân sang cấu trúc: team được định hình ra sao, pipeline tuyển dụng vận hành thế nào, và các quyết định thiết kế tổ chức (ranh giới team, tuyến báo cáo) ảnh hưởng đến delivery ra sao — xem ./06-hiring-and-organization-design.md.
Delivery (chủ đề 07–08) đi sâu vào đòn bẩy quy trình: lập kế hoạch, ước lượng, cơ chế agile/Scrum/Kanban, và cách một EM theo dõi và gỡ vướng cho delivery mà không micromanage nó.
Định hướng kỹ thuật (chủ đề 09–10) bao gồm cách một EM tham gia vào kiến trúc và ra quyết định kỹ thuật mà không phải là tác giả chính của mọi quyết định — xem ./09-technical-decision-making-and-architecture.md.
Quản lý sự cố và khủng hoảng (chủ đề 11–12) bao gồm cách vai trò của EM thay đổi dưới áp lực: outage, deadline gấp gáp, và khủng hoảng đội nhóm, những nơi nhịp độ quy trình bình thường nhường chỗ cho một chế độ lãnh đạo khác.
Stakeholder (chủ đề 13–14) bao gồm quản lý theo chiều dọc và liên chức năng: giao tiếp với ban lãnh đạo, hợp tác với product và design, và quản lý kỳ vọng trong toàn tổ chức.
Chiến lược và business (chủ đề 15–17) là nơi khả năng đánh giá kỹ thuật và tổ chức của EM kết nối với kết quả kinh doanh: xây dựng business case, ưu tiên hóa dựa trên mục tiêu chiến lược, và suy nghĩ về đầu tư kỹ thuật theo cách business suy nghĩ về đầu tư — xem ./15-strategy-business-case-and-prioritization.md.

Thứ tự này gần như phản ánh cách công việc diễn ra trong thực tế: một EM mới trước tiên dựa vào kỹ năng con người và quy trình delivery, sau đó phát triển thành quyền sở hữu định hướng kỹ thuật sâu hơn, rồi đến việc xử lý áp lực và khủng hoảng tốt, và cuối cùng là sự thông thạo với stakeholder và chiến lược khi phạm vi công việc của họ mở rộng.

Best Practices

Một “tuần làm việc tốt” trông như thế nào

Vì công việc được định nghĩa bởi giao điểm của ba đòn bẩy thay vì một đầu ra duy nhất, các EM mới rất dễ cảm thấy “mình không làm việc thật sự” nếu lịch của họ kín mít các buổi họp. Một bức tranh phân bổ thời gian cụ thể sẽ giúp neo công việc này vào thực tế. Tỷ lệ chính xác thay đổi theo quy mô team, độ trưởng thành của tổ chức, và việc EM có còn code hay không, nhưng một tỷ lệ hợp lý cho một EM lần đầu quản lý một team duy nhất gồm 6–8 engineer trông đại khái như sau:

Khu vực	Tỷ lệ thời gian ước tính	Bao gồm
Con người	30–40%	1:1, coaching, các buổi feedback, phỏng vấn tuyển dụng và debrief, lập kế hoạch sự nghiệp/phát triển
Quy trình và delivery	20–25%	Lập kế hoạch sprint/iteration, theo dõi rủi ro delivery, gỡ vướng cho đồng đội, retro
Định hướng kỹ thuật	15–20%	Design review, thảo luận kiến trúc, lấy mẫu review code, review sự cố/postmortem
Stakeholder và liên chức năng	15–20%	Đồng bộ với product/design, báo cáo tình hình lên cấp trên, phối hợp liên team
Chiến lược và chi phí quản trị	5–10%	Đóng góp ý kiến cho roadmap, lập kế hoạch nhân sự, công việc hành chính nội bộ (chu kỳ đánh giá, ngân sách)

Có vài hệ quả thực tế rút ra từ bảng này. Thứ nhất, thời gian dành cho con người là khối lớn nhất, và có lý do chính đáng — đây là đòn bẩy có vòng phản hồi chậm nhất và chi phí bỏ bê cao nhất: một báo cáo trực tiếp (report) đang mất động lực hoặc suy giảm hiệu suất không “báo động” theo cách một bản build bị hỏng làm, nên nó cần thời gian được chủ động lên lịch (1:1 đều đặn), chứ không chỉ là sự chú ý thụ động. Thứ hai, thời gian cho định hướng kỹ thuật cố tình nhỏ hơn so với khi còn là IC, nhưng không phải là bằng không — một EM để tỷ lệ này về 0 sẽ đánh mất uy tín đã bàn ở trên; một EM để tỷ lệ này quay lại mức của một IC thì đang âm thầm không làm phần còn lại của công việc. Thứ ba, tỷ lệ này thay đổi theo phạm vi công việc: một EM của một team nhỏ duy nhất dành nhiều thời gian gần với con người và code hơn; một manager-of-managers dành tỷ lệ thời gian lớn hơn cho stakeholder, chiến lược, và thiết kế tổ chức, và tương ứng ít hơn cho coaching từng cá nhân, vì việc đó giờ đây diễn ra ở một cấp thấp hơn.

Một cách kiểm tra hữu ích khác cho “tuần làm việc tốt,” độc lập với tỷ lệ phần trăm chính xác: vào cuối tuần, bạn có thể kể tên (a) ít nhất một người mà tình huống của họ được bạn thúc đẩy tiến bộ một cách có ý nghĩa — gỡ vướng, coaching, đưa feedback hữu ích; (b) ít nhất một rủi ro delivery mà bạn hoặc đã giải quyết hoặc đã làm rõ ràng nó ra; và (c) ít nhất một quyết định kỹ thuật hoặc quy trình mà bạn hoặc đã đưa ra hoặc đã kiểm tra tính hợp lý. Một tuần mà bạn không thể trả lời được điều nào trong ba điều trên, dù lịch có kín đến đâu, là một tuần mà công việc thực sự chưa xảy ra.

Những thói quen sớm khác đáng xây dựng

Một danh sách ngắn các thực hành thường xuyên phân biệt những EM ramp-up tốt với những người gặp khó khăn: bảo vệ thời gian 1:1 như một điều không thể thương lượng, vì đây là kênh chính giúp các vấn đề về con người nổi lên đủ sớm để giải quyết với chi phí thấp; chủ động và thường xuyên xin feedback về cách quản lý của chính mình, vì sẽ không ai tự nguyện đưa ra nó nếu không được hỏi; giữ một bản ghi chép cá nhân đơn giản về những gì mỗi report đang làm và đang gặp khó khăn, vì trí nhớ đơn thuần không thể mở rộng quá một vài người; cưỡng lại thôi thúc phải có ý kiến về mọi chi tiết kỹ thuật, và thay vào đó dồn năng lượng đó vào việc đảm bảo team có một quy trình tốt để đi đến các quyết định kỹ thuật; và coi vài tháng đầu tiên là giai đoạn lắng nghe — hiểu các chuẩn mực, lịch sử, và những căng thẳng chưa được giải quyết hiện có của team trước khi cố gắng thay đổi chúng.

Tài liệu tham khảo

Camille Fournier, The Manager’s Path (O’Reilly) — tài liệu tham chiếu kinh điển về career ladder của EM và các chuyển đổi được đề cập trong bài này.
Google, Engineering Practices documentation — hướng dẫn công khai của Google về code review và tiêu chuẩn kỹ thuật, hữu ích để suy nghĩ về cách tiêu chuẩn chất lượng mở rộng vượt ra ngoài review cá nhân.
Julie Zhuo, The Making of a Manager (Portfolio) — một góc nhìn thực tế, từ trải nghiệm cá nhân về chuyển đổi từ IC sang manager.
Will Larson, An Elegant Puzzle: Systems of Engineering Management — về thiết kế tổ chức và góc nhìn hệ thống trong engineering management.
Lara Hogan, Resources for New Managers — các framework thực tế cho manager mới, bao gồm cấu trúc feedback và 1:1.
Charity Majors, “Engineering Management Is Not a Promotion” — một lập luận được trích dẫn rộng rãi cho việc coi EM là một con đường sự nghiệp riêng biệt, chứ không phải một bậc thang cao hơn senior IC.

Part of the Engineering Manager Roadmap knowledge base.

Overview

Engineering management is often described, badly, as “what happens to a senior engineer who stops writing code.” That description survives because it is half-true and fully misleading. It is true that most engineering managers (EMs) come from a strong individual-contributor (IC) background, and it is true that many EMs write less production code than they used to. But the job itself is not a diminished version of engineering — it is a different discipline that happens to require engineering fluency as a prerequisite.

An EM’s actual output is not code. It is a team that reliably ships the right things, at a sustainable pace, with people who are growing and who want to stay. That output is produced through three intertwined levers:

People — hiring, coaching, feedback, performance management, career growth, and the day-to-day emotional and motivational state of each person on the team.
Process — how work is planned, estimated, communicated, and delivered; how quality is enforced; how incidents are handled; how the team learns from both successes and failures.
Technical direction — architecture judgment, technical risk management, and the ability to set a bar for engineering quality without necessarily writing the code that meets it.

None of these three is optional, and none of them is “the real job” while the others are overhead. A manager who only does 1:1s but never engages with architecture will eventually preside over a team that ships a mess. A manager who only reviews architecture but never gives feedback will eventually lose their best people. A manager who obsesses over process but ignores both people and technology will build a bureaucracy that nobody wants to work in. The job is the intersection of all three, and most of the day-to-day skill of being an EM is deciding, in real time, which of the three needs your attention right now.

This note is the entry point to the rest of this knowledge base. It defines what the job actually is, how it differs from adjacent roles (tech lead, IC), what technical foundation it rests on, what changes when you transition into it, and how the following topics in this roadmap fit together.

Fundamentals

The job is not “senior engineer plus admin”

The “senior engineer plus admin” mental model fails because it assumes the manager’s technical judgment is applied the same way it was as an IC — by personally writing the critical code, personally reviewing every pull request, personally making every design call — with meetings and paperwork bolted on top. In reality, the moment you become responsible for more work than you can personally produce or personally check, your technical judgment has to change shape. Instead of being applied directly to artifacts (code, designs, documents), it gets applied indirectly, through the people and systems that produce those artifacts: who you hire, how you set standards, what you choose to review closely versus delegate, what questions you ask in a design review, and what kind of postmortem culture you build after something breaks.

This is the central mental shift of engineering management: from doing the work to enabling the work. It is not a demotion of technical involvement — good EMs stay technically sharp for years — but it is a change in the mechanism through which that technical judgment reaches the codebase. A useful way to phrase it: an IC’s job is to produce good outcomes directly; an EM’s job is to build and run a system (people, norms, process) that reliably produces good outcomes without the EM personally touching every piece of it.

EM vs Tech Lead vs IC

A common source of confusion — especially for engineers considering the switch, and for organizations designing their career ladder — is treating “IC → Tech Lead → EM” as a strict hierarchy, where each step is “more senior” and “more responsible” than the last. That framing causes real damage: it pushes people toward management who would be happier and more effective staying technical, and it undersells the seniority and difficulty of a principal-level IC role. The healthier framing is that these are three different jobs measured by three different definitions of success, and the skills that make someone excellent at one do not automatically transfer to another.

Dimension	Individual Contributor (IC)	Tech Lead	Engineering Manager
Primary unit of output	Their own code, designs, and technical artifacts	The technical shape of a project or system; the team’s collective technical output	The team’s collective people, process, and delivery outcomes
Where their time goes	Coding, design docs, code review, debugging	Architecture, design reviews, unblocking technical decisions, mentoring on technical problems, often still writing code	1:1s, hiring, performance management, planning, cross-team coordination, roadmap and prioritization work
Primary skill set	Deep technical craft, problem-solving, execution	Technical judgment at scale, ability to make and communicate architecture decisions, technical mentoring	Coaching, feedback, organizational design, conflict resolution, prioritization, business context
How success is measured	Quality and impact of what they personally build; growth in technical scope	Whether the system’s technical direction is sound and the team executes it well; how well technical risk is managed	Whether the team delivers reliably, whether people are growing and retained, whether the org around the team functions well
Authority	Over their own work, and influence through expertise	Influence over technical decisions; usually no formal authority over people	Formal authority over people decisions (hiring, performance, compensation input, org structure)
Who they’re accountable to for failure	Missed personal commitments, poor code/design quality	A bad architecture decision, unmanaged technical debt, unclear technical direction	Missed team delivery, attrition, low morale, poor hiring decisions, a failing process
Career pressure they typically feel	”Do I still enjoy building things by hand?"	"Do I want people-authority to go with my technical authority, or do I want to stay purely technical?"	"Am I willing to be measured by outcomes I don’t personally produce?”

A few things are worth pulling out of this table explicitly, because the table alone understates the “why.”

First, a tech lead is not a junior manager. The tech lead role is a technical-authority role without people-authority: they are the person the team trusts to make or arbitrate technical calls, but they typically do not run someone’s performance review, do not decide who gets hired or let go, and do not own the team’s delivery commitments to the business. Many excellent tech leads have no interest in ever becoming an EM, and organizations that assume “tech lead” is step one of a management track lose good technical leaders by forcing that assumption on them.

Second, the EM’s authority is different in kind, not just in degree. An IC or tech lead earns influence through the quality of their technical judgment — people follow their proposals because the proposals are good. An EM has that same kind of earned influence available to them, but they also hold formal organizational authority (hiring, firing, compensation input, performance ratings) that ICs and tech leads do not. That formal authority is a responsibility, not a perk: it means an EM’s words carry different weight in a room even when they don’t intend them to, and it means the EM is accountable for outcomes — like attrition or a bad hire — that a tech lead is not accountable for in the same way.

Third, and most importantly: these are different skill sets, not a strict ladder. Someone can be a phenomenal IC and a poor manager, or a phenomenal manager who was only an average IC. The switch from IC to EM is a career change, not a promotion in the literal sense, even though it is frequently administered through the same promotion process and pay bands. Treating it as “the next rung” is one of the most common reasons people become managers for the wrong reasons — because it looked like the only way up — and then either burn out or make the team worse.

The technical background an EM needs

If the EM’s authority isn’t primarily technical, why does technical background matter at all? Because the EM still has to make or approve decisions that have deep technical consequences — approving an architecture, pushing back on a timeline that assumes an unrealistic scope, deciding whether a piece of tech debt is worth paying down now, evaluating whether an engineer’s proposal is sound. None of that requires the EM to be the strongest coder in the room. All of it requires enough technical fluency to ask the right questions, recognize a bad answer when they hear one, and retain the trust of the team when they push back on something.

There is a useful, if imprecise, threshold here: an EM needs enough hands-on technical background to have personally felt the consequences of the decisions they now oversee — what it’s like to live with an under-designed system, what a rushed timeline does to code quality, what technical debt actually costs in day-to-day friction — even if they no longer produce that work themselves. This is what “technical credibility” means in practice. It is not “can still write the hardest algorithm on the team” — it is “has done this job, understands its texture, and can tell the difference between an engineer who’s being appropriately cautious and one who’s sandbagging an estimate.”

This credibility decays if neglected entirely, which is why most good EMs deliberately keep some technical surface area: reading design docs and diffs even when they don’t have to, staying in architecture and incident reviews, occasionally pairing or doing small hands-on work, keeping up with the tools and languages the team actually uses. The goal isn’t to remain the best engineer on the team — trying to do that is itself a common failure mode, discussed below — the goal is to remain technically credible enough that your judgment calls are trusted, and technically current enough that you don’t accidentally make decisions based on how the codebase worked three years ago.

Key Concepts

Keeping a quality bar without doing all the reviewing

A natural anxiety for new EMs is: “if I’m not reviewing every pull request and not making every design decision myself, how does quality not slip?” The answer is that quality becomes something the EM engineers into the system rather than something they personally enforce line by line. Concretely, this happens through several mechanisms working together:

Standards and norms, made explicit rather than left as tribal knowledge — coding guidelines, definition of done, what “production-ready” means for this team, when a design doc is required before code is written.
Delegated, distributed review, where senior ICs and the tech lead carry the bulk of day-to-day code and design review, and the EM samples deeply rather than checking everything shallowly — reading a subset of pull requests or docs closely enough to catch drift in the standard, rather than skimming all of them.
Structural quality gates that don’t depend on any one person’s judgment in the moment: CI checks, required design reviews above a certain size of change, staged rollouts, on-call rotations that surface problems quickly.
Retrospectives and postmortems, which convert individual incidents (a bug, an outage, a missed deadline) into system-level learning — the point isn’t to blame the person involved, it’s to ask what about the process or the standards let this happen, and fix that.
Hiring and growth, which is the slowest but most powerful lever: a team of people who already have good technical instincts needs far less direct quality enforcement than a team that doesn’t.

The common thread is that the EM’s job is to build a system where good engineering is the path of least resistance, and to notice — via sampling, via metrics like incident rates or review turnaround, via what comes up in 1:1s — when that system is failing, rather than to personally be the backstop for every artifact the team produces. See ./09-technical-decision-making-and-architecture.md for how this plays out in architecture decisions specifically.

The IC-to-manager transition, and its classic pitfalls

The transition into management is one of the highest failure-rate transitions in tech, not because the job is impossible, but because the instincts that made someone a great IC actively work against them in the first months of managing. A few pitfalls show up so consistently they’re worth naming directly:

Still wanting to code everything. New managers often keep a large chunk of hands-on coding work “because I’m faster at it” or “because I don’t want to lose my skills.” Done in moderation this is fine and even healthy; done to excess it means the manager is spending their scarce time on the one thing that doesn’t require their unique authority (anyone competent can write that code) while the things that do require their authority — coaching, hard feedback, hiring — get neglected.
Struggling to delegate. Related to the above: many new managers delegate tasks but not decisions, meaning they hand out work while still insisting on approving every detail, which is slower than doing it themselves and also stunts the growth of the person they delegated to. Real delegation means giving someone a problem and the authority to solve it, not a set of instructions to execute.
Measuring self-worth by personal output instead of team output. This is arguably the deepest pitfall, because it’s identity-level rather than skill-level. An IC’s sense of a “good day” is built around what they personally shipped. An EM has to rebuild that sense of a good day around what the team shipped, whether someone had a breakthrough in a 1:1, whether a hard conversation went well — outcomes the manager influenced but didn’t personally produce. People who can’t make this shift tend to either quietly keep doing IC work at the expense of management work, or feel a persistent, low-grade sense that they’re not “really working,” even when the team is thriving.
Avoiding difficult feedback. ICs are rarely required to tell a peer their work isn’t good enough. Managers are required to do this regularly, and the discomfort of it drives some new managers to soften feedback into vagueness, which helps nobody. See ./02-one-on-ones-feedback-and-performance.md for how to build the skill of direct, kind, actionable feedback.
Over-indexing on being liked. New managers sometimes conflate being a good manager with being popular, which leads to avoiding necessary friction — tough performance conversations, unpopular prioritization calls, holding a line on quality. Respect is a more durable and more useful currency than likability, and it’s usually earned through consistency and fairness rather than through avoiding conflict.

None of these pitfalls are moral failings — they’re the natural residue of years of being rewarded for personal technical output, showing up in a job that rewards something else. Naming them explicitly is often enough to help a new manager catch themselves.

The manager-of-managers transition, briefly

A further transition happens when an EM starts managing other managers rather than ICs directly. The shift here rhymes with the IC-to-EM transition: instead of coaching individual engineers on their code and their career, the manager-of-managers coaches other managers on their people decisions, their process choices, and their own technical judgment calls — one level more removed from the work again. The classic pitfall repeats in a new form: a manager-of-managers who can’t resist stepping around their managers to solve an IC’s problem directly undermines those managers exactly the way a new EM who can’t resist coding everything undermines their team. This transition also introduces organizational design as a first-class concern — team boundaries, reporting lines, span of control — covered in ./06-hiring-and-organization-design.md.

A map of what follows in this roadmap

This introduction sits at the top of a roadmap that expands each of the three levers (people, process, technical direction) into practical depth, plus the situational skills layered on top of them:

People management (topics 02–04) covers the foundational mechanics of managing individuals: 1:1s, feedback, and performance management (./02-one-on-ones-feedback-and-performance.md), along with growth planning and career conversations.
Organization (topics 05–06) moves from individuals to structure: how teams are shaped, how hiring pipelines work, and how org design decisions (team boundaries, reporting lines) affect delivery — see ./06-hiring-and-organization-design.md.
Delivery (topics 07–08) covers the process lever in depth: planning, estimation, agile/Scrum/Kanban mechanics, and how an EM tracks and unblocks delivery without micromanaging it.
Technical direction (topics 09–10) covers how an EM engages with architecture and technical decision-making without being the primary author of every decision — see ./09-technical-decision-making-and-architecture.md.
Incident and crisis management (topics 11–12) covers how the EM’s role changes under pressure: outages, deadline crunches, and team crises, where the normal cadence of process gives way to a different mode of leadership.
Stakeholders (topics 13–14) covers upward and cross-functional management: communicating with leadership, partnering with product and design, and managing expectations across the org.
Strategy and business (topics 15–17) is where the EM’s technical and organizational judgment connects to business outcomes: building a business case, prioritizing against strategic goals, and thinking about engineering investment the way the business thinks about investment — see ./15-strategy-business-case-and-prioritization.md.

The ordering roughly mirrors how the job unfolds in practice: a new EM leans first on people skills and delivery process, then grows into deeper technical-direction ownership, then into handling pressure and crisis well, then into stakeholder and strategic fluency as their scope expands.

Best Practices

What a “good week” looks like

Because the job is defined by an intersection of three levers rather than a single output, it’s easy for new EMs to feel like they’re “not doing real work” if their calendar is full of meetings. A concrete time-allocation picture helps ground the job. The exact split varies by team size, org maturity, and whether the EM still codes, but a reasonable rule-of-thumb split for a first-time EM of a single team of 6–8 engineers looks roughly like this:

Area	Rough share of time	What it includes
People	30–40%	1:1s, coaching, feedback conversations, hiring interviews and debriefs, career/growth planning
Process and delivery	20–25%	Sprint/iteration planning, tracking delivery risk, unblocking teammates, retros
Technical direction	15–20%	Design review, architecture discussions, sampling code review, incident/postmortem review
Stakeholders and cross-functional	15–20%	Syncing with product/design, reporting status upward, cross-team coordination
Strategy and admin overhead	5–10%	Roadmap input, headcount planning, internal admin (reviews cycle, budget)

A few practical implications follow from this table. First, people time is the largest single bucket for a reason — it’s the lever with the slowest feedback loop and the highest cost of neglect: a disengaged or underperforming report doesn’t announce itself the way a broken build does, so it needs proactively scheduled time (regular 1:1s), not just reactive attention. Second, technical direction time is deliberately smaller than it was as an IC, but not zero — an EM who lets this go to zero loses the credibility discussed above; an EM who lets it grow back to IC-levels is quietly not doing the rest of the job. Third, the ratio shifts with scope: an EM of a single small team spends more time close to the people and the code; a manager-of-managers spends proportionally more time on stakeholders, strategy, and organizational design, and correspondingly less on individual coaching, because that’s now happening one level down.

The other useful heuristic for a “good week,” independent of the exact percentages: at the end of it, can you name (a) at least one person whose situation you meaningfully moved forward — unblocked, coached, given useful feedback; (b) at least one delivery risk you either resolved or clearly surfaced; and (c) at least one technical or process decision you either made or sanity-checked. A week where you can’t answer any of the three, no matter how full the calendar was, is a week where the job didn’t actually happen.

Other early habits worth building

A short list of practices that consistently separate EMs who ramp well from those who struggle: protect 1:1 time as non-negotiable, since it is the main channel through which people-problems surface early enough to fix cheaply; ask for feedback on your own management explicitly and often, since nobody will volunteer it unprompted; keep a lightweight personal record of what each report is working on and struggling with, since memory alone doesn’t scale past a handful of people; resist the urge to have an opinion on every technical detail, and instead invest that energy in making sure the team has a good process for reaching technical decisions; and treat the first few months as a listening period — understanding the team’s existing norms, history, and unresolved tensions before trying to change them.

References

Camille Fournier, The Manager’s Path (O’Reilly) — the standard reference on the EM career ladder and the transitions covered in this note.
Google, Engineering Practices documentation — Google’s public guide to code review and engineering standards, useful for thinking about how quality bars scale beyond individual review.
Julie Zhuo, The Making of a Manager (Portfolio) — a practical, first-person account of the IC-to-manager transition.
Will Larson, An Elegant Puzzle: Systems of Engineering Management — on organizational design and the systems view of engineering management.
Lara Hogan, Resources for New Managers — practical frameworks for new managers, including feedback and 1:1 structures.
Charity Majors, “Engineering Management Is Not a Promotion” — a widely cited argument for treating EM as a distinct career track rather than a rung above senior IC.