Tuyển dụng & Thiết kế tổ chứcHiring & Organization Design

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

Tổng quan

Có hai quyết định định hình một tổ chức kỹ thuật nhiều hơn bất kỳ điều gì khác: cho ai vào và sắp xếp những người đã có mặt như thế nào. Hiring là hoạt động có đòn bẩy cao nhất mà một manager thực hiện — một lần hiring tốt tích lũy giá trị trong nhiều năm, còn một lần hiring sai lặng lẽ đánh thuế lên mọi đồng đội phải review code, làm lại việc, hoặc quản lý người đó. Org design là đòn bẩy thứ hai: cùng một nhóm engineer có thể hiệu quả hơn hoặc kém hơn rất nhiều tùy vào cách họ được chia thành các team, mỗi team chịu trách nhiệm về cái gì, và các team được kỳ vọng tương tác với nhau ra sao.

Cả hai lĩnh vực đều dễ mắc chung một sai lầm — coi chúng là sự kiện rời rạc thay vì hệ thống liên tục. Hiring làm tốt là một quy trình có cấu trúc, lặp lại được, với một hiring bar được định nghĩa rõ, chứ không phải chuỗi cảm tính (gut check) ngẫu nhiên. Org design làm tốt là sự khớp nối có chủ đích giữa hình dạng team và bài toán cần giải, được xem xét lại định kỳ, chứ không phải phản xạ reorg mỗi khi lãnh đạo cảm thấy bất an. Bài viết này bao quát cả hai: cách chạy một hiring funnel cho ra quyết định nhất quán và tốt, và cách cấu trúc/tái cấu trúc team sao cho architecture, giao tiếp, và tổ chức luôn đồng bộ.

Chủ đề này nằm ở tầng dưới của các kỹ năng cá nhân trong Introduction to Engineering Management và ở tầng trên của các cuộc thảo luận ngân sách trong Budgeting, Cost & Capacity Planning — các kế hoạch headcount là quyết định ngân sách trước khi là quyết định tuyển dụng. Nó cũng phụ thuộc nhiều vào niềm tin và psychological safety được xây dựng trong Organizational Culture & Learning: reorg và team merger là sự kiện văn hóa không kém gì sự kiện cấu trúc.

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

Hiring funnel

Hiring là một funnel với rất nhiều bề mặt để bias và sự thiếu nhất quán len vào. Đặt tên rõ ràng cho từng giai đoạn là bước đầu tiên để kiểm soát chất lượng ở mỗi bước.

Giai đoạn	Mục tiêu	Sai lầm phổ biến
Sourcing	Xây dựng một pool ứng viên có khả năng đạt hiring bar	Phụ thuộc quá nhiều vào inbound application; pipeline đồng nhất vì network hẹp
Screening	Lọc rẻ các ứng viên rõ ràng không đạt bar	Screening dựa trên pedigree (trường học, thương hiệu công ty cũ) thay vì tín hiệu thực chất
Interviewing	Thu thập bằng chứng độc lập, có thể so sánh được so với bar	Mỗi interviewer hỏi tùy hứng, test trùng cùng một kỹ năng
Decision	Tổng hợp bằng chứng thành quyết định hire/no-hire	Nghe theo interviewer senior nhất hoặc nói to nhất thay vì dựa trên bằng chứng
Offer	Chốt được ứng viên	Coi offer được chấp nhận là điểm kết thúc và bỏ bê onboarding

Khung funnel này quan trọng vì mỗi giai đoạn có một nhiệm vụ khác nhau và một kiểu thất bại khác nhau; một quy trình yếu ở “screening” nhưng mạnh ở “interviewing” sẽ lãng phí thời gian đắt đỏ của interviewer vào các ứng viên đáng lẽ đã bị lọc từ sớm, trong khi một quy trình yếu ở “interviewing” cho ra quyết định hire nghe có vẻ tự tin nhưng chất lượng thấp, bất kể screening tốt đến đâu.

Structured interview vs. unstructured interview

