Tôn giáo của tốc độ

• Khi “di chuyển nhanh” vượt khỏi nhu cầu thực tiễn và trở thành bằng chứng của sự nghiêm túc và tham vọng, việc xem xét thận trọng bị coi là thái độ cản trở động lực tiến lên
• Tốc độ thật sự xuất hiện khi hiểu công việc, ràng buộc và phụ thuộc, đưa ra quyết định rõ ràng rồi mới thực thi; nhưng nhiều tổ chức lại khoác áo tốc độ cho yêu cầu mơ hồ và quyết định còn dang dở
• Nếu vội vàng ở giai đoạn hiểu vấn đề, việc làm lại sẽ được ghi nhận là “lặp lại”, hỗn loạn là “căn chỉnh”, thất bại vốn có thể tránh được là “học hỏi”; còn các hệ thống không được tin cậy và quy trình đi đường vòng sẽ đóng cứng thành cấu trúc cốt lõi của doanh nghiệp
• Tính cấp bách là trạng thái trong đó việc quan trọng thật sự có giới hạn thời gian, còn hấp tấp là trạng thái tìm sự nhẹ nhõm cảm xúc từ hành động mà không phải gánh nặng đạt được sự rõ ràng
• Để làm việc đúng cách, cần hiểu, quyết định, xem xét đầy đủ rồi mới hành động; cái giá của việc bỏ qua suy nghĩ, bối cảnh và trách nhiệm sẽ quay lại dưới dạng hệ thống hỏng hóc, đội ngũ kiệt sức, khách hàng rời bỏ và những vết thương vận hành dài hạn

---

Quá trình tốc độ bị nhầm là tiến bộ

• Ra mắt, phản hồi, tuyển dụng, mở rộng và chuyển hướng nhanh tự thân chúng được đối xử như bằng chứng của tham vọng và sự nghiêm túc
  • Yêu cầu chậm lại để suy nghĩ bị xem là cản trở động lực tiến lên
  • Chỉ ra một kế hoạch yếu về mặt cấu trúc lại bị tiếp nhận như thái độ tiêu cực
• Tốc độ vận hành như một loại ma túy tổ chức, đem lại cảm giác rằng tổ chức đang chuyển động dù thiếu kỷ luật phán đoán
  • Mọi người đều thấy bận rộn và khẩn cấp, và có thể lấy chính hoạt động làm bằng chứng của tiến triển
  • Nhưng phần lớn những gì được gọi là tốc độ chỉ là sự nôn nóng được đổi tên
• Tốc độ thật sự chỉ khả thi khi công việc và ràng buộc đã rõ ràng, người phụ trách có năng lực thực thi theo những quyết định đã chốt gọn gàng và không lặp lại tranh luận
• Trong những tình huống thường được gọi là tốc độ, vẫn còn các yêu cầu mơ hồ, quyết định dang dở, phụ thuộc chưa được xem xét và bối cảnh thiếu hụt
  • Đó là cấu trúc kỳ vọng người phụ trách tiếp theo sẽ giải quyết vấn đề chưa được quyết định, rồi ngạc nhiên khi kết quả bị hỏng
  • Nó thất bại vì được xây dựng trên giả định rằng quá trình suy nghĩ là phần tốn kém nhất
• Mô thức này xuất hiện không chỉ trong phần mềm mà cả vận hành, quản lý, tuyển dụng, logistics, dịch vụ khách hàng và phát triển sản phẩm khi nhầm hoạt động với tiến triển
• Sau khi vội vàng ở giai đoạn cần phải hiểu, người ta tốn gấp mười lần thời gian để dọn dẹp hậu quả, trong khi ý nghĩa trên hồ sơ cũng bị đảo ngược
  • Công việc hấp tấp ban đầu trở thành “thực thi nhanh”
  • Việc dọn dẹp trở thành “việc không lường trước”, làm lại là “lặp lại”, hỗn loạn là “căn chỉnh”, thất bại vốn có thể tránh được là “học hỏi”
• Khi mọi quyết định nhỏ đều chọn tốc độ thay vì sự hiểu biết, hệ thống không ai tin, quy trình không ai hiểu, cuộc họp không ai muốn và dashboard không ai tin sẽ tích tụ
  • Các giải pháp đi đường vòng tạm thời cuối cùng trở thành cấu trúc thiết yếu chống đỡ doanh nghiệp
  • Những nỗ lực “hiện đại hóa” sau đó cũng dễ chỉ thay thế phần hỗn loạn nhìn thấy được, trong khi vẫn giữ nguyên sự sùng bái tốc độ

