Ý nghĩa thực sự của việc "xong việc (Done)" ở các công ty Big Tech

• Ở Big Tech, thực sự hoàn thành công việc có nghĩa là đưa nó đến trạng thái mà công ty hài lòng rồi rời đi, trong một hệ thống có thể được cải thiện vô hạn
• Một kỹ sư giỏi nhưng thiếu tính chủ động sẽ chỉ lặp đi lặp lại các cải tiến nhỏ nhặt và bỏ lỡ thành quả thực sự
• Bạn phải tạo ra kết quả rõ ràng, dễ thấy cho người ra quyết định thì mới được công nhận là "đã làm việc"
• Hãy luôn kiểm tra xem công việc mình làm có ở dạng mà cấp quản lý cao hơn có thể đọc và đánh giá hay không
• Không thể sắp xếp mọi thứ đến mức hoàn hảo; đến một thời điểm nào đó, khả năng "tuyên bố chiến thắng rồi rời đi" trở thành năng lực cốt lõi

---

'Công việc' có bản chất không thể hoàn tất trọn vẹn

• Không giống bài toán hay bài tập, công việc trong thế giới thực là một hệ thống mở có thể được cải thiện vô hạn
• Phát triển dịch vụ giống như trồng cây: về sau vẫn là một quá trình cần được chăm sóc liên tục

Cái bẫy của người kỹ sư giỏi

• Một kỹ sư tự mình gánh vác mọi thứ và chỉ lặp lại các cải tiến nhỏ, liên tục có thể cảm thấy mình đang tạo ra thành tích, nhưng
• Từ góc nhìn của quản lý cấp cao, điều đó có thể bị xem là không tạo ra "giá trị hữu hình cho công ty"
• Kết quả là họ có thể bị hiểu lầm như một người bận rộn nhưng không có thành quả

Ý nghĩa thực tế của việc ‘hoàn thành’

• Đưa công việc đến điểm mà công ty (người ra quyết định) hài lòng, rồi chuyển sang việc tiếp theo
• Thay vì tiếp tục refactor hoặc lặp lại các cải tiến nhỏ, cần tạo ra một danh sách thành quả rõ ràng
• Sự quyết đoán để tuyên bố “đã xong” và chuyển sang việc tiếp theo là điều quan trọng

Đảm bảo ‘tính dễ đọc’ của công việc

• Những dự án mà quản lý đã biết hoặc đã yêu cầu, hay việc xử lý các sự cố lớn, đều có tính dễ đọc cao
• Về cơ bản, phần lớn công việc kỹ thuật đối với quản lý chỉ là nhiễu kỹ thuật khó đánh giá
• Vì vậy, cần điều chỉnh để công việc được nhìn thấy và đọc hiểu, chẳng hạn biến thành quả thành thứ hữu hình hoặc nhấn mạnh tác động tài chính

‘Hoàn thành’ là một khái niệm mang tính xã hội

• Về mặt triết học, khái niệm 'đã xong' cũng là một cấu trúc xã hội, nhưng trong thực tế nó có sức mạnh rất thực dụng
• Nếu phớt lờ điều này, bạn có thể không được ghi nhận, và cuối cùng thậm chí có thể bị sa thải

Tóm tắt

• Làm việc không có nghĩa là đã hoàn thành
• Phần lớn công việc không thể kết thúc dứt điểm và có thể tiếp diễn mãi
• Đừng là người làm vườn; hãy trở thành một chiến lược gia lấy thành quả làm trung tâm
• Tiêu chuẩn của "đã xong" là sự hài lòng của công ty/quản lý
• "Tuyên bố chiến thắng → rời đi → sang việc tiếp theo" là chiến lược cốt lõi

[aer0700]

Có lẽ việc chọn những đầu việc đủ để có thể tuyên bố chiến thắng cũng là một kỹ năng quan trọng.

[elbanic]

Việc giới hạn phạm vi được gọi là scoping. Khả năng chính là biết scoping tốt để có thể giành chiến thắng.

[bakyeono]

Hanshin vs Soha

[doolayer]

Thành quả hữu hình có thể đo lường bằng số liệu, chứ không phải tiểu tiết

[GN⁺]

Ý kiến trên Hacker News

