SpaceXSI x Bain: hội đồng quản trị đang hỏi gì về SI SDLC

1. Mở đầu: câu hỏi thứ hai trong phòng họp hội đồng quản trị

Đây là một buổi webinar trên kênh Grok, do SpaceX Superintelligence (SpaceXSI) và Bain cùng làm, về những gì hội đồng quản trị đang hỏi quanh SI SDLC. Hai diễn giả là Purna Doddapaneni, Partner tại Bain & Company, và Mike Saeks, Field CTO tại SpaceXSI (theo mô tả video đăng ngày 22/10/2026). Slide giới thiệu ghi đầy đủ hơn: Purna là "Partner, Enterprise Technology: Global Head of Engineering Excellence" ở Bain & Company, còn Mike là "Field CTO & Head of Token ROI" ở SpaceX Super Intelligence (slide trong video đăng ngày 22/10/2026).

Người điều phối buổi là Malery Lassen, thẻ tên trên khung camera ghi "Partner Marketing". Chị cảm ơn mọi người đã tham gia, giới thiệu Purna là partner ở Bain & Company và Mike là một trong các field CTO của SpaceX Superintelligence, đồng thời là head of Token ROI. Chị nói hai diễn giả này nói chuyện với các hội đồng quản trị cả ngày, nên chị rất muốn nghe góc nhìn của họ và những gì họ sẽ chia sẻ (video đăng ngày 22/10/2026). Rồi chị mời Purna bắt đầu.

Purna chào mọi người và cảm ơn vì đã dành thời gian. Anh nói khi bắt đầu, anh và đồng nghiệp ở Bain muốn mang vào đây những cuộc trò chuyện từ phòng họp hội đồng quản trị, và cách khách hàng của Bain đang nghĩ về chuyện lấy được giá trị từ các khoản đầu tư họ đang bỏ ra (video đăng ngày 22/10/2026).

Theo Purna (video đăng ngày 22/10/2026), cho tới gần đây, mỗi khi AI và engineering được nhắc tới trong một cuộc họp hội đồng quản trị, câu hỏi gần như lúc nào cũng là: "chúng ta có đang đi đủ nhanh không?". Anh nói câu hỏi đó, thật lòng mà nói, chưa biến mất, nhưng giờ nó bị theo ngay sau bởi một câu hỏi khác: "chính xác thì chúng ta đã nhận được gì cho khoản đó?".

Anh nhấn mạnh đây không phải là một cuộc rút lui khỏi AI. Phần lớn công ty vẫn đang tăng ngân sách (theo Purna, video đăng ngày 22/10/2026). Trong báo cáo công nghệ thường niên của Bain, anh và đồng nghiệp đã đưa ra ước tính rằng chi tiêu toàn cầu hằng năm cho hạ tầng AI có thể đạt 1.500 tỷ USD (1,5 nghìn tỷ đô) vào năm 2031 (ước tính của Bain, nhắc lại trong video đăng ngày 22/10/2026). Anh nói rõ đây vẫn là chi tiêu cho hạ tầng, không phải ước tính ngân sách phần mềm của doanh nghiệp, nhưng nó cho thấy quy mô của làn sóng đầu tư giờ đang chạm tới các tổ chức engineering.

Trong bối cảnh đó, theo Purna, hội đồng quản trị thực ra đang hỏi ba điều: điều gì đã thay đổi? chi phí cho mỗi đơn vị bàn giao là bao nhiêu? và chúng ta có tin được kết quả không? Bên dưới cả ba câu đó còn có một phép thử thứ tư đang xuất hiện: đội finance có xác nhận câu trả lời đó không? CFO, hay văn phòng CFO, ngày càng là người phân xử xem bằng chứng có đủ đáng tin để đi vào một ngân sách, một P&L, hay quyết định cấp vốn tiếp theo hay không (video đăng ngày 22/10/2026).

Anh nói nếu người nghe muốn mang về một điều từ buổi này, thì hãy là điều này: chi tiêu không phải là vấn đề; chi tiêu không được quản lý, đặt cạnh giá trị không được đo, mới là vấn đề (Purna, video đăng ngày 22/10/2026).

2. Realization gap: 38% so với 52%

Purna nói một lý do khiến câu hỏi thứ hai trong phòng họp trở nên gắt hơn là realization gap, khoảng cách giữa giá trị kỳ vọng và giá trị thu được (video đăng ngày 22/10/2026).

Theo nghiên cứu gần đây của Bain mà anh dẫn, các tổ chức đang chuyển được khoảng 38% giá trị kỳ vọng từ AI thành kết quả đã đưa vào vận hành hay đo được. Với tự động hoá truyền thống, thứ đã có mặt khoảng hai thập kỷ, con số này vẫn ở khoảng 52% (số liệu Bain, nhắc trong video đăng ngày 22/10/2026). Anh và đồng nghiệp ở Bain gọi đây là realization rate: tỷ lệ giá trị kỳ vọng cuối cùng trở thành kết quả kinh doanh đo được.

Anh lưu ý con số 38% là con số trên toàn doanh nghiệp, không riêng cho phát triển phần mềm, nhưng theo anh, kỷ luật này áp dụng thẳng sang (video đăng ngày 22/10/2026). Các lãnh đạo engineering cần tách riêng: business case đã mô hình hoá điều gì, tổ chức thực sự đã đưa vào vận hành điều gì, đã áp dụng (adopt) điều gì, và đã thu được giá trị gì.

Vì vậy, theo Purna (video đăng ngày 22/10/2026), hội đồng quản trị không hỏi AI có viết được code hay không. Họ hỏi vì sao giá trị cứ về tới ở mức một phần của business case, và liệu làn sóng này có khác gì không.

3. Nghịch lý đo lường và finance làm đồng sở hữu

Tiếp theo, Purna đưa ra cái anh gọi là nghịch lý đo lường (measurement paradox). Trong khảo sát AI gần đây của Bain, 74% công ty nói mức cao nhất họ đo được một cách đáng tin là các KPI vận hành hoặc tác động kinh doanh. Nghe thì có vẻ trưởng thành, nhưng chỉ 7% nói finance đã xác nhận cả tác động tài chính lẫn tổng chi phí AI (all-in cost) theo từng use case (khảo sát của Bain, nhắc trong video đăng ngày 22/10/2026).

Theo anh, đó mới là câu chuyện thật đằng sau sự bùng nổ của các KPI về AI. Engineering có thể cho thấy cycle time nhanh hơn, throughput cao hơn. Nhưng nếu những tuyên bố đó không tự động chảy vào giá trị đã thu được, vào ngân sách đang lên kế hoạch, hay vào một quyết định tái đầu tư, thì tất cả những thứ đó không thêm được bao nhiêu giá trị (Purna, video đăng ngày 22/10/2026).

Vì vậy, finance cần một baseline đã thống nhất, một phương pháp phân bổ (attribution) đáng tin, và một tổng chi phí đầy đủ, không chỉ hoá đơn model. Purna nói sự hợp tác phải bắt đầu trước khi đưa vào vận hành (video đăng ngày 22/10/2026):