Cách hành động đúng mà không vội vàng

• Làm chậm lại không có nghĩa là làm việc chậm, mà là không bỏ qua quá trình làm cho công việc trở nên rõ ràng
  • Cần xác nhận thực sự đang muốn xây dựng gì và ai phụ thuộc vào nó
  • Cần xem nếu giả định sai thì điều gì sẽ hỏng, đã biết điều gì và đang giả vờ không biết điều gì
  • Cũng cần kiểm tra những điểm thất bại trong quá khứ và các điều kiện cần cho thành công
• Những câu hỏi cơ bản này loại bỏ sự thỏa mãn tức thì có được từ chuyển động, và không cho phép ẩn nấp sau cảm giác khẩn cấp hay PowerPoint
  • Vì phải thật sự hiểu công việc và chịu trách nhiệm với các quyết định chi tiết, chúng dễ trở thành thứ bị né tránh
• Tốc độ cho phép tiếp tục để quyết định mơ hồ và chuyển chi tiết thành tình trạng khẩn cấp của người khác
  • Khi tình trạng khẩn cấp xảy ra, tổ chức lại lấy việc sửa nhanh hơn, tuyển nhanh hơn, thay thế nhanh hơn, ra mắt nhanh hơn làm lời giải, khiến cùng một vấn đề lặp lại như thể đó là phương thuốc
• Tính cấp bách là phù hợp khi việc quan trọng có giới hạn thời gian thật sự, nhưng hấp tấp xuất hiện khi ta muốn tìm sự nhẹ nhõm cảm xúc từ hành động mà không phải gánh nặng của sự rõ ràng
• Phê phán tốc độ không có nghĩa là cố tình hành động chậm hay biến mọi quyết định thành cuộc họp
  • Cũng không cần dành 6 tháng tự xây hạ tầng triển khai chỉ để chứng minh mình sâu sắc
  • Quan điểm ở đây là hãy tôn trọng công việc đủ để làm đúng ngay từ đầu
• Trình tự đúng là hiểu → quyết định → xem xét đầy đủ → thực thi
  • Nếu đảo ngược trình tự, cái giá phải trả là hệ thống hỏng, đội ngũ kiệt sức và khách hàng âm thầm rời đi
  • Nó cũng để lại những vết thương vận hành buộc phải đi đường vòng trong nhiều năm vì không đủ kiên nhẫn để hiểu lại nguyên nhân
• Biến động thị trường, cạnh tranh, khách hàng khó tính, đội ngũ nhỏ, ngân sách eo hẹp và cơ hội đang khép lại có thể là các ràng buộc thật
  • Nhưng chúng cũng thường được dùng làm lý do để né tránh công việc chậm hơn và khó hơn: hiểu tình huống trước khi hành động
• Cách tốt hơn là giữ sự điềm tĩnh trong khi vẫn tiếp tục quyết định và ra mắt
  • Không nhầm hoảng loạn với nghiêm túc, mọi sự dừng lại với yếu đuối, hay chính chuyển động với tiến triển
  • Bỏ qua suy nghĩ, sự rõ ràng, bối cảnh và trách nhiệm có thể giúp nhanh hơn trong chốc lát, nhưng hệ thống và những người bảo trì sẽ tiếp tục gánh hậu quả
  • Một số việc chỉ có thể trở nên nhanh hơn sau khi ta ngừng vội vàng

[GN⁺]

Ý kiến trên Hacker News

