Nếu bạn không bảo vệ thời gian của mình, người khác sẽ lấy nó

Vấn đề: lịch của bạn đang bị người khác thiết kế giùm

• Lịch rỗng = lịch dễ bị chiếm dụng: Nếu bạn không chặn thời gian, người khác sẽ lấp đầy nó bằng ưu tiên của họ.
• Ngắt quãng giết chết deep work: Chỉ một cuộc gọi 10 phút cũng đủ xé nát 90 phút tập trung.
• Không có định nghĩa xong: Bạn bị kéo vào việc không có đầu cuối, không có tiêu chí hoàn tất.

Dấu hiệu bạn không bảo vệ thời gian đủ chặt

• Không có khối deep work 90–120 phút tối thiểu 1 lần/ngày.
• Họp > 3 lần/ngày hoặc các slot 30 phút rải khắp ngày.
• Thông báo bật toàn thời gian, bạn phản ứng theo ping thay vì theo kế hoạch.
• Không có lịch ship, sprint cứ dời vì “phát sinh”.

Nguyên tắc cốt lõi để bảo vệ thời gian

1. Deep work là ưu tiên mặc định: Mọi thứ khác phải xoay quanh, không phải ngược lại.
2. Chặn lịch trước, giải thích sau: Lịch là tường lửa; ai thật sự cần sẽ tìm cách phù hợp.
3. Ship > bận: Bận không tạo giá trị. Ship mới tạo giá trị.
4. Không họp khi chưa có tài liệu/hypothesis: Họp là chi phí cao, cần điều kiện đầu vào rõ.

Khung lịch cho developer: Maker vs Manager

Nhà phát triển cần block dài (maker schedule), trong khi quản lý làm việc theo block ngắn (manager schedule). Nếu bạn để lịch của mình giống quản lý, năng suất sẽ sụt mạnh.

• Buổi sáng: 1–2 block 90–120 phút deep work cho coding/thiết kế hệ thống.
• Đầu giờ chiều: 1 block 60–90 phút review PR, viết spec, trả lời issue có chiều sâu.
• Cuối ngày: 30–45 phút xử lý việc ngắn: email, lịch, phản hồi ngắn.
• Ngày họp: Gom họp vào 1–2 buổi cố định/tuần để bảo toàn các ngày còn lại.

Checklist bảo vệ thời gian hằng tuần

1. Chặn sẵn 10–12 giờ deep work cho tuần (lý tưởng là 2 giờ mỗi buổi sáng).
2. Gom họp vào khung giờ cố định: ví dụ 14:00–16:00 thứ Ba và thứ Năm.
3. Đặt quy tắc phản hồi: đọc email 2 lần/ngày, tắt thông báo không khẩn.
4. Xác định 1–2 “đầu ra phải có” trước thứ Sáu (ví dụ: ship tính năng X, viết spec Y).
5. Lập danh sách “not now”: việc thiếu dữ liệu, không có deadline, không chạm mục tiêu sprint.

Khung quyết định trước lời mời họp

1. Mục tiêu là gì? Không có mục tiêu cụ thể, từ chối hoặc yêu cầu mô tả.
2. Đầu vào đủ chưa? Chỉ họp khi có tài liệu, số liệu, giả thuyết cần kiểm chứng.
3. Hình thức rẻ hơn họp? Có thể giải qua comment, doc hay video 5 phút không?
4. Ai cần có mặt? Cắt người không liên quan, chọn người quyết định và người thực thi.
5. Thời lượng tối thiểu? 15 phút thay vì 30 phút, 25 phút thay vì 60 phút.

Mẫu trả lời “không” lịch sự nhưng dứt khoát

• Khi chưa đủ đầu vào: “Bạn gửi giúp tài liệu/tóm tắt mục tiêu và câu hỏi cần quyết định nhé. Mình review trước, nếu cần thì set slot 15 phút.”
• Khi lệch ưu tiên sprint: “Hiện nhóm đang khóa vào mục tiêu X. Việc này đưa vào danh sách đánh giá đầu sprint sau.”
• Khi có kênh rẻ hơn: “Chủ đề này phù hợp comment trên ticket. Mình sẽ phản hồi trong khung 16:30–17:00 hôm nay.”

Luồng daily thực dụng cho coder

1. 05 phút chọn 1–2 đầu ra quan trọng nhất trong ngày.
2. 120 phút deep work không gián đoạn (tắt thông báo, bật chế độ toàn màn hình).
3. 15 phút break và ghi chú những gì đã tiến triển.
4. 60–90 phút xử lý PR/spec/bug theo mức độ ưu tiên.
5. 30–45 phút cho email, lịch, trao đổi ngắn.

Kỹ thuật chặn gián đoạn hiệu quả

• Timeboxing: Mỗi task có khung thời gian cứng, hết giờ chuyển bối cảnh.
• Calendar blocking: Lịch “bận” cho deep work, kèm tên đầu ra để người khác thấy lý do.
• Batching: Gom việc lặt vặt vào các cửa sổ cố định trong ngày.
• Asynchronous-first: Ưu tiên doc/comment thay vì họp.
• Definition of done: Mọi việc phải có tiêu chí hoàn tất trước khi bắt đầu.

Đo lường: bạn có thật sự lấy lại thời gian?

• Giờ deep work/tuần: Mục tiêu 10–15 giờ.
• Số lần ngắt quãng/ngày: Giảm về < 5 lần.
• Số đầu ra ship/tuần: Tối thiểu 1 tính năng hoặc 1 spec có chất lượng.
• Tỉ lệ họp có tài liệu trước: Hướng đến > 80%.

Thử thách 14 ngày để lấy lại quyền chủ động

1. Chặn lịch deep work 2 giờ mỗi buổi sáng trong 10 ngày làm việc.
2. Tắt tất cả thông báo ngoại trừ kênh khẩn; kiểm tra email 2 lần/ngày.
3. Chỉ tham dự họp có mục tiêu và tài liệu đầu vào; còn lại xin chuyển sang async.
4. Mỗi ngày ghi lại một điều bạn dừng làm để bảo vệ thời gian.

FAQ ngắn

Nếu sếp muốn họp bất cứ lúc nào thì sao? Đề xuất khung giờ cố định cho sync; gửi báo cáo ngắn trước để giảm nhu cầu họp đột xuất. Khi có đầu ra ship đều, đề xuất của bạn có sức nặng hơn.

Team remote cần phản hồi nhanh, làm sao tắt thông báo? Thỏa thuận SLA nội bộ: ví dụ phản hồi trong 2 khung giờ cố định/ngày. Nhanh không đồng nghĩa tức thì.

Kết luận

Bảo vệ thời gian là trách nhiệm nghề nghiệp, không phải đặc quyền. Khi bạn lập hàng rào cho lịch của mình, bạn không ích kỷ; bạn đang bảo vệ khả năng ship, chất lượng sản phẩm và uy tín của cả nhóm. Nếu bạn không thiết kế ngày làm việc, người khác sẽ làm thay — theo ưu tiên của họ. Hãy bắt đầu chặn lịch hôm nay.