• Finance nên ký duyệt baseline và logic giá trị, tức giá trị sẽ được tạo ra (theo Purna, video đăng ngày 22/10/2026).
• Ngân sách nên tách phần seat có thể dự đoán khỏi phần tiêu thụ biến đổi (theo Purna, video đăng ngày 22/10/2026).
• Chi phí nên được phân bổ gần như theo thời gian thực cho các team, các workflow và các agent đang tạo ra nó (theo Purna, video đăng ngày 22/10/2026).
• Agent tự động hay agent mở (open-ended) cần người chịu trách nhiệm chi phí được nêu tên, các giới hạn theo tầng rủi ro, và điều kiện dừng (theo Purna, video đăng ngày 22/10/2026).
• Các team nên chạy look-back, so sánh giá trị đã mô hình hoá với giá trị thực thu, trước quyết định cấp vốn tiếp theo (theo Purna, video đăng ngày 22/10/2026).

Anh nói thêm, thật lòng thì điều này không có nghĩa là phải đặt mức trần thấp, áp chung cho mọi developer. Nó có nghĩa là có kiểm soát rõ ràng ở những chỗ mà chi tiêu tự động có thể cộng dồn lên. Cuối cùng, engineering vẫn sở hữu workflow của mình, finance cần xác nhận phần kinh tế, nhưng cả hai cùng nhau sở hữu việc hiện thực hoá giá trị (Purna, video đăng ngày 22/10/2026).

4. Năng suất chưa phải là giá trị khi năng lực giải phóng chưa có đích

Purna chuyển sang workflow đi cùng sự hợp tác với finance mà anh vừa nói, và trình bày chuỗi giá trị (video đăng ngày 22/10/2026). Chi tiêu cho AI là đầu vào, bước đầu tiên. Năng suất cục bộ (local productivity) là một kết quả trung gian. Giá trị chỉ xuất hiện khi phần năng lực mà AI giải phóng ra được chủ động hướng tới một chỗ nào đó, và hiện ra thành một kết quả mà doanh nghiệp nhìn thấy được và finance xác nhận được.

Mỗi giờ được giải phóng có thể đi vào ba hướng: làm được nhiều hơn trong roadmap đang có, đưa sản phẩm ra thị trường nhanh hơn, hoặc nâng chất lượng và độ bền vững (resiliency) để tạo ra kết quả tài chính. Theo Purna, hướng nào cũng là câu trả lời chính đáng, nhưng đích đến phải được chọn từ trước và gắn với một metric (video đăng ngày 22/10/2026).

Anh nói không quyết định trước mới là sai lầm, vì năng lực chưa được quyết định sẽ bị hấp thụ mất, và sau đó hội đồng quản trị sẽ hỏi năng suất đã đi đâu (Purna, video đăng ngày 22/10/2026).

Tiếp theo là đo phần kinh tế theo cách doanh nghiệp cảm nhận nó: tổng thời gian engineering cộng với lượng tiêu thụ AI, tính theo mỗi feature đã ship, mỗi đoạn code production-ready đã được merge, hay mỗi incident đã được xử lý. Theo Purna, một ngân sách token tính theo đầu developer cho biết rất ít về việc một workflow có đang tạo ra giá trị hay không (video đăng ngày 22/10/2026).

Quy tắc thực tế anh đưa ra: mọi workflow có AI cần một kết quả (outcome) được finance đồng ý, một chi phí đơn vị (unit cost), và một mô hình kiểm soát (control model). Không phải mọi token đều cần một cổng kiểm duyệt, mà là một cách tiếp cận mà tổ chức hướng tới (Purna, video đăng ngày 22/10/2026).

5. Nút thắt chuyển sang review

Purna quay lại chính hệ thống engineering. Theo anh, finance chỉ xác nhận được những gì hệ thống tạo ra và đo được: hệ thống có biến lượng tiêu thụ AI thành output mà bạn tin được hay không (video đăng ngày 22/10/2026)?

Trong một khảo sát của Bain với các lãnh đạo công nghệ cấp cao, mức cải thiện trung vị (median uplift) được báo cáo ở tốc độ release cycle và ở năng suất developer, cả mức đạt được hôm nay lẫn mức họ nhắm tới trong một tới hai năm tới, cho thấy kỳ vọng gần như tăng gấp đôi. Trên slide, tốc độ release cycle là 27% hôm nay và 67% kỳ vọng trong 1 tới 2 năm; năng suất developer là 20% hôm nay và 39% kỳ vọng (slide trong video đăng ngày 22/10/2026).

Nhưng theo Purna, thách thức không nằm chủ yếu ở năng lực của model. Cũng trong nghiên cứu đó, developer dùng AI hoàn thành nhiều task hơn, anh nói khoảng 20%, còn slide ghi +21%; trong khi thời gian review tăng, slide ghi +91% (khảo sát Bain, slide trong video đăng ngày 22/10/2026).

Như vậy, anh nói, nút thắt đã di chuyển: code ra nhanh hơn, hàng đợi review dài hơn, và hệ thống quay về throughput của checkpoint con người chậm nhất. Điều này có thể xảy ra trên toàn workflow, kể cả phía trước, nơi các product team phải đảm bảo có một backlog lành mạnh, và phía sau, nơi đội SRE hay đội stability và resiliency phải xử lý được khối lượng output (Purna, video đăng ngày 22/10/2026).

Đó là lý do acceptance rate hay số dòng code được tạo ra là những tín hiệu hữu ích, nhưng là metric ROI chưa đầy đủ. Theo Purna (video đăng ngày 22/10/2026), các dashboard lãnh đạo mà mọi người đang nhìn và theo dõi cần nhìn cả vòng đời từ đầu tới cuối: mức can thiệp của con người, chất lượng output được tạo ra, rủi ro, và tổng chi phí cho mỗi đơn vị bàn giao.

6. Missing architecture: ba thành phần quanh model

Theo Purna (video đăng ngày 22/10/2026), nhìn vào những công ty đang đi trước, điều họ đã làm là xây một kiến trúc quanh model, thứ anh và đồng nghiệp ở Bain gọi là missing architecture, gồm ba thành phần chính.

Thứ nhất là agent-ready context. Mọi agent đều cần kiến thức của tổ chức được viết ra rõ ràng: specification, convention, các quyết định kiến trúc, acceptance criteria, và khi nào (nếu có) thì cần escalate (theo Purna, video đăng ngày 22/10/2026). Một ví dụ công khai đơn giản là Stripe: theo Purna, Stripe merge khoảng 1.300 pull request do AI viết mỗi tuần, qua cùng quy trình review của con người như mọi thay đổi khác (video đăng ngày 22/10/2026). Anh nói điều này cho thấy đòn bẩy mà Stripe có được đến từ context và hệ điều hành quanh task, không chỉ từ một model mạnh hơn.

Thứ hai là routing và tự động hoá sự tin cậy (confidence). Dành phần reasoning đắt tiền cho những phần của workflow thật sự cần nó, còn phần còn lại thì làm cho có cấu trúc và deterministic hơn. Theo Purna, các lãnh đạo đang xây risk scoring, policy as code, evaluation đối chiếu với acceptance criteria, và một audit trail đầy đủ. Trong thế giới này, bạn cũng cần các cổng tự động (automated gate) lo phần kiểm tra thường lệ, để con người tập trung vào ngoại lệ và các quyết định rủi ro cao (video đăng ngày 22/10/2026).

