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 trời, phỏng vấn hàng chục ứng viên, cạnh tranh với đủ loại công ty khác để cuối cùng chốt được một kỹ sư giỏi. Rồi ngày đầu tiên đi làm, người đó đến văn phòng, ngồi xuống, và... không có laptop. Không có tài khoản đăng nhập hệ thống. Không có ai được phân công dẫn dắt. Người quản lý thì đang bận họp cả ngày. Đến trưa, người mới ngồi lướt điện thoại vì chẳng biết làm gì.
Nghe có vẻ cường điệu, nhưng đây là câu chuyện có thật diễn ra ở rất nhiều công ty công nghệ tại Việt Nam mỗi tuần. Và cái giá của nó lớn hơn bạn tưởng. Một khảo sát của công ty tuyển dụng thường được trích dẫn cho thấy: nhân viên có trải nghiệm onboarding tốt gắn bó với công ty cao hơn 58% sau ba năm, và đạt hiệu suất làm việc đầy đủ nhanh hơn tới 34%. Ngược lại, gần một nửa số nhân viên nghỉ việc trong 90 ngày đầu đều nói rằng lý do bắt nguồn từ việc onboarding hỗn loạn, mờ mịt kỳ vọng.
Onboarding không phải là thủ tục hành chính ngày đầu. Đó là một quy trình có thiết kế, kéo dài xuyên suốt 90 ngày đầu tiên, với mục tiêu rõ ràng: biến một người "ngoài cuộc" thành một thành viên đóng góp toàn diện nhanh nhất có thể mà không đốt cháy họ. Trong bài này, chúng ta sẽ đi sâu vào công cụ kinh điển và hiệu quả nhất để làm điều đó: kế hoạch 30-60-90 ngày.
Khái niệm cốt lõi
30-60-90 Day Plan là gì
30-60-90 day plan là một bản kế hoạch chia hành trình hội nhập của nhân viên mới thành ba giai đoạn 30 ngày, mỗi giai đoạn có một trọng tâm và kết quả kỳ vọng riêng. Triết lý nền tảng rất đơn giản: học trước, làm sau, tự chủ sau cùng. Bạn không thể đòi một người vừa vào ngày thứ 5 phải "own một feature". Nhưng nếu đến ngày thứ 60 họ vẫn chưa dám sờ vào codebase thì cũng có vấn đề.
Ba giai đoạn tương ứng với ba động từ:
- 30 ngày đầu — Learn (Học và Quan sát): Hiểu sản phẩm, hiểu team, hiểu quy trình, thiết lập môi trường, và ship một thứ nhỏ để "phá băng".
- 60 ngày — Contribute (Đóng góp có kiểm soát): Bắt đầu sở hữu một mảng công việc thực sự, làm việc với sự giám sát vừa phải.
- 90 ngày — Own & Perform (Tự chủ và Đóng góp toàn diện): Vận hành như một thành viên chính thức của team, ra quyết định độc lập trong phạm vi vai trò.
Vì sao chia thành ba cột mốc 30 ngày
Con số 30 ngày không phải ngẫu nhiên. Nó đủ dài để một người tạo ra kết quả có ý nghĩa, nhưng đủ ngắn để cả người mới lẫn quản lý cảm nhận được đà tiến (momentum). Trong tâm lý học, chúng ta gọi đây là "small wins" — những chiến thắng nhỏ giúp duy trì động lực. Nếu bạn chỉ nói với người mới "sau 6 tháng em sẽ giỏi", họ sẽ mất phương hướng trong tuần đầu. Nhưng nếu bạn nói "trong 30 ngày em cần ship được X", họ có mục tiêu cụ thể để bám vào.
Ba cột mốc cũng tạo ra ba điểm kiểm tra tự nhiên (checkpoint) để quản lý đánh giá xem người mới có đang đi đúng hướng không. Đây chính là cơ chế phát hiện sớm: nếu đến ngày 30 mà một kỹ sư vẫn chưa setup được môi trường dev, đó là tín hiệu cảnh báo cần can thiệp ngay, chứ không đợi đến khi thử việc kết thúc mới ngã ngửa.
Ba tầng hội nhập: Kỹ thuật, Xã hội, Văn hóa
Một sai lầm phổ biến là chỉ tập trung onboarding về mặt kỹ thuật — cho người ta quyền truy cập, chỉ họ codebase, xong. Nhưng một người hội nhập thành công cần cả ba tầng:
- Hội nhập kỹ thuật (Technical): Công cụ, hệ thống, kiến trúc, quy trình làm việc.
- Hội nhập xã hội (Social): Biết ai là ai, ai phụ trách gì, mình có thể hỏi ai khi bí.
- Hội nhập văn hóa (Cultural): Hiểu "cách chúng ta làm việc ở đây" — những giá trị, chuẩn mực bất thành văn.
Tình huống thực tế
Ví dụ 1: Tiki và câu chuyện "ship trong tuần đầu"
Tại một công ty thương mại điện tử lớn ở Việt Nam (chúng ta gọi giả định là mô hình kiểu Tiki), đội kỹ thuật từng gặp vấn đề: kỹ sư mới trung bình mất tới 3 tuần mới tạo được pull request đầu tiên. Lý do không phải họ kém, mà vì môi trường dev quá phức tạp, tài liệu tản mát, và không ai biết "task đầu tiên nên là gì".
Team lead quyết định thiết kế lại. Họ tạo ra một danh mục "good first issues" — những lỗi nhỏ, những dòng text cần sửa, những cải tiến giao diện đơn giản đã được gắn nhãn sẵn trong hệ thống. Mỗi kỹ sư mới được phân công một "onboarding buddy" (người đồng hành, không phải sếp) ngồi cùng trong 2 giờ đầu ngày thứ nhất để setup môi trường theo một checklist chuẩn.
Kết quả: thời gian trung bình để ship pull request đầu tiên giảm từ 3 tuần xuống còn 4 ngày. Bài học rút ra: cái cảm giác "mình đã đóng góp được thứ gì đó" trong tuần đầu có sức mạnh tâm lý khổng lồ. Nó biến người mới từ trạng thái lo lắng "liệu mình có làm được không" sang trạng thái tự tin "à, hóa ra mình làm được đây". Đó chính là tinh thần của cột mốc Day 30.
Ví dụ 2: Grab và cái giá của onboarding hời hợt
Ở một công ty công nghệ khu vực Đông Nam Á quy mô lớn (mô hình kiểu Grab), một quản lý sản phẩm mới được tuyển vào với kỳ vọng rất cao. Nhưng trong 60 ngày đầu, người này gần như bị "thả trôi" — quản lý trực tiếp bận rộn liên tục, không có kế hoạch cụ thể, chỉ nói "em cứ tìm hiểu dần đi". Đến ngày thứ 70, người này trình bày một đề xuất tính năng lớn trong cuộc họp, nhưng bị phản bác gay gắt vì đề xuất đó đã từng bị team thử và thất bại một năm trước — một thông tin mà lẽ ra onboarding phải truyền đạt.
Người quản lý sản phẩm này cảm thấy mất mặt, mất niềm tin, và nghỉ việc sau 4 tháng. Chi phí thay thế một vị trí cấp trung như vậy, tính cả tuyển dụng lại và thời gian mất năng suất, ước tính bằng 6-9 tháng lương của vị trí đó.
Bài học: onboarding không chỉ là dạy làm việc, mà còn là truyền đạt bối cảnh và lịch sử. Cái người mới thiếu không phải năng lực, mà là "context" — những gì team đã thử, đã học, đã quyết định. Giai đoạn 30-60 ngày chính là lúc phải nạp context này một cách có hệ thống, chứ không để người mới tự vấp ngã rồi mới học.
Ví dụ 3: Một startup fintech và "reverse onboarding"
Một startup fintech ở TP.HCM khoảng 40 người áp dụng một cách làm thú vị. Ở cột mốc Day 30, họ yêu cầu mỗi nhân viên mới viết một tài liệu ngắn gọi là "fresh eyes report" — báo cáo góc nhìn tươi mới. Trong đó, người mới ghi lại tất cả những gì họ thấy khó hiểu, rườm rà, hoặc vô lý trong 30 ngày đầu: tài liệu nào lỗi thời, quy trình nào phiền phức, công cụ nào khó dùng.
Vì sao? Vì sau 3 tháng, ai cũng "mù" trước những vấn đề đó do đã quen. Chỉ người mới mới nhìn ra. Startup này thu được hàng loạt cải tiến quy trình miễn phí, đồng thời người mới cảm thấy tiếng nói của mình có giá trị ngay từ đầu — một cú hích lớn cho sự gắn kết.
Bài học: onboarding là con đường hai chiều. Người mới không chỉ nhận, mà còn cho. Biến giai đoạn quan sát của họ thành một tài sản cho tổ chức là một thiết kế thông minh.
Hướng dẫn từng bước
Dưới đây là cách xây dựng một kế hoạch 30-60-90 cụ thể cho một kỹ sư mới. Bạn có thể điều chỉnh cho các vai trò khác.
Bước 0: Chuẩn bị trước Day 1 (Pre-boarding)
Đây là bước bị bỏ quên nhiều nhất nhưng quyết định ấn tượng đầu tiên. Trước khi người mới đến, hãy đảm bảo:
- Laptop đã được chuẩn bị và cài đặt sẵn phần mềm cơ bản.
- Tài khoản email, Slack, GitHub, các hệ thống nội bộ đã được tạo (hoặc quy trình cấp quyền đã sẵn sàng để hoàn tất trong buổi sáng đầu tiên).
- Một email chào mừng gửi trước, nói rõ giờ đến, gặp ai, mang gì.
- Buddy đã được chỉ định và thông báo.
- Kế hoạch 30-60-90 đã được soạn sẵn để trao cho người mới ngay ngày đầu.
Bước 1: Day 1 — Welcome và thiết lập nền tảng
Mục tiêu ngày đầu không phải là làm việc, mà là làm cho người mới cảm thấy được chào đón và không bị lạc lối. Cụ thể:
- Đón tiếp, giới thiệu team, đi một vòng làm quen.
- Buddy ngồi cùng hoàn tất setup môi trường: truy cập hệ thống, cài công cụ, clone codebase, chạy được dự án trên máy.
- Trao kế hoạch 30-60-90 và cùng đọc qua để người mới biết trước lộ trình.
- Ăn trưa cùng team — nghe có vẻ nhỏ nhưng đây là hoạt động hội nhập xã hội cực kỳ hiệu quả.
Bước 2: Thiết kế mục tiêu Day 30 — Learn & Ship Small
Viết ra 3-5 mục tiêu cụ thể, đo được. Ví dụ cho kỹ sư:
- Hoàn tất tất cả khóa học onboarding nội bộ và đọc tài liệu kiến trúc hệ thống.
- Ship ít nhất một pull request nhỏ đã được merge (bug fix hoặc cải tiến nhỏ).
- Có 1-1 với ít nhất 5 thành viên chủ chốt trong và ngoài team.
- Hiểu được luồng làm việc: từ khi nhận task đến khi deploy lên production.
Bước 3: Thiết kế mục tiêu Day 60 — Own a Feature
Đến giai đoạn này, người mới bắt đầu sở hữu công việc thực sự nhưng vẫn có giám sát:
- Sở hữu và hoàn thành một tính năng nhỏ hoặc một mảng công việc từ đầu đến cuối.
- Tham gia code review cho người khác (không chỉ nhận review).
- Bắt đầu tham gia on-call hoặc trực hỗ trợ ở mức độ có người kèm.
- Nắm được các quyết định kỹ thuật quan trọng và lý do đằng sau chúng.
Bước 4: Thiết kế mục tiêu Day 90 — Full Contributor
Đây là đích đến: người mới vận hành như một thành viên chính thức:
- Đóng góp độc lập trong phạm vi vai trò, không cần giám sát sát sao.
- Chủ động nhận task, ước lượng thời gian, và giao đúng hẹn.
- Có khả năng dẫn dắt một mảng nhỏ hoặc mentor một người còn mới hơn.
- Đưa ra ít nhất một đề xuất cải tiến có giá trị cho team hoặc quy trình.
Bước 5: Lịch check-in đều đặn
Kế hoạch chỉ sống nếu có nhịp kiểm tra. Đề xuất: 1-1 với quản lý mỗi tuần trong tháng đầu, hai tuần một lần sau đó, và ba buổi review chính thức tại các mốc ngày 30, 60, 90. Mỗi buổi review, cùng nhau đối chiếu kế hoạch với thực tế và điều chỉnh nếu cần.
Lỗi thường gặp & mẹo
Lỗi 1 — Không chuẩn bị gì cho ngày đầu. Đây là lỗi chết người về mặt ấn tượng. Người mới nhớ mãi cảm giác ngày đầu bị bỏ rơi. Mẹo: có một checklist pre-boarding cố định, giao cho một người chịu trách nhiệm rõ ràng, không để "ai cũng lo nghĩa là không ai lo".
Lỗi 2 — Kỳ vọng người mới đóng góp lớn quá sớm. Áp lực bắt junior "own feature" trong tuần đầu chỉ khiến họ hoảng loạn và làm ẩu. Mẹo: tôn trọng nguyên tắc học trước, làm sau. Ship nhỏ ở Day 30 mới là chuẩn.
Lỗi 3 — Onboarding không có chủ nhân. Khi cả HR, quản lý, và team đều nghĩ người kia lo, rốt cuộc chẳng ai lo. Mẹo: mỗi người mới cần một manager chịu trách nhiệm về kế hoạch và một buddy chịu trách nhiệm về hỗ trợ hàng ngày. Hai vai trò tách biệt.
Lỗi 4 — Dùng chung một template cho mọi người. Kế hoạch của một senior khác hoàn toàn kế hoạch của một fresher. Mẹo: giữ khung 30-60-90 nhưng cá nhân hóa mục tiêu theo cấp độ và vai trò.
Lỗi 5 — Quá tải thông tin ngày đầu. Nhồi 20 buổi họp giới thiệu trong tuần đầu khiến người mới quá tải, chẳng nhớ gì. Mẹo: rải thông tin theo nhịp, ưu tiên "just-in-time" — dạy cái gì khi người ta cần dùng nó.
Mẹo vàng — Biến kế hoạch thành tài liệu sống. Đừng để 30-60-90 nằm chết trong một file. Hãy đưa nó vào công cụ theo dõi (Notion, Trello) mà cả người mới và quản lý cùng nhìn thấy, cùng tick, cùng cập nhật.
Bài tập thực hành
- Soạn kế hoạch 30-60-90 cho chính vai trò của bạn. Giả sử ngày mai có một người mới thay thế vị trí của bạn. Hãy viết ra 3-5 mục tiêu cụ thể, đo được cho từng mốc 30, 60, 90 ngày. Nếu bạn thấy khó viết, đó là dấu hiệu vai trò của bạn chưa được định nghĩa rõ.
- Thiết kế checklist pre-boarding. Liệt kê tất cả những gì cần chuẩn bị trước ngày đầu của một nhân viên mới ở công ty bạn: phần cứng, tài khoản, quyền truy cập, con người. Rồi tự chấm điểm: hiện tại công ty bạn đang làm được bao nhiêu phần trong danh sách đó?
- Phỏng vấn một đồng nghiệp mới. Tìm một người vào công ty trong 6 tháng gần đây và hỏi ba câu: Điều gì trong 90 ngày đầu khiến bạn bối rối nhất? Bạn ước gì đã được chuẩn bị tốt hơn? Khoảnh khắc nào khiến bạn cảm thấy mình thực sự thuộc về team? Ghi lại và rút ra ít nhất một cải tiến cho quy trình onboarding.
Tóm tắt
Onboarding không phải thủ tục hành chính, mà là một khoản đầu tư có thiết kế quyết định việc nhân viên mới sẽ ở lại và tỏa sáng, hay ra đi trong âm thầm. Công cụ mạnh nhất để thiết kế nó là kế hoạch 30-60-90 ngày, với triết lý cốt lõi: học trước, làm có kiểm soát, rồi tự chủ.
- Day 1 lo về ấn tượng và nền tảng: laptop, quyền truy cập, chào đón, và trao lộ trình rõ ràng.
- Day 30 là học và ship một thứ nhỏ để tạo đà tâm lý.
- Day 60 là sở hữu một mảng công việc thực sự dưới sự giám sát vừa phải.
- Day 90 là vận hành như một thành viên toàn diện, đóng góp độc lập.