• Tôi không hoàn toàn phản đối lập luận của bài này, nhưng với kinh nghiệm từng làm ở big tech, nhiều startup và cả các công ty kỳ lân, tôi thấy đây không phải lời khuyên quá thực tế. Trong 10 năm qua, công việc của developer đã bị chuyên môn hóa quá mức, đến mức tách rời khỏi nhu cầu của người ra quyết định và khách hàng. Hiện tượng này xảy ra vì Product Manager chen vào giữa engineer và phần còn lại của công ty. Tôi luôn muốn tạo ra kết quả có giá trị, nhưng để thực sự làm được vậy thì phải chấp nhận căng thẳng liên tục. Đóng góp của tôi nhất định sẽ bị điều chỉnh qua cái tôi của người nói chuyện với bên ra quyết định. Trong 5 năm qua, lần duy nhất tôi thật sự cảm thấy thành tựu là khi tạm thời đảm nhiệm vai trò Product Manager trong 9 tháng. Trong giai đoạn đó, đội của chúng tôi đã hoàn thành thành công ba dự án mà trước đó các đội khác đã thất bại nhiều lần. Bí quyết là nói chuyện trực tiếp với các bên liên quan để hiểu nhu cầu, chứ không phải cố làm theo cách của riêng tôi. Vì vậy, từ nay tôi sẽ chỉ cung cấp đúng những gì được yêu cầu, bị trách vì bug, và không được ghi nhận vì tính năng. Ít nhất thì lương cũng ổn. Tôi vẫn đang tiếp tục tìm nơi mà mình có thể thực sự đóng góp đúng nghĩa

  • Phần “ít nhất thì lương cũng ổn” này đặc biệt đọng lại trong tôi. Tôi có quan điểm riêng rằng trạng thái “giậm chân tại chỗ” ở big tech cũng không tệ đến vậy. Ví dụ, nếu làm ở Google hay MS với mức lương 300 nghìn USD và chỉ phụ trách cùng một dự án nhàm chán suốt 10 năm, thì kinh nghiệm đó vẫn được công nhận ở bất cứ đâu. Một người đầy tham vọng như tôi ngày trước có thể sẽ bất mãn với điều đó, nhưng kiểu người như vậy rồi cũng sẽ tìm cách chuyển sang công ty nhỏ hơn. Càng lớn tuổi, mối quan tâm của tôi càng chuyển từ công ty sang gia đình và bạn bè. Nếu ai đó nói với tôi rằng sẽ không có thăng chức, tôi sẽ đáp “thì sao?”. Tôi kiếm đủ tiền cho gia đình và vẫn giữ được cân bằng công việc - cuộc sống. Thành thật mà nói, điều tốt nhất ở công ty là tiền lương và việc nó giúp phần còn lại của cuộc sống tốt hơn
  • Tôi đã trải nghiệm việc vai trò Product Manager trong thực tế khác hẳn với cách nó được mô tả một cách lý tưởng, thường là bị kẹt ở giữa và không đại diện tốt cho bên nào cả. Kết quả là tôi tự trau dồi năng lực quản lý sản phẩm, và kỹ năng đó thực sự hữu ích để tránh làm việc vô ích. Vì vậy tôi bắt đầu tự hỏi liệu với một engineer giỏi, product management có nên là kỹ năng bắt buộc hay không
  • Một điều nữa cần nghĩ tới là nếu cứ tiếp tục như hiện tại thì bạn đang đi trên con đường dẫn tới burnout
  • Tôi nhận ra rằng giao tiếp là bộ kỹ năng quan trọng nhất trong bất kỳ tổ chức nào. Chỉ với 9 tháng làm tạm thời thì chưa đủ để hiểu hết giá trị của nó. Bản thân bài viết nghe giống như tác giả, cũng như nhiều engineer khác, đang ở trong trạng thái quá bực bội và nghĩ rằng mình thông minh hơn những người khác trong tổ chức. Thực tế thường không phải vậy, và kiểu tư duy này ảnh hưởng xấu đến hợp tác
  • Đằng sau bất kỳ ứng dụng web vận hành tốt nào cũng luôn có một người làm vườn
  • Tôi tò mò vì sao bạn không tiếp tục làm Product Manager
  • Tùy công ty mà khác nhau một trời một vực. Có rất nhiều nơi mà ảnh hưởng của engineer lớn hơn. Ngay cả trong big tech cũng có những trường hợp không hề tách rời khỏi khách hàng
  • Ý là nên sa thải các Product Manager à?
  • Tôi cũng từng làm vai trò Product Manager, tức là hòa giải giữa engineer và công ty, và đúng là đóng góp của tôi cũng bị lọc qua cái tôi của chính mình, nhưng nghe như bạn thấy việc đó khá thỏa mãn… chắc hẳn là một công việc khá dễ chịu

