INFOCHIEF ACADEMY · IT MANAGER KNOWLEDGE SERIES

Giao việc và phân quyền cho nhân viên IT: Tránh hai cực đoan buông lỏng và quản lý vi mô.

Hai cực đoan thường xuất hiện cùng một nguồn gốc: người quản lý chưa thiết kế rõ quyền quyết định. Khi không rõ nhân viên được tự quyết đến đâu, trưởng phòng hoặc can thiệp vào từng chi tiết, hoặc giao một câu “em tự xử lý đi” rồi chỉ xuất hiện khi có vấn đề. Giao việc chuyên nghiệp nằm ở khoảng giữa: mục tiêu rõ, quyền hạn đủ, ranh giới kiểm soát minh bạch và cơ chế hỗ trợ có chủ đích.

Biên soạn: Infochief Academy · Chuyên đề: Trưởng Phòng IT Chuyên Nghiệp – IT Manager

← Trở về danh mục IT Manager

Minh họa biên tập: giao việc hiệu quả cần đồng thời làm rõ mục tiêu, quyền hạn, hỗ trợ và trách nhiệm.

Vì sao trưởng phòng IT dễ rơi vào quản lý vi mô?

Nhiều IT Manager được thăng chức từ chuyên gia kỹ thuật. Khi gặp một vấn đề khó, phản xạ tự nhiên là đi sâu vào log, cấu hình hoặc giải pháp vì đó là vùng năng lực quen thuộc. Trong ngắn hạn, cách này có thể làm công việc nhanh hơn. Nhưng nếu lặp lại, đội ngũ học được rằng quyết định quan trọng cuối cùng vẫn phải chờ sếp; trưởng phòng trở thành nút thắt và nhân viên không phát triển khả năng phán đoán.

Quản lý vi mô cũng thường xuất hiện khi tiêu chuẩn đầu ra mơ hồ. Nếu chỉ nói “xử lý sự cố này” mà không nêu mức tác động chấp nhận được, điều kiện rollback, thời hạn cập nhật hay ai phải được thông báo, người quản lý sẽ có xu hướng hỏi liên tục để bù cho phần chưa được thiết kế. Vấn đề không phải trưởng phòng “quá kiểm soát” về tính cách; nhiều khi hệ thống giao việc khiến họ buộc phải kiểm tra chi tiết.

Ngược lại, buông lỏng xảy ra khi người quản lý giao cả trách nhiệm lẫn rủi ro cho nhân viên nhưng không cung cấp quyền, thông tin hoặc hỗ trợ. Đây không phải empowerment. Trao quyền đúng nghĩa yêu cầu một cấu trúc giúp người nhận việc hiểu điều họ được phép quyết định và khi nào phải báo cáo.

Tách ba khái niệm: trách nhiệm, quyền hạn và accountability

Giao việc tốt bắt đầu bằng việc phân biệt ba thứ thường bị trộn lẫn. Responsibility là phần việc phải thực hiện; authority là quyền được ra quyết định hoặc sử dụng nguồn lực trong phạm vi đã định; accountability là nghĩa vụ giải trình về kết quả. Một nhân viên có thể chịu trách nhiệm triển khai thay đổi nhưng không có quyền phê duyệt downtime. Một trưởng nhóm có quyền phê duyệt trong cửa sổ bảo trì nhưng vẫn phải giải trình về tác động dịch vụ.

Khi responsibility lớn hơn authority, nhân viên dễ mắc kẹt và liên tục xin phép. Khi authority lớn nhưng accountability mơ hồ, rủi ro tăng. Trưởng phòng cần cân bằng ba yếu tố này theo độ phức tạp và mức trưởng thành của người nhận việc. Với các hoạt động có nhiều bên tham gia, bài viết trước về RACI và phân định trách nhiệm là nền tảng hữu ích để xác định ai thực hiện, ai chịu trách nhiệm cuối cùng và ai cần tham vấn.

PMI cũng nhấn mạnh mối liên hệ giữa giao trách nhiệm, trao quyền và thiết lập accountability trong quá trình delegation. Trong môi trường IT, nguyên tắc này đặc biệt quan trọng vì quyết định kỹ thuật thường có tác động vượt ra ngoài nhóm thực hiện: an toàn, dữ liệu, khách hàng và tính liên tục của dịch vụ.