Unstructured interview để mỗi interviewer hỏi bất cứ điều gì nảy ra trong đầu và hình thành ấn tượng tổng thể kiểu “gut feel”. Nó nghe có vẻ tự nhiên và gần gũi, nhưng đây chính xác là định dạng mà hàng thập kỷ nghiên cứu tâm lý học công nghiệp - tổ chức (industrial-organizational psychology) chỉ ra là dự báo yếu về hiệu suất công việc — vì nó tối đa hóa ảnh hưởng của rapport, affinity bias, và halo effect, và vì các ứng viên khác nhau thực chất bị đánh giá bằng những câu hỏi khác nhau, khiến việc so sánh trở nên vô nghĩa.

Structured interview cố định trước bộ câu hỏi (hoặc problem set), hỏi cùng bộ câu hỏi cốt lõi cho mọi ứng viên ở cùng một vị trí, và chấm điểm câu trả lời theo một rubric định trước với các mốc cụ thể cho việc điểm 1, 3, hay 5 trông như thế nào. Các meta-analysis trong nghiên cứu personnel selection (nghiên cứu của Schmidt & Hunter về độ hiệu lực của các phương pháp tuyển chọn được trích dẫn nhiều nhất) liên tục cho thấy structured interview là một trong những dự báo mạnh nhất về hiệu suất công việc trong số các định dạng interview, chỉ đứng sau work-sample test và cognitive ability test kết hợp với structured interview. Cơ chế rất đơn giản: structure loại bỏ các bậc tự do (degrees of freedom) mà bias có thể khai thác. Nó không yêu cầu loại bỏ phán đoán — nó yêu cầu neo phán đoán vào cùng một thước đo cho mọi ứng viên.

Trong thực tế điều này có nghĩa là: mọi interview loop cho một vị trí có một tập giai đoạn cố định với mục đích rõ ràng, mỗi interviewer có sẵn câu hỏi mẫu và rubric chấm điểm (không chỉ là “thumbs up / thumbs down”), và interviewer viết đánh giá trước khi nghe ý kiến của người khác để tránh anchoring.

Định nghĩa hiring bar trước khi bắt đầu

Hành động có đòn bẩy cao nhất mà một hiring manager có thể làm là viết ra, trước khi bất kỳ buổi interview nào diễn ra, “yes” trông như thế nào: kỹ năng nào là must-have vs. nice-to-have, mức kinh nghiệm nào với sự mơ hồ (ambiguity) hoặc scale là cần thiết, và một “no” ở ranh giới trông khác biệt rõ ràng với một “yes” rõ ràng ra sao. Nếu không có bar được viết ra, bar sẽ trôi dạt — panel trở nên dễ dãi hơn khi pipeline mỏng và khắt khe hơn khi pipeline dồi dào, quyết định thiếu nhất quán giữa các ứng viên được phỏng vấn cách nhau vài tuần, và “nâng cao bar” trở thành một khẩu hiệu rỗng không có ý nghĩa thực thi. Một bar được định nghĩa tốt cũng đồng thời đóng vai trò là rubric debrief, và sau này là cơ sở cho cuộc thảo luận về leveling và performance calibration mà nhân viên mới cuối cùng sẽ trải qua.

Chi phí bất đối xứng giữa một lần hire sai và một quy trình chậm

Các hiring manager chịu áp lực phải lấp đầy vị trí liên tục đánh giá thấp một vế của một trade-off có thật. Một quy trình hiring chậm có chi phí rõ ràng, tức thời: một req còn mở, một team quá tải, một hạng mục roadmap bị trễ. Một lần hire sai có chi phí lớn hơn nhưng bị hoãn lại và trải rộng: nhiều tháng đầu tư onboarding không sinh lời, chất lượng code và velocity bị kéo chậm cho cả team, chi phí cảm xúc và thời gian của một performance improvement plan hoặc termination, chi phí cơ hội của headcount đáng lẽ dành cho một hire mạnh hơn, và tổn hại tinh thần cho team phải bù đắp. Vì chi phí của việc hire sai bị hoãn lại và khó quy trách nhiệm, nó thường xuyên bị đánh giá thấp tại thời điểm quyết định — chính vì vậy một hiring bar cứng, được cam kết trước, quan trọng nhất đúng vào lúc áp lực lấp đầy vị trí cao nhất.