• Tôi phản đối về mặt nền tảng việc chỉ lấy chuyện làm hài lòng người có quyền lực làm thước đo thành công. Chúng ta đúng là đang bị trói trong những cấu trúc địa vị lố bịch, nhưng tôi không cho rằng việc chuyển ticket trong Jira sang “done” hay loại bỏ warning của compiler là tất cả. Không ai nói rằng “tôi không hối tiếc vì suốt 40 năm chỉ làm hài lòng sếp”

  • Tôi đã đi làm 30 trong số 40 năm, và việc làm hài lòng sếp cùng sếp của sếp rõ ràng cũng có giá trị của nó. Dù góc nhìn hoài nghi không phải là toàn bộ cuộc sống, nhưng biết đến góc nhìn hoài nghi này cũng có nghĩa là tiến gần hơn tới sự thật
  • Thực ra tôi nghĩ “làm hài lòng sếp và sếp của sếp” chính là định nghĩa của việc làm công ăn lương. Bạn làm điều người khác bảo và nhận tiền

• Nhìn chung tôi đồng ý, nhưng xin bổ sung một điều: để hiểu điều manager muốn, bạn phải nắm được cấu trúc kinh doanh của công ty. Bạn nhất định phải tự hiểu công ty kiếm tiền như thế nào và coi điều gì là có giá trị. Khi làm ở nơi phù hợp với giá trị của công ty, phần thưởng cũng cao hơn và cảm giác thỏa mãn cũng lớn hơn. Điều quan trọng là gặp trực tiếp khách hàng, sales, marketing, và nếu có thể thì cả ban điều hành. Dù chỉ phụ trách hệ thống nội bộ, điều cốt yếu là phải biết hệ thống đó tạo ra hay bảo vệ giá trị ở đâu. Nếu bộ phận của bạn không tạo ra giá trị rõ ràng, hãy cân nhắc chuyển sang một đội có giá trị hơn. Làm những việc lệch khỏi nhu cầu của công ty luôn là sai lầm lớn

  • Tôi nghĩ cũng không sao nếu xem mình như một người thợ mộc. Phát triển phần mềm là triển khai theo spec, nhưng nếu spec đó vô lý hoặc bất khả thi thì phải trực tiếp chỉ ra vấn đề. Nếu phía business không thể giải thích rõ việc của họ, nghĩa là chính họ cũng không hiểu. Hơn nữa, nếu developer còn bắt buộc phải hiểu cả business, thì nhất định phải có bù đắp tương xứng cho điều đó. Thời gian dùng cho việc ấy cũng có chi phí cơ hội, vì lẽ ra có thể phát triển kỹ năng kỹ thuật hơn nữa
  • Nhiều trường hợp giả định rằng “manager sẽ thực sự hiểu và quan tâm đến business” tự nó đã không đứng vững

• Tác giả nói rằng “cần tạo ra kết quả mà người có quyền ra quyết định nhìn thấy được”, và tôi đồng cảm với tư duy “business” của người này. Nhiều developer chật vật vì không biết diễn giải công việc của mình theo hướng mang lại lợi ích kinh doanh như thế nào. Refactoring cũng vậy. Việc cải thiện code trong ngắn hạn có thể trông hoàn toàn vô nghĩa, nhưng tùy bối cảnh mà có thể tạo ra lợi ích rất lớn cho tổ chức. Rốt cuộc, cốt lõi là phải nghĩ cách gắn công việc của mình với doanh thu hoặc tiết kiệm chi phí của tổ chức, và tìm cách truyền đạt điều đó

  • Developer phải học ngôn ngữ của business và đóng khung vấn đề theo cách mà người làm business có thể hiểu và quan tâm. Nhìn vào hầu hết các quyết định kinh doanh thì cuối cùng vẫn là chi phí so với lợi ích. Thực tế, nhiều doanh nhân còn xem phần mềm đơn thuần là chi phí. Tức là, trái với suy nghĩ hiển nhiên của developer kiểu “phần mềm chẳng phải là trung tâm của việc tạo doanh thu sao?”, business thực ra không quan tâm đến bản thân phần mềm. Nếu có thể bán nó miễn phí thì mọi chi phí bằng 0 và biên lợi nhuận là vô hạn — đó là suy nghĩ thật sự của giới kinh doanh. Sales là lĩnh vực mà thương vụ được chốt bằng bầu không khí, quan hệ, thậm chí cả hối lộ, hơn là lý trí. Nghe có vẻ phi lý, nhưng nhất định phải hiểu điều này

