Bước ngoặt: Từ "học để code" sang "học để quyết định"
Hồi còn là developer, tôi học công nghệ mới theo một cách: đọc docs, làm tutorial, code một project nhỏ, rồi dùng trong dự án thực. Mất 2-4 tuần cho một framework mới, nhưng tôi hiểu rất sâu.
Khi tôi lên senior, tôi vẫn giữ được nhịp đó. Vẫn còn đủ thời gian để code, đủ không gian để thực hành.
Nhưng khi trở thành CEO, mọi thứ thay đổi. Lịch họp kín từ 9h đến 5h. Quyết định phải đưa ra nhanh - từ hiring, đến architecture review, đến business strategy, đến pricing, đến... mọi thứ. Thời gian để học theo kiểu cũ: không còn nữa.
Và đây là cái bẫy mà tôi thấy nhiều CEO/CTO rơi vào: ngừng học kỹ thuật hoàn toàn. Họ delegate tất cả cho CTO, cho tech lead, và dần dần mất đi ngôn ngữ chung với team kỹ thuật. 5 năm sau, họ không còn đủ context để có opinion kỹ thuật nào có giá trị.
Tôi không muốn thành người đó.
Nhưng tôi cũng không thể học theo cách cũ. Vậy, tôi phải tìm ra cách thứ ba.
Framework học của tôi hiện tại: T-shape, nhưng ở một chiều khác
Chắc các bạn biết T-shaped skills - chiều ngang là breadth (hiểu rộng nhiều lĩnh vực), chiều dọc là depth (sâu một lĩnh vực).
Khi là developer, bạn xây chiều dọc. Khi là CEO/CTO, bạn chuyển sang xây chiều ngang - nhưng có chiều dọc chiến lược.
Tôi chia việc học của mình thành 3 layer:
Layer 1: Radar scan - 15 phút mỗi ngày
Mỗi buổi sáng, tôi đọc:
- ThoughtWorks Technology Radar (quarterly)
- TLDR Newsletter (daily, 5 phút)
- GitHub trending (hàng tuần)
- LinkedIn của các tech leader tôi follow
Mục tiêu không phải là hiểu sâu. Mục tiêu là biết tên, biết context, biết xu hướng. Khi ai đó đề cập Bun.js hay Dapr hay Temporal hay Wasm - tôi không bị lost.
Layer 2: 2-hour deep dives - khi cần thiết
Khi một công nghệ xuất hiện 3 lần trong vòng 1 tháng trong radar của tôi - từ nhiều nguồn khác nhau - đó là signal để tôi đầu tư 2 tiếng học sâu hơn.
2 tiếng đủ để làm gì? Đủ để:
- Đọc official docs phần overview và getting started
- Xem 1-2 YouTube video của người thực chiến
- Đọc 2-3 bài blog case study
- Hiểu problem nào công nghệ đó giải quyết, trade-off là gì
Tôi không cần code được. Tôi cần có quan điểm.
Layer 3: Build one small thing - khi quyết định đưa vào production
Khi công ty thực sự có khả năng dùng một công nghệ mới - và tôi cần hiểu sâu để quyết định - tôi build một thứ nhỏ.
Không cần production-ready. Chỉ cần cảm giác thực.
Ví dụ: Khi chúng tôi đang cân nhắc chuyển sang Azure Container Apps, tôi tự tay deploy một app .NET nhỏ lên đó. Mất một buổi tối. Nhưng sau đó tôi hiểu rõ ràng limitation, DevEx, pricing model. Tôi có thể nói chuyện với team mà không chỉ dựa vào presentation của Azure salesperson.
Những thứ tôi học trong 12 tháng qua
Để các bạn có hình dung thực tế - đây là danh sách công nghệ/concept tôi đã học theo framework trên trong năm vừa rồi:
Layer 1 (radar scan): Bun.js, Deno 2.0, Zod, Drizzle ORM, Temporal.io, Dapr, HTMX, Bun macros, Wasm components, AI Gateway patterns
Layer 2 (2-hour deep dive): Semantic Kernel, Azure AI Foundry, OpenTelemetry, Testcontainers, .NET Aspire, Feature flags với LaunchDarkly
Layer 3 (build something): .NET Aspire (poc cho internal tooling), RAG pipeline với Azure OpenAI, GitHub Actions custom workflow cho CI/CD mới
Nhìn vào danh sách đó, các bạn sẽ thấy: tôi không đi sâu tất cả. Nhưng tôi biết tất cả. Và khi team cần quyết định, tôi có thể tham gia cuộc trò chuyện một cách có ý nghĩa.
Điều quan trọng hơn kỹ năng: Học cùng team
Một thứ tôi học được trong mấy năm vừa rồi: tốc độ học của cả team quan trọng hơn tốc độ học của tôi.
Vậy nên, tôi không chỉ học một mình. Tôi tạo ra môi trường để team học:
- Tech sharing session mỗi 2 tuần - developer tự chọn topic và chia sẻ 20-30 phút
- Budget học tập cho mỗi developer - dùng mua sách, khóa học, conference
- Thời gian 20% cho learning projects - không phải tất cả, nhưng ai muốn thì được
- "I don't know but let me find out" culture - tôi model cái này bằng cách tự nói câu đó thường xuyên
Khi CEO/CTO liên tục học và liên tục thừa nhận không biết, team sẽ cảm thấy an toàn để làm điều tương tự. Đó là competitive advantage thực sự - không phải bất kỳ technology nào cụ thể.
Những cái tôi bỏ hẳn để có thời gian học
Mọi bài về time management đều nói "làm thêm cái này". Tôi muốn nói ngược lại: cái gì tôi đã bỏ.
- Meeting không có agenda: Decline thẳng, hoặc yêu cầu agenda trước 24h
- Status update meetings: Thay bằng async (Notion, Slack threads)
- Email dài: Thay bằng voice message hoặc Loom video 2 phút
- Đọc mọi PR: Delegate cho senior dev review, tôi chỉ review architecture-level decisions
- Mạng xã hội buổi sáng: First 30 phút sau khi thức dậy là không screen
Bằng cách bỏ những thứ đó, tôi tìm lại được 1-2 tiếng mỗi ngày. Và 1-2 tiếng đó, tôi dùng để học.
Bài học cho các bạn trẻ
Nhiều bạn junior/mid-level hỏi tôi: "Anh Son, sau này lên senior hay lead, có còn cần học kỹ thuật không?"
Câu trả lời ngắn: Cần. Nhưng cách học thay đổi.
Và đây là điều tôi muốn các bạn ghi nhớ:
Đừng chờ đến khi lên senior mới bắt đầu xây habit học. Habit đó phải được xây từ bây giờ. Từ những năm junior, mid-level - thời điểm bạn còn có cả breadth lẫn depth để học.
Khi tôi lên CEO, tôi không bắt đầu học habit từ đầu. Tôi chỉ adjust một habit đã có từ 15 năm trước. Nếu 15 năm trước tôi không có habit đó, tôi không biết mình có làm được không.
Vậy nên, hãy bắt đầu ngay từ hôm nay:
- Đăng ký 1-2 newsletter kỹ thuật tốt (TLDR, Bytes, The Pragmatic Engineer)
- Đặt 30 phút mỗi tuần để đọc một bài về công nghệ ngoài dự án hiện tại
- Build một project nhỏ mỗi quý với một công nghệ mới
- Chia sẻ cái bạn học được - viết blog, làm presentation cho team
Không cần nhiều. Cần consistent.
Các bạn đang dùng framework học như thế nào? Đặc biệt khi lịch ngày càng kín? Comment cho anh biết với - anh cũng muốn học từ các bạn.
/Son Do - believe in basic
#1percentbetter #selfdevelopment #techlead #lifelonglearning #growthmindset