Ghi chép từ video · Tư duy & cách làm việc
7 nguyên tắc làm việc của Elon Musk — và cách dùng chúng mà không tự đốt cháy đội của mình
Bảy nguyên tắc lặp đi lặp lại qua bảy công ty và ba thập kỷ. Chúng không phải bí quyết thiên tài — chúng là một quy trình có thể học. Nhưng ba trong bảy nguyên tắc sẽ phá đội của bạn nếu copy nguyên xi.
Nguồn: video tiếng Việt “Học được gì sau 1020 phút nghe podcast về tư duy & cách làm việc của Elon Musk” (youtube.com/watch?v=fs5g8O2Hfp4). Video tóm tắt lại một podcast về cuốn tiểu sử Elon Musk của Walter Isaacson.
Cách đọc tài liệu này: mỗi nguyên tắc gồm bốn phần — câu chuyện gốc, cơ chế phía sau, chuyển thành hành động, và cảnh báo khi áp dụng. Phần cảnh báo là phần tôi thêm vào, không có trong video.
Nguyên tắc 01
Đặt câu hỏi cho mọi yêu cầu
Không hỏi “làm sao tốt hơn”, mà hỏi “tại sao phải làm cái này”.
Câu chuyện gốc
Năm 2002, sau khi bán PayPal, Musk muốn đưa người lên sao Hỏa và phát hiện một quả tên lửa giá 65 triệu đô. Thay vì đi tìm nhà cung cấp rẻ hơn, ông đọc sách về động cơ đẩy và nhiệt động lực học, rồi bóc giá thành ra tận đáy: nguyên vật liệu thô chỉ chiếm khoảng 2% giá bán. 98% còn lại là quy trình sản xuất và “tiêu chuẩn ngành” đã được chấp nhận suốt nhiều thập kỷ mà không ai hỏi lại.
Đỉnh điểm là câu hỏi mà cả ngành coi là ngớ ngẩn: tại sao tên lửa không tái sử dụng được, trong khi máy bay thì được? Câu hỏi đó dẫn tới Falcon — tên lửa đầu tiên hạ cánh thẳng đứng và bay lại nhiều lần.
Cơ chế phía sau
Đây là first-principles thinking: bẻ vấn đề xuống các định luật vật lý và ràng buộc thật, rồi dựng lại từ đó — thay vì suy luận bằng phép loại suy (“ngành mình xưa nay làm thế”). Điểm mấu chốt trong video không phải là kỹ thuật đó, mà là một câu chốt đáng nhớ hơn:
Đặt câu hỏi đúng luôn quan trọng hơn tìm câu trả lời đúng. Nếu đề bài sai, mọi nỗ lực tối ưu phía sau đều không cứu nổi.
Người kể chuyện đưa ví dụ của chính mình: suốt một thời gian dài cô tối ưu cho câu hỏi “làm sao xuất hiện trên bốn nền tảng cùng lúc hiệu quả nhất?” — xây quy trình, xây team, lịch đăng dày đặc — rồi burn out và chất lượng tụt. Khi đổi đề bài thành “làm sao tạo nội dung chất lượng nhất ở nơi thu hút khán giả tốt nhất?”, chiến lược đảo chiều: dồn 80% nguồn lực vào một kênh duy nhất.
Chuyển thành hành động
Liệt kê ba quy trình hoặc tiêu chuẩn bạn đang tuân thủ vì “người ta bảo vậy”: họp team sáng thứ Hai, trả lời email trong 24 giờ, slide tối thiểu 10 trang, mọi PR phải có hai approval, mọi ticket phải có ước lượng story point. Với từng cái, hỏi bốn câu: Ai đặt ra? Tại sao? Có thật sự cần không? Bỏ đi thì sao?
Mẹo quan trọng từ câu chuyện SpaceX: mỗi yêu cầu phải gắn tên một người cụ thể, không được để “bộ phận X yêu cầu”. Yêu cầu vô danh là yêu cầu không ai dám bỏ.
First-principles chỉ hoạt động khi bạn thật sự hiểu ràng buộc. Musk đọc sách kỹ thuật trước khi bác bỏ tiêu chuẩn ngành. Bỏ một tiêu chuẩn mà bạn chưa hiểu lý do nó tồn tại không phải là tư duy nguyên bản — đó là học lại bài học cũ bằng máu. Nhiều tiêu chuẩn trong ngành phần mềm (code review, migration có rollback, phân tách quyền) là hoá đơn của những sự cố đã xảy ra. Hỏi thì luôn nên; bỏ thì phải trả lời được câu “sự cố nào sinh ra quy tắc này”.
Nguyên tắc 02
Đi theo sứ mệnh, tiền tính sau
Follow the mission.
Câu chuyện gốc
Sau Zip2 và PayPal, lựa chọn hợp lý là nghỉ, hoặc tiếp tục trong ngành công nghệ nơi ông đã thắng hai lần. Musk chọn hàng không vũ trụ tư nhân — lĩnh vực ông là tay ngang, và chính ông thừa nhận xác suất thất bại rất cao. Có giai đoạn SpaceX và Tesla đứng bên bờ phá sản cùng lúc.
Lý do ông đưa ra không liên quan tới doanh thu: ý thức con người có thể là thứ hiếm và độc nhất trong vũ trụ, nên loài người cần một “hợp đồng bảo hiểm” — một thuộc địa tự duy trì trên sao Hỏa. Một người bạn của ông tóm tắt cách vận hành này gọn hơn nhiều:
Elon không nghĩ theo hướng đó. Ông bắt đầu bằng một sứ mệnh, rồi mới nghĩ cách kiếm tiền từ nó. Trích lại trong video
Cơ chế phía sau
Sứ mệnh không phải khẩu hiệu treo tường — nó là hàm mục tiêu để cắt lựa chọn. Khi đã có một câu trả lời rõ ràng cho “chúng ta tồn tại để làm gì”, phần lớn cơ hội hấp dẫn trở nên dễ từ chối. Không có nó, mọi cơ hội đều trông đáng làm và bạn chết vì dàn trải.
Người kể chuyện dùng chính mình làm ví dụ: kênh YouTube bắt đầu từ năm hai đại học với ý định hồn nhiên là chia sẻ hành trình của mình. Khi kênh lớn và có sản phẩm để bán, cô tự nhốt mình vào một cái ngách — “mở mồm ra là phải nói về kiếm tiền online” — rồi mất hứng và biến mất khỏi mạng xã hội một thời gian. Câu hỏi kéo cô quay lại: nếu tiền không còn là biến số quan trọng, rốt cuộc mình làm việc này để làm gì?
Chuyển thành hành động
Hai câu hỏi để tự trả lời bằng bút, không phải trong đầu:
- Nếu tiền không còn là biến số quan trọng, điều gì khiến bạn hào hứng dậy vào buổi sáng?
- Đội của bạn có thể trả lời câu “chúng ta tồn tại để giải bài toán gì cho ai” bằng một câu không — và mọi người có trả lời giống nhau không?
Với người dẫn dắt kỹ thuật, phép thử của một sứ mệnh thật là: nó phải giúp bạn từ chối được một thứ hấp dẫn. Nếu sứ mệnh của đội chưa từng khiến bạn nói không với feature nào, nó chưa phải sứ mệnh — nó là câu marketing.
“Mission first” là con dao hai lưỡi trong quản lý. Nó tạo động lực thật, nhưng cũng là công cụ quen thuộc để hợp lý hoá việc trả lương thấp, overtime kéo dài và burnout — “vì chúng ta đang làm điều lớn lao”. Musk tự chọn rủi ro đó cho bản thân với tư cách người sở hữu công ty; nhân viên của bạn thì không sở hữu gì. Dùng sứ mệnh để chọn việc, đừng dùng nó để trả công.
Nguyên tắc 03
Tạo cảm giác khẩn cấp phi lý
Maniacal sense of urgency.
Câu chuyện gốc
Musk có thói quen cắt đôi mọi lịch trình. Khi kỹ sư đưa ước lượng, phản ứng quen thuộc của ông là “cái quái gì khiến nó lâu đến thế — cắt đôi đi”. Một lần, kỹ sư động cơ của ông phản đối rằng không thể cắt đôi một lịch trình vốn đã bị cắt đôi. Musk giữ người này lại sau buổi họp, hỏi “anh còn muốn làm kỹ sư ở đây không?”, và khi nhận câu trả lời có, ông nói: vậy thì làm theo những gì tôi bảo.
Chi tiết đáng chú ý là phần kết: chính người kỹ sư đó về sau thừa nhận họ trượt phần lớn các deadline Musk đặt ra — nhưng vẫn về đích trước mọi đối thủ trong ngành.
Cơ chế phía sau
Deadline phi lý không dùng để dự báo, nó dùng để ép cắt phạm vi. Khi thời gian bị bóp còn một nửa, đội buộc phải trả lời câu hỏi “cái gì thật sự cần thiết” — đúng nguyên tắc số 1, chỉ khác là được kích hoạt bằng áp lực thay vì bằng lý trí. Nó cũng chống lại định luật Parkinson: công việc luôn giãn ra vừa đủ lấp kín thời gian được cấp.
Ví dụ thực tế trong video nhỏ nhưng đúng bản chất: trợ lý hẹn trả kết quả vào thứ Ba; hỏi lại thì việc chỉ tốn 3 giờ; lúc đó là 2 giờ chiều, nên deadline thành 5 giờ chiều cùng ngày. Kết quả vẫn tốt, và tiết kiệm được vài ngày trôi nổi.
Chuyển thành hành động
Câu hỏi cần hỏi mỗi khi nhận một ước lượng: “Việc này tốn bao nhiêu giờ làm thật?” — không phải “khi nào xong”. Khoảng cách giữa hai con số đó chính là thời gian chờ, chuyển ngữ cảnh và hàng đợi. Đó là chỗ để cắt, không phải cắt vào chất lượng.
Nói rõ với đội deadline đó thuộc loại nào — đây là điểm khác biệt sống còn:
| Loại | Mục đích | Trượt thì sao |
|---|---|---|
| Deadline kéo căng | Ép cắt phạm vi, phá thói quen giãn việc | Không sao — học được giới hạn thật |
| Deadline cam kết | Có bên thứ ba phụ thuộc vào ngày này | Có hậu quả — phải báo sớm |
Trộn lẫn hai loại này là cách nhanh nhất để mất niềm tin của đội: nếu mọi deadline đều “cháy”, sẽ không còn deadline nào cháy thật.
Đây là nguyên tắc nguy hiểm nhất trong bảy cái. Nguyên bản của nó đi kèm quát mắng và doạ sa thải — phần đó bạn phải bỏ, không thương lượng. Áp lực liên tục ở mức tối đa không tạo ra tốc độ bền vững; nó tạo ra nợ kỹ thuật, test bị bỏ, và người giỏi nghỉ việc. Chi phí thay một senior engineer thường vượt xa vài tuần bạn tiết kiệm được. Dùng deadline căng như một công cụ có liều lượng — cho một sprint, một đợt cắt scope — chứ không phải nhiệt độ mặc định của đội.
Nguyên tắc 04
Đi tìm giới hạn thật
Giới hạn bạn tin là giới hạn, thường chỉ là con số ai đó đưa ra cho an toàn.
Câu chuyện gốc
SpaceX thuê một công ty dựng tháp thép không gỉ. Musk không nói chuyện với giám đốc — ông đi thẳng tới chỗ những người thợ đang hàn và hỏi: bức tường này có thể mỏng tới mức nào? Thợ trả lời 4,8 mm. Musk hỏi lại: còn 4 mm thì sao? Họ nói nghe hơi khó, hơi lo. Ông bảo: vậy làm 4 mm đi, thử xem sao. Tường 4 mm hoạt động.
Chi tiết mà người kể chuyện chỉ nhận ra ở lần nghe thứ ba: Musk không biết trước 4 mm là được. Ông chỉ đặt một câu hỏi có vẻ điên rồ rồi thử.
Cơ chế phía sau
Mọi con số “tối thiểu” trong tổ chức đều đã cộng sẵn một biên an toàn của người đưa ra nó — và biên an toàn đó cộng dồn qua từng lớp. Cách duy nhất để biết giới hạn thật là chạm vào nó, bằng một thí nghiệm rẻ và có thể quay đầu.
Người kể chuyện áp dụng ngay lên chính video này: bình thường viết kịch bản mất 3 ngày, quay là một ngày riêng. Lần này cô gộp cả hai vào một ngày, rồi siết thêm — xong trước 2 giờ chiều để kịp đi đánh cầu lông. Tác dụng phụ thú vị hơn kết quả: khi bị siết, những giả định vô hình rụng xuống. “Tại sao phải quay ở phòng khách có kệ sách đẹp? Thứ quan trọng nhất của video là nội dung — quay trong phòng ngủ cho nhanh.”
Chuyển thành hành động
Chọn một con số bạn đang coi là bất di bất dịch và thử hạ nó xuống trong một chu kỳ: thời gian build, số bước trong quy trình release, thời lượng buổi họp tuần, số người bắt buộc có mặt trong một cuộc họp, số ngày từ merge tới production.
Hai điều kiện để thí nghiệm này an toàn: rẻ để thử và dễ quay đầu. Cắt thời lượng họp từ 60 xuống 30 phút thoả mãn cả hai. Cắt số approval trên hotfix production thì không.
Và học chi tiết đắt nhất của câu chuyện: hỏi người trực tiếp làm, không hỏi người quản lý họ. Biên an toàn nằm ở tay người hàn, không nằm trong bản báo cáo.
Câu chuyện tường 4 mm được kể lại như một thành công, nhưng nó là mẫu sống sót — những lần cắt biên an toàn thất bại thì không ai kể thành giai thoại. Trong phần mềm, ranh giới rõ ràng: hạ giới hạn ở những chỗ hỏng thì tốn tiền và thời gian (build, quy trình, họp, scope) — giữ nguyên biên an toàn ở những chỗ hỏng thì mất dữ liệu, rò rỉ thông tin hoặc gây sự cố cho khách hàng.
Nguyên tắc 05
Thất bại nhanh, và thật sự học
Khác biệt không nằm ở việc sai — nằm ở việc có sai lại lần hai không.
Câu chuyện gốc
Musk sai rất nhiều. Điểm khác là cách ông tính sổ với thất bại:
Tốt hơn là thử và thất bại nhanh, hơn là dành nhiều tháng chỉ để phân tích vấn đề.
Starship nổ hai lần trước khi bay được ở lần thứ ba, và cả hai lần nổ đều được tính là thành công trong nội bộ vì chúng chỉ ra chỗ cần sửa. Văn hoá này được duy trì bằng cách chủ động không nhập khẩu nỗi sợ rủi ro vốn là mặc định của ngành hàng không vũ trụ.
Cơ chế phía sau
Video nối sang một ý của Alex Hormozi mà tôi thấy là phần giá trị nhất của cả đoạn: khác biệt giữa người thông minh và người không nằm ở hành vi, không nằm ở nhận thức. Rất nhiều người nói “đã rút kinh nghiệm” rồi lần sau lặp lại đúng lỗi cũ. Nghĩa là: bạn điều khiển được mức độ “thông minh” của mình — chỉ cần không tái phạm lỗi đã mắc, bất kể cảm xúc lúc đó thế nào.
Thói quen cụ thể mà người kể chuyện dùng để ép việc học thành hành vi: journaling mỗi sáng — hôm qua đã làm gì, điểm nào tốt, điểm nào cải thiện được, từ cách điều phối đội tới cách phân bổ sự tập trung.
Chuyển thành hành động
Với đội kỹ thuật, phiên bản có kỷ luật của nguyên tắc này là postmortem không đổ lỗi, và phép thử duy nhất cho chất lượng của nó: mỗi sự cố phải sinh ra ít nhất một thay đổi trong hệ thống hoặc quy trình, có người chịu trách nhiệm và có ngày hoàn thành. Một postmortem kết thúc bằng “lần sau cẩn thận hơn” là một postmortem thất bại — nó dựa vào trí nhớ, mà trí nhớ thì thua deadline.
Cấp cá nhân: một trang mỗi sáng, chỉ cần ba dòng — làm tốt gì, hỏng ở đâu, thay đổi gì hôm nay. Giá trị nằm ở việc bạn phải đọc lại chính mình của tuần trước.
“Fail fast” chỉ đúng khi chi phí thất bại nhỏ hơn giá trị thông tin thu được, và khi thất bại xảy ra trong môi trường bạn kiểm soát. SpaceX cho tên lửa nổ ở bãi thử, không nổ khi có phi hành gia bên trong. Bản dịch sang phần mềm: thử thoải mái sau feature flag, trên staging, với canary release — không thử trên toàn bộ dữ liệu khách hàng.
Nguyên tắc 06
Thuật toán 5 bước
Phần cốt lõi nhất — thứ tự các bước quan trọng ngang nội dung các bước.
Đây là quy trình mà những người cộng sự thân cận của Musk đều thuộc lòng vì nó lặp lại gần như mỗi ngày. Nó cũng chính là khung gom lại năm nguyên tắc phía trên.
- Đặt câu hỏi cho mọi yêu cầu Trước khi làm bất cứ gì, hỏi nó có cần thiết không. Yêu cầu phải có tên người đứng sau. Ví dụ đời thường trong video: một video YouTube có thật sự cần edit hào nhoáng và background xịn, hay chỉ cần nội dung đủ sâu?
- Xoá bỏ mọi phần có thể xoá Hơn nửa cuốn tiểu sử là Musk đi khắp nơi yêu cầu người ta xoá bớt. Với đội nhóm: đâu là điểm nghẽn duy nhất cần giải lúc này? Giải xong mới chuyển sang cái tiếp theo — laser focus. Nguyên tắc kèm theo trong sách gốc: nếu bạn không phải thỉnh thoảng thêm lại 10% những gì đã xoá, nghĩa là bạn xoá chưa đủ mạnh tay.
- Đơn giản hoá và tối ưu Sau khi đã chạy một thời gian, xem yếu tố nào tạo ra phần lớn kết quả và cắt tiếp phần còn lại. Thứ tự ở đây là điểm mấu chốt: tối ưu sau khi xoá, vì sai lầm phổ biến nhất là tối ưu một thứ lẽ ra không nên tồn tại.
- Tăng tốc chu kỳ Việc này tốn bao nhiêu giờ thật? Nếu 3 giờ thì đừng để tới ngày mai. Đặt deadline căng để tạo cảm giác cấp bách — nhưng chỉ tăng tốc sau khi ba bước trên đã xong.
- Tự động hoá Bước cuối cùng, không bao giờ là bước đầu. Chính Musk thừa nhận đã nhiều lần tự động hoá quá sớm và kết quả là tự động hoá luôn cả những bước lẽ ra phải bị xoá — biến lãng phí thủ công thành lãng phí được nhân bản với tốc độ cao.
Chuyển thành hành động
Bước 5 là bước đáng giá nhất với người làm kỹ thuật, vì nghề của chúng ta là tự động hoá — nên ta có xu hướng nhảy thẳng vào đó. Mỗi lần định viết script, dựng pipeline hay xây internal tool, hãy chạy ngược lại bốn bước trước: quy trình này có cần tồn tại không → bỏ được bước nào → gộp được bước nào → có nhanh hơn được không — rồi mới tự động hoá phần còn lại.
Cùng logic đó áp cho AI agent và automation: tự động hoá một quy trình rác chỉ tạo ra rác nhanh hơn và khó gỡ hơn, vì giờ đây nó đã được viết thành code và không ai dám đụng.
Nguyên tắc 07
Sống quyết liệt với thứ mình chọn
All in.
Nguyên tắc cuối là nguyên tắc mềm nhất và cũng là nguyên tắc người kể chuyện thấy truyền cảm hứng nhất. Musk là một nhân vật gây tranh cãi — thiếu kiên nhẫn, quát mắng, coi thường nhiều người. Nhưng ông sống hết mình với thứ mình chọn: làm việc thâu đêm, ngủ trên sàn nhà máy, ngồi nhìn một bức tường trống để nghĩ từ đêm tới sáng, và không đổi hướng vì lời bàn tán bên ngoài.
Kết luận mà video rút ra không phải “hãy sống như Musk”, mà là: chọn cho mình một sứ mệnh, dám bước ra khỏi vùng an toàn, đi tìm giới hạn, và giữ được sự hồn nhiên trên đường đi.
Đây là chỗ nên tách con người khỏi phương pháp. Bảy nguyên tắc trên đứng vững độc lập với việc bạn nghĩ gì về Musk, và cái giá cá nhân đi kèm lối sống đó — quan hệ, sức khoẻ, những người xung quanh bị cuốn theo — được ghi lại khá rõ trong chính cuốn tiểu sử. “Quyết liệt” đáng học; “không có ranh giới nào” thì không.
Tổng hợp
Dùng cái gì, sửa cái gì, bỏ cái gì
Bảy nguyên tắc, xếp theo mức độ có thể dùng nguyên bản.
| Nguyên tắc | Phán quyết | Điều kiện |
|---|---|---|
| Thuật toán 5 bước | Dùng nguyên bản | Giữ đúng thứ tự. Tự động hoá luôn là bước cuối. |
| Đặt câu hỏi cho mọi yêu cầu | Dùng nguyên bản | Hiểu lý do tiêu chuẩn tồn tại trước khi bỏ nó. |
| Đi tìm giới hạn | Dùng có điều kiện | Chỉ ở nơi thí nghiệm rẻ và quay đầu được. Hỏi người trực tiếp làm. |
| Thất bại nhanh | Dùng có điều kiện | Trong môi trường có kiểm soát. Kèm postmortem sinh ra thay đổi thật. |
| Follow the mission | Dùng để chọn việc | Không dùng để thay lương hay biện minh cho overtime. |
| Khẩn cấp phi lý | Dùng liều lượng thấp | Phân biệt deadline kéo căng và deadline cam kết. Bỏ hoàn toàn phần doạ nạt. |
| All in | Chọn lọc | Quyết liệt thì học; xoá ranh giới cá nhân thì không. |
Một câu để nhớ cả bảy
Hỏi lại đề bài trước khi tối ưu lời giải. Xoá trước khi tối ưu. Tối ưu trước khi tăng tốc. Tăng tốc trước khi tự động hoá. Và đừng bao giờ tự động hoá thứ lẽ ra phải bị xoá.
Thực hành
Bài tập 7 ngày
Mỗi ngày một nguyên tắc, mỗi ngày một hành động cụ thể — không đọc thêm.
- Ngày 1 — Đề bài. Viết ra ba quy trình bạn đang tuân theo vì quán tính. Với mỗi cái, tìm cho ra tên người đã đặt ra nó. Bỏ một cái không tìm được tên.
- Ngày 2 — Sứ mệnh. Viết một câu trả lời cho “nếu tiền không phải biến số, tôi làm việc này để làm gì”. Sau đó liệt kê một thứ bạn sẽ từ chối vì câu đó.
- Ngày 3 — Giờ thật. Với ba việc đang chờ, hỏi “tốn bao nhiêu giờ làm thật?” thay vì “khi nào xong?”. So sánh với ngày hẹn hiện tại.
- Ngày 4 — Giới hạn. Chọn một con số bạn coi là cố định và hạ nó xuống trong tuần này. Ghi lại chuyện gì xảy ra.
- Ngày 5 — Xoá. Lấy quy trình tốn thời gian nhất của đội và xoá đúng một bước. Chạy thử một chu kỳ.
- Ngày 6 — Học thật. Lấy sự cố hoặc sai lầm gần nhất. Nó đã sinh ra thay đổi nào trong hệ thống chưa? Nếu chưa, tạo ngay một thay đổi có người chịu trách nhiệm và có deadline.
- Ngày 7 — Nhìn lại. Trong sáu ngày qua, thí nghiệm nào cho kết quả tốt hơn mong đợi? Biến đúng một cái thành mặc định mới.
Câu hỏi tự kiểm sau 7 ngày
Bạn đã bỏ được thứ gì chưa, hay chỉ mới thêm vào những cách làm mới? Cả bảy nguyên tắc trên đều xoay quanh việc lấy bớt đi. Nếu sau một tuần danh sách việc của bạn dài hơn, bạn đã đọc nhưng chưa áp dụng.