• Làm chậm thì mới mượt, mượt thì mới nhanh
  Những gì học được về tốc độ là: con người có xu hướng không đo lường, hoặc đo sai những hạng mục trước mắt thấy tiện. Đo lường đúng sẽ được khách quan hóa bằng con số, nhưng cũng có người không thể đo lường cho đúng, giống như người khó tự phản tỉnh. Các con số phỏng đoán sai hơn 80% và dễ lệch vài bậc độ lớn. Những cải thiện nhỏ rút ra từ đo lường tích lũy lớn đến bất ngờ, và cách chắc chắn nhất để nhanh hơn là thay đổi kỹ năng và kỹ thuật. Tuyển dụng thì chậm, thêm người vào một dự án đã trễ sẽ làm nó chậm hơn, và càng cải thiện các tầng thấp hơn của tech stack thì càng có được cả tốc độ lẫn độ linh hoạt, rồi có thể tận dụng chúng để mở rộng quy mô

  • Các vận động viên chèo thuyền gọi trạng thái chuyển động không ma sát là swing. Giống như để cơ thể nương theo trọng lực và động lượng thay vì cố ép chiếc xích đu chuyển động, con thuyền vốn đã muốn đi nhanh, nên điều quan trọng là đừng vùng vẫy tuyệt vọng mà cản trở nó. Cố quá mức sẽ phá hỏng tốc độ; swing không phải là trạng thái đang gắng sức, mà là trạng thái đã đạt tới — Houghton Mifflin, Mind Over Water
  • Khó hiểu vì sao một số người không thể tự phản tỉnh, và liệu thật sự có người không thể tự phản tỉnh hay không
  • Nếu bạn là người đầu tiên đo lường đúng cách trong một codebase, kết quả sẽ không chỉ là vài cải thiện nhỏ. Thường thì các cơ hội cải thiện lớn và hiển nhiên có ở khắp nơi
  • Không thể đo lường mọi thứ, và bản thân việc chọn đo lường cái gì là một quyết định biên tập kéo theo thiên kiến

• Dù không sai về mặt kỹ thuật, nếu mất 6 tháng thay vì 6 tuần để tìm một giải pháp thực dụng cho vấn đề của khách hàng và làm khách hàng kiệt sức, dự án vẫn có thể thất bại. Từ góc nhìn khách hàng, tốc độ là một tính năng và là giá trị kinh tế
  Hãy nghĩ đến cảm giác gọi thợ đến sửa máy lạnh hỏng vào một buổi chiều tháng 8 ở Texas. Trong những lĩnh vực phức tạp và bất định, quy trình lặp nhanh là quan trọng; còn có quá nhanh hay không thì nên phán đoán qua phản ứng mà khách hàng thể hiện

  • Khách hàng phần mềm rất đa dạng: công ty đặt làm ứng dụng cho sự kiện, Walmart xây nền tảng thương mại điện tử, nhà phát triển dùng dịch vụ AWS, hay người dùng Windows·iOS thông thường. Khi khách hàng không kiểm soát chất lượng, độ tin cậy hay giải pháp, không có cách nào biết trước việc phát triển có quá nhanh hay không
    Sửa máy lạnh giống một bản vá khẩn cấp hơn; ví dụ tốt hơn là xây một căn nhà trong vài ngày để tránh cái nóng Texas, rồi sửa chữa suốt 6 năm lớp cách nhiệt, những bức tường chưa cố định, dây điện chạy bên ngoài và hệ thống ống nước đổ xuống dưới nhà
  • Bài viết cũng cho rằng tốc độ thật sự xuất hiện khi hiểu công việc và ràng buộc, và khi những người thành thạo đưa ra quyết định rõ ràng rồi thực thi mà không tranh luận lặp đi lặp lại. Sự hấp tấp cản trở lập kế hoạch và đồng thuận dễ làm tăng sai sót và chi phí, phá hỏng dự án, niềm tin và tinh thần; nếu lấy trạng thái hoảng loạn làm mặc định thì cũng thất bại trong việc tạo ra kết quả nhanh
  • Cũng phải nghĩ đến tình huống thợ kỹ thuật đến sáu lần trong một tuần, lần nào cũng nói đã sửa xong nhưng máy lạnh vẫn tiếp tục hỏng
  • Không rõ bài viết có ý nói nên phớt lờ bản thân tính khẩn cấp hay không, và cũng tò mò thực tế có bao nhiêu công ty hay cá nhân thật sự bỏ qua tính khẩn cấp
    Trong các sự cố nghiêm trọng với kinh doanh, người ta thường thử bừa đủ thứ bất kể cấp bậc, làm hỗn loạn tăng thêm; tổng thời gian và phạm vi ảnh hưởng lớn hơn so với khi hợp tác, hiểu vấn đề rồi giải quyết. Một cách tiếp cận bình tĩnh và bền bỉ, tạm dừng để lấy hơi và nắm toàn bộ vấn đề, bao gồm cả tính khẩn cấp, rốt cuộc lại nhanh hơn; điều này vẫn tương thích với việc thông báo tiến độ cho khách hàng và xoa dịu lo ngại của họ
  • Trước hết cần định nghĩa tiêu chuẩn của giải pháp thực dụng. Nhận định rằng 6 tuần là đủ cũng chủ quan như 6 tháng; nếu liên tục cập nhật một kết quả ban đầu trông có vẻ dùng được, thì phải xét xem khách hàng chịu được bao nhiêu lần, và vấn đề ở tuần thứ 7 nghiêm trọng đến mức nào. Sau khi đổi mô hình thác nước sang agile, chúng ta coi như đang sống trong một giải pháp thực dụng được cập nhật không ngừng