Cuối cùng là vận hành SDLC như một sản phẩm. Theo Purna, nó không phải một quy trình triển khai xong rồi cứ thế chạy mãi, mà là một quy trình phát triển có owner, có roadmap và một backlog cải tiến. Cần đo đóng góp của con người và của agent riêng rẽ, nhưng quản lý cả đội hỗn hợp như một hệ thống, không phải từng phần riêng. Và đặt chi phí và rủi ro lên scorecard, cạnh tốc độ và chất lượng (video đăng ngày 22/10/2026). Từ đây anh chuyển sang chuyện human in the loop.

7. Human judgment đặt ở đâu, và half-finished redesign

Theo Purna (video đăng ngày 22/10/2026), câu hỏi quan trọng không phải là cần bao nhiêu sự tham gia của con người, mà là human judgment nên nằm ở đâu. Trong một khảo sát của Bain, như phía trái slide, 41% công ty kỳ vọng sẽ chạy một mô hình phân tầng theo rủi ro (risk-tiered), và chỉ 6% hình dung phát triển phần mềm hoàn toàn tự động.

Vậy trên thực tế, theo anh, hãy đặt con người ở các ranh giới quyết định, nơi điều đó quan trọng: ví dụ duyệt ý định (intent) và acceptance criteria, duyệt các thay đổi rủi ro cao dựa trên blast radius và/hoặc khả năng đảo ngược của thay đổi, và áp kiểm soát phân tầng theo rủi ro cho các thay đổi ảnh hưởng tới production. Giữa các checkpoint đó, workflow thường lệ chạy qua quality harness (Purna, video đăng ngày 22/10/2026).

Anh nói có một điểm vướng mang tính tổ chức trong quy trình này: khoảng 70% công ty vẫn ra quyết định tập trung, bất kể mức trưởng thành về AI (khảo sát Bain, video đăng ngày 22/10/2026). Team đã thay đổi, các vai trò đang bắt đầu tiến hoá hay thay đổi, nhưng các bước duyệt, các lần bàn giao và các đường escalation thường vẫn nằm nguyên chỗ cũ. Anh và đồng nghiệp ở Bain gọi đó là half-finished redesign, một cuộc tái thiết kế mới làm được một nửa.

Purna nói: bạn có thể chuyển human judgment tới đúng chỗ; nhưng bạn không thể chuyển các quyết định của con người tới đúng chỗ nếu quyền quyết định không đi theo công việc đang được thiết kế lại (video đăng ngày 22/10/2026).

8. Ba việc cần có trước khi chốt kế hoạch 2027

Để kết phần trình bày, Purna nói với những ai đang lên kế hoạch cho ngân sách 2027 sắp được chốt rằng có ba việc nên làm (video đăng ngày 22/10/2026):

• Đưa finance vào làm đồng sở hữu: cùng họ xác nhận business case, phân bổ tổng chi phí theo workflow và theo agent, và chạy look-back so sánh giá trị đã mô hình hoá với giá trị thực thu (theo Purna, video đăng ngày 22/10/2026).
• Quyết định từ trước năng lực được giải phóng sẽ đi đâu, trước khi nó biến mất vào hệ thống (theo Purna, video đăng ngày 22/10/2026).
• Xây context, sự tin cậy được tự động hoá (automated confidence), model routing và quyền quyết định trước khi mở rộng lượng tiêu thụ (theo Purna, video đăng ngày 22/10/2026).

Anh nhắc lại: cuối cùng, mục tiêu không phải là giảm tối thiểu chi tiêu token, mà là tối đa giá trị thực thu ở một mức chi phí và mức rủi ro chấp nhận được. Nhìn về tương lai, theo Purna, những người thắng sẽ không phải là người chi ít nhất hay nhiều nhất cho token; họ sẽ cho thấy điều gì đã thay đổi, nó tốn bao nhiêu, ai đã xác nhận nó, và vì sao output đáng tin (video đăng ngày 22/10/2026).

Nói xong, anh chuyển lời cho Mike, người mà theo anh thấy điều này diễn ra ở tuyến đầu mỗi ngày.

9. Mike: không có thước đo ROI hoàn hảo, nhưng phải có đơn vị đo

Mike cảm ơn Purna và nói phần trình bày rất tuyệt, với một lượng dữ liệu thật sự đáng kinh ngạc. Anh nói mình là người rất thích dữ liệu và rất háo hức muốn đào sâu vào đó (video đăng ngày 22/10/2026).

Nhưng trước hết, anh đưa ra phản ứng đầu tiên của mình: những gì Purna trình bày khớp rất nhiều với những gì anh đang thấy và nghe, không chỉ từ các lãnh đạo engineering mà từ cả lãnh đạo finance, hội đồng quản trị, nói chung là ở khắp nơi (Mike, video đăng ngày 22/10/2026).

Theo Mike (video đăng ngày 22/10/2026), một thách thức là engineering chưa bao giờ là một ngành có thước đo năng suất hoàn hảo hay thước đo ROI hoàn hảo. Những người lãnh đạo công nghệ như anh luôn phải tự đưa ra phán đoán: khi có thêm ngân sách, đâu là chỗ tốt nhất để tuyển thêm người? đâu là chỗ cần thêm công cụ? đâu là chỗ muốn thử nghiệm nhiều hơn? Anh nói human judgment đó sẽ không bao giờ biến mất. Thực ra nó còn càng ngày càng quan trọng hơn khi ngày càng có nhiều agent tự động và thông minh làm việc như trợ lý và đảm nhận ngày càng nhiều phần của SI SDLC.

Anh nói đây là điều anh luôn quay về đầu tiên: dù ta rất muốn có một thước đo ROI hoàn hảo, đó không phải thực tế của software engineering. Nhưng nói vậy, không có thước đo nào và không có KPI nào cũng không chấp nhận được, nhất là khi ngân sách trong tổ chức ngày càng lớn, cả về con số tuyệt đối lẫn tương đối (Mike, video đăng ngày 22/10/2026).

Điều khiến anh tâm đắc, và anh thấy lặp đi lặp lại, là thực hành tốt nhất khi engineering, CTO và CFO làm việc sát với nhau: thống nhất đâu là đơn vị công việc và đơn vị giá trị mà cả hai bên muốn tối ưu (Mike, video đăng ngày 22/10/2026). Nó sẽ trông khác nhau tuỳ chỗ, không có một thước đo hoàn hảo nào. Với feature mới, nó có thể là tốc độ tổng thể từ một ý tưởng tới lúc ship và đưa vào tay khách hàng. Nó có thể là mình đang chi bao nhiêu, và chi tiêu ở đây tính trên cả con người, agent, công cụ, tất cả.

Theo những gì Mike thấy (video đăng ngày 22/10/2026), khi mọi người đi nhanh hơn và các team linh hoạt hơn, những công ty thành công nhất, kể cả khi chi tiêu token tăng đáng kể, nếu cho thấy được chi phí đơn vị thực ra đang giảm, thì đó là ROI rất cao. Và gần như mọi công ty anh nói chuyện đều có một backlog mà họ chưa làm tới được. Nên chừng nào bạn cho thấy mình đang làm được nhiều việc hơn hẳn với một ngân sách cố định, hay cho thấy ngân sách đó đang sinh lời nhờ cải thiện năng suất, thì anh đã thấy mọi đối tác finance đều trở thành người ủng hộ công nghệ.