Khái niệm chính

Thiết kế interview panel

Một anti-pattern phổ biến là một loop bốn vòng mà mỗi interviewer độc lập quyết định hỏi một câu coding, tạo ra bốn điểm dữ liệu trên cùng một trục và không có tín hiệu nào về system design, khả năng phối hợp, hay judgment. Thiết kế panel tốt phân bổ cho mỗi giai đoạn một mục đích riêng biệt để toàn bộ loop bao phủ hiring bar với sự trùng lặp tối thiểu.

Giai đoạn	Cần đánh giá điều gì	Không nên trùng lặp với
Recruiter screen	Động lực, logistics, kỳ vọng lương, kỹ năng giao tiếp cơ bản	Chiều sâu kỹ thuật
Technical screen	Khả năng coding/giải quyết vấn đề cơ bản — cổng pass/fail	System design chuyên sâu
System design / architecture	Lý luận về trade-off ở phạm vi phù hợp với level (component vs. system vs. toàn org)	Tốc độ coding thuần túy
Coding / hands-on	Code chạy được dưới ràng buộc thực tế, debugging, độ thành thạo công cụ	Câu đố thuật toán chỉ trên whiteboard
Behavioral / values	Hành vi trong quá khứ dưới ràng buộc thực tế (xung đột, thất bại, sự mơ hồ), qua câu hỏi behavioral có cấu trúc	Một ý kiến kỹ thuật thứ hai trá hình
Bar-raiser / cross-functional	Một góc nhìn độc lập, đã được calibrate, ít bị ảnh hưởng bởi động cơ của hiring manager muốn lấp vị trí	Lặp lại bất kỳ vòng nào ở trên

Debrief theo sau đó là nơi structure mang lại giá trị nhiều nhất. Mỗi interviewer nộp một đánh giá độc lập bằng văn bản theo rubric trước khi diễn ra cuộc họp debrief, để không ai bị anchor bởi việc nghe ý kiến mạnh trước. Debrief sau đó phơi bày sự bất đồng một cách rõ ràng thay vì hội tụ về mức trung bình — một ứng viên được ba interviewer đánh giá strong yes và một interviewer đánh giá strong no với một mối lo cụ thể, đáng tin cậy, xứng đáng được xem xét kỹ hơn là một sự đồng thuận giả tạo. Calibration giữa các interviewer là một kỷ luật liên tục, không phải một lần đào tạo duy nhất: interviewer mới shadow các interviewer đã được calibrate, các panel định kỳ so sánh ghi chú về các ứng viên ở ranh giới, và hiring manager theo dõi xem có interviewer nào là outlier dai dẳng (quá dễ dãi hoặc quá khắt khe) so với kết quả công việc thực tế sau này hay không.

Span of control

Span of control là số người báo cáo trực tiếp cho một manager. Đây là một tham số nền tảng của org design vì nó giới hạn lượng sự chú ý cá nhân hóa, coaching, và bối cảnh (context) mà một manager có thể thực sự nắm giữ. Một khoảng thường được trích dẫn là bền vững cho một line manager làm people management thực sự (1:1, coaching, performance management, phát triển sự nghiệp) là 6 đến 8 direct report. Dưới mức đó, manager có thể bị under-utilize như một người quản lý con người hoặc có thể trôi dạt sang làm công việc individual contributor lẽ ra thuộc về team. Trên khoảng 10-12, chất lượng của 1:1, chiều sâu của các cuộc trò chuyện về career, và khả năng của manager nhận ra vấn đề sớm đều có xu hướng suy giảm — manager trở thành một chức năng lên lịch và báo cáo trạng thái hơn là coaching.

Khoảng này là một heuristic, không phải một quy luật, và một số yếu tố có thể chính đáng mở rộng hoặc thu hẹp nó:

