Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa được thăng chức lên vị trí Engineering Manager của một startup fintech ở TP.HCM. Team bạn có 12 kỹ sư. Một buổi sáng, một bạn Senior gõ cửa và hỏi: "Anh ơi, sao em làm ba năm rồi mà vẫn chưa lên được Staff? Em code nhiều hơn ai hết mà." Bạn ngồi im vài giây, và nhận ra mình… không biết trả lời sao cho đúng. Bởi vì trong đầu bạn, "giỏi" nghĩa là "viết code nhanh và nhiều", còn cái thang bậc thực sự phân biệt Junior, Senior, Staff, Principal thì bạn chưa bao giờ vẽ ra rõ ràng.
Đây là vấn đề rất phổ biến ở các công ty công nghệ Việt Nam đang scale. Khi team còn 5 người, ai làm gì cũng được, không cần thang bậc. Nhưng khi lên 30, 50, 100 kỹ sư, việc thiếu một hệ thống engineering levels rõ ràng sẽ gây ra ba hậu quả nghiêm trọng: người giỏi rời đi vì không thấy con đường phát triển, lương trả không công bằng vì không có chuẩn để so sánh, và các cuộc thăng chức trở thành trò chơi cảm tính "sếp thích ai thì lên".
Bài này giúp bạn hiểu bản chất từng cấp bậc kỹ sư — từ Junior (L3) đến Staff và Principal — không phải theo số năm kinh nghiệm hay số dòng code, mà theo phạm vi ảnh hưởng (scope of impact) và mức độ tự chủ (autonomy). Nắm được điều này, bạn sẽ biết chính xác một kỹ sư đang ở đâu, cần gì để tiến lên, và làm sao đánh giá công bằng. Đây là nền tảng cho toàn bộ các bài về Career Ladder, Performance Review và Compensation ở phía sau.
Khái niệm cốt lõi
Nguyên tắc nền tảng bạn phải khắc cốt ghi tâm: engineering level không đo bằng số năm kinh nghiệm hay kỹ năng code thuần túy, mà đo bằng phạm vi tác động của công việc và mức độ độc lập khi thực hiện.
Có hai trục chính để xác định một cấp bậc:
- Scope (phạm vi ảnh hưởng): Công việc của người này ảnh hưởng đến ai? Một task nhỏ? Cả một feature? Cả một team? Nhiều team? Toàn bộ công ty?
- Autonomy (mức độ tự chủ): Người này cần được chỉ dẫn bao nhiêu? Cần vẽ sẵn task ra từng bước? Tự làm được feature? Hay tự nhìn ra vấn đề mà không ai giao?
Junior Engineer (L3) — 0 đến 2 năm
Đây là điểm khởi đầu. Một Junior nhận một task đã được định nghĩa rõ ràng và hoàn thành nó với sự hướng dẫn (guidance). Ví dụ: "Thêm nút xác nhận vào màn hình thanh toán, khi bấm thì gọi API /confirm". Task đã rõ, đầu vào đầu ra rõ, Junior chỉ cần thực thi.
Đặc trưng của Junior:
- Chất lượng code ở mức ổn sau khi được review — nghĩa là code chạy được, nhưng cần người senior soi lại để bắt lỗi edge case, cải thiện cấu trúc.
- Đang trong giai đoạn học codebase và tooling — hiểu cách deploy, cách chạy test, các quy ước của team.
- Phạm vi ảnh hưởng: gói gọn trong một task cụ thể.
- Cần được hỏi thăm, mentor thường xuyên. Bị "kẹt" (stuck) là chuyện bình thường và nên chủ động hỏi.
Mid-level / Software Engineer (L4) — 2 đến 4 năm
Bước nhảy từ Junior lên Mid-level là chuyển từ "làm task được giao" sang "làm được cả một feature với ít giám sát". Bạn giao cho họ một vấn đề ở mức feature — ví dụ "Xây dựng luồng đăng nhập bằng OTP qua SMS" — và họ tự chia nhỏ, tự làm, tự test, chỉ hỏi khi thực sự vướng.
Đặc trưng của Mid-level:
- Tự chủ ở phạm vi một feature hoàn chỉnh.
- Code chất lượng tốt, ít cần sửa lớn sau review.
- Bắt đầu review code cho người khác và mentor Junior.
- Phạm vi ảnh hưởng: team's codebase — công việc của họ tác động đến cả team.
Senior Engineer (L5) — 4 đến 8 năm
Đây là cấp bậc mà nhiều công ty coi là "điểm dừng chân bền vững" (terminal level — nghĩa là bạn có thể ở đây suốt sự nghiệp mà vẫn được trọng dụng, không bắt buộc phải lên tiếp). Senior không chỉ giải quyết vấn đề — họ định nghĩa vấn đề và thiết kế giải pháp cho những bài toán mơ hồ (ambiguous).
Đặc trưng của Senior:
- Nhận một vấn đề chưa rõ ràng ở cấp độ project, và tự biến nó thành kế hoạch thực thi.
- Chịu trách nhiệm về technical design cho một mảng lớn.
- Là người mà team dựa vào về mặt kỹ thuật; nâng đỡ (level up) những người xung quanh.
- Phạm vi ảnh hưởng: cả team, thậm chí lan sang team lân cận.
Staff Engineer (L6) — Bước ngoặt lớn
Đây là ranh giới quan trọng nhất và cũng dễ hiểu lầm nhất. Bước từ Senior lên Staff không phải là "code giỏi hơn nữa". Một Staff Engineer có thể code ít hơn một Senior. Điểm khác biệt cốt lõi: phạm vi ảnh hưởng vượt ra ngoài team, tác động đến nhiều team hoặc cả một tổ chức.
Staff Engineer làm những việc như:
- Dẫn dắt những dự án kỹ thuật xuyên nhiều team (cross-team technical initiatives).
- Định hình kiến trúc và định hướng kỹ thuật cho cả một mảng lớn của sản phẩm.
- Giải quyết những vấn đề mà không ai giao — họ tự nhìn ra "hệ thống thanh toán của chúng ta sẽ sập ở quy mô 10x" và chủ động dẫn dắt việc giải quyết.
- Nhân bản năng lực của người khác — một Staff giỏi làm cho 20 kỹ sư xung quanh làm việc hiệu quả hơn, thay vì tự mình gánh mọi thứ.
Principal Engineer (L7+) — Tác động cấp công ty
Principal là cấp bậc nơi tác động của một cá nhân ngang tầm với cả một tổ chức. Họ ảnh hưởng đến chiến lược kỹ thuật của toàn công ty, đặt ra các tiêu chuẩn mà hàng trăm kỹ sư tuân theo, và thường là người ra quyết định kỹ thuật có tính "một chiều khó đảo ngược" (liên quan Bài 24 về Type 1 decisions).
Đặc trưng của Principal:
- Phạm vi: toàn công ty, đôi khi ảnh hưởng ra cả ngành (qua open source, hội nghị).
- Định hình technical vision dài hạn (2-5 năm).
- Là "người cuối cùng" mà các Staff và Senior tìm đến khi bế tắc chiến lược.
Bảng tổng hợp: Scope tăng dần
| Cấp | Autonomy | Scope tác động |
|---|---|---|
| Junior (L3) | Cần hướng dẫn từng task | Một task |
| Mid (L4) | Tự làm feature, ít giám sát | Một feature |
| Senior (L5) | Tự định nghĩa & giải bài toán mơ hồ | Cả team |
| Staff (L6) | Tự tìm ra vấn đề chưa ai giao | Nhiều team |
| Principal (L7+) | Định hình chiến lược kỹ thuật | Cả công ty / ngành |
Hai con đường: IC Track và Management Track
Một điểm cực kỳ quan trọng: từ Senior trở lên, sự nghiệp tách làm hai nhánh song song. Nhánh IC (Individual Contributor) đi tiếp lên Staff, Principal — vẫn là kỹ sư, không quản lý người. Nhánh Management rẽ sang EM, Director... Hai nhánh này ngang cấp về lương và tầm ảnh hưởng. Staff Engineer thường được coi là ngang Engineering Manager, Principal ngang Director. Điều này phá vỡ định kiến sai lầm rằng "muốn thăng tiến thì phải đi làm sếp".
Tình huống thực tế
Tình huống 1: Cái bẫy "Senior mãi mãi" tại một startup logistics Hà Nội
Một startup logistics tại Hà Nội có anh Tuấn, code cực nhanh, làm 5 năm, giữ chức Senior. Anh liên tục xin lên Staff và bị từ chối, dẫn đến chán nản và cuối cùng nghỉ việc sang một công ty khác với chức danh "Staff" — nhưng thực chất chỉ là Senior đổi tên.
Diễn giải: Anh Tuấn là một Senior xuất sắc về mặt thực thi. Anh giải quyết mọi task khó nhất được giao. Nhưng anh chưa bao giờ tự tìm ra vấn đề chưa ai giao hay dẫn dắt một sáng kiến xuyên team. Khi có sự cố hệ thống, anh chờ được phân công thay vì đứng ra điều phối cả ba team liên quan. Manager của anh, đáng tiếc, không giải thích rõ ràng rằng khoảng cách Senior → Staff không nằm ở tốc độ code mà ở phạm vi ảnh hưởng và chủ động lãnh đạo kỹ thuật.
Bài học: Nếu bạn là manager, đừng để nhân viên hiểu lầm rằng "code nhiều hơn = lên cấp". Phải chỉ ra cụ thể: "Để lên Staff, em cần dẫn dắt được một dự án chạm tới ít nhất hai, ba team, và cho anh thấy em tự nhìn ra vấn đề trước khi có ai giao." Nếu bạn là kỹ sư, hãy tự hỏi: tác động của mình đang dừng ở phạm vi nào?
Tình huống 2: Grab và mô hình dual-track khi scale lên hàng nghìn kỹ sư
Các công ty công nghệ lớn ở Đông Nam Á như Grab, khi mở rộng tổ chức kỹ thuật lên hàng nghìn người, buộc phải xây dựng career framework với hai nhánh IC và Management rõ ràng (Grab công khai chia sẻ về Tech Family và các cấp bậc kỹ sư của họ). Một kỹ sư giỏi có thể chọn ở lại nhánh IC, lên tới Principal, mà không phải chuyển sang quản lý.
Diễn giải: Trước khi có framework này, nhiều công ty rơi vào cái bẫy kinh điển: kỹ sư giỏi nhất bị "thăng chức" thành manager, rồi trở thành một manager tồi và một kỹ sư đã mất — mất cả hai. Việc tách hai nhánh giải quyết đúng vấn đề đó: người muốn tiếp tục sâu về kỹ thuật có đường đi, người thích dẫn dắt con người có đường riêng.
Bài học: Khi công ty bạn scale, hãy xây dual-track trước khi mất người. Định nghĩa rõ Staff ≈ EM, Principal ≈ Director về cả lương lẫn tầm ảnh hưởng. Đây là tín hiệu mạnh mẽ giữ chân những IC xuất sắc.
Tình huống 3: Cô Junior "nhảy cóc" ở một công ty product Đà Nẵng
Linh, một kỹ sư mới ra trường vào một công ty product ở Đà Nẵng, sau 18 tháng đã được đề xuất lên Mid-level, trong khi đồng nghiệp cùng lứa vẫn ở Junior. Không phải vì Linh code nhanh hơn, mà vì cô đã bắt đầu tự chủ hoàn thành cả một feature (luồng thông báo đẩy) mà chỉ hỏi vài câu, đồng thời viết tài liệu để đồng nghiệp khác dùng lại.
Diễn giải: Cấp bậc không cứng nhắc theo thời gian. Linh thể hiện đúng hành vi của Mid-level: tăng scope từ task lên feature, tăng autonomy. Ngược lại, một người có thể ngồi 3 năm mà vẫn chỉ làm task được vẽ sẵn — đó vẫn là Junior về mặt bản chất, dù thâm niên cao.
Bài học: Đánh giá cấp bậc theo hành vi và tác động thực tế, không theo lịch. Và với tư cách kỹ sư, muốn lên cấp thì hãy chủ động thể hiện hành vi của cấp trên trước khi được thăng — thăng chức là sự công nhận điều đã xảy ra, không phải lời hứa cho tương lai.
Hướng dẫn từng bước
Nếu bạn là manager muốn áp dụng, hoặc là kỹ sư muốn định vị bản thân, đây là quy trình:
- Bỏ tư duy "số năm". Ngừng hỏi "làm mấy năm rồi". Bắt đầu hỏi "công việc của người này tác động đến phạm vi nào, và cần chỉ dẫn bao nhiêu".
- Định vị trên hai trục. Với mỗi kỹ sư, chấm điểm trên hai trục Scope (task → feature → team → nhiều team → công ty) và Autonomy (cần vẽ sẵn → tự làm feature → tự định nghĩa vấn đề → tự tìm vấn đề). Giao điểm cho bạn cấp bậc gần đúng.
- Viết ra "expectations" từng cấp. Với mỗi cấp, viết 3-5 câu mô tả hành vi quan sát được. Ví dụ Senior: "Tự biến bài toán mơ hồ thành kế hoạch", "Là điểm tựa kỹ thuật cho team", "Nâng đỡ người xung quanh". Đây là hạt giống cho Career Ladder (Bài 20).
- Xác định khoảng cách (gap). So sánh vị trí hiện tại với cấp kế tiếp. Liệt kê 2-3 hành vi cụ thể còn thiếu. Ví dụ: "Để lên Staff, cần dẫn dắt một sáng kiến chạm ít nhất 2 team."
- Thiết kế cơ hội, không chỉ chờ đợi. Cấp bậc lên khi có bằng chứng. Manager phải chủ động giao cơ hội tương xứng: giao cho Senior một dự án cross-team để họ chứng minh năng lực Staff.
- Tách IC và Management từ Senior trở lên. Đảm bảo có hai nhánh song song, ngang cấp về lương và ảnh hưởng.
Lỗi thường gặp & mẹo
Lỗi 1: Đánh đồng level với thâm niên. "Làm 5 năm thì phải là Senior." Sai. Có người 5 năm vẫn làm task vẽ sẵn. Mẹo: luôn quy chiếu về scope và autonomy, không về lịch.
Lỗi 2: Nghĩ Staff = code giỏi hơn Senior. Đây là hiểu lầm tai hại nhất. Staff khác Senior ở phạm vi ảnh hưởng vượt ngoài team và khả năng dẫn dắt, không phải tốc độ gõ phím. Mẹo: hỏi "tác động của người này lan tới bao nhiêu team?".
Lỗi 3: Ép mọi IC giỏi phải làm manager để thăng tiến. Kết quả: mất một kỹ sư giỏi, được một manager tồi. Mẹo: xây dual-track và truyền thông rằng Staff ngang EM.
Lỗi 4: Lạm phát chức danh (title inflation). Gọi ai cũng là "Senior" hay "Staff" để giữ chân/tuyển người. Về lâu dài phá hủy ý nghĩa của thang bậc và gây bất công. Mẹo: giữ kỷ luật calibration (đối chiếu chuẩn) giữa các team (liên quan Bài 21).
Lỗi 5: Thăng chức như một "lời hứa". "Cứ cố lên rồi năm sau anh cho lên Staff." Mẹo: thăng chức là sự công nhận hành vi đã xảy ra ở cấp mới, không phải phần thưởng đặt cược vào tương lai.
Mẹo tổng: Với kỹ sư — muốn lên cấp, hãy "hành xử như cấp trên một bậc" trong ít nhất một quý trước khi kỳ vọng được thăng. Với manager — mỗi cuộc 1-1 (Bài 42) nên có một phần bàn về gap tới cấp kế tiếp.
Bài tập thực hành
- Tự định vị: Viết ra công việc lớn nhất bạn làm trong 3 tháng qua. Nó tác động đến phạm vi nào (task/feature/team/nhiều team/công ty)? Bạn cần bao nhiêu chỉ dẫn? Từ đó xác định cấp bậc thực tế của mình — bất kể chức danh hiện tại.
- Vẽ bảng expectations: Chọn hai cấp liền kề (ví dụ Senior và Staff). Viết 3 câu mô tả hành vi quan sát được của mỗi cấp. Đưa cho một đồng nghiệp đọc và hỏi họ có phân biệt được hai cấp không.
- Phân tích gap: Chọn cấp kế tiếp bạn muốn đạt. Liệt kê đúng 2 hành vi cụ thể mà một người ở cấp đó làm còn bạn thì chưa. Thiết kế một hành động trong quý tới để tạo ra bằng chứng.
- Tình huống manager: Anh Tuấn (Tình huống 1) tới gặp bạn xin lên Staff. Viết ra 3 câu bạn sẽ nói để giải thích khoảng cách một cách rõ ràng, cụ thể và tôn trọng.
Tóm tắt
- Engineering level đo bằng scope (phạm vi ảnh hưởng) và autonomy (mức tự chủ), KHÔNG phải số năm hay số dòng code.
- Junior (L3): làm task đã định nghĩa rõ, cần hướng dẫn, đang học codebase. Mid (L4): tự làm cả feature. Senior (L5): tự định nghĩa và giải bài toán mơ hồ, là điểm tựa kỹ thuật của team — cấp "dừng chân bền vững".
- Staff (L6) là bước ngoặt: tác động vượt ra ngoài team, dẫn dắt sáng kiến xuyên nhiều team, tự tìm ra vấn đề chưa ai giao. Không phải "code giỏi hơn Senior".
- Principal (L7+): tác động cấp công ty, định hình chiến lược kỹ thuật dài hạn.
- Từ Senior trở lên, tách IC track và Management track song song, ngang cấp — để không mất người giỏi.
- Thăng chức là sự công nhận hành vi đã xảy ra ở cấp mới, không phải lời hứa. Muốn lên cấp, hãy thể hiện hành vi của cấp đó trước.