1. Mở Đầu: Tại Sao Engineering Manager Cần Quản Lý Theo Mục Tiêu?
Trong môi trường kỹ thuật hiện đại, vai trò của một Engineering Manager (EM) không phải là ngồi đếm số dòng code, đo số lượng commit hay soi xét từng giờ làm việc của kỹ sư trên Jira. Những chỉ số đo lường đầu ra đơn thuần (Output metrics) đó chỉ tạo ra ảo tưởng về năng suất và dẫn đến thói quen chống đối hoặc tối ưu hóa số liệu ảo (gaming the system).
Quản lý theo Mục tiêu (Management by Objectives - MBO) — cùng các biến thể cải tiến như OKRs (Objectives and Key Results) hay SMART Goals — dịch chuyển trọng tâm quản lý từ Hoạt động (Activities / Output) sang Giá trị thực tế (Outcomes / Business Impact).
TƯ DUY QUẢN LÝ CŨ (OUTPUT-DRIVEN) TƯ DUY QUẢN LÝ MỚI (OUTCOME-DRIVEN)
┌──────────────────────────────┐ ┌───────┐
│ - Số lượng Ticket hoàn thành│ │ - Tốc độ phản hồi API (p95) │
│ - Số giờ Log-time trên Jira │ VS │ - Tỷ lệ Uptime hệ thống │
│ - Số dòng Code viết ra │ │ - Mức độ hài lòng người dùng│
│ - "Thợ gõ phím" thụ động │ │ - Sự chủ động & Tự chủ │
└──────────────────────────────┘ └───────┘
Áp dụng thành công quản lý theo mục tiêu giúp EM:
- Tạo khoảng thở tự chủ (Autonomy): Cho phép đội ngũ tự do lựa chọn phương án kỹ thuật tốt nhất để đạt được kết quả mong muốn.
- Đồng bộ hóa nguồn lực (Alignment): Đảm bảo mọi dòng code kỹ sư viết ra đều đóng góp trực tiếp vào định hướng kinh doanh của công ty.
- Đánh giá hiệu suất minh bạch (Fair Performance Review): Loại bỏ tính cảm quan, thiên vị dựa trên số liệu định lượng rõ ràng.
2. Các Khung Quản Lý Theo Mục Tiêu Phổ Biến Trong Kỹ Thuật (MBO, OKRs & SMART)
Để quản lý hiệu quả, EM cần hiểu rõ cách vận dụng linh hoạt từng khung mục tiêu vào đúng bối cảnh:
[ BỨC TRANH TỔNG THỂ MỤC TIÊU ]
│
┌────────────────────────────────┴─────┐
▼ ▼
[ KHUNG STRATEGIC: OKRs ] [ KHUNG TACTICAL: SMART ]
Objectives: Tầm nhìn định tính Specific: Cụ thể & Rõ ràng
Key Results: Kết quả định lượng Measurable: Đo lường được
Thời gian: Quý / Năm (Quarterly/Yearly) Achievable: Khả thi
Tính chất: Thử thách, bứt phá (Stretch) Relevant: Thích hợp
Time-bound: Giới hạn thời gian
Thời gian: Sprint / Tháng
2.1. Khung Mục Tiêu OKRs (Objectives and Key Results)
Phù hợp nhất cho mục tiêu cấp Team, Bộ phận hoặc Dự án lớn theo Quý.
- Objective (O - Mục tiêu): Tuyên bố định tính, mang tính truyền cảm hứng, trả lời câu hỏi "Chúng ta muốn đạt được điều gì?".
- Key Results (KRs - Kết quả cốt lõi): 3–5 chỉ số định lượng khắt khe, trả lời câu hỏi "Làm sao để biết chúng ta đã đạt được mục tiêu đó?".
2.2. Khung Mục Tiêu SMART
Phù hợp nhất cho mục tiêu cá nhân (Individual Goals) trong các đợt Review hiệu suất hoặc bài toán kỹ thuật cụ thể trong Sprint.
- Specific (Cụ thể): Không nói "Tối ưu database", hãy nói "Giảm thời gian truy vấn bảng Orders".
- Measurable (Đo lường được): Giảm từ 800ms xuống dưới 150ms.
- Achievable (Tính khả thi): Đã có giải pháp Indexing và Redis caching rõ ràng.
- Relevant (Tính liên quan): Trực tiếp giúp giảm tỷ lệ timeout khi người dùng thanh toán.
- Time-bound (Hạn chót): Hoàn thành trước ngày 15 tháng sau.
3. Khung Quy Trình 5 Bước Triển Khai Quản Lý Theo Mục Tiêu Dành Cho Dev Manager
Dưới đây là lộ trình 5 bước giúp EM áp dụng quản lý theo mục tiêu một cách bài bản, từ khâu thiết lập đến khâu đánh giá:
[ Bước 1: Tiếp Nhận & Dịch Chuyển Mục Tiêu Cấp Trên (Cascading Alignment) ]
│
▼
[ Bước 2: Thảo Luận & Đồng Thiết Lập Mục Tiêu (Co-creation & Buy-in) ]
│
▼
[ Bước 3: Cụ Thể Hóa Thành Lộ Trình Kỹ Thuật (Mapping to Engineering Execution) ]
│
▼
[ Bước 4: Theo Dõi, Đánh Giá & Unblock Định Kỳ (Check-in & Tracking) ]
│
▼
[ Bước 5: Tổng Kết, Đánh Giá Hiệu Suất & Rút Kinh Nghiệm (Retrospective & Scoring) ]
Bước 1: Tiếp Nhận & Dịch Chuyển Mục Tiêu Cấp Trên (Cascading Alignment)
Mục tiêu của team kỹ thuật không thể tách rời chiến lược công ty. EM cần tham gia các buổi họp chiến lược với Ban Giám đốc và Product Director để nắm rõ ưu tiên hàng đầu của doanh nghiệp.
- Ví dụ dịch chuyển:
- Mục tiêu Công ty: "Nâng cao trải nghiệm giữ chân người dùng (Retention Rate) trên ứng dụng Mobile."
- Mục tiêu Team Engineering: "Cải thiện độ ổn định và hiệu năng ứng dụng Mobile để loại bỏ tình trạng giật lag và gián đoạn trải nghiệm."
Bước 2: Thảo Luận & Đồng Thiết Lập Mục Tiêu (Co-creation & Buy-in)
Một cạm bẫy lớn là EM tự mình áp đặt 100% mục tiêu từ trên xuống (Top-down). Lập trình viên sẽ chỉ coi đó là "việc của Sếp" và thiếu tinh thần làm chủ.
- Quy tắc 60/40:
- 60% Mục tiêu do EM định hướng dựa trên chiến lược công ty.
- 40% Mục tiêu do chính các Kỹ sư đề xuất từ dưới lên (Bottom-up) — ví dụ: trả nợ kỹ thuật, nâng cấp công cụ CI/CD, cải tiến quy trình kiểm thử.
Bước 3: Cụ Thể Hóa Thành Lộ Trình Kỹ Thuật (Mapping to Engineering Execution)
Sau khi chốt OKRs/SMART Goals, EM cùng Tech Lead cần quy đổi các chỉ số này thành các công việc kỹ thuật cụ thể trong Backlog:
[ Objective: Tối ưu hiệu năng ứng dụng Mobile ]
│
├─► [ Key Result 1: Giảm tỷ lệ Crash xuống dưới 0.1% ]
│ ├─ Task: Nâng cấp SDK Firebase & Sentry
│ └─ Task: Fix top 5 lỗi Memory Leak trên Android
│
└─► [ Key Result 2: Giảm thời gian Cold Start ứng dụng xuống < 1.5s ]
├─ Task: Tối ưu luồng Lazy Loading tài nguyên khi khởi động
└─ Task: Chuyển đổi mã nguồn khởi tạo sang dạng bất đồng bộ (Async)
Bước 4: Theo Dõi, Đánh Giá & Unblock Định Kỳ (Check-in & Tracking)
Đừng bao giờ giao mục tiêu đầu quý rồi bỏ đó đến cuối quý mới mở ra kiểm tra. Mục tiêu phải được sống trong từng chu kỳ làm việc:
- Hàng tuần (Weekly Check-in): Dành 15–20 phút trong buổi họp Team để đánh giá tiến độ chỉ số confidence score (0.0 đến 1.0) cho từng Key Result.
- Trong họp 1:1: Thảo luận với từng cá nhân về tiến độ mục tiêu cá nhân, lắng nghe những rào cản (blockers) và giúp họ tháo gỡ.
Bước 5: Tổng Kết, Đánh Giá Hiệu Suất & Rút Kinh Nghiệm (Retrospective & Scoring)
Cuối kỳ (theo Quý/Năm), EM cùng team tiến hành đánh giá lại mức độ hoàn thành:
- Thang điểm OKRs chuẩn (0.0 - 1.0):
- 0.6 – 0.7: Mức độ hoàn thành lý tưởng cho các mục tiêu thử thách (Stretch Goals).
- 1.0: Rất tốt, nhưng có thể mục tiêu đặt ra quá an toàn.
- < 0.4: Cần phân tích nguyên nhân kỹ lưỡng (Do ước lượng sai, nguồn lực bị rút bớt hay năng lực thực thi có vấn đề).
4. Xây Dựng Bộ Chỉ Số Đo Lường Mục Tiêu Kỹ Thuật (Engineering Goal Metrics)
Để tránh đặt mục tiêu mơ hồ, EM có thể tham khảo bộ khung chỉ số kỹ thuật tiêu chuẩn đã được chứng minh hiệu quả:
| Nhóm Mục Tiêu | Chỉ Số Đo Lường Cụ Thể (Metrics) | Ví Dụ Thiết Lập OKR / SMART |
| Giao Hàng & Tốc Độ (Delivery & Velocity) | - Lead Time for Changes - Deployment Frequency - Cycle Time | Giảm Cycle Time từ khi mở PR đến khi Deploy lên Production từ 48 giờ xuống dưới 12 giờ. |
| Chất Lượng & Tin Cậy (Quality & Reliability) | - Change Failure Rate - Mean Time to Recovery (MTTR) - Uptime / Availability (SLA) | Đạt chỉ số Availability 99.9% cho dịch vụ Payment API và giảm MTTR sự cố P1 xuống dưới 30 phút. |
| Hiệu Năng Hệ Thống (System Performance) | - p95 / p99 Latency - API Throughput (RPS) - Resource Utilization (CPU/RAM) | Tối ưu hóa Database Query giúp giảm p95 Latency của API Tìm kiếm từ 450ms xuống 120ms. |
| Xuất Sắc Kỹ Thuật (Tech Excellence & Debt) | - Code Coverage - Static Analysis Issues (SonarQube) - Flaky Tests Rate | Nâng Test Coverage toàn bộ module Core từ 60% lên 80% và giảm 100% các lỗi Security High Risk. |
| Phát Triển Con Người (People & DevEx) | - Developer Experience (DevEx) Survey - Internal Knowledge Sharing - Onboarding Time | Tự động hóa Environment Setup giúp rút ngắn thời gian Onboarding Dev mới từ 5 ngày xuống 1 ngày. |
5. Kỹ Năng Mềm Hỗ Trợ Quản Lý Theo Mục Tiêu Cho Dev Manager
Quản lý theo mục tiêu không chỉ là kỹ thuật xử lý số liệu, mà là nghệ thuật dẫn dắt tâm lý con người:
| Kỹ Năng Mềm | Tác Động Đến Quá Trình Quản Lý Theo Mục Tiêu |
| Trao Quyền & Tin Tưởng (Delegation & Trust) | Sẵn sàng giao lại quyền quyết định giải pháp kỹ thuật cho team sau khi đã thống nhất về mục tiêu (Outcome). |
| Phản Hồi Xây Dựng (Constructive Feedback) | Sử dụng dữ liệu mục tiêu để đưa ra phản hồi công tâm trong họp 1:1, giúp nhân sự nhận ra điểm nghẽn mà không cảm bị tấn công cá nhân. |
| Nghệ Thuật Thương Lượng (Negotiation) | Thương lượng với Product Manager và Ban Giám đốc để bảo vệ Capacity dành cho các mục tiêu kỹ thuật (Tech Debt/Refactoring). |
| Tư Duy Mở (Growth Mindset) | Coi việc không đạt 100% mục tiêu thử thách là cơ hội học hỏi và cải tiến quy trình, thay vì trừng phạt đội ngũ. |
6. Các Cạm Bẫy Cần Tránh Trong Quản Lý Theo Mục Tiêu (MBO Anti-Patterns)
- Gắn 100% Kết Quả OKRs Với Thưởng/Pha Lương Direct: Nếu biến OKRs thành tiêu chí duy nhất để xét thưởng, lập trình viên sẽ có xu hướng đặt mục tiêu cực kỳ an toàn (Sandbagging) để chắc chắn đạt 100%, triệt hạ hoàn toàn tinh thần đổi mới sáng tạo.
- Quá Nhiều Mục Tiêu (Goal Overload): Đặt ra 10–15 OKRs cho một team trong 1 quý. Điều này khiến nguồn lực bị phân tán, team rơi vào tình trạng "mục tiêu nào cũng quan trọng nên không có mục tiêu nào là ưu tiên". Lời khuyên: Chỉ giữ 2–4 Objectives trọng tâm cho mỗi kỳ.
- Mục Tiêu Thiếu Sự Linh Hoạt (Rigid Goals): Bắt buộc team bám chặt vào mục tiêu đặt ra từ đầu quý dù tình hình thị trường hoặc chiến lược công ty đã thay đổi hoàn toàn.
- Nhầm Lẫn Giữa Task Báo Cáo Và Key Result: Đặt Key Result dạng "Viết xong tài liệu A", "Họp xong buổi B". Đây chỉ là các Task/Output. Key Result phải đo lường được kết quả: "100% Dev mới sử dụng tài liệu A có thể tự setup môi trường thành công trong ngày đầu tiên".
Lời Kết
Quản lý theo mục tiêu là chiếc cầu nối vững chắc giúp Engineering Manager giải bài toán cân bằng giữa kỳ vọng kinh doanh khắt khe và khát khao sáng tạo kỹ thuật của đội ngũ lập trình.
Khi thiết lập được hệ thống mục tiêu rõ ràng, minh bạch và có tính thử thách, bạn không chỉ giải phóng bản thân khỏi thói quen quản lý tiểu tiết (Micromanagement), mà còn tạo ra một môi trường làm việc nơi mỗi kỹ sư đều hiểu rõ giá trị công việc của mình, tự chủ trong hành động và cùng nhau chinh phục những đỉnh cao mới về công nghệ lẫn sản phẩm.
){kind=link}
0 Nhận xét