• Sự sùng bái tốc độ đến từ lịch trình của đầu tư mạo hiểm. Nhà đầu tư mạo hiểm có hạn chót phải trả lợi nhuận cho nhà góp vốn, nên muốn được chú ý thì phải khiến họ tin rằng công ty có thể tăng trưởng 10 lần trong lịch trình đó
  Nếu thật sự bị ràng buộc bởi lịch trình ấy, người ta dễ đặt ra các hạn chót tùy tiện bất chấp thực tế kỹ thuật, rồi trở thành kiểu người xóa sổ dự án chỉ vì không kịp hạn chót đó

  • Với nhà đầu tư mạo hiểm, hạn chót đó không tùy tiện mà do chi phí vốn quyết định. Tình hình thị trường và công nghệ không quan trọng; nếu lợi nhuận, doanh thu hoặc thị phần không tăng đủ nhanh, họ sẽ ghi nhận lỗ và thanh lý công ty
    Nếu mục tiêu của bạn không phù hợp với cấu trúc không tăng trưởng điên cuồng thì chết, đừng nhận đầu tư mạo hiểm. Muốn phát triển không vội vã thì nên chọn startup đã có product-market fit (PMF) được kiểm chứng và một đội ngũ bán hàng xuất sắc chịu trách nhiệm cho đường cong tăng trưởng
  • Các công ty nhận đầu tư mạo hiểm chỉ là một phần rất nhỏ trong tổng số công ty. Phương án thay thế là tài trợ bằng nợ lại có nhiều hạn chót và sự cấp bách hơn nhiều
  • Sự cấp bách ở các công ty tự lực tăng trưởng không có đầu tư mạo hiểm có thể còn lớn hơn. Nếu không trúng lớn sớm, áp lực giao hàng nhanh để tạo doanh thu và nhận mức lương tử tế là rất thực tế, mà cũng khó tuyển thêm người để chia việc
    Startup đã nhận đầu tư mạo hiểm có lớp đệm tiền mặt dồi dào và khả năng được hỗ trợ thêm, nên ngược lại còn đỡ vất vả hơn. Nhà đầu tư muốn lợi nhuận cao hơn thị trường chứng khoán, nhà sáng lập muốn tài sản lớn hơn so với khi làm ở FAANG, nên áp lực phần thưởng tương xứng với rủi ro phát sinh bất kể hình thức đầu tư
  • Các mốc hay lịch trình dự án tùy ý cũng hữu ích. Không nhất thiết phải dùng chúng làm tiêu chí xóa sổ dự án, nhưng chúng trở thành chuẩn để bộc lộ thành quả của nỗ lực khi so với thay đổi bên ngoài
  • Vì khiến người ta phớt lờ không chỉ thực tế kỹ thuật mà gần như mọi thứ đáng làm có giá trị, đầu tư mạo hiểm giống như ung thư của thế giới

• Một vị đại tá lục quân hoài nghi thường nói: “trong một đơn vị thời gian đủ ngắn, ngay cả chuyển động tuần hoàn cũng trông như tiến bộ”, và “làm chậm thì mới mượt, mượt thì mới nhanh”

  • Ở khúc cua gắt trên đường đua, ta cảm thấy chậm nên muốn đẩy nhanh hơn, nhưng trái lại cần giảm tốc hơn nữa để vào cua chính xác trong trạng thái mượt và có kiểm soát, nhờ đó tăng tốc sau cua tốt hơn. Đó là nguyên tắc vào chậm, thoát nhanh
    Ngay cả theo tính toán, tăng 1 dặm/giờ trên đoạn thẳng một phần tư dặm vẫn có lợi hơn tăng 1 dặm/giờ ở một khúc cua chậm dài 100 foot
  • Trong huấn luyện quân sự cơ bản, các huấn luyện viên lặp đi lặp lại câu đó không ngừng. Trong khóa đào tạo sĩ quan, khi bước vào một boong-ke bê tông nơi các viên hơi cay đang được đốt nóng, mắt đau rát dữ dội, nhưng trước cả khi kịp suy nghĩ có ý thức, tôi đã lấy mặt nạ phòng độc ra đeo và thực hiện chính xác cả quy trình với bộ lọc lẫn kem tẩy độc
    Việc có thể kìm lại thôi thúc tháo mặt nạ phòng độc và dụi mắt là nhờ huấn luyện chậm rãi, lặp đi lặp lại dẫn đến hành động nhanh đã được tự động hóa. Thay băng đạn và thao tác nút hỗ trợ đóng khóa nòng cũng theo cùng nguyên lý

