Tư duy (Mindset) khi làm Leader Develop Bài 1: Tư duy làm chủ (Ownership) - Từ Coder thành Problem Solver.

Sự khác biệt lớn nhất giữa một Developer bình thường và một người có tiềm năng làm Leader nằm ở giới hạn trách nhiệm mà họ tự đặt ra cho bản thân.

• Developer bình thường: "Task của tôi là viết API này. Code chạy, pass test là xong việc. Lỗi ở phía Frontend thì để Frontend lo."
• Leader tiềm năng: "Tính năng này giải quyết vấn đề gì cho user? API này có chịu được tải khi scale không? Cần phối hợp với Frontend thế nào để tích hợp mượt mà nhất?"

3 Cấp độ của Tư duy Làm chủ cần rèn luyện

Cấp độ 1: Hiểu "Tại sao" (The WHY) trước khi hỏi "Làm thế nào" (The HOW)

Đừng bao giờ nhận một task (Jira ticket) và cắm mặt vào code ngay. Hãy luôn tự hỏi:

• Tính năng này mang lại giá trị gì cho người dùng cuối hoặc cho công ty?
• Nếu không làm tính năng này thì sao? Có cách nào đơn giản hơn để giải quyết vấn đề không?

Hành động: Trong buổi họp Sprint Planning/Grooming, hãy tập đặt câu hỏi cho Product Owner (PO) hoặc BA về mục đích kinh doanh của task đó.

Cấp độ 2: Mang đến Giải pháp (Solutions), thay vì chỉ báo cáo Vấn đề (Problems)

Khi gặp bug khó hoặc dự án có nguy cơ trễ deadline, Developer thường báo cáo: "Anh ơi, thư viện này bị lỗi rồi, em không làm tiếp được."

Người có tư duy Leader sẽ nói: "Anh ơi, thư viện A bị lỗi. Em đã thử tìm hiểu thì có 2 hướng giải quyết: Hướng 1 dùng thư viện B mất 2 ngày, hướng 2 tự viết lại hàm cốt lõi mất 1 ngày nhưng khó maintain sau này. Em đề xuất chọn hướng 1. Ý anh sao?"

Hành động: Luôn chuẩn bị sẵn ít nhất 1-2 phương án giải quyết trước khi trình bày khó khăn với cấp trên.

Cấp độ 3: Trách nhiệm vắt chéo (Cross-boundary Responsibility)

Sản phẩm là của chung. Đừng nói câu "Đó không phải việc của tôi".

• Nếu thấy tài liệu (Docs) cũ, hãy chủ động cập nhật nó.
• If thấy quy trình deploy quá thủ công, hãy tự tìm hiểu CI/CD để đề xuất tự động hóa.
• Nếu team có một bạn mới vào (fresher), hãy chủ động hướng dẫn bạn ấy set up môi trường mà không cần ai nhờ.

📝 Bài tập thực hành cho Bài 1 (Trong tuần này)

Hãy chọn 1 task/ticket bạn đang làm hiện tại và thực hiện 3 bước sau:

1. Viết ra giấy/note: Task này giải quyết bài toán kinh doanh (business) gì? (Chứ không phải bài toán kỹ thuật).
2. Review lại đoạn code bạn vừa viết: Liệu có case nào dễ gây lỗi mà QA có thể sót không? Chủ động viết thêm Unit Test hoặc note lại cho QA.
3. Tìm ra 1 điểm bất cập nhỏ trong dự án hiện tại (ví dụ: một đoạn code lặp lại nhiều lần, một step build quá lâu) -> Ghi chú lại nguyên nhân và tự nghĩ ra 1 phương án cải thiện.

Bí quyết: Đừng vội vàng muốn làm chuyện đao to búa lớn. Leader xuất sắc bắt đầu từ việc làm xuất sắc và chịu trách nhiệm đến cùng cho những việc nhỏ nhất.