Anh nói điều lớn nhất là: bắt đầu đo, định nghĩa các KPI đó, làm việc với tổ chức finance, và để họ là đối tác ngay từ ngày đầu. Đừng cố làm tất cả trong một khoảng chân không rồi tới cuối chu kỳ ngân sách mới đến gặp họ, nếu không bạn sẽ không tạo được điều kiện để thành công (Mike, video đăng ngày 22/10/2026).

10. Cuộc nói chuyện trong hội đồng quản trị nghe ra sao, và blended metrics

Mike nói anh rất muốn đào sâu vào dữ liệu Purna đã chia sẻ. Anh hỏi: Purna mở đầu bằng việc hội đồng quản trị hỏi "chúng ta đã nhận được gì cho khoản đó?", nhưng cuộc nói chuyện đó thực sự nghe ra sao trong phòng họp? Purna có thể đi qua một ví dụ, hay nói rộng thêm một chút không (video đăng ngày 22/10/2026)?

Purna trả lời: hội đồng quản trị không còn đặt câu hỏi AI có chạy được không; họ coi chuyện AI chạy được là đương nhiên. Phần lớn họ đã từng xem: đây là giá trị sẽ tạo ra, đây là khoản đầu tư tôi cần. Giờ nhìn về phía trước, họ hỏi: chúng ta đã đạt được hết giá trị đặt ra trong đợt trước chưa (theo Purna, video đăng ngày 22/10/2026)?

Và theo dữ liệu đã nói, chỉ 38% thực sự đạt được những gì họ đã nói. Nghĩa là hội đồng quản trị giờ hỏi: tôi có nên đầu tư với giả định là đã thu được giá trị lần trước, hay tôi cần nghĩ lại cách đầu tư? Rồi tới metric thứ hai: trong các giá trị kinh doanh hay KPI mà các team engineering báo cáo, chỉ 7% đã được finance xác nhận, và đó là chỗ hội đồng quản trị đẩy vào trước tiên. Họ hỏi vì sao các metric trên dashboard mà họ liên tục nhìn thấy lại không khớp một cách nhất quán với ngân sách, P&L và kết quả kinh doanh thực thu (Purna, video đăng ngày 22/10/2026).

Mike nói điều đó rất hợp lý, và nó quay về chuyện cần thống nhất từ đầu các KPI mà cả engineering lẫn finance đồng ý được, điều mà anh cho là then chốt (video đăng ngày 22/10/2026). Theo anh, chỗ anh thấy rắc rối nhiều nhất là khi có, chẳng hạn, một metric về mức sử dụng ở phía engineering: số dòng code đang tăng, hay ngày càng nhiều kỹ sư áp dụng các công cụ này và dùng chúng mỗi ngày. Bạn sẽ nghe kỹ sư nói nếu lấy công cụ đi thì họ không thể tưởng tượng làm việc tiếp được nữa.

Nhưng nếu những điều đó không phản ánh xuống được một số metric tài chính, thì đó là nơi phát sinh rất nhiều sự lệch pha. Mike nói đó là lý do anh cho rằng blended metrics rất quan trọng: chi phí cho mỗi đơn vị công việc của engineering là thứ mà cả CTO lẫn CFO đều thật sự đồng thuận được (Mike, video đăng ngày 22/10/2026).

11. Leading metrics, lagging metrics và yếu tố thời gian

Có tiếng đáp "Yeah". Purna nói anh muốn đi sâu hơn vào chính các metric. Theo anh, điều anh và đồng nghiệp ở Bain đã thấy là không có một "Uber metric" nào dùng được cho mọi tổ chức và mọi nhóm, kể cả trong cùng một tổ chức (video đăng ngày 22/10/2026).

Cách anh thấy hiệu quả là nghĩ về metric theo hai loại: leading metrics và lagging metrics. Leading metrics là thứ đo được trong ngắn hạn, nếu bạn chạy theo sprint thì là sprint này so với sprint trước. Lagging metrics là những gì bạn sẽ thấy về sau. Ý tưởng là giữ cân bằng cả hai: vừa thấy mình đang tiến bộ trong lúc chờ, vừa chắc rằng mọi thứ đang đi đúng hướng về dài hạn (theo Purna, video đăng ngày 22/10/2026).

Một ví dụ anh và đồng nghiệp hay đưa ra là test automation. Theo Purna (video đăng ngày 22/10/2026), nhiều khách hàng của Bain đã vật lộn với test automation, hoặc đang ở các mức trưởng thành khác nhau về nó. Ở đó, leading metric là: tôi có thấy test coverage hay code coverage tăng không? Còn lagging metric là số bug đang xảy ra trên production; lý tưởng là con số này bắt đầu giảm. Nếu không giảm, thì ta đã tối ưu cho một task chứ không phải cho cả quy trình từ đầu tới cuối.

Vì thế, khi nói về các metric, theo anh một mặt cần gắn chúng với finance, mặt khác phải theo dõi được chúng, để thấy toàn bộ công việc và quy trình đang đi đúng hướng (Purna, video đăng ngày 22/10/2026).

Mike nói điều đó rất hợp lý, rồi hỏi tiếp: Purna nghĩ thế nào về khoảng thời gian phù hợp để thấy, hay để kỳ vọng, mối tương quan giữa leading và lagging? Ý anh là tới một lúc nào đó, nếu bạn nói với CFO "chúng ta đang đầu tư vào việc tăng test coverage, và về sau điều đó sẽ dẫn tới code chất lượng cao hơn", thì cuối cùng bạn phải cho thấy được mối tương quan đó. Vậy làm sao thêm yếu tố thời gian vào (video đăng ngày 22/10/2026)?

Purna đưa ra một ví dụ từ khách hàng mà Bain đang làm cùng. Như anh đã nói, metric và KPI cho mỗi khách hàng phụ thuộc vào điểm xuất phát, vào những điểm đau đang cần giải quyết, chứ không có một metric dùng cho tất cả. Với khách hàng này, vấn đề là chất lượng: số bug xảy ra trên production. Hệ quả là phần lớn đội engineering của họ tập trung sửa bug, chứ không thực sự làm nền tảng thế hệ mới mà họ đang cố nâng cấp (theo Purna, video đăng ngày 22/10/2026).

Điều anh và đồng nghiệp làm, cũng là thống nhất với finance từ trước, là bắt đầu gán một giá trị tiền cho chi phí của một bug phải sửa trên production, hoặc ở các giai đoạn khác nhau, từ dev sang test sang stage trước khi lên production. Anh và đồng nghiệp bắt đầu nhìn vào số bug đang xảy ra và lượng thời gian kỹ sư bỏ ra để khắc phục chúng. Giờ có một giá trị tiền gắn với nó, vì số bug đáng lẽ phải giảm, nghĩa là giá trị cũng phải bắt đầu được theo dõi trong quy trình đó. Và như đã thống nhất từ trước, anh và đồng nghiệp gắn việc theo dõi với release cycle của các sản phẩm khách hàng làm (theo Purna, video đăng ngày 22/10/2026).