• Từ góc nhìn kỹ thuật, làm chậm rãi thì mới trơn tru và nhanh hơn, nhưng từ góc nhìn kinh doanh, chậm đơn giản là chậm. Trong lúc hứa hẹn chất lượng cao hơn sau 6 tháng, nếu đối thủ giành mất một hợp đồng hiếm có kéo dài 5–10 năm, có thể không chỉ là tập trung vào việc khác, mà còn phải sa thải cả một đội không còn chỗ để bố trí.
  Điểm thất bại là vừa cho công ty thời gian để làm cho đúng, vừa đòi kết quả ngay từ đầu. Nếu dành 6 tháng hay 1 năm cho hạ tầng, design system, thư viện component, thiết kế hệ thống mà không có kết quả gì để trình bày, việc tính chi phí và theo dõi sẽ trở nên kỳ lạ, và lời hứa rằng việc phát triển sau này sẽ rất nhanh sẽ không thuyết phục được ban lãnh đạo.

  • Tính cấp bách có thể là thật, nhưng bỏ qua khâu lập kế hoạch không làm mọi thứ nhanh hơn. Nhiều khi chỉ cần vài giờ lập kế hoạch đã có thể tránh được nhiều tuần làm việc vô ích và làm lại.
  • Trong ngắn hạn, vội vã có vẻ là đúng, nhưng những góc bị cắt xén cuối cùng cũng sẽ đuổi kịp. Nếu từng trải qua việc đội sales yêu cầu nhét các tính năng đặc thù vào mà không có thời gian cân nhắc kiến trúc, hoặc yêu cầu phát hành trước khi kiểm thử xong để chốt hợp đồng lớn, bạn sẽ hiểu rõ. Bên kia có thể thắng một hợp đồng, nhưng hiếm khi thắng được cả cuộc chơi dài hạn.
    Cần phân biệt giữa làm chậm một cách kỹ lưỡng, có trách nhiệm và chậm vì kém năng lực. Áp lực thị trường là có thật, và những đội cứ chậm mãi sẽ biến mất. Đôi khi chậm dẫn đến trơn tru và nhanh, đôi khi chỉ đơn thuần là chậm; điều cốt lõi là biết được sự khác nhau giữa hai điều đó.

• Ở giai đoạn đầu sự nghiệp, tôi nhận ra rằng đôi khi ban lãnh đạo cho rằng nếu bạn không thể hiện stress ra bên ngoài thì bạn không xem vấn đề là nghiêm túc. Những câu như “không cảm thấy có sự khẩn trương” khi đó đã làm tôi dao động rất nhiều.

  • Quản trị thực sự là quyết định cách phân bổ nguồn lực hạn chế giữa các lựa chọn cạnh tranh. Nhưng nhiều quản lý và nhân viên lại xem quản trị là kiểm soát con người, và trên thực tế chỉ dừng ở vai trò giám sát viên, theo dõi xem người khác có làm việc chăm chỉ hơn hay không.
  • Tôi cũng từng nghe đúng câu đó, nhưng thay vì bị dao động, tôi kết luận rằng một người không phân biệt được vẻ bề ngoài và thực tế thì không nên làm CEO.
  • Quản lý bất an thường cũng thấy bất an khi người đối diện không tỏ ra bất an, nhưng cũng có nhiều quản lý không như vậy.

• “Đừng nhầm lẫn chuyển động với tiến bộ. Ghế bập bênh luôn chuyển động, nhưng không tiến về phía trước” — Alfred A. Montapert