Dùng năm mức phân quyền thay vì chỉ “được” hoặc “không được”

Một cách thực tế là định nghĩa các mức quyền quyết định. Mức 1: thu thập thông tin và đề xuất, trưởng phòng quyết định. Mức 2: đưa ra phương án ưu tiên kèm rủi ro, trưởng phòng phê duyệt. Mức 3: nhân viên quyết định trong tiêu chí đã thống nhất và thông báo trước khi thực hiện. Mức 4: nhân viên tự quyết, sau đó báo cáo theo checkpoint. Mức 5: nhân viên sở hữu hoàn toàn phạm vi, trưởng phòng chỉ review kết quả hoặc ngoại lệ.

Không có mức nào luôn tốt hơn. Một nhân viên mới xử lý thay đổi production có thể ở mức 1–2; cùng người đó với quy trình backup định kỳ có thể ở mức 4. Phân quyền theo rủi ro và năng lực giúp tránh hai sai lầm: áp một mức kiểm soát cho mọi việc, hoặc dùng thâm niên làm thước đo duy nhất.

Mức	Người nhận việc được làm gì?	Khi nào phù hợp?
1	Phân tích và đề xuất	Rủi ro cao, kinh nghiệm thấp
2	Đề xuất phương án ưu tiên, chờ duyệt	Quyết định có ảnh hưởng rộng
3	Tự quyết trong tiêu chí, thông báo trước	Quy trình rõ, năng lực ổn định
4	Tự quyết và báo cáo theo checkpoint	Công việc quen thuộc, rủi ro kiểm soát được
5	Sở hữu phạm vi và kết quả	Chuyên gia/trưởng nhóm đã chứng minh năng lực

Một brief giao việc tốt cần sáu thành phần

Thay vì giao task bằng một câu ngắn trong chat, IT Manager nên chuẩn hóa brief cho các công việc có ý nghĩa. Sáu thành phần cốt lõi gồm: Why – lý do và tác động; What – kết quả đầu ra; Boundaries – điều không được vượt; Authority – quyền được quyết định; Checkpoints – mốc cập nhật; Escalation – điều kiện phải báo ngay. Cấu trúc này làm rõ phần quản lý cần kiểm soát mà không buộc trưởng phòng can thiệp vào cách làm chi tiết.

Ví dụ, “nâng phiên bản firewall” là mô tả công việc. Một brief tốt hơn sẽ nói rõ mục tiêu là loại bỏ lỗ hổng đã đánh giá, cửa sổ bảo trì tối đa 60 phút, yêu cầu có rollback đã kiểm tra, ai có quyền phê duyệt nếu downtime kéo dài và mốc cập nhật trước/sau thay đổi. Người thực hiện vẫn có không gian kỹ thuật, nhưng rủi ro và kỳ vọng quản trị được kiểm soát.

Khóa Quản Lý Giám Sát IT – IT Supervisor phù hợp với phần kỹ năng giao việc, giám sát và phản hồi; còn Trưởng Phòng IT Chuyên Nghiệp – IT Manager đi rộng hơn ở cấp quản lý bộ phận, phân quyền và điều hành theo kết quả.

Kiểm soát bằng checkpoint, không bằng việc hỏi liên tục

Micromanagement thường có hình thức rất đời thường: “xong chưa?”, “đang ở đâu rồi?”, “gửi tôi xem từng bước”. Thay vào đó, hãy xác định checkpoint theo rủi ro và mốc quyết định. Với task hai ngày, một điểm xác nhận đầu vào và một review trước khi triển khai có thể đủ. Với dự án sáu tuần, checkpoint nên gắn với deliverable hoặc quyết định, không gắn với việc người quản lý cảm thấy lo lắng.

Mỗi checkpoint cần trả lời ba câu: trạng thái so với kết quả mong đợi; rủi ro/giả định nào đã thay đổi; quyết định hoặc hỗ trợ nào cần từ quản lý. Nếu cuộc cập nhật chỉ liệt kê “đã làm gì hôm qua”, nó dễ biến thành báo cáo hoạt động hơn là công cụ quản trị. Người quản lý cần học cách hỏi về bằng chứng, rủi ro và next decision.