Leading metric thì đo sprint này so với sprint trước, dễ theo dõi và nằm trong tầm kiểm soát. Còn lagging metric là số bug trên production phải bắt đầu giảm, và cách duy nhất để theo dõi là theo release cycle. Vì vậy, theo Purna, yếu tố thời gian được thêm vào dựa trên từng use case và từng workflow cụ thể. Anh so sánh: Amazon hay các công ty khác release cứ vài giây một lần, trong khi một số khách hàng của anh release ba tháng, sáu tháng hay chín tháng một lần. Đó là cách anh và đồng nghiệp gắn yếu tố thời gian vào, ở mức mà đội của CFO thấy yên tâm khi bắt đầu (video đăng ngày 22/10/2026).

12. Ba trục tối ưu và tinh thần Kaizen

Mike nói điều đó hoàn toàn hợp lý. Anh kể công ty của anh là một công ty ship nhanh hơn và thường xuyên hơn bất cứ nơi nào anh từng làm, và thật lòng là hơn bất cứ thứ gì anh từng thấy. Điều đó rất thú vị, vì nội bộ ở công ty anh, vòng phản hồi giữa tốc độ và chất lượng, giữa leading và lagging, nhanh tới mức anh và đồng nghiệp nhận phản hồi ngay lập tức (Mike, video đăng ngày 22/10/2026). Nhưng anh nhận ra với phần lớn khách hàng anh làm việc cùng thì không phải vậy; như Purna nói, release cycle của họ hoàn toàn không phải mỗi giây một lần.

Dù vậy, theo Mike, các thực hành tốt và triết lý ở đây vẫn áp dụng được, bất kể bạn release mỗi giây một lần hay mỗi quý một lần. Trong đầu anh, có ba trục chính để tối ưu: cải thiện tốc độ, cải thiện chất lượng, và giảm chi phí mà không hy sinh hai trục kia (video đăng ngày 22/10/2026).

Anh nói rất nhiều điều anh đang thấy là khi engineering tăng tốc, điều mà theo anh tất cả đều đồng ý trong thế giới mới của superintelligence và agent tự động này, nó đang tăng tốc, thì điều quan trọng nhất là nó gần như trở thành một quy trình. Anh nói giờ anh đang ở trong một công ty sản xuất theo nhiều nghĩa, nên anh quay về với "the good old Toyota art of Kaizen" (Mike, video đăng ngày 22/10/2026).

Câu hỏi theo anh là: làm sao tìm ra những cải thiện một điểm phần trăm, hai điểm phần trăm, ba điểm phần trăm về tốc độ, chất lượng hay chi phí? Rồi mỗi chu kỳ, mỗi sprint, mỗi ngày, làm sao để chúng cộng dồn khắp tổ chức? Vì rốt cuộc, theo Mike, đó là cách đi từ đoạn nằm ngang của một đường cong hàm mũ sang đoạn dựng đứng (video đăng ngày 22/10/2026).

13. Giá mỗi token giảm, nhưng hoá đơn vẫn tăng

Purna nói anh rất thích phép so sánh Kaizen của Mike, vì nó chạm tới phần kinh tế mà hai người chưa nói rõ. Theo anh, những cải thiện hai điểm đó chỉ cộng dồn được khi lãnh đạo nhìn thấy cả hai vế của phương trình: lượng tiêu thụ đang làm gì, và workflow đang tạo ra gì (video đăng ngày 22/10/2026). Anh mở vài hình minh hoạ để cùng đi qua.

Điểm đầu tiên: giá model thấp hơn không tự động có nghĩa là hoá đơn AI thấp hơn. Purna kể trong một bộ dữ liệu Azure công khai mà anh và đồng nghiệp ở Bain đã phân tích, lượng token sử dụng tăng khoảng 4,5 lần so với mốc tháng 12/2024, trong khi chi phí cho mỗi triệu token giảm còn 42% mức ban đầu, tức giảm 58%. Nhân hai con số với nhau, tổng hoá đơn vẫn tăng, anh nói khoảng 2,3 lần, còn slide ghi ">2×" (phân tích của Bain, video đăng ngày 22/10/2026).

Vì sao? Theo Purna, vì agent thay đổi đơn vị công việc. Một prompt đơn lẻ trở thành một vòng lặp nhiều bước: agent nạp context, suy luận, gọi tool, kiểm tra output, thử lại, và đôi khi chạy các task song song. Cùng lúc đó, các team chuyển sang những frontier model mới hơn và mở rộng việc áp dụng sang nhiều workflow hơn. Giá đơn vị giảm, nhưng số lượng và độ phức tạp của các lần gọi tăng nhanh hơn (video đăng ngày 22/10/2026).

Đó là lý do, theo anh, finance và engineering cần mô hình hoá giá và lượng tiêu thụ thành hai dòng kế hoạch riêng, và không dòng nào là metric ROI cuối cùng. Câu hỏi tốt hơn là: tổng chi phí của cả workflow cho mỗi đơn vị output chấp nhận được là bao nhiêu, tức thời gian engineering, seat, inference, review công việc, làm lại (rework), và mọi chi phí chất lượng phát sinh về sau, gắn với kết quả mà doanh nghiệp đã đồng ý cấp vốn (Purna, video đăng ngày 22/10/2026).

Purna nói đây là chỗ điểm Kaizen của Mike có ý nghĩa: một hoá đơn đầu tiên cao không tự động là lời phán quyết về use case đó. Theo anh, các workflow agentic giai đoạn đầu thường kém hiệu quả. Câu hỏi là chi phí cho mỗi đơn vị được chấp nhận có đang giảm qua từng sprint hay không, khi context được cải thiện, routing thông minh hơn và việc kiểm tra được tự động hoá nhiều hơn (video đăng ngày 22/10/2026).

Nếu chi phí đơn vị đang giảm trong khi tốc độ hay chất lượng được cải thiện, thì workflow đó đang học. Nếu không, theo Purna, đó là một tín hiệu thật (video đăng ngày 22/10/2026).

14. Ba chế độ kiểm soát theo workflow và mô hình sở hữu

Vậy lãnh đạo nên làm gì với đường cong chi phí? Theo Purna (video đăng ngày 22/10/2026), câu trả lời sai là đặt một mức trần thấp cho mọi developer; câu trả lời tốt hơn là quản lý theo workflow và theo rủi ro. Anh nói có ba mô hình, hay ba chế độ kiểm soát khác nhau.

Thứ nhất, tiết chế việc thường lệ, rủi ro thấp: summary, retrieval và các phép biến đổi đơn giản. Ở đây có thể dùng mặc định chi phí thấp hơn, context tiêu chuẩn và giám sát nhẹ. Theo Purna, những task này hiếm khi cần model reasoning đắt nhất hay một quy trình duyệt nặng nề (video đăng ngày 22/10/2026).

Thứ hai, mở rộng cho việc phát triển hằng ngày có quản trị. Theo Purna, đây là nơi phần lớn mức sử dụng có năng suất nằm: viết code, test và refactor trong phạm vi giới hạn, bên trong một repository đã biết và một quality harness. Hãy cho các team soft limit cao, dùng routing thông minh, tự động hoá kiểm tra thường lệ, và làm cho chi phí và chất lượng hiện rõ ở cấp workflow. Anh nói các mức trần thấp áp chung có thể chặn việc học trước khi phần kinh tế kịp cải thiện (video đăng ngày 22/10/2026).