• Tôi tự hỏi liệu “kiểu tư duy trên có phải lý do nhiều engineer không quan tâm đến chất lượng code, test, tài liệu v.v. hay không?”. Nếu chỉ quan tâm đến việc làm cấp trên hài lòng ngay lập tức, thì ai sẽ cố viết code có thể bảo trì lâu dài? Có thể không cần chất lượng vượt chuẩn, nhưng chỉ cần đầu tư tối thiểu thôi cũng có thể tiết kiệm được hàng tỷ

  • Ngày càng nhiều người không còn quan tâm đến tinh thần nghề nghiệp và chất lượng. Bây giờ người ta nghe thấy những câu như “tôi chỉ làm đúng bằng mức lương tôi nhận”. Trước đây từng có cảm giác rằng dù lương thế nào thì công việc vẫn phải làm cho tử tế, nhưng dường như điều đó đã phai nhạt đi nhiều
  • Ai cũng có lý do để đảm nhận vai trò của mình. Giống như trên phim trường, engineer cũng có thể có mục tiêu khác nhau. Nếu ngăn engineer nuôi dưỡng đam mê, cuối cùng chỉ còn lại những người làm việc vì tiền. Rủi ro rất lớn
  • Tôi không nghĩ có ai cố tình viết code tệ. Khi sự thờ ơ hay burnout xuất hiện trong môi trường mà nỗ lực bổ sung liên tục không được ghi nhận, sẽ chẳng ai muốn cố thêm nữa. Và cũng có nhiều developer đơn giản là năng lực yếu. Đây không phải nghề siêu cạnh tranh như actuary, nên ai từ nền tảng nào cũng có thể bước vào, mà bản thân việc trở nên giỏi vốn cũng không dễ
  • Nhiều Product Manager chỉ muốn tốc độ thật nhanh. Chúng tôi muốn test và tài liệu, nhưng các CFO coi những việc phụ đó là “không phải tính năng nên không cần”, và xem chúng là thừa thãi
  • Engineer không giả định mình sẽ gắn bó lâu với công ty, nên cũng không nghĩ tới việc phải chịu trách nhiệm cho tương lai. Khi nhảy việc liên tục, họ không bao giờ tự mình trải qua những vấn đề do đoạn code mình viết ở công ty cũ gây ra, nên không có trải nghiệm thất bại để học và cứ lặp lại. Tôi đã ở cùng một công ty gần 20 năm và luôn chứng kiến những sai lầm lặp đi lặp lại. Tôi cũng chán ngấy những thay đổi chỉ sửa phần bề mặt mà để nguyên vấn đề cốt lõi. Nếu không sửa được vấn đề thật sự, thay đổi chẳng có ý nghĩa gì. Mục tiêu của tôi là giải quyết vấn đề thật sự

• Tôi đã nhiều lần trải qua thực tế và vấn đề này, tôi hiểu nhưng vẫn phản đối. Nhiều dự án được khởi động, rồi đội bị giải tán cùng với câu “xong rồi, done!”. Nhưng sản phẩm vẫn còn vấn đề, vẫn cần thêm tính năng, và công ty thì tiếp tục thay đổi. Kết quả là technical debt chỉ chồng chất vì quản lý kém. Một manager mới đến, xây lại dự án cũ và lặp lại đúng sai lầm trước đây. Cách này rất kém hiệu quả. Nếu ví như điều hòa, thì giữ nhiệt độ ổn định sẽ hiệu quả hơn là cứ tắt đi rồi lại hạ xuống. Thực tế, công cụ quản trị mà tôi tạo ra không được ban lãnh đạo quan tâm, nhưng lại cần thiết đến mức có hơn 500 người dùng nội bộ. Điều quan trọng là tiếp tục duy trì độ tin cậy mà không cần đầu tư quá nhiều thời gian bảo trì. Nếu bị bỏ mặc, nó sẽ phân mảnh và độ tin cậy của công cụ cũng biến mất. Chỉ cần bỏ ra vài phút thôi cũng có thể giữ được tính nhất quán

  • Ví dụ điều hòa thực ra sai về mặt nhiệt động lực học. Tắt đi rồi làm lạnh lại mới hiệu quả hơn