• Kinh nghiệm và mức độ tự chủ của report — một team gồm các engineer senior, tự định hướng, chỉ cần coaching nhẹ và ít bị block, có thể duy trì span rộng hơn một team gồm new grad cần hỗ trợ có cấu trúc, thường xuyên.
• Tính đồng nhất của team — một manager phụ trách một team gắn kết với sứ mệnh chung có thể duy trì span rộng hơn một manager phải chắp vá nhiều chức năng không liên quan.
• Trách nhiệm khác của manager — một player-coach manager vẫn còn ôm công việc delivery cá nhân có ít capacity cho direct report hơn một manager toàn thời gian dành cho management.
• Tầng tổ chức — span thường được cố ý thu hẹp hơn ở tầng senior/executive (nơi mỗi report là một manager-of-manager mang scope đáng kể) và có thể rộng hơn cho các team front-line thiên về individual contributor.

Span of control tương tác trực tiếp với số lượng tầng quản lý mà một tổ chức cần: span hẹp ở mọi tầng tạo ra một hierarchy cao (tall) với nhiều handoff hơn và độ trễ ra quyết định chậm hơn; span rộng tạo ra một tổ chức phẳng hơn nhưng có nguy cơ mỗi manager trở thành nút thắt cổ chai. Không có thái cực nào miễn phí — câu hỏi thiết kế luôn là “tôi đang đánh đổi cái gì”, chứ không phải “con số nào là đúng.”

Team topologies — nhìn tổng quan

Team Topologies (Skelton & Pais) đưa ra một bộ từ vựng được áp dụng rộng rãi cho các loại team, dựa trên quan sát rằng cấu trúc team nên là một lựa chọn tường minh, có chủ đích, nhằm giảm thiểu cognitive load và coordination overhead, chứ không phải một sự ngẫu nhiên của lịch sử hay sự tiện lợi của org chart. Nó định nghĩa bốn loại team cơ bản và ba interaction mode giữa chúng.

Loại team	Mục đích	Tín hiệu điển hình cho thấy đây là hình dạng đúng
Stream-aligned	Sở hữu toàn bộ một value stream (một sản phẩm, một khu vực tính năng, một hành trình người dùng) từ đầu đến cuối, có khả năng ship độc lập	Loại team mặc định; hầu hết team trong một tổ chức khỏe mạnh nên thuộc loại này
Platform	Cung cấp các khả năng self-service nội bộ (infra, data platform, developer tooling) giúp giảm cognitive load mà các team stream-aligned phải gánh	Nhiều team stream-aligned lặp đi lặp lại việc tự giải quyết cùng một bài toán infrastructure
Enabling	Giúp các team stream-aligned tiếp thu một năng lực họ đang thiếu (ví dụ: testing practice, một công nghệ mới) rồi lùi lại	Một team yêu cầu cùng một kiểu hỗ trợ chuyên gia tạm thời hơn một lần, hoặc bị kẹt khi tự adopt một practice
Complicated-subsystem	Sở hữu một subsystem đòi hỏi kiến thức chuyên sâu (một rendering engine, một thuật toán matching, codec internals) không nên bị phân tán qua các team stream-aligned	Subsystem thực sự cần chiều sâu chuyên môn mà việc trải mỏng ra sẽ lãng phí hoặc rủi ro

Các interaction mode — collaboration (làm việc chặt chẽ cùng nhau trong một khoảng thời gian giới hạn để khám phá điều gì đó), X-as-a-Service (một team tiêu thụ output/API của team khác với giao tiếp thường xuyên tối thiểu), và facilitating (một team enabling giúp một team khác cải thiện, tạm thời) — quan trọng không kém bản thân các loại team, vì một interaction mode không được công bố rõ hoặc bị lệch pha là nguồn friction thường gặp: một platform team kỳ vọng được tiêu thụ theo kiểu X-as-a-Service nhưng lại bị tràn ngập yêu cầu collaboration ad hoc sẽ bị quá tải, và một team stream-aligned kỳ vọng collaboration sâu nhưng bị đối xử như một khách hàng self-service sẽ cảm thấy không được hỗ trợ.

Khớp loại team với mục đích giúp giảm coordination overhead vì nó làm cho mối quan hệ mặc định giữa mỗi team với mọi team khác trở nên tường minh và nhẹ nhàng theo mặc định (X-as-a-Service), để dành collaboration tốn kém, băng thông cao cho những khoảnh khắc cụ thể, có giới hạn thực sự cần đến nó, thay vì để nó trở thành chế độ vận hành mặc định liên tục.