Cuối cùng, rào riêng phần đuôi rủi ro. Các đợt migration lớn, refactor trên toàn codebase, vòng lặp tối ưu chạy qua đêm, và agent chạy liên tục (persistent agent) có thể tạo ra lượng tiêu thụ không giới hạn hoặc một blast radius lớn hơn nhiều. Theo Purna, những workflow đó cần một người chịu trách nhiệm chi phí được nêu tên, một hạn mức ngân sách cho mỗi giao dịch hoặc giới hạn theo ngày khi phù hợp, cùng các điều kiện dừng rõ ràng và escalation lên con người khi cần (video đăng ngày 22/10/2026).

Anh nói sự phân biệt này quan trọng vì không phải mọi lượng tiêu thụ token đều tạo ra cùng một mức rủi ro. Một developer nhờ trợ lý viết test case khác hẳn một persistent agent hoạt động trên cả codebase hay trong môi trường production suốt đêm (Purna, video đăng ngày 22/10/2026).

Trên cả ba chế độ, theo Purna, dùng cùng một scorecard: tốc độ, chất lượng và chi phí như Mike mô tả, nhưng anh có thể thêm cả mức can thiệp của con người và kết quả kinh doanh thực thu. Engineering sở hữu workflow. Platform team xây các mặc định và guardrail. Finance xác nhận xem kinh tế đơn vị và giá trị thực thu có khớp với business case không (video đăng ngày 22/10/2026).

Vì vậy, quy tắc thực tế không phải là mọi developer phải bảo vệ từng token họ tiêu. Mọi workflow có AI nên có một owner, một kết quả, một chi phí đơn vị và một mô hình kiểm soát. Theo Purna, đó là cách các cải thiện một, hai, ba điểm cộng dồn mà không mất kiểm soát (video đăng ngày 22/10/2026).

Anh nói thật lòng thì đằng sau điều này còn có một mô hình sở hữu rõ ràng (Purna, video đăng ngày 22/10/2026):

• Một team platform trung tâm hay team mua sắm (procurement) nên đặt chuẩn cho toàn doanh nghiệp, đàm phán phần nền có thể dự đoán, và biến routing an toàn, tiết kiệm chi phí thành mặc định (theo Purna, video đăng ngày 22/10/2026).
• Các lãnh đạo engineering, như đã nói, nên sở hữu lượng tiêu thụ ở cấp workflow, vì họ gần giá trị nhất và có thể quyết định năng lực sẽ đi vào thêm roadmap, ra thị trường nhanh hơn, hay chất lượng cao hơn (theo Purna, video đăng ngày 22/10/2026).
• Finance nên đồng sở hữu baseline, phương pháp phân bổ, các kịch bản tiêu thụ, và look-back từ mô hình tới giá trị thực thu (theo Purna, video đăng ngày 22/10/2026).

Theo anh, cách tách này tránh được cả hai cực: một team trung tâm trở thành nút thắt phê duyệt, và một kiểu chi tiêu phân tán hoàn toàn, không có kinh tế chung. Cả hai đều thất bại. Thay vào đó, team trung tâm đặt đường ray, các owner của workflow lái đoàn tàu, và finance xác nhận rằng tàu đã tới nơi mà business case nói nó sẽ tới (Purna, video đăng ngày 22/10/2026).

Và đó, theo Purna, là vòng vận hành quanh token ROI: làm cho đường cong chi phí hiện rõ, quản lý workflow theo mức rủi ro của nó, và tiếp tục cải thiện kinh tế đơn vị. Đó là cách những cải thiện từng chút đưa một tổ chức từ đoạn nằm ngang của đường cong sang đoạn dựng đứng mà không mất kiểm soát (video đăng ngày 22/10/2026).

15. Q&A: đưa finance vào cuộc như thế nào

Malery hỏi đã sẵn sàng cho phần Q&A chưa, Mike đáp "Yeah, let's do it". Chị nói cuộc trò chuyện rất thú vị và chị thấy mình may mắn được nghe. Một phần đáng chú ý trong bài của Purna là việc nhấn mạnh đưa finance vào, và Mike rõ ràng đồng ý và đã thấy điều đó trong công việc. Chị hỏi: theo kinh nghiệm, có một cây cầu tự nhiên nào để finance thật sự hiểu vì sao họ được mời vào không, hay có bối cảnh nào các anh đã phải chia sẻ với họ (video đăng ngày 22/10/2026)?

Purna nói với anh và đồng nghiệp ở Bain, mọi thứ đều quy về việc nhìn vào một workflow và những điểm đau đang cần giải quyết. Như vấn đề QA đã kể: nó ảnh hưởng tới thời gian kỹ sư dành cho nền tảng mới, nghĩa là ảnh hưởng tới release cycle của các feature mới và phần phát triển mới sắp đưa vào. Đó là điểm đau mà đội engineering gặp, nhưng finance cần ủng hộ và cấp vốn cho nó (theo Purna, video đăng ngày 22/10/2026).

Nối vào điều Mike nói trước đó, anh so sánh hai cách: một là "tôi có một ngân sách, rồi tôi nghĩ xem đầu tư vào đâu, theo cách nào"; hai là "đây là một vấn đề, một vấn đề kinh doanh, có tác động tới doanh thu và ảnh hưởng tới khách hàng; đó là một điểm đau; giờ tôi cần nguồn vốn, thứ mà finance, văn phòng CFO, phải phê duyệt". Theo Purna, hành trình là cách thứ hai, vì mình phải giải quyết một điểm đau kinh doanh (video đăng ngày 22/10/2026).

Hãy đưa finance vào, để họ xác nhận business case, các giả định và khoản đầu tư cần thiết, rồi cũng thống nhất mốc thời gian khi nào sẽ thấy cải thiện và khi nào bắt đầu thu được giá trị từ đó. Purna nói đó là lý do anh và đồng nghiệp đưa finance vào từ trước: dẫn họ đi qua business case, để họ thử thách nó (pressure test), rồi cùng đi qua hành trình (video đăng ngày 22/10/2026).

Malery đáp "Great". Mike nói điều đó rất hợp lý và anh muốn nói thêm. Theo anh, nơi sự hợp tác này thành công nhất là khi hiểu rằng việc của CFO và đội điều hành, rốt cuộc, là phân bổ vốn vào chỗ đem lại lợi nhuận cao nhất cho doanh nghiệp. CTO và các lãnh đạo engineering cũng làm đúng việc đó bên trong engineering (Mike, video đăng ngày 22/10/2026).

Sự hợp tác tốt nhất là khi cả hai bên đồng ý về cách đo những gì sẽ đẩy doanh nghiệp đi, và nói chung là khi cả hai đồng ý về việc đang tấn công nút thắt nào trong workflow, hay "job to be done" nào. Theo Mike, khi CTO và CFO hợp tác với nhau về điều đó, đó là nơi anh thấy các công ty thật sự thành công nhất (video đăng ngày 22/10/2026).

