Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa tốn ba tháng, hàng chục vòng phỏng vấn và một khoản chi phí tuyển dụng không nhỏ để đưa được một kỹ sư giỏi về đội. Rồi tuần đầu tiên của họ trôi qua như thế này: laptop chưa được cấp quyền truy cập repo, không ai chỉ cho họ cách chạy dự án trên máy local, người mentor được phân công thì đang chạy deadline nên biến mất, và đến cuối tuần họ vẫn chưa mở nổi một pull request nào. Cảm giác của một người mới trong tình huống đó là gì? Lạc lõng, tự nghi ngờ bản thân, và bắt đầu tự hỏi liệu mình có chọn sai chỗ hay không.
Đây không phải là kịch bản hiếm gặp. Ở rất nhiều công ty công nghệ tại Việt Nam và Đông Nam Á, onboarding vẫn bị coi là "việc phụ" — một checklist HR gửi email, cấp tài khoản, rồi phó mặc cho người mới tự bơi. Nhưng với vai trò Tech Lead, bạn cần hiểu một sự thật kinh tế lạnh lùng: thời gian một kỹ sư đạt được năng suất đầy đủ (time-to-productivity) là một trong những chi phí ẩn lớn nhất của đội. Nếu một kỹ sư giỏi mất sáu tháng mới thực sự đóng góp thay vì hai tháng, bạn đã đốt bốn tháng lương của một người senior — và tệ hơn, bạn đã tăng nguy cơ họ nghỉ việc trong năm đầu.
Nghiên cứu về onboarding trong ngành phần mềm cho thấy những kỹ sư có trải nghiệm 90 ngày đầu tốt gắn bó lâu hơn và đạt hiệu suất cao hơn đáng kể. Bài học này sẽ trang bị cho bạn một khung công cụ cụ thể — kế hoạch 30/60/90 ngày — để biến onboarding từ một mớ hỗn độn tùy hứng thành một quy trình có chủ đích, đo lường được, và tạo cảm giác thành công sớm cho người mới.
Khái niệm cốt lõi
Onboarding là gì và không phải là gì
Onboarding không phải là buổi định hướng ngày đầu tiên, cũng không phải là việc phát laptop và tài khoản Slack. Onboarding là toàn bộ quá trình đưa một người từ trạng thái "người ngoài" thành một thành viên đóng góp độc lập, tự tin và gắn kết với đội. Nó bao gồm ba lớp đan xen nhau:
- Technical onboarding: hiểu hệ thống, chạy được code, biết công cụ, quy trình deploy, testing.
- Social onboarding: biết ai làm gì, xây dựng quan hệ, hiểu văn hóa giao tiếp của đội.
- Organizational onboarding: hiểu công ty đang cố gắng đạt điều gì, đội của mình đóng vai trò gì trong bức tranh lớn.
Vì sao lại là 30/60/90 ngày
Con người cần các cột mốc rõ ràng để định hướng và cảm nhận tiến bộ. Ba mốc 30 – 60 – 90 ngày chia quá trình hòa nhập thành ba giai đoạn với trọng tâm khác nhau, tăng dần độ khó và độ tự chủ. Đây là khung được phổ biến rộng rãi trong quản lý và được các đội kỹ thuật ở những công ty như GitLab, Stripe hay Shopify điều chỉnh cho phù hợp với đặc thù engineering.
Mốc 30 ngày — Learning (Học và hòa nhập): Trọng tâm là hiểu và kết nối, không phải tạo ra output lớn. Đến cuối ngày 30, một kỹ sư mới nên:
- Ship được ít nhất một thay đổi nhỏ vào production — dù chỉ là sửa một dòng text, một bug nhỏ, hay thêm một log. Mục tiêu là đi trọn vòng đời từ code → review → merge → deploy để hiểu quy trình.
- Nắm được kiến trúc ở mức cao (high-level architecture): các service chính, luồng dữ liệu, những phần quan trọng nhất.
- Biết tên và vai trò của tất cả thành viên trong đội, đã có ít nhất một buổi trò chuyện 1:1 với từng người.
- Own được một task hoặc một feature vừa phải từ đầu đến cuối mà không cần cầm tay chỉ việc.
- Hiểu sâu một phần (subsystem) của hệ thống — trở thành người biết rõ khu vực đó.
- Bắt đầu tham gia review code của người khác, đóng góp ý kiến trong các cuộc thảo luận kỹ thuật.
- Tham gia vào rotation on-call ở mức shadow (quan sát) nếu đội có on-call.
- Làm việc độc lập ở mức mong đợi của cấp bậc họ được tuyển.
- Đề xuất cải tiến, phát hiện vấn đề mà đội chưa nhìn ra — góc nhìn "người mới" là tài sản quý nếu được khuyến khích lên tiếng.
- Là điểm liên hệ chính (owner) cho ít nhất một khu vực của hệ thống.
- Đã có phản hồi hiệu suất chính thức đầu tiên (thường trùng với mốc kết thúc thử việc theo luật lao động Việt Nam — 60 ngày với vị trí cần chuyên môn cao).
Vai trò của Tech Lead trong onboarding
Nhiều Tech Lead nghĩ onboarding là việc của HR hoặc của mentor được phân công. Sai lầm. Tech Lead là người thiết kế lộ trình kỹ thuật cho người mới: chọn "first task" phù hợp, quyết định ai làm mentor, đảm bảo người mới không bị giao việc quá khó hoặc quá dễ, và theo dõi tín hiệu sớm về sự phù hợp. Bạn không cần tự tay làm tất cả, nhưng bạn chịu trách nhiệm cuối cùng cho kết quả.
Tình huống thực tế
Tình huống 1: Startup fintech Sài Gòn và "tuần đầu tiên tê liệt"
Một startup fintech tại TP.HCM (khoảng 40 kỹ sư, series A) tuyển một backend engineer senior từ một công ty product lớn. Kỳ vọng rất cao. Nhưng tuần đầu tiên là thảm họa: hệ thống có 12 microservice, không có tài liệu setup nào cập nhật, và bạn kỹ sư mới mất trọn ba ngày chỉ để chạy được môi trường local vì thiếu biến môi trường và phải hỏi từng người một cách rời rạc trên Slack.
Tech Lead nhận ra vấn đề khi thấy người mới im lặng bất thường trong daily standup. Anh ngồi lại, làm một việc đơn giản: dựng một checklist onboarding trong Notion và giao cho chính bạn kỹ sư mới nhiệm vụ đầu tiên là cập nhật lại tài liệu setup dựa trên những gì bạn ấy vừa vật lộn. Một mũi tên trúng hai đích: người mới có first task ý nghĩa (ship được thay đổi thật vào cuối tuần một), và đội có tài liệu cập nhật cho người tiếp theo.
Bài học: Người mới chính là "cảm biến" tốt nhất phát hiện chỗ hỏng trong quy trình onboarding, vì họ trải nghiệm nó với con mắt tươi mới. Hãy biến việc cải thiện tài liệu thành first task — vừa tạo giá trị, vừa tạo cảm giác thành công sớm.
Tình huống 2: GitLab và văn hóa onboarding có cấu trúc
GitLab là công ty remote-first hoàn toàn, và họ nổi tiếng vì onboarding được document hóa cực kỳ kỹ. Mỗi người mới có một onboarding issue riêng — một danh sách task được sinh tự động với hàng chục mục có người chịu trách nhiệm rõ ràng, deadline rõ ràng, chia theo tuần. Người mới tự tick từng mục, và mọi người trong đội biết chính xác trạng thái onboarding đến đâu.
Điều đáng học không phải là số lượng task, mà là triết lý: onboarding được đối xử như một dự án có sản phẩm đầu ra và người chịu trách nhiệm, chứ không phải một lời chúc "cố lên nhé". Với đội remote hoặc hybrid — ngày càng phổ biến ở Việt Nam sau 2021 — cách tiếp cận bất đồng bộ và tài liệu hóa này là bắt buộc, vì bạn không thể trông chờ vào việc "quay sang bàn bên hỏi".
Bài học: Đừng để onboarding phụ thuộc vào trí nhớ và thiện chí. Hãy biến nó thành một checklist sống, có người sở hữu từng mục, đặc biệt quan trọng với đội làm việc từ xa.
Tình huống 3: Kỹ sư 90 ngày "vẫn ổn" nhưng thực ra không ổn
Một công ty e-commerce ở Hà Nội tuyển một frontend engineer. Ba tháng trôi qua, bạn ấy vẫn hoàn thành task được giao, không gây rắc rối gì, nên Tech Lead cho qua thử việc mà không suy nghĩ nhiều. Sáu tháng sau, bạn ấy nghỉ việc. Trong buổi exit interview, lý do lộ ra: bạn ấy chưa bao giờ cảm thấy được giao việc đủ thách thức, chưa bao giờ hiểu rõ mình đang phát triển theo hướng nào, và mối quan hệ với đội vẫn hời hợt. "Vẫn ổn" ở ngày 90 hóa ra chỉ là bề nổi.
Bài học: Onboarding không được đo bằng "có gây rắc rối không" mà bằng các tín hiệu chủ động: người mới có đang chủ động đặt câu hỏi khó không? Có đề xuất cải tiến không? Có kết nối xã hội thật sự không? Một mốc 90 ngày tốt cần một cuộc trò chuyện thẳng thắn về sự phát triển, không chỉ một cái tick "pass thử việc".
Hướng dẫn từng bước
Đây là cách bạn triển khai một chương trình onboarding 30/60/90 với vai trò Tech Lead.
Bước 1 — Chuẩn bị trước ngày đầu tiên (Day 0). Đừng để người mới đến rồi mới lo. Trước ngày họ vào: đảm bảo tài khoản, quyền truy cập repo/CI/CD, laptop đã sẵn sàng. Chỉ định một onboarding buddy (người đồng hành, khác với manager) để trả lời những câu hỏi nhỏ mà không sợ ngại. Chọn sẵn first task.
Bước 2 — Chọn "first task" thông minh. First task lý tưởng phải: nhỏ đủ để hoàn thành trong tuần đầu, chạm vào toàn bộ quy trình (code → review → CI → deploy), có giá trị thật (không phải task giả), và ít rủi ro. Ví dụ: sửa một bug nhỏ, cải thiện một message lỗi, cập nhật tài liệu, thêm một test còn thiếu.
Bước 3 — Viết ra kế hoạch 30/60/90 cụ thể cho từng vị trí. Đừng dùng một template chung cho mọi người. Một senior khác một junior, một backend khác một mobile engineer. Viết ra kỳ vọng cụ thể cho mỗi mốc và chia sẻ trực tiếp với người mới ngay tuần đầu để họ biết mình đang được đánh giá theo tiêu chí gì.
Bước 4 — Thiết lập nhịp check-in đều đặn. Tuần đầu: gặp mỗi ngày (dù chỉ 10 phút). Tháng đầu: 1:1 hằng tuần. Từ tháng hai: có thể giãn ra hai tuần một lần. Ở mỗi mốc 30/60/90, tổ chức một buổi review riêng để nhìn lại và điều chỉnh.
Bước 5 — Tăng dần độ tự chủ có chủ đích. Ở giai đoạn 30 ngày, pair programming và review kỹ. Ở 60 ngày, để họ tự dẫn dắt một feature nhưng vẫn sẵn sàng hỗ trợ. Ở 90 ngày, lùi lại và để họ own thật sự. Việc "buông tay" phải là quyết định có chủ đích, không phải vì bạn bận quá nên bỏ mặc.
Bước 6 — Thu thập phản hồi hai chiều. Ở mỗi mốc, hỏi người mới: điều gì trong onboarding hữu ích, điều gì gây khó khăn? Dùng phản hồi đó cải thiện quy trình cho người tiếp theo. Onboarding tốt là một hệ thống tự hoàn thiện.
Lỗi thường gặp & mẹo
Lỗi 1 — Kỳ vọng năng suất quá sớm. Ép người mới "chạy" ngay ngày đầu tạo áp lực phản tác dụng. 30 ngày đầu trọng tâm là học, không phải output. Đo sai giai đoạn sẽ khiến bạn đánh giá nhầm một người giỏi.
Lỗi 2 — First task quá to hoặc quá nhạy cảm. Giao ngay một feature phức tạp chạm vào core system khiến người mới sa lầy hàng tuần mà không có cảm giác thắng lợi nào. Nhỏ và ý nghĩa luôn tốt hơn to và bế tắc.
Lỗi 3 — Không có buddy, dồn hết vào manager. Người mới thường ngại hỏi những câu "ngớ ngẩn" với sếp. Một buddy ngang hàng gỡ bỏ rào cản tâm lý này. Tách vai trò buddy (hỗ trợ hằng ngày) khỏi vai trò manager (đánh giá).
Lỗi 4 — Bỏ quên lớp xã hội và tổ chức. Chỉ lo technical mà quên giới thiệu người, giải thích công ty đang đi đâu. Người mới hiểu code nhưng không hiểu "vì sao" sẽ khó ra quyết định tốt và khó gắn bó.
Lỗi 5 — Onboarding phụ thuộc trí nhớ. Không viết ra thành checklist thì mỗi lần lại thiếu sót một kiểu. Tài liệu hóa một lần, dùng lại mãi mãi.
Mẹo vàng: Khuyến khích người mới ghi lại mọi thứ họ thấy khó hiểu trong 30 ngày đầu và biến đó thành đóng góp cải thiện tài liệu. Đây là "cửa sổ vàng" — sau 90 ngày họ sẽ quen đến mức không còn nhìn thấy những điểm khó cho người mới nữa.
Bài tập thực hành
- Soạn kế hoạch 30/60/90 cho một vị trí cụ thể. Chọn một vị trí trong đội bạn (hoặc giả định) — ví dụ "backend engineer mid-level". Viết ra 3–4 kỳ vọng đo lường được cho mỗi mốc 30, 60, 90 ngày. Yêu cầu: mỗi kỳ vọng phải cụ thể đến mức có thể trả lời "đạt hay chưa đạt".
- Chọn và biện luận first task. Nhìn vào backlog dự án hiện tại của bạn, chọn ra một task phù hợp làm "first task" cho người mới. Viết ba câu giải thích vì sao nó thỏa các tiêu chí: nhỏ, đi trọn quy trình, có giá trị thật, ít rủi ro.
- Audit onboarding hiện tại. Nhớ lại (hoặc phỏng vấn) người gần đây nhất gia nhập đội bạn. Liệt kê ba điều khiến họ mất thời gian oan trong tuần đầu. Với mỗi điều, đề xuất một cải tiến có thể đưa vào checklist onboarding.
- Thiết kế mốc 90 ngày. Viết ra danh sách câu hỏi bạn sẽ dùng trong buổi review 90 ngày để đánh giá không chỉ năng suất, mà cả sự gắn kết xã hội và cảm nhận về hướng phát triển của người mới.
Tóm tắt
Onboarding không phải việc phụ của HR mà là trách nhiệm cốt lõi của Tech Lead, vì thời gian đưa một kỹ sư đạt năng suất là một trong những chi phí ẩn lớn nhất — và trải nghiệm 90 ngày đầu quyết định phần lớn khả năng giữ chân người tài.
Khung 30/60/90 chia quá trình thành ba giai đoạn với trọng tâm tăng dần: 30 ngày là học và hòa nhập (ship một thay đổi nhỏ vào production, hiểu kiến trúc cao cấp, biết tên cả đội); 60 ngày là đóng góp tự chủ (own một feature vừa phải, hiểu sâu một subsystem, bắt đầu review code người khác); 90 ngày là làm chủ (làm việc độc lập ở đúng cấp bậc, đề xuất cải tiến, trở thành owner của một khu vực).
Onboarding có ba lớp — technical, social và organizational — và cả ba đều cần được chăm sóc. Hãy chuẩn bị trước Day 0, chọn first task thông minh, chỉ định buddy tách biệt với manager, viết kế hoạch cụ thể cho từng vị trí, tăng dần độ tự chủ có chủ đích, và biến chính người mới thành cảm biến để cải thiện quy trình. Cuối cùng, đừng đo onboarding bằng "có gây rắc rối không" mà bằng những tín hiệu chủ động: người mới có đặt câu hỏi khó, đề xuất cải tiến và kết nối thật sự với đội hay không.