Best Practices

Kích thước team, coordination overhead, và Conway’s Law

Brooks’s Law (“thêm người vào một dự án phần mềm đang trễ sẽ làm nó trễ hơn”) nắm bắt một sự thật cụ thể nhưng quan trọng: coordination overhead trong một team tăng xấp xỉ theo bình phương số người (n(n-1)/2 đường giao tiếp), vì vậy tăng team không làm output tăng tuyến tính — thời gian ramp-up cho thành viên mới và chi phí phối hợp ăn mòn bất kỳ mức tăng capacity nào, đôi khi đến mức throughput ròng âm trong ngắn hạn. Bài học thực tế không phải là “không bao giờ tăng team” mà là “tăng một cách có chủ đích, kỳ vọng một sự sụt giảm tạm thời, và không coi headcount là vật thay thế tức thời cho một lịch trình bị trễ.”

Heuristic “two-pizza team” (một team đủ nhỏ để được nuôi bởi hai chiếc pizza, khoảng 6-10 người) là một proxy phổ biến để giữ team dưới điểm mà coordination overhead lấn át công việc hữu ích. Nó là một sanity check hữu ích hơn là một quy tắc chặt chẽ — trần đúng phụ thuộc vào mức độ decoupled của công việc team và bao nhiêu phần trong đó đòi hỏi phối hợp đồng bộ, chặt chẽ so với có thể song song hóa với phối hợp nhẹ.

Conway’s Law — “các tổ chức thiết kế hệ thống phản chiếu cấu trúc giao tiếp của chính họ” — là lý do ranh giới team và kiến trúc hệ thống không thể được thiết kế độc lập với nhau. Nếu hai team sở hữu các phần liên kết chặt chẽ của một hệ thống nhưng hiếm khi nói chuyện với nhau, interface giữa các phần đó sẽ tích lũy friction, giả định lệch pha, và các thay đổi cross-team chậm chạp; nếu kiến trúc mong muốn yêu cầu một interface sạch, được định nghĩa rõ giữa hai subsystem, việc đặt mỗi subsystem vào một team khác nhau với mối quan hệ X-as-a-Service tường minh củng cố ranh giới đó, trong khi đặt cả hai dưới một team với quyền sở hữu code chung có thể làm mờ nó. Hệ quả được sử dụng có chủ đích trong org design là inverse Conway maneuver: định hình cấu trúc team trước, khớp với kiến trúc mà bạn muốn, và để kiến trúc hệ thống đi theo cấu trúc giao tiếp bạn đã thiết lập — thay vì vẽ kiến trúc lên whiteboard rồi hy vọng một cấu trúc team không liên quan sẽ tạo ra nó.

Reorganization (reorg)

Reorg xảy ra vì những lý do có thật — một sự thay đổi chiến lược làm thay đổi value stream nào là quan trọng, đau đớn vì scaling khi một team đã vượt quá span of control bền vững hoặc một team stream-aligned duy nhất không còn có thể sở hữu toàn bộ bề mặt của mình một cách nhất quán, hoặc một sự kiện M&A phải sáp nhập hai tổ chức đã tồn tại từ trước. Một reorg được kích hoạt bởi một sự lệch pha cấu trúc thực sự (hình dạng team hiện tại không còn khớp với bài toán hiện tại) là đáng chi phí. Một reorg được kích hoạt bởi mong muốn của một lãnh đạo mới muốn “để lại dấu ấn của mình”, hoặc như một phản ứng phản xạ với một quý tệ, thường thì không — vấn đề nền tảng hiếm khi được giải quyết bằng cách vẽ lại các ô, mà tổ chức vẫn phải trả giá.