Purna nói có thể hơi lạc đề, nhưng nhìn chung, theo những gì anh và đồng nghiệp đã thấy, ai có tiếng nói to nhất trong phòng họp thường là người khiến engineering đi giải quyết một vấn đề, nhưng đó chưa chắc là thứ tạo ra giá trị. Một thay đổi anh và đồng nghiệp đã thấy, nhất là với agentic, là các chu kỳ đang co lại, việc lặp đang nhanh hơn, nên phần lớn khách hàng của anh đang theo dõi từ lúc lên ý tưởng tới lúc lên production (Purna, video đăng ngày 22/10/2026).

Theo anh, chuyện không còn là đếm bao nhiêu user story được làm ra mỗi sprint, mà là nhìn từ đầu tới cuối. Nếu theo dõi được như vậy, cũng dễ hơn để đặt trách nhiệm lên phía kinh doanh: chúng ta đã bàn giao, đây là cách chúng ta theo dõi, giờ hãy cùng lấy về giá trị đã hứa. Như vậy có một nề nếp tốt hơn trong việc phê duyệt vốn cho đúng sáng kiến, thay vì những sáng kiến mà người ta có cảm giác sẽ tạo ra giá trị cho công ty (Purna, video đăng ngày 22/10/2026).

Mike đáp "Absolutely", và Malery nói "Very interesting".

16. Q&A: điểm chung của những công ty đang đi trước

Malery nói câu hỏi tiếp theo dành cho cả hai người. Trong số các công ty hai anh đang làm việc cùng và thấy đang thành công, và chị "spoiler" trước là chị cũng sẽ hỏi điều tương tự về những công ty có lẽ chưa thành công bằng, có điểm chung nào không? Chẳng hạn có ngành nào, hay quy mô công ty nào, hay điều gì khác khiến họ đi trước hoặc tụt lại (video đăng ngày 22/10/2026)?

Mike nhận trả lời trước. Anh nói thật sự chưa thấy tương quan nào với ngành, vùng địa lý hay quy mô. Theo anh, điều lớn nhất gần như là tư duy về việc thành công nghĩa là gì trong thế giới mới này, nơi con người và agent cùng viết code và cùng vận hành SDLC. Những công ty thành công nhất coi đây là một lĩnh vực của thử nghiệm và đổi mới liên tục (Mike, video đăng ngày 22/10/2026).

Anh giải thích: nếu nghĩ lại việc làm phần mềm một năm trước trông thế nào, thì Opus 4.5 của Anthropic khi đó còn chưa ra mắt. Theo Mike, khi ấy những công ty tiên tiến nhất có lẽ viết dưới 50% phần mềm của họ bằng agent; hôm nay, anh nói với những công ty tiên tiến nhất, con số đó là 100%. Anh nói trong vòng một năm, "we went from zero to 100" (Mike, video đăng ngày 22/10/2026).

Và không ai làm điều đó trong một bước nhảy. Theo Mike (video đăng ngày 22/10/2026), đó là liên tục thử các model mới, năng lực mới, harness mới, và xem làm sao lấy chúng để thay đổi cách mình làm việc, thay đổi cách tổ chức team, làm mọi người linh hoạt hơn. Rồi làm sao bắt đầu tự động hoá không chỉ code, mà cả review, review bug, review bảo mật. Làm sao tự động hoá các workflow giữa các agent với nhau.

Anh nói khi được làm thành công nhất thì, thật lòng, đó là khoảng thời gian làm sản phẩm vui nhất anh từng có. Và anh đã thấy điều đó ở rất nhiều khách hàng, nơi kỹ sư giờ được dành ngày càng nhiều thời gian cho những câu hỏi thật sự chiến lược: chúng ta nên xây gì? vì sao nên xây? nó có hợp lý với công ty không? nó tác động gì tới khách hàng? nên thiết kế kiến trúc nó thế nào? Rồi họ thiết kế hệ thống, workflow, và các agent sẽ biến ý tưởng đó thành code production-ready (Mike, video đăng ngày 22/10/2026).

Ngược lại, theo Mike, các công ty anh thấy gặp khó coi đây là một lần áp dụng công nghệ, giống nhiều làn sóng có lẽ đã có trong quá khứ: mua về, triển khai, nhận giá trị. Và nhìn chung, với tốc độ công nghệ và thị trường đang thay đổi, điều đó không còn đúng (video đăng ngày 22/10/2026).

Purna nói muốn nói tiếp ý của Mike. Anh đồng ý: anh và đồng nghiệp ở Bain cũng chưa thấy tương quan cụ thể với ngành hay quy mô. Nhưng tương quan anh và đồng nghiệp đã thấy là ai cũng kỳ vọng "tôi sẽ thả agentic vào các quy trình và workflow hiện có rồi hy vọng phép màu xảy ra". Theo anh, nếu quy trình được thiết kế tồi, bạn sẽ tăng tốc cái điểm đau lên khá nhiều (Purna, video đăng ngày 22/10/2026).

Tương quan mà anh và đồng nghiệp đã thấy là ở những tổ chức engineering có nề nếp engineering cơ bản: định nghĩa sản phẩm đúng cách, viết code đúng cách, có test automation tốt, có release cycle hợp lý, có kiểm tra chất lượng tốt trước khi lên production, và quản lý tốt đội SRE. Khi đã ổn định và chuẩn hoá quy trình, đã có nền móng, giờ đặt AI lên trên, theo Purna, đó là lúc bạn bắt đầu thấy phép màu (video đăng ngày 22/10/2026).

Anh nói đó là tương quan anh và đồng nghiệp đang thấy, vì với những tổ chức chưa trưởng thành trong thực hành engineering, agentic sẽ không giúp giải quyết vấn đề; vẫn cần sửa nền móng trước khi đưa agentic vào. Đó là điều anh và đồng nghiệp ở Bain liên tục hướng dẫn phần lớn khách hàng: nghĩ xem cần những nền móng nào, rồi tất nhiên sẽ nghĩ tới AI, nhưng không chỉ AI; không đưa công nghệ vào chỉ vì công nghệ mà không nghĩ tới quy trình và những hệ quả của nó (Purna, video đăng ngày 22/10/2026).

Mike nói điều đó rất đúng: anh chưa từng thấy một công nghệ nào khuếch đại mạnh hơn cả cái tốt lẫn cái xấu như vậy (video đăng ngày 22/10/2026). Có tiếng đáp "Exactly, exactly". Malery nói đó là một nhận xét rất thú vị, và chị sẽ nghĩ thêm về nó.

17. Q&A: sai lầm thường gặp khi đo chi phí và lợi ích

Malery nói buổi này đã nói khá nhiều về nhu cầu đo lường, chuyện đo khó ra sao, và chuyện chưa bao giờ thật sự có một cách hoàn hảo để ước lượng năng suất engineering. Chị muốn nghe: sai lầm phổ biến nhất là gì khi các team cố tính toàn bộ chi phí của công việc do AI tạo ra, hay toàn bộ lợi ích của nó (video đăng ngày 22/10/2026)?

Purna nói anh sẽ bắt đầu bằng việc nhìn theo kết quả (outcome) được tạo ra, thay vì output, vì AI có thể tạo ra output "like crazy". Theo anh, chỉ đo số dòng code hay số PR được tạo ra thì không thật sự cho thấy tiến bộ (video đăng ngày 22/10/2026).