Các công việc dịch vụ có thể sử dụng SLA, runbook và escalation path để giảm nhu cầu giám sát thủ công. Tư duy này có liên hệ trực tiếp với Quản Lý Dịch Vụ IT – ITSM, nơi trách nhiệm và cam kết dịch vụ được thiết kế thành hệ thống thay vì phụ thuộc vào việc trưởng phòng luôn theo sát.

Phân quyền phải đi cùng năng lực và khả năng phục hồi

Không nên trao quyền theo kiểu “người giỏi nhất được làm tất cả”. Càng tập trung quyền vào một cá nhân xuất sắc, bộ phận càng phụ thuộc. Trưởng phòng cần dùng phân quyền để phát triển chiều sâu đội ngũ: cho người thứ hai tham gia review, luân phiên ownership, yêu cầu tài liệu hóa và tạo cơ hội quyết định có kiểm soát. Điều này biến delegation thành công cụ phát triển năng lực chứ không chỉ là cách giảm tải cho quản lý.

Ở những phạm vi nhạy cảm như bảo mật, dữ liệu hoặc thay đổi production, quyền được trao phải đi cùng segregation of duties khi cần. Người thực hiện không nhất thiết là người phê duyệt. Quyền truy cập tạm thời nên có thời hạn và được ghi nhận. Với tổ chức đang hoàn thiện kiểm soát an toàn, chương trình Quản Lý Bảo Mật Thông Tin cung cấp góc nhìn về rủi ro và kiểm soát cần thiết khi phân quyền kỹ thuật.

Tình huống minh họa: sự cố production lúc nửa đêm

Tình huống giả định: trưởng nhóm ứng dụng phát hiện lỗi gây gián đoạn đơn hàng. Trước đây, quy định ngầm là mọi thay đổi production phải gọi IT Manager duyệt. Trong ca trực đêm, việc chờ phê duyệt kéo dài thời gian khôi phục. Sau đó, trưởng phòng thiết kế lại quyền: trưởng ca được phép rollback một release nếu đáp ứng ba điều kiện đã xác định, bắt buộc ghi log quyết định và báo cáo sau khi dịch vụ ổn định.

Cơ chế mới không phải “thả lỏng”. Nó làm rõ tiêu chí, giới hạn và bằng chứng. Với những thay đổi không nằm trong tiêu chí, escalation vẫn bắt buộc. Sau vài vòng review, trưởng ca trưởng thành hơn về phán đoán, trong khi IT Manager không còn là nút thắt của mọi sự cố. Đây là ví dụ về việc chuyển quyền quyết định xuống gần nơi có thông tin nhất nhưng vẫn giữ được accountability.

Điểm mấu chốt là thiết kế quyền trước khi khủng hoảng xảy ra. Nếu doanh nghiệp chỉ tranh luận “ai được quyền làm gì” giữa lúc dịch vụ đang gián đoạn, tốc độ và chất lượng quyết định đều giảm.

Checklist giao việc mà không buông lỏng hoặc quản lý vi mô

Kết quả đầu ra có được mô tả rõ hơn một danh sách task?
Người nhận việc có đủ thông tin và năng lực để ra quyết định?
Quyền hạn được nêu cụ thể: được làm gì, không được làm gì?
Điều kiện escalation có rõ và dễ nhớ?
Checkpoint gắn với rủi ro/mốc quyết định thay vì hỏi trạng thái liên tục?
Tiêu chuẩn chất lượng và bằng chứng hoàn thành đã thống nhất?
Người quản lý có tránh “làm hộ” khi nhân viên đang học cách xử lý?
Sau công việc có feedback để nâng mức phân quyền trong lần tới?

Hành động nên bắt đầu: chọn ba công việc thường khiến bạn phải theo sát nhất, xác định lại mức quyền hiện tại và viết brief sáu thành phần cho từng việc. Bạn sẽ nhanh chóng thấy micromanagement đến từ đâu: thiếu chuẩn đầu ra, thiếu quyền hay thiếu năng lực.

Nguồn tham khảo

Các nguồn trên được sử dụng để tham khảo các nguyên tắc quản trị, quản lý dịch vụ và thực hành quản lý. Nội dung bài viết là diễn giải ứng dụng của Infochief Academy.