Chi phí của một reorg là có thật và thường bị đánh giá thấp: một sự sụt giảm năng suất khi mọi người học lại ai sở hữu cái gì và xây dựng lại mối quan hệ làm việc và niềm tin với đồng đội mới và manager mới, công việc đang dang dở bị đình trệ khi quyền sở hữu chưa rõ ràng, và — nếu reorg xảy ra quá thường xuyên — một sự xói mòn niềm tin có tính ăn mòn, nơi mọi người ngừng đầu tư vào các mối quan hệ và dự án dài hạn vì họ đã học được rằng team họ đang ở hôm nay sẽ không tồn tại trong sáu tháng nữa. Sự xói mòn đó tích lũy: reorg thứ hai và thứ ba trong một khoảng thời gian ngắn tốn nhiều niềm tin hơn reorg đầu tiên, ngay cả khi lý do cấu trúc cho mỗi lần là hợp lý riêng lẻ.

Chạy một reorg với thiệt hại tối thiểu nhìn chung có nghĩa là:

• Một lý do rõ ràng, được truyền đạt trung thực. Mọi người có thể chấp nhận một reorg mà họ không đồng ý nếu họ hiểu và tin vào lý do đó; họ không thể chấp nhận một reorg cảm thấy tùy tiện hoặc mà quản lý không sẵn lòng giải thích thẳng thắn.
• Thực thi nhanh khi đã quyết định. Một reorg rò rỉ dần dần qua nhiều tuần tối đa hóa sự lo lắng và đồn đoán mà không có lợi ích bù đắp; công bố và triển khai nhanh (với một giai đoạn chuyển tiếp ngắn, có giới hạn) kiềm chế cửa sổ gián đoạn.
• Giao tiếp trung thực, trực tiếp về điều gì thay đổi với từng cá nhân — họ báo cáo cho ai, họ sở hữu cái gì, cái gì còn chưa chắc chắn và đang được giải quyết — thay vì trấn an mơ hồ rằng “sẽ không có gì thực sự thay đổi.”
• Bảo vệ các cam kết đang dang dở khi có thể, hoặc đàm phán lại một cách tường minh, thay vì để chúng âm thầm đình trệ vì quyền sở hữu mơ hồ.
• Không lạm dụng tần suất. Coi reorg là một biện pháp can thiệp tốn kém, không thường xuyên cho một sự lệch pha cấu trúc thực sự — không phải phản ứng mặc định đầu tiên cho bất kỳ friction nào.

Team merger

Một team merger là một reorg với thêm một lớp khó khăn: hai team, mỗi team đã có văn hóa, chuẩn mực làm việc, và bản sắc được thiết lập, đang được kết hợp lại, và friction không chỉ mang tính cấu trúc mà còn mang tính xã hội. Các thách thức cụ thể ngoài một reorg thông thường bao gồm:

• Culture clash — hai team có thể có những chuẩn mực thực sự khác nhau (cách feedback trong code review được đưa ra, cách quyết định được đưa ra, “done” nghĩa là gì) mà cả hai đều cảm thấy đơn giản là “cách mọi thứ được làm”, và có thể không bên nào nhận ra bên kia vận hành khác cho đến khi việc merge làm lộ ra xung đột.
• Vai trò dư thừa (redundant roles) — merger thường kết hợp hai người mỗi người từng là chủ sở hữu duy nhất của một trách nhiệm tương tự (ví dụ: hai tech lead, hai người phụ trách on-call), đòi hỏi một quyết định tường minh, kịp thời về ai sở hữu cái gì tiếp theo, thay vì một sự đồng sở hữu mơ hồ mà không ai trong hai người đã đăng ký làm.
• Khác biệt về tooling và quy trình — CI khác nhau, nhịp độ sprint khác nhau, định nghĩa “ready” khác nhau, công cụ code review khác nhau — mỗi thứ nhỏ riêng lẻ, nhưng cộng lại là một khoản thuế thực sự cho công việc hàng ngày cho đến khi được hòa giải, và là nguồn friction liên tục, âm ỉ nếu không được xử lý.
• Mất bản sắc và vị thế — bị merge “vào” một team khác (so với merge như những bên bình đẳng) có thể đọc như một sự giáng chức hoặc một lá phiếu bất tín nhiệm ngay cả khi đó không phải là ý định; gọi tên điều này một cách trực tiếp và xử lý nó trong các buổi 1:1 ngăn nó âm ỉ thành sự oán giận.