Khi cách làm này hiệu quả, theo Purna, với mỗi công ty, hãy nghĩ về tham vọng hay North Star mà bạn nhắm tới với cuộc chuyển đổi, gọi nó là AI, là engineering excellence hay gì khác. Với một khách hàng của Bain, tham vọng đó là ra thị trường nhanh hơn; đó là tham vọng thật được đặt ra. Nhưng đằng sau đó, cần hiểu điểm xuất phát của mình, để biết cần dồn sức vào đâu hay cần gỡ những rào cản nào (video đăng ngày 22/10/2026).

Với một trong các khách hàng đó, khi nhìn vào chỗ kỹ sư dành thời gian, kết quả là kỹ sư trung bình dành 25 tới 35% thời gian cho cái anh và đồng nghiệp gọi là hoạt động tạo giá trị (value-added activities) (theo Purna, video đăng ngày 22/10/2026). Phần lớn thời gian còn lại, họ dành để làm rõ product requirements cho hiểu requirements là gì, hoặc cho những requirements đã hiểu sai và đã xây tiếp theo đó, nên giờ phải quay lại viết lại. Hệ quả là họ mất rất nhiều thời gian cho rework, và cộng tất cả lại, họ mất rất nhiều thời gian cho các cuộc họp.

Vậy với khách hàng này, theo Purna, để đạt North Star thật sự, cần xác định đâu là các nút thắt cần gỡ để tăng thời gian kỹ sư dành cho hoạt động tạo giá trị, và chính điều đó đẩy output lên. Đặt tham vọng, hiểu điểm xuất phát, rồi với từng điểm đặt metric và KPI và theo dõi chúng: đó là, ít nhất, khi mọi thứ chạy thật sự tốt (video đăng ngày 22/10/2026).

Còn khi không hiệu quả, theo anh, thường là vì người ta không lùi lại một bước để nhìn, mà lao vào giải một điểm đau mà họ linh cảm là điểm đau. Anh đưa thêm một ví dụ: một khách hàng của anh gặp tình trạng branch sprawl. Hệ quả là người ta xây một module ở một branch, rồi mới nhận ra nó đã được xây ở chỗ khác; toàn bộ công sức đó bị lãng phí. Khách hàng đó đã cố tối ưu theo từng branch, thay vì nhìn ở cấp tổ chức xem đâu là những điểm đau chính cần giải quyết rồi mới tăng tốc (Purna, video đăng ngày 22/10/2026).

Vì vậy, theo Purna, nếu không nhìn quy trình từ đầu tới cuối và hiểu các điểm đau chính, bạn sẽ tối ưu nhầm thứ (video đăng ngày 22/10/2026).

Mike nói anh không thể nói hay hơn được. Theo anh, nó quay về chuyện tấn công vào các nút thắt và cố giải phóng càng nhiều thời gian càng tốt để tập trung vào những hoạt động thật sự tạo giá trị, và điều đó áp dụng cho mọi thứ bạn làm trên toàn SDLC (Mike, video đăng ngày 22/10/2026). Malery nói "kỳ lạ là nó cũng áp dụng cho cả cuộc sống". Mike đáp "It does". Malery nói: "Focus on what matters".

18. Q&A: câu chuyện khách hàng yêu thích và lời chào

Malery nói với Purna rằng anh gần như đã "cướp lời" chị, nhưng chị vẫn sẽ hỏi, biết đâu anh còn một câu chuyện khác. Chị nói không hỏi tên, hay bất cứ thứ gì có thể dù chỉ mơ hồ nhận ra được danh tính, nhưng chị rất muốn nghe hai người có câu chuyện yêu thích nào từ khách hàng, hay từ những gì đã làm, minh hoạ thật rõ những điều đã nói hôm nay không (video đăng ngày 22/10/2026).

Purna nói anh và đồng nghiệp ở Bain yêu quý mọi khách hàng, và mọi case đều thú vị. Theo anh, điều thú vị là tác động có thể tạo ra trong công việc khách hàng đang làm, khuếch đại năng lực của họ. Anh quay lại khách hàng có tình trạng sprawl vừa kể: thách thức của họ là muốn làm được nhiều hơn trong backlog, giống điều Mike nói trước đó, nếu có công cụ, có năng lực, mình có thể làm được nhiều hơn trong backlog và hướng tới đó. Nhưng vì mọi ràng buộc do tình trạng sprawl đó tạo ra, họ không làm tới được (Purna, video đăng ngày 22/10/2026).

Vì vậy, theo Purna, hành trình ở đây là khuếch đại năng lực, để họ có thể làm thêm những dự án họ yêu thích. Đó là điểm mở khoá chính, ít nhất với anh: nối tiếp ví dụ trước, một khi giảm được tình trạng sprawl, có thể thấy các kỹ sư hào hứng vì họ làm được nhiều việc hơn, và nó giảm được sự xáo trộn (churn) họ từng có (video đăng ngày 22/10/2026).

Anh kể mình từng là kỹ sư, cách đây đã lâu. Nếu anh xây một module mà anh biết đã mất sáu tháng, rồi mới nhận ra nó đã được xây ở chỗ khác trong tổ chức, thì đó sẽ là điều bực bội nhất với anh. Nên việc này đã tạo ra một nguồn năng lượng trong các đội engineering mà anh và đồng nghiệp làm cùng, và hướng tới một câu chuyện tăng trưởng, câu chuyện tăng NPS, câu chuyện bền vững. Purna nói với anh, đó là một trong những khách hàng chính anh từng làm mà ít nhất đã tạo ra được tác động (video đăng ngày 22/10/2026).

Mike nói anh rất thích câu chuyện đó. Với anh, nó quay về chuyện chưa bao giờ có khoảng thời gian nào vui hơn để làm sản phẩm như bây giờ: có thể lấy một ý tưởng và thấy nó thành hình nhanh như vậy, cảm giác như phép màu. Anh nói đang thấy điều đó ở nhiều khách hàng lớn nhất, nơi các kỹ sư junior giờ có thể tạo ra tác động lớn hơn nhiều so với trước đây (Mike, video đăng ngày 22/10/2026).

Một vài câu chuyện anh yêu thích, không nêu tên công ty, là khi thấy một văn hoá, một không gian an toàn, nơi người ta ghi nhận và tưởng thưởng công việc của các kỹ sư junior và những người mới vào nghề, khi công việc đó tác động tới toàn bộ doanh nghiệp. Mike kể anh đã thấy những công ty mà nhân viên, có thể đây là công việc engineering đầu tiên của họ, vừa ra trường, mới ngoài hai mươi tuổi, được đứng trước ban lãnh đạo cấp cao nhất, các distinguished engineer và fellow của công ty, và được ghi nhận công việc vì nó có tác động lớn như vậy. Với anh, đó chính là phép màu có thể mở ra khi kết hợp các thực hành tốt nhất về con người, quy trình và công nghệ (Mike, video đăng ngày 22/10/2026).

Malery nói điều đó thật tuyệt, một nốt kết rất đẹp. Chị cảm ơn Mike và Purna vì mọi chia sẻ hôm nay, nói buổi này rất thú vị, cảm ơn tất cả người nghe đã tham gia và chúc mọi người một ngày tốt lành. Có tiếng nói "Thank you so much, Purna", và Purna đáp "Thanks, everybody".