Tính Trễ (Time Lag): Tại Sao Kiên Nhẫn Là Một Năng Lực Chiến Lược?

Trở lại với hai chậu gừng trên bàn. Sau khi tôi quyết định dừng can thiệp thô bạo ở Kỳ 2, chậu gừng thứ hai vẫn im lìm thêm một thời gian nữa.

Nếu là một người nôn nóng, tôi đã có thể kết luận ngay: “Cách này không hiệu quả” và đổ thêm phân bón hoặc thậm chí vứt bỏ củ gừng đó để thay bằng một củ khác. Nhưng Khoa học về sự phức tạp (Complexity Science) dạy chúng ta về Tính trễ (Time Lag) – khoảng trống thời gian giữa hành động và kết quả.

Bài học này không chỉ đúng với chậu gừng, mà nó chính là cách chúng tôi đã giải bài toán vận hành tại công ty mình.

1. Khi “Lá” héo không phải do lỗi của “Cây”

Chúng tôi từng đối mặt với con số trung bình 10 incidents mỗi tháng. Phản ứng thông thường của một quản lý theo tư duy tuyến tính sẽ là: “Tại sao team làm ẩu thế?”, “Có nên thay người không?”.

Nhưng khi nhìn qua lăng kính hệ thống, chúng tôi bắt đầu phân tích sâu hơn thay vì đổ lỗi cho đội ngũ. Hóa ra, phần lớn incidents đến từ việc các thành viên trong team dự án không hiểu hết quy trình phát triển phần mềm. Chúng tôi từng có một bộ quy định rất đầy đủ, nhưng cách chúng tôi đưa nó vào hệ thống lại quá hời hợt: Chỉ gửi tài liệu xuống và hỏi các Manager: “Có ai hỏi gì không?”.

Kết quả là không ai hỏi gì, nhưng khi Audit (kiểm tra) lại, chúng tôi mới ngã ngửa: Team không hiểu nhiều điểm cốt lõi trong chính bộ quy tắc đó. Hệ thống đang “đói” thông tin và sự thấu hiểu, chứ không phải “đói” nhân sự giỏi.

2. Tác động vào “Hệ sinh thái” thay vì “Cây trồng”

Thay vì thay đổi đội ngũ – hành động tương đương với việc nhổ cây cũ đi trồng cây mới – chúng tôi chọn cách cải tạo “nguồn nước” và “dinh dưỡng”:

• Tổ chức các buổi chia sẻ: Giải thích cặn kẽ từng điểm quy trình thay vì chỉ gửi file.

• Bổ sung “Evidence” (Bằng chứng): Chúng tôi đưa thêm các điểm kiểm soát vào Operation note và Release note. Việc này giúp các bước triển khai đầy đủ hơn và dễ dàng review hơn.

• Chuẩn hóa quy trình: Tạo ra các “khuôn mẫu” chung để tất cả các team đều có thể sử dụng dễ dàng.

Chúng tôi không “ra lệnh” cho số lượng incident phải giảm ngay lập tức. Chúng tôi tập trung thay đổi cách hệ thống vận hành.

3. Đối diện với “Độ trễ”

Sau khi triển khai những thay đổi trên, số lượng incident không giảm xuống 0 ngay ngày hôm sau.

Đó là lúc Tính trễ xuất hiện. Team cần thời gian để thẩm thấu kiến thức mới, làm quen với cách ghi Operation note mới, và các dự án cũ cần kết thúc để các quy trình chuẩn mới bắt đầu phát huy tác dụng.

Nếu trong giai đoạn này, chúng tôi mất kiên nhẫn và tiếp tục áp đặt thêm các quy định chồng chéo khác, hệ thống sẽ bị rối loạn (giống như việc bạn vặn vòi hoa sen quá nóng vì chưa thấy nước ấm ngay). Nhưng vì hiểu về Độ trễ, chúng tôi kiên trì quan sát và hỗ trợ.

4. Thành quả của sự kiên nhẫn chiến lược

Kết quả sau đó đã minh chứng tất cả: Số lượng incident giảm đi rõ rệt. Điều tuyệt vời nhất là chúng tôi đạt được kết quả đó mà không cần thay đổi đội ngũ. Những “cây gừng” cũ, khi được đặt trong một “môi trường nước” trong sạch, rõ ràng và có quy chuẩn, đã tự hồi sinh và phát triển mạnh mẽ.

Bài học cho người điều hành

Kiên nhẫn trong tư duy hệ thống không phải là sự thụ động. Đó là sự kiên trì thực hiện những thay đổi đúng đắn tại các điểm đòn bẩy (Leverage Points) và chấp nhận rằng hệ thống cần thời gian để chuyển mình.

Khi bạn thấy một bộ phận đang gặp vấn đề, trước khi nghĩ đến chuyện “thay người”, hãy tự hỏi:

• Quy trình (nguồn nước) của mình đã thực sự rõ ràng chưa?

• Công cụ hỗ trợ (dinh dưỡng) đã đủ để họ làm đúng chưa?

• Bạn có đủ kiên nhẫn để đợi qua khoảng thời gian “trễ” trước khi kết quả xuất hiện không?