Mở đầu — vì sao bài này quan trọng
Có một câu nói cay đắng mà rất nhiều Tech Lead mới lên nói với nhau: "Ngày làm việc của tôi giờ toàn của người khác." Trước khi lên Tech Lead, một ngày của bạn khá đơn giản: mở IDE, kéo task, code, review, push. Bạn kiểm soát gần như toàn bộ thời gian của mình. Nhưng khoảnh khắc bạn đeo cái mũ Tech Lead vào, lịch của bạn bắt đầu bị người khác lấp đầy — một cuộc họp planning ở đây, một câu hỏi kiến trúc ở kia, một buổi 1:1 với thành viên đang bối rối, một cuộc gọi khẩn từ on-call. Đến cuối tuần, bạn nhìn lại và giật mình: mình chưa viết được một dòng code nào có ý nghĩa, mà cũng chẳng nhớ rõ mình đã làm gì.
Đây không phải chuyện quản lý thời gian kiểu "dùng app to-do cho hiệu quả". Đây là vấn đề bản chất của vai trò. Tech Lead là một vị trí lai (hybrid): bạn vẫn phải giữ được năng lực kỹ thuật đủ sâu để đưa ra quyết định đúng, nhưng đồng thời bạn phải tạo ra đòn bẩy (leverage) thông qua người khác. Hai loại công việc này đòi hỏi hai chế độ thời gian hoàn toàn khác nhau — và nếu bạn không chủ động thiết kế lịch của mình, hai chế độ đó sẽ giết chết lẫn nhau.
Bài học này không nói về việc bạn là ai hay bạn khác Engineering Manager thế nào (đó là chuyện của các bài trước). Bài này rất cụ thể và chiến thuật: làm sao để cái calendar — công cụ tưởng chừng tầm thường nhất — trở thành vũ khí giúp bạn vừa giữ được deep work, vừa không bỏ rơi đội. Chúng ta sẽ bàn về tỷ lệ phân bổ thời gian lý tưởng, về sự khác biệt giữa maker's schedule và manager's schedule, và về những kỹ thuật rất đời thường như batching, office hours, hay việc bảo vệ "vùng cấm" trên lịch.
Khái niệm cốt lõi
Maker's schedule vs Manager's schedule
Paul Graham, nhà sáng lập Y Combinator, đã viết một bài luận kinh điển năm 2009 phân biệt hai loại lịch làm việc. Maker's schedule (lịch của người tạo ra sản phẩm — lập trình viên, nhà thiết kế, nhà văn) hoạt động theo khối lớn: bạn cần ít nhất nửa ngày liền mạch để đi vào trạng thái tập trung sâu và giải một bài toán phức tạp. Một cuộc họp 30 phút chèn vào giữa buổi sáng không chỉ tốn 30 phút — nó phá vỡ cả khối 4 tiếng, vì trước cuộc họp bạn không dám bắt đầu việc gì lớn, và sau cuộc họp bạn mất 20-30 phút để "khởi động lại" bộ não.
Manager's schedule thì ngược lại: chia ngày thành các ô 30 phút hoặc 1 tiếng, mỗi ô là một cuộc gặp, một quyết định. Với manager, một ngày kín lịch là một ngày làm việc tốt.
Bi kịch của Tech Lead là bạn sống trong cả hai thế giới cùng lúc. Bạn cần khối deep work của maker để thiết kế hệ thống, gỡ bug khó, viết code mẫu; nhưng bạn cũng có trách nhiệm manager với các cuộc họp, 1:1, unblock đội. Nếu bạn để lịch manager tràn ngập, phần maker của bạn chết. Nếu bạn cố thủ phần maker, đội bạn bị bỏ rơi và bạn thất bại ở vai trò lãnh đạo.
Tỷ lệ phân bổ tuần lý tưởng
Không có con số vàng cho mọi bối cảnh, nhưng đây là khung phân bổ mà nhiều Tech Lead ở giai đoạn "hands-on lead" (đội 4-7 người) thấy hợp lý:
| Hoạt động | % thời gian | Ghi chú |
|---|---|---|
| Coding / deep tech work | 40% | Việc kỹ thuật thật, không phải "sửa vặt" |
| Code review | 15% | Review PR, để lại phản hồi chất lượng |
| 1:1s | 10% | Gặp riêng từng thành viên, mentoring |
| Planning & meetings | 15% | Standup, sprint planning, họp cross-team |
| Unblocking / hỗ trợ ad-hoc | 10% | Trả lời câu hỏi, gỡ vướng cho đội |
| Suy nghĩ chiến lược / tài liệu | 10% | RFC, tech vision, tài liệu kiến trúc |
Khi đội lớn dần (8-12 người) hoặc bạn kiêm thêm trách nhiệm quản lý, tỷ lệ coding tự nhiên tụt xuống 20-25%, và phần meetings, 1:1, chiến lược phình ra. Điều quan trọng không phải là bám cứng con số, mà là bạn có ý thức về việc mình đang phân bổ ra sao — và tỷ lệ đó có khớp với kỳ vọng của cả sếp lẫn đội hay không.
Đòn bẩy: một giờ của bạn không bằng nhau
Nguyên tắc nền tảng cho mọi quyết định về lịch là khái niệm leverage (đòn bẩy) từ cuốn High Output Management của Andy Grove. Sản lượng của bạn không phải là những gì bạn tự làm, mà là sản lượng của cả đội cộng với sản lượng của những đội chịu ảnh hưởng từ bạn. Vì thế, một giờ dành để unblock ba kỹ sư đang kẹt có thể tạo ra giá trị gấp nhiều lần một giờ bạn ngồi code một mình. Ngược lại, một giờ họp vô nghĩa mà bạn dự chỉ để "có mặt" là leverage âm. Mọi kỹ thuật quản lý lịch trong bài này thực chất là công cụ để bạn tối đa hóa những giờ có đòn bẩy cao và cắt bỏ những giờ đòn bẩy thấp.
Tình huống thực tế
Tình huống 1 — Tech Lead "vô hình" ở một fintech tại TP.HCM
Minh là Tech Lead của đội thanh toán (7 kỹ sư) tại một công ty fintech ở TP.HCM, khoảng 120 nhân sự. Sau ba tháng lên vai trò, Minh kiệt sức. Anh vẫn cố hoàn thành các user story được assign trong mỗi sprint, nhưng vì suốt ngày bị gọi để trả lời câu hỏi và dự họp, anh thường phải code buổi tối và cuối tuần. Tệ hơn, các task của anh liên tục trễ, kéo cả sprint chậm theo, và team bắt đầu ngầm coi anh là điểm nghẽn.
Manager yêu cầu Minh làm một việc đơn giản: trong hai tuần, ghi lại mỗi giờ mình thực sự làm gì (time audit). Kết quả gây sốc: chỉ 12% thời gian là deep work thật, 35% là "trả lời câu hỏi lặt vặt trên Slack và bàn làm việc", 28% là họp — trong đó một nửa là họp anh không cần dự.
Minh làm ba điều. Thứ nhất, anh ngừng nhận task nằm trên critical path, chuyển sang nhận việc hạ tầng và prototype. Thứ hai, anh gom mọi câu hỏi ad-hoc vào hai khung "office hours" 45 phút mỗi ngày (10h30 và 16h), và công khai với team rằng ngoài khung đó, hãy để câu hỏi lại trừ khi thực sự khẩn. Thứ ba, anh rút khỏi 4 cuộc họp định kỳ mà anh chỉ ngồi nghe, thay bằng đọc biên bản.
Sau một tháng, deep work của Minh lên 33%, sprint của đội hết trễ vì anh không còn là nút thắt, và anh không còn phải code cuối tuần. Bài học: vấn đề của Minh không phải thiếu thời gian, mà là thời gian bị phân mảnh và anh đứng sai vị trí trong luồng công việc. Time audit là bước đầu tiên gần như bắt buộc — bạn không thể sửa cái bạn không đo được.
Tình huống 2 — Batching và "no-meeting mornings" ở một scale-up Đông Nam Á
Tại một công ty logistics đang scale nhanh (giả định, kiểu Ninja Van hay J&T), Tech Lead tên Rina quản lý đội định tuyến (routing) 9 người, làm việc trên hai múi giờ Singapore và Jakarta. Vấn đề của Rina khác Minh: cô có kỷ luật cá nhân tốt, nhưng lịch bị xé nhỏ bởi các cuộc họp rải rác cả ngày — một cái lúc 9h, một cái 11h, một cái 14h, một cái 16h. Giữa các cuộc họp là những khoảng 45-90 phút, đủ để trả lời email nhưng không đủ để suy nghĩ sâu.
Rina đề xuất với team và các stakeholder một thỏa thuận: mọi cuộc họp định kỳ dồn vào buổi chiều; buổi sáng từ 9h đến 12h là "no-meeting mornings" bất khả xâm phạm cho cả đội, không chỉ riêng cô. Cô cũng gom các buổi 1:1 vào hai buổi chiều thứ Ba và thứ Năm liên tiếp nhau (batching), thay vì rải mỗi ngày một buổi.
Kết quả sau một quý: khảo sát nội bộ cho thấy cảm nhận về "khả năng tập trung" của cả team tăng rõ rệt, và số PR merge trong tuần tăng khoảng 20%. Điều thú vị là lợi ích không chỉ cho Rina — cả đội đều được hưởng khối buổi sáng liền mạch. Bài học: một Tech Lead giỏi không chỉ bảo vệ lịch của riêng mình, mà thiết kế nhịp làm việc (cadence) cho cả đội. Batching các việc cùng loại lại với nhau (họp gom một chỗ, 1:1 gom một buổi) giảm chi phí chuyển ngữ cảnh (context switching) — thứ thuế vô hình đắt nhất với công việc trí óc.
Tình huống 3 — Khi "hands-on" biến thành nút thắt tại một startup 15 người
Đức là founding engineer kiêm Tech Lead ở một startup SaaS 15 người tại Hà Nội. Vì là người viết ra phần lớn hệ thống ban đầu, mọi quyết định kỹ thuật đều dồn về Đức, và anh cũng thích tự tay làm những phần khó nhất. Anh dành tới 70% thời gian để code. Nghe thì tuyệt, nhưng hệ quả là: ba kỹ sư junior mới vào không được mentor, không ai review PR kịp thời (PR nằm chờ 2-3 ngày), và mỗi khi Đức nghỉ phép, cả đội gần như tê liệt.
CTO chỉ ra vấn đề: Đức đang tối ưu sản lượng cá nhân thay vì sản lượng đội. Họ thống nhất kéo tỷ lệ code của Đức xuống còn khoảng 35-40%, và phần thời gian được giải phóng dồn vào ba việc leverage cao: review PR trong ngày (đặt cam kết SLA review dưới 4 giờ), một buổi pairing 90 phút mỗi tuần với từng junior, và viết tài liệu kiến trúc để "gỡ" kiến thức ra khỏi đầu anh.
Sau hai tháng, thời gian chờ review giảm từ 2-3 ngày xuống dưới nửa ngày, hai junior bắt đầu tự nhận được task khó hơn, và lần Đức nghỉ Tết dài, đội vẫn chạy được. Bài học: với Tech Lead, coding nhiều không phải lúc nào cũng tốt. Câu hỏi đúng không phải "tôi có bận không" mà là "thời gian của tôi có đang tạo ra đòn bẩy lớn nhất không". Đôi khi việc giá trị nhất bạn làm cả ngày là một buổi pairing giúp junior tự đứng vững — thứ nhân lên theo thời gian.
Hướng dẫn từng bước
Đây là quy trình để bạn giành lại quyền kiểm soát calendar của mình:
Bước 1 — Làm time audit trong 1-2 tuần. Đừng đoán, hãy đo. Cứ mỗi 30-60 phút, ghi nhanh bạn vừa làm gì và nó thuộc loại nào (deep work / review / họp / unblock / linh tinh). Cuối tuần cộng lại thành phần trăm. Gần như chắc chắn bạn sẽ ngạc nhiên về khoảng cách giữa lịch bạn nghĩ và lịch thực tế.
Bước 2 — Xác định tỷ lệ mục tiêu cho bối cảnh của bạn. Dựa trên quy mô đội và kỳ vọng vai trò, đặt ra khung phân bổ (ví dụ bảng ở trên). Trao đổi con số này với manager để hai bên cùng thống nhất — điều này tránh việc sếp nghĩ bạn phải code 80% trong khi bạn nghĩ mình nên lead 80%.
Bước 3 — Đặt trước (block) các khối deep work trên lịch. Tạo các sự kiện lặp lại 3-4 tiếng, đặt tên rõ ràng như "Deep Work — Do Not Book", tô màu riêng. Coi chúng như cuộc họp với người quan trọng nhất: chính bạn. Ưu tiên đặt vào giờ vàng năng lượng của bạn (với đa số là buổi sáng).
Bước 4 — Batching các việc cùng loại. Gom mọi buổi 1:1 vào một hoặc hai buổi liền nhau trong tuần. Gom các câu hỏi ad-hoc vào office hours. Gom việc review vào một hai khung cố định thay vì phản xạ theo từng thông báo.
Bước 5 — Thiết lập office hours công khai. Chọn 1-2 khung mỗi ngày (mỗi khung 30-45 phút) mà bạn sẵn sàng cho mọi gián đoạn. Nói rõ với đội: ngoài khung này và ngoài trường hợp khẩn thật sự (production down), hãy để câu hỏi lại. Điều này chuyển gián đoạn từ đồng bộ (interrupt ngay) sang bất đồng bộ (chờ được).
Bước 6 — Kiểm toán lại danh sách họp mỗi tháng. Với mỗi cuộc họp định kỳ, hỏi: nếu tôi vắng, có gì tệ đi không? Nếu câu trả lời là "không", hãy rời đi hoặc chỉ đọc biên bản. Đề nghị được ủy quyền (delegate) cho một senior đi thay ở những cuộc họp mang tính đại diện.
Bước 7 — Đặt lịch cho việc chiến lược và mentoring. Nếu không block trước, việc quan trọng-nhưng-không-khẩn (viết RFC, nghĩ về tech vision, mentor) sẽ luôn bị việc khẩn nuốt mất. Hãy dành hẳn một khung cố định hàng tuần cho chúng.
Bước 8 — Review và tinh chỉnh mỗi 4-6 tuần. Calendar không phải thiết kế một lần rồi thôi. Khi đội đổi, dự án đổi, giai đoạn đổi, tỷ lệ của bạn cũng phải đổi. Lặp lại time audit định kỳ.
Lỗi thường gặp & mẹo
Lỗi 1 — Để lịch trống nghĩa là "rảnh". Nếu bạn không block deep work, mọi khoảng trống sẽ bị người khác đặt họp. Ô trống trên calendar không phải thời gian rảnh — nó là tài sản bạn phải chủ động bảo vệ.
Lỗi 2 — Phản xạ với Slack như phản xạ với báo cháy. Không phải câu hỏi nào cũng khẩn. Thói quen trả lời mọi tin nhắn trong 30 giây khiến bạn không bao giờ có nổi một khối tập trung, và vô tình dạy đội rằng cách nhanh nhất để giải quyết vấn đề là hỏi bạn thay vì tự tìm hiểu.
Lỗi 3 — Nhận task trên critical path. Vì lịch bạn dễ vỡ, nhận việc cả đội đang chờ là công thức để trở thành nút thắt. Hãy nhận việc có thể ngắt quãng được.
Lỗi 4 — Bảo vệ deep work đến mức bỏ rơi đội. Đây là thái cực ngược lại. Nếu bạn khóa mình sáu tiếng mỗi ngày và đội không tiếp cận được bạn, bạn đang thất bại ở vai trò lead. Cân bằng là chìa khóa — deep work có block, nhưng cũng có office hours mở.
Mẹo 1 — Ghép cặp năng lượng với loại việc. Việc khó, sáng tạo (thiết kế, code phần hóc búa) để vào giờ đỉnh năng lượng. Việc ít đòi hỏi (review đơn giản, trả lời email, họp status) để vào giờ năng lượng thấp.
Mẹo 2 — Chừa buffer giữa các cuộc họp. Đặt họp 25 hoặc 50 phút thay vì 30 hoặc 60, để có khoảng thở, ghi chú và di chuyển. Chuỗi họp liên tục không nghỉ là cách nhanh nhất dẫn đến kiệt sức.
Mẹo 3 — Nói "để tôi xem lịch" thay vì "được" ngay. Tạo thói quen không đồng ý dự họp ngay lập tức. Một khoảng dừng nhỏ cho bạn cơ hội hỏi: việc này có xứng với thời gian của tôi không, hay có thể giải quyết async?
Mẹo 4 — Công khai lịch của bạn cho đội. Khi đội thấy rõ khung deep work và office hours của bạn, họ tự điều chỉnh cách tiếp cận. Minh bạch về lịch chính là cách đặt kỳ vọng mà không cần nói nhiều lời.
Bài tập thực hành
- Time audit 5 ngày. Trong tuần tới, mỗi 60 phút hãy ghi lại bạn đang làm gì và phân loại nó. Cuối tuần, tính phần trăm cho từng loại và so sánh với khung 40/15/10/15/10/10 ở trên. Viết ra ba con số khiến bạn bất ngờ nhất.
- Thiết kế tuần lý tưởng. Vẽ ra một lịch tuần mẫu cho chính bạn: đặt các khối deep work, khung office hours, buổi batching 1:1, và khung việc chiến lược. So sánh với lịch thực tế tuần này và liệt kê ba thay đổi cụ thể bạn sẽ thực hiện.
- Kiểm toán họp. Liệt kê mọi cuộc họp định kỳ bạn đang dự. Với mỗi cái, viết một câu trả lời cho câu hỏi "nếu tôi vắng, điều gì tệ đi?". Xác định ít nhất một cuộc họp bạn có thể rời hoặc ủy quyền.
- Thí điểm office hours. Công bố với đội hai khung office hours mỗi ngày trong hai tuần. Cuối kỳ, hỏi đội xem điều đó ảnh hưởng thế nào tới việc họ nhận hỗ trợ, và tự đánh giá khối deep work của bạn có tăng lên không.
Tóm tắt
Với một Tech Lead, calendar không phải là thứ để "sắp xếp cho gọn" mà là công cụ chiến lược quyết định bạn thành hay bại ở vai trò. Bạn sống đồng thời trong hai thế giới thời gian: maker's schedule cần những khối lớn liền mạch để làm việc kỹ thuật sâu, và manager's schedule chia nhỏ để lãnh đạo và unblock đội. Nếu không chủ động thiết kế, phần manager sẽ nuốt chửng phần maker, hoặc ngược lại bạn cố thủ code mà bỏ rơi đội.
Một khung phân bổ tham khảo là khoảng 40% deep work, 15% review, 10% cho 1:1, phần còn lại cho họp, unblock và chiến lược — nhưng con số cụ thể phải khớp với quy mô đội và giai đoạn của bạn. Nguyên tắc chi phối mọi quyết định là đòn bẩy: hãy dồn thời gian vào những giờ nhân lên sản lượng cả đội, và cắt bỏ những giờ đòn bẩy thấp.
Về mặt chiến thuật, hãy bắt đầu bằng time audit để biết sự thật, block deep work như một cuộc hẹn bất khả xâm phạm, batching các việc cùng loại, mở office hours để biến gián đoạn đồng bộ thành bất đồng bộ, và kiểm toán họp thường xuyên. Quan trọng nhất, đừng nhận việc trên critical path để khỏi thành nút thắt, và đừng để ô trống trên lịch bị hiểu nhầm là thời gian rảnh — nó là tài sản quý nhất bạn có, hãy bảo vệ nó một cách có chủ đích.