• Không khó để đồng ý với bài viết, nhưng phần thảo luận hoàn toàn thiếu deadline. Yêu cầu về tốc độ không phải lúc nào cũng xuất hiện trong chân không; nếu vô lý thì nên phản đối, nhưng thực tế liệu ta có luôn có quyền lựa chọn hay không là điều đáng hỏi.

  • Bài viết có vẻ nhìn công việc hơi lý tưởng và thong thả. So với sa vào chủ nghĩa hoàn hảo, chờ phản hồi hoặc xây những thứ không cần thiết, việc di chuyển nhanh dù có làm hỏng một phần vẫn có lợi ích rõ ràng. Đây là bài học cơ bản của quản lý Agile; dù không tuyệt đối, nhìn chung tốc độ nhanh hơn mức khiến ta cảm thấy thoải mái thường có lợi.
  • Với tư cách người viết, tôi cho rằng deadline thường là ràng buộc nhân tạo. Cũng có những hạn chót không thể thay đổi như điều kiện phóng hay lịch sản xuất của nhà cung cấp, nhưng chúng thường bị dùng làm cái cớ để đánh lạc hướng khỏi mục tiêu thực sự và thúc ép vội vã, hoặc như một roi tâm lý.
    Nếu chỉ vội để kịp hạn, ban đầu có thể trông nhanh hơn, nhưng kết quả sẽ kém hơn mức tốt nhất mà đội có thể tạo ra, rồi sau đó lại tốn nhiều thời gian hơn để dọn dẹp mớ hỗn độn. Ý tôi không phải là áp dụng sự thong thả cho mọi tình huống, mà là trong một môi trường luôn di chuyển nhanh nhưng hầu như không đạt mục tiêu, hãy xem xét liệu chính sự vội vã có phải là nguyên nhân thất bại hay không.
    Sau khi FedEx triển khai dashboard mới cho nhân viên giao nhận, hệ thống đã bị treo trong quy trình tiếp nhận MacBook; nhân viên xử lý thủ công rồi đưa biên lai, nhưng nhãn in ra lại sai. Kết quả là laptop không đến được Apple, tôi phải giải thích tình hình lặp đi lặp lại với nhiều nhân viên trong nhiều tuần, và một tháng sau Apple phải gửi một laptop mới trị giá 5.000 đô la. Đây là ví dụ về một phần mềm bị làm vội vì một hạn chót tùy tiện đã lãng phí lượng lớn thời gian và chi phí; nói chậm lại không phải vì muốn thoải mái tâm lý, mà là để ngăn hỗn loạn ở hiện tại và tương lai.
  • Phần lớn deadline là những ràng buộc nhân tạo và tự tạo ra. Điều đó không có nghĩa là khi nửa căn nhà đang cháy thì ta lại đặt lịch họp và bàn trên Slack; có những việc thực sự khẩn cấp hơn. Bài viết không theo chủ nghĩa tuyệt đối, mà phê phán việc tôn thờ tốc độ và đòi hỏi kỷ luật phán đoán theo hoàn cảnh.

• Tốc độ vô hướng và vector vận tốc là khác nhau. Một người rơi từ tòa nhà 100 tầng có thể nghĩ mình đang bay với tốc độ khủng khiếp, nhưng vector vận tốc hướng tới mục tiêu chỉ xuất hiện khi suy xét rất nhiều phụ thuộc và điều hướng đúng cách.
  Ở các tập đoàn lớn, cả hai đều không quan trọng, và phần lớn sản phẩm đầu ra đều tệ. Deadline được lên kế hoạch theo kỳ đánh giá hiệu suất hằng năm, và những người được ban lãnh đạo ưu ái tạo ra câu chuyện thành công rằng họ đã đạt đúng chỉ số, hoặc thay đổi cột mốc để được thưởng. Bản thân ban lãnh đạo cũng được thưởng vì đã giám sát xuất sắc thành công đó.

• Càng có nhiều năm kinh nghiệm, nguyên tắc này càng trở nên rõ ràng. Nhưng sẽ thành vấn đề nếu một đồng nghiệp trẻ chưa nhận ra điều đó lại nằm ở tầng quản lý phía trên tôi.
  Tôi thường gợi mở suy ngẫm bằng những câu như: “Một số thành quả lớn nhất tôi từng tạo ra là những đoạn code mà tôi quyết định không viết.”