• Tôi có cảm xúc lẫn lộn theo nhiều hướng. Rõ ràng với visibility và thăng tiến thì bài này nói đúng, nhưng thực chất đây là lời khuyên lấy manager làm trung tâm, kiểu chỉ cần làm hài lòng quản lý. Nhưng nếu không có định hướng rõ ràng và ưu tiên cứ liên tục thay đổi thì sao? Khi đó rất khó tạo ra kết quả có ý nghĩa, và mối quan hệ manager - cấp dưới sẽ hoàn toàn biến thành cấu trúc “yes-man”. Kết quả đó chẳng hay ho gì

  • Câu trả lời đơn giản thôi. Nếu cảm thấy mình đang làm dưới một ông sếp ngốc, thì cứ nghỉ việc. Khổ là tạm thời, nhưng rồi mọi thứ sẽ tốt hơn. Còn hơn lãng phí thời gian giải thích công việc của mình cho kẻ ngu
  • Ngược lại, nếu làm việc với một manager thật sự tốt, thì chỉ riêng việc “làm hài lòng quản lý” cũng có thể giúp cả sự nghiệp lẫn kết quả công việc phát triển nhanh chóng

• "unagentic engineer" có nghĩa là engineer thiếu tính chủ động. Nếu engineer làm việc theo kiểu đó, nó có thể dẫn đến sự kém hiệu quả và các vấn đề nghiêm trọng như chi phí cloud quá mức, sự cố bảo mật, khách hàng bất mãn v.v. Ví dụ về những công việc không bao giờ thực sự kết thúc gồm vá bảo mật, sửa lỗi sai, tối ưu chi phí, và phản hồi feedback của khách hàng. Nếu công ty không hiểu giá trị này thì cách tốt nhất là chuyển việc

  • Đó chính là ý chính của bài viết. Có tổ chức lấy thực tế làm trung tâm và có nơi lấy địa vị làm trung tâm. Tổ chức thực tế thì hợp lý hơn trong dài hạn, còn tổ chức địa vị thì mục tiêu duy nhất là làm hài lòng sếp. Thứ bậc quan trọng hơn chất lượng sản phẩm hay quan hệ khách hàng. Những tổ chức như vậy không nhất thiết phải sụp đổ, nhưng đôi khi rồi cũng có thể sụp rất nhanh
  • “Unagentic” nghĩa là một nhân viên không có agency. Người ta mong họ thể hiện tính chủ động, nhưng trên thực tế lại có cái bẫy khiến sự hiện diện của developer trở nên vô hình
  • Không nhất thiết lúc nào cũng phải như vậy, nhưng nếu ban điều hành không quan tâm thì mặc định văn hóa kiểu này sẽ hình thành. Ví dụ, tôi thích tập trung vào những chi tiết tinh tế của thiết kế giao diện. Nhưng chỉ khi sự chăm chút đó được tổ chức công nhận là có giá trị thì nó mới được đền đáp. Ở nhiều nơi người ta chẳng buồn để ý
  • “unagentic engineer” là kiểu người thiếu khả năng tự ra quyết định và tự dẫn dắt công việc, chỉ đơn giản là để mình trôi theo dòng
  • Chỉ một engineer không có nhiều quyền phán đoán, tức là thiếu tính tự chủ
  • Nghĩa là không phải kiểu “high agency”, tức dù trông thông minh và có năng lực nhưng luôn chờ được chỉ đạo và không thể tự mình chủ động

• Tôi cực kỳ ghét những buzzword như "alignment". Nhưng dù vậy thì đây vẫn là một khái niệm quan trọng về bản chất. Ở trạng thái lý tưởng, tôi, manager của tôi, và cả ban điều hành phía trên nữa phải thống nhất với nhau về việc đâu là điều quan trọng nhất. Nếu không làm được vậy thì đó là vấn đề đối với tư cách thành viên của tổ chức mà tôi thuộc về. Dù chuyện đó có đúng hay công bằng hay không, chúng ta vẫn phải sống theo nó. Cuối cùng, làm theo chỉ đạo từ trên xuống là lý do chúng ta được trả tiền. Chỉ có số rất ít người có đặc quyền gây ảnh hưởng ngược lên phía trên. Đó chính là cái gọi là "managing up"

• Bài gốc hữu ích, nhưng có vẻ bỏ sót những điểm cốt lõi còn quan trọng hơn:

  • Làm ở đúng đội quan trọng hơn làm đúng việc
  • PM và manager tốt quan trọng hơn công việc tốt
  • Hệ thống báo cáo tốt quan trọng hơn giá trị của kết quả
  • Những công việc khớp với mục tiêu của lãnh đạo được đánh giá cao hơn rất nhiều so với việc hỗ trợ vận hành business thực tế
  • Luôn phải sẵn sàng tự mình làm mọi thứ, và chính trị ở doanh nghiệp lớn lúc nào cũng đi kèm động lực làm giảm hợp tác

[heal9179]

Những ý kiến bên này lại chạm đúng vào cốt lõi hơn.

[roxie]

Đúng vậy mà haha