Chạy một merger tốt vay mượn từ playbook của reorg (lý do rõ ràng, thực thi nhanh, giao tiếp trung thực) và thêm một bước hòa giải tường minh về văn hóa, quyền sở hữu, và tooling trong vài tuần đầu tiên, thay vì giả định rằng những điều này sẽ tự sắp xếp ổn thỏa.

Chuyển đổi vai trò ở cấp độ tổ chức

Reorg và merger di chuyển người giữa các team và đôi khi giữa các vai trò — một IC trở thành tech lead ở team mới, một manager trở lại làm IC, một tech lead ôm thêm một team thứ hai. Những chuyển đổi này xứng đáng nhận được sự chú ý tường minh giống như một promotion: một scope rõ ràng, một tập kỳ vọng được nêu tên, và một nhịp độ check-in để xác nhận việc chuyển đổi đang diễn ra suôn sẻ. Bài viết này tập trung vào cơ chế cấp tổ chức của việc ai chuyển đến đâu; trải nghiệm cá nhân của việc chuyển đổi giữa vai trò IC và management — kỹ năng, sự thay đổi tư duy, và sự hỗ trợ mà một người cần để thành công trong chuyển đổi cụ thể đó — được đề cập trong Introduction to Engineering Management.

Resource allocation và forecasting

Headcount là một nguồn lực hữu hạn, có ngân sách, và coi hiring như một hoạt động thuần túy chiến thuật, phản ứng — chỉ mở một req khi một team đã rõ ràng quá tải — tạo ra một hiring pipeline luôn luôn bị chậm. Vì một quy trình hiring mạnh (structured interview, một bar được định nghĩa, panel được calibrate) có thời gian dẫn (lead time) nhiều tháng từ lúc req được duyệt đến khi có một hire mới hiệu quả, kế hoạch headcount cần được xây dựng từ roadmap tiến về phía trước, chứ không phải từ nỗi đau hiện tại lùi về phía sau: dựa trên các cam kết trên roadmap cho hai đến bốn quý tới, tổ chức cần những năng lực gì và bao nhiêu capacity, và do đó req nào cần được mở ngay bây giờ để hire kịp lúc trước khi khoảng trống capacity thực sự gây hại.

Đây là nơi hiring và org design gặp trực tiếp budgeting — một kế hoạch headcount là một cam kết chi phí trước khi là một tập req đang mở, và nó nên được xây dựng và bảo vệ trong cùng chu kỳ forecasting được mô tả trong Budgeting, Cost & Capacity Planning. Sai lầm phổ biến là một kế hoạch headcount chỉ tồn tại như một danh sách req đã duyệt không có liên kết nào với roadmap đã biện minh cho chúng, khiến việc khi ưu tiên thay đổi, không thể biết được một req cụ thể còn cần thiết hay không, nên được re-scope, hay nên được phân bổ lại cho nơi khác.

Tài liệu tham khảo

• Team Topologies — Matthew Skelton & Manuel Pais, sách và trang web định nghĩa các loại team stream-aligned, platform, enabling, complicated-subsystem và các interaction mode giữa chúng
• The Mythical Man-Month — Fred Brooks, nguồn gốc của Brooks’s Law và lập luận về coordination overhead chống lại việc phản xạ thêm headcount
• Conway, M. (1968), “How Do Committees Invent?” — phát biểu gốc của Conway’s Law
• Schmidt, F. L., & Hunter, J. E. (1998), “The Validity and Utility of Selection Methods in Personnel Psychology” — meta-analysis trên Psychological Bulletin về structured interview và các phương pháp tuyển chọn khác như dự báo hiệu suất công việc
• Google re:Work — Structured Interviewing — hướng dẫn thực tế về rubric, sự độc lập của interviewer, và calibration
• Quy trình “Bar Raiser” của Amazon — một ví dụ về vai trò calibration độc lập được thiết kế để bảo vệ hiring bar dưới áp lực
• roadmap.sh — Engineering Manager — roadmap mà bộ kiến thức này theo sát