Không làm gì ở nơi làm việc
(seangoedecke.com)- Hiệu suất của kỹ sư phần mềm không được quyết định bởi việc bỏ ra nhiều thời gian hay viết nhiều code hơn, mà bởi những công việc tác động lớn vào đúng thời điểm; trong ngày thường, duy trì mức sử dụng 80% bằng cách dành khoảng 20% ngày làm việc rời xa máy tính là một cách hiệu quả
- Trong các tổ chức kỹ thuật lớn, những cơ hội phụ thuộc vào thời điểm như hỗ trợ chốt hợp đồng lớn, giảm thiểu sự cố, hay phát hành tính năng quan trọng có thể tạo ra giá trị rất lớn; nếu đã luôn bận rộn thì rất dễ bỏ lỡ những cơ hội này
- Nếu cứ liên tục xử lý các ticket ưu tiên thấp, bạn sẽ không thấy được tình hình ở các nhóm khác, cập nhật của nhóm, hay các sự cố đang diễn ra, và quản lý cũng khó đánh giá bạn là người đang có dư địa để tham gia
- Khoảng thời gian không làm gì giúp phục hồi sau căng thẳng, giữ bình tĩnh khi ứng phó sự cố, nảy ra ý tưởng mới, và tạo sự tập trung cho các công việc quan trọng
- Việc cố ý để lại dư địa trong ngày thường, rồi chỉ dốc 100% cường độ vào những giai đoạn có phần thưởng rất lớn, tạo điều kiện thuận lợi hơn để trở thành kỹ sư hiệu suất cao
Cơ hội tác động lớn
- Nhiều kỹ sư nên làm việc ít hơn, không phải theo nghĩa viết ít code hay tạo ít thay đổi hơn, mà là giảm thời gian thực sự làm việc trong ngày và làm chậm lại cả khi đang làm
- Ở trạng thái mặc định, hãy nhắm tới mức sử dụng 80%, và khi không có dự án áp lực cao thì dành 20% thời gian làm việc ở xa máy tính
- Hiệu quả ở công ty công nghệ bị chi phối mạnh bởi các sự kiện bất thường, và nhiều thay đổi tạo ảnh hưởng lớn nhất lại có thể đến từ lượng công việc ít đến ngạc nhiên
- Trong phát triển phần mềm, nỗ lực tự thân không được chấm điểm; điều quan trọng là giải đúng vấn đề vào đúng thời điểm
-
Ba ví dụ có thể xảy ra trong tổ chức lớn
- Khi công ty đang cố chốt một hợp đồng enterprise lớn, việc hỗ trợ tính năng hoặc sửa lỗi đúng lúc có thể giúp thương vụ thành công
- Tính năng đó không nhất thiết phải thật xuất sắc; đôi khi chỉ cần cho thấy ý chí và năng lực tạo ra thay đổi cụ thể là đủ
- Nếu ngăn chặn hoặc giảm nhẹ sự cố từ sớm, bạn có thể giảm tổn thất doanh thu tức thời trong lúc sự cố xảy ra, cũng như tổn thất doanh thu sau đó do khách hàng rời bỏ hoặc từ chối ký hợp đồng
- Chỉ cần biết cần tắt đúng feature flag nào cũng có thể tiết kiệm một khoản tiền rất lớn
- Khi công ty sắp phát hành một tính năng quan trọng, thành bại có thể phụ thuộc vào một thay đổi nhỏ nhưng khó tìm
- Ví dụ như nhanh chóng thêm một field mới vào cấu hình người dùng, hoặc sửa tính năng xuất dữ liệu enterprise cũ kỹ đã không ai đụng tới suốt nhiều năm
- Mức độ quen thuộc với hệ thống có thể tạo ra khác biệt giữa một thay đổi mất vài giờ và một thay đổi mất cả tuần
-
Phụ thuộc vào thời điểm
- Tất cả các cơ hội này đều phụ thuộc vào thời điểm; bạn không thể chỉ đăng nhập vào buổi sáng rồi tùy ý giải quyết một hợp đồng lớn, giảm nhẹ sự cố, hay nhanh chóng làm ra một tính năng chủ chốt
- Chỉ ở đúng chỗ, đúng lúc là chưa đủ; bạn còn phải ở trong trạng thái chưa quá bận
Giữ dư địa
- Nếu cứ liên tục xử lý công việc ưu tiên thấp và duy trì trạng thái sử dụng 100%, bạn sẽ bỏ lỡ cơ hội làm việc tác động lớn theo hai cách
- Thứ nhất, nếu quá bận thì bạn sẽ không nhận ra cơ hội đó ngay từ đầu
- Bạn sẽ có ít thời gian hơn để trò chuyện với những người đang làm việc khác, đọc cập nhật của nhóm, hoặc xem các sự cố đang diễn ra
- Cách tốt nhất để tham gia vào công việc tác động lớn là chủ động tình nguyện chuyên môn của mình
- Thứ hai, nếu lúc nào cũng trông bận rộn thì quản lý khó có thể kéo bạn vào
- Cách tham gia tốt thứ hai là để quản lý hoặc product manager kết nối bạn vào vì họ thấy “người này đang có dư địa để giúp”
- Quản lý và product manager thường tham dự những cuộc họp mà kỹ sư không tham gia, nên họ nhiều khi nắm rõ hơn công việc tác động lớn nào đang diễn ra
Không làm gì
- Nếu cần để trống thời gian cho công việc tác động lớn và không thể chỉ tiếp tục cày ticket, thì ở cấp độ từng phút, bạn thực sự có thể không làm gì cả
- Kỹ nghệ phần mềm có thể là một nghề nhiều căng thẳng, nhưng thường không phải là nghề căng thẳng liên tục
- Căng thẳng thường đến từ các sự cố thỉnh thoảng mới xảy ra, các việc khẩn cấp áp lực cao, hoặc những tình huống như đợt sa thải gần đây
- Nếu bạn tiếp cận cả những giai đoạn công việc tương đối ít áp lực bằng cường độ khẩn cấp, thì đến khi phải xử lý tình huống áp lực cao, bạn đã kiệt sức và dễ cáu gắt
- Ngay cả trong các giai đoạn công việc áp lực cao, thái độ không làm gì đôi lúc vẫn hữu ích
- Với những kỹ sư chưa quen on-call, tốt hơn là đừng vội; hãy hít thở vài nhịp trước khi vào cuộc gọi hoặc trước khi lên tiếng
- Trong ứng phó sự cố, nhìn chung cần “suy nghĩ bằng các chuyển động chậm”
- Phần lớn sự cố tự nó sẽ được giải quyết, và những thay đổi “biết đâu sẽ giúp” được đưa vào một cách vội vàng trong lúc sự cố diễn ra thường làm tình hình tệ hơn chứ không tốt hơn
- Nói chung, chỉ cần tránh hoảng loạn thôi là trong ứng phó sự cố bạn đã làm tốt hơn phần lớn kỹ sư khác
- Thời gian không làm gì là khoảng trống để công việc có thể xuất hiện
- Khi não có cơ hội nghỉ ngơi, khả năng nảy ra ý tưởng mới sẽ cao hơn
- Khi nhận được việc quan trọng, bạn có thể tập trung trọn vẹn thay vì đồng thời cố xử lý ba thứ khác đang chạy nền
- Khi không bận, bạn đơn giản có thời gian để nhìn mọi thứ và tiếp nhận dữ liệu mới
Cố ý không làm một số việc cụ thể
- Nhiều kỹ sư cảm thấy khó chịu khi nhìn thấy việc cần làm mà lại không làm
- Xu hướng này là một đặc điểm tâm lý mà nhiều kỹ sư phần mềm cùng chia sẻ, và ở một mức độ nào đó chính là yếu tố khiến họ hợp với nghề này
- Để tạo ra thời gian không làm gì, đôi khi bạn phải tự buộc mình không chen vào
-
Tránh glue work
- Kỹ sư nói chung nên tránh glue work
- Glue work là những việc như khiến mọi người nói chuyện với nhau, cập nhật tài liệu cho công việc mà mình không dẫn dắt, hoặc tìm nguồn lực để xử lý technical debt
- Phần lớn glue work phản ánh thực tế là tổ chức đã không đặt công việc đó làm ưu tiên một cách rõ ràng
- Nếu tổ chức thực sự ưu tiên nó, thì cá nhân không cần phải tự nguyện đứng ra
- Nếu việc tổ chức không ưu tiên vốn dĩ cũng không sao, thì nhận làm nó là lãng phí thời gian và còn có thể khiến quản lý khó chịu
- Kể cả nếu việc tổ chức không ưu tiên là một sai lầm lớn, thì khi cá nhân đứng ra xử lý thay, công ty sẽ không phải chịu hậu quả từ sai lầm của mình, còn sự nghiệp và sức khỏe tinh thần của cá nhân lại phải trả giá
- Đây là một thỏa thuận tệ cho chính bạn, là tấm gương xấu cho đồng nghiệp junior, và tạo ra tiền lệ xấu để sau burnout lại có người khác bước vào đúng vị trí đó
- Nếu hậu quả thực sự nghiêm trọng, hãy để nó xảy ra để tổ chức cảm nhận được nỗi đau và thay đổi chính sách
-
Giúp đỡ quá mức tạo ra sự dễ bị lợi dụng
- Việc quá muốn giúp đỡ khiến bạn dễ bị tổn thương trước những người muốn moi ra lao động không được đền bù
- Ở các công ty công nghệ có rất nhiều người muốn rút từ kỹ sư phần mềm những công việc không được tưởng thưởng
- Điều này khác với các công việc đi theo luồng bình thường và được đền đáp bằng thăng chức, bonus, hoặc lương thông thường
- Những công việc có vấn đề thường đi vào qua kênh không chính thức và đến từ người không có khả năng hoặc không có ý chí ghi nhận công việc đó chính thức dưới tên bạn
- Ví dụ như product manager ở tổ chức khác nhờ bạn trích xuất một số thống kê cụ thể vì bạn giỏi truy vấn dữ liệu
- Hoặc một kỹ sư ở nhóm khác xin pair làm việc, nhưng thực tế lại để bạn viết toàn bộ code rồi tự nộp thay đổi dưới tên họ
- Làm một phần những việc kiểu này thì không sao, và nếu có thể bạn vẫn có thể giúp người khác
- Nhưng bạn cần biết cách tạo áp lực ngược bằng cách từ chối hoặc trả lời chậm vài giờ hay vài ngày
-
Đừng đầu tư quá mức vào việc có khả năng biến mất
- Tốt hơn là đừng đầu tư quá nhiều vào những việc có khả năng sẽ biến mất
- Khi product designer đang thay đổi mong muốn theo thời gian thực, đừng viết lại toàn bộ trang mỗi giờ một lần
- Ví dụ như 9 giờ sáng họ muốn phần header theo một kiểu, 10 giờ sửa lại, rồi 11 giờ lại đổi tiếp
- Trong những trường hợp như vậy, tốt hơn là đi dạo hoặc không làm gì một lúc, rồi đến buổi chiều viết lại một lần dựa trên bản thiết kế mới nhất
- Một ví dụ phổ biến khác là ý tưởng lớn từ một quản lý thiếu lực đẩy về mặt chính trị
- Nhiều khi bạn chỉ cần để thời gian trôi qua cho đến khi dự án bị hủy
- Tuy vậy, nếu đánh giá sai mức độ hậu thuẫn chính trị của dự án, bạn có thể trông như một người lười biếng và rồi bị đẩy vào tình huống phải vội vàng làm ra kết quả
Kết luận
- Các lời khuyên và công cụ trong kỹ nghệ phần mềm thường tập trung vào việc mở rộng năng lực nỗ lực kỹ thuật: làm được nhiều việc hơn cùng lúc, nhận những dự án có phạm vi lớn hơn, và viết nhiều code hơn
- Thành công trong kỹ nghệ phần mềm không được quyết định bởi những yếu tố đó
- Thành công được quyết định bởi khả năng làm đúng việc vào đúng thời điểm, và để làm được như vậy bạn cần cố ý giữ lại một phần nỗ lực trong công việc hằng ngày
- Hoàn toàn có thể trở thành kỹ sư hiệu suất cao với mức nỗ lực 80%; thậm chí điều đó còn giúp giảm những sai lầm ngớ ngẩn do căng thẳng và khiến bạn dễ lao vào những công việc tác động lớn tạo ra lợi ích lớn
- Cũng sẽ có những thời điểm cần dốc 100% nỗ lực; khoảng hai hoặc ba lần mỗi năm, bạn có thể làm việc trong thời gian dài, tập trung cao độ, và nghĩ về vấn đề suốt cả ngày
- Hãy để kiểu làm việc đó dành cho những lúc phần thưởng thực sự lớn, còn trong phần thời gian còn lại thì nên làm việc một cách tương đối thong thả
1 bình luận
Ý kiến trên Hacker News
Bài viết hay, nhưng rốt cuộc lại lộ ra rằng vấn đề vẫn là incentive
Nói rằng ngăn chặn hoặc giảm nhẹ sự cố từ sớm có thể tiết kiệm rất nhiều tiền là đúng, nhưng điều tôi đã nhiều lần thấy ở nhiều công ty là việc phòng ngừa vấn đề không được ghi nhận, còn chất đầy mồi lửa rồi dập đám cháy tất yếu xảy ra thì lại được ghi nhận hai lần. Ngay cả ở những tổ chức “tốt” cũng vậy
Tôi chưa bao giờ có thể thực sự nhập cuộc vào thứ chính trị kiểu lý thuyết trò chơi, nơi người ta cố tình tung code rác ra thật nhanh rồi giành công về mình. Vì tôi quá tự hào về công việc của mình
Tôi đã duy trì và phát triển suốt hơn 5 năm một framework để loại bỏ cả một nhóm vấn đề từng hành hạ các phiên bản sản phẩm trước đây, nhưng đội đối tác thì triển khai code rác gây sự cố rồi sửa nó lại được khen công khai, còn đội chúng tôi chẳng được ghi công gì chỉ vì không có những sự cố như thế. Vì đó là phòng ngừa không thể đo lường
Thread.sleep(100000)khắp nơi rồi chờ đến lúc nó vỡ thôi. Thế là sau mỗi lần phát hành bạn trở thành người đã chữa cháy dài lâu và anh dũng đến tận nửa đêm thứ SáuĐừng hỏi vì sao điều đó lại được thưởng, và tất nhiên đôi khi tổ chức cũng đổi tiêu chí khen thưởng sang thứ khác
Một cách tiếp cận trung thực là tạo ra vài công cụ phức tạp nhưng thiết yếu khiến các kỹ sư khác cứ phải tìm đến mình. Bạn sẽ trở nên rất giỏi trong việc phát hiện cách người ta dùng sai một công cụ nào đó, và nếu bạn chỉ ra bug trong code của người khác chỉ trong vài giây thì trông bạn sẽ thông minh hơn thực tế rất nhiều
Lý tưởng nhất là công cụ phải đáng tin cậy, hữu ích nhưng cũng đủ phức tạp. Khi các lập trình viên khác dùng công cụ rồi gặp bug, họ sẽ tiếp tục tìm đến bạn, và bạn có thể chỉ ra lỗi của họ. Để chiến lược này hiệu quả thì lỗi gần như luôn phải nằm ở phía bên kia, và code của bạn phải vững chắc
Nếu phát hiện bug thật sự trong code của bạn, tốt nhất là một ca biên nhỏ, thì bạn phải rất khiêm tốn và xin lỗi, đồng thời khen nhà phát triển đã tìm ra bug phức tạp đó trong buổi họp nhóm
Cách này tốt hơn việc sửa chính code lỗi của mình để lấy công. Trò đó có thể qua mặt quản lý hoặc người junior, nhưng các kỹ sư senior khác sẽ ghét nó
Cách xây dựng công cụ phức tạp nhưng ổn định sẽ giúp bạn được ghi nhận lặp đi lặp lại, thường là nhiều hơn hai lần rất nhiều, và sự công nhận từ các lập trình viên khác cuối cùng cũng sẽ đến tai quản lý. Những lãnh đạo thông minh biết rằng đây là tín hiệu tốt hơn các màn demo hào nhoáng
Những lãnh đạo đi phát lời khen chỉ vì một lập trình viên nào đó làm prototype nhanh thì sớm muộn cũng sẽ học được bài học. Các nhà sáng lập trẻ dường như thường trải qua giai đoạn khen ngợi những thứ bề nổi này
Một phần của việc làm ra sản phẩm hay một nhóm tính năng gần với khám phá hơn là kỹ thuật xuất sắc. Đôi khi thay vì làm ra một tính năng thật chắc chắn, tốt hơn là làm hai tính năng đủ ổn để tìm ra thứ gì thực sự mang lại giá trị cho người dùng
Tôi vốn luôn thuộc phe “cứ làm rồi sẽ biết”. Dù vậy tôi vẫn biết ơn vì có ai đó khác với mình đã tạo ra git
Ở đây cần có sự cân bằng, và điều đó phụ thuộc vào việc bài toán hiện tại mang tính khám phá đến mức nào. Ở đây “độ chắc chắn” nghĩa là những thứ như khả dụng, khả năng bảo trì theo góc nhìn kỹ thuật thuần túy, hay khả năng làm lộ ảnh nhạy cảm của người dùng
Phần nói về “những người muốn vắt kiệt các công việc không được tưởng thưởng” thì đáng để đóng khung treo lên tường
Đặc biệt là những tình huống như quản lý sản phẩm từ tổ chức khác hỏi “Anh/chị giỏi truy vấn dữ liệu, có thể lấy giúp tôi ít thống kê về X không?” hoặc kỹ sư đội khác xin “pair” nhưng cuối cùng tôi lại viết hết code còn họ lặng lẽ gửi thay đổi dưới tên mình
Chiến lược của anh ấy là giúp đỡ mọi người và chủ động nhường công cho họ. Trong các buổi 1:1 hay họp có nhiều cấp quản lý, anh ấy liên tục nhấn mạnh giá trị công việc của đồng đội, nhờ đó được cả nhóm quý mến
Vài năm sau, khi một dự án trị giá rất lớn bị trễ tiến độ và nhiều kỹ sư chủ chốt nghỉ việc, anh ấy làm đêm để đưa dự án tới thành công và ở kỳ đánh giá tiếp theo đã được tăng chức danh lẫn lương
Dự án đó đúng là cú hích cuối cùng, nhưng anh ấy không phải kỹ sư duy nhất làm đêm. Anh ấy xem việc mình được thăng tiến là nhờ thiện cảm tích lũy bằng cách nhường công cho người khác trong suốt thời gian làm việc
Dù có nằm trong mô tả công việc hay không, tôi vẫn muốn làm cùng những người thấy vấn đề và đề xuất giải pháp
Nếu công việc của tôi không được ghi nhận thì đó là vấn đề của lãnh đạo. Cách thẳng tay từ chối việc cảm giác như con đường dẫn tới một văn hóa tổ chức cứng nhắc và chậm chạp
Tương tự, một ngày nào đó chính tôi cũng có thể cần gì đó từ đồng nghiệp, và khi đó nếu họ chủ động giúp thay vì đuổi tôi đi với câu “hãy đi theo kênh chính thức”, tôi sẽ rất biết ơn. Kênh chính thức có thể mất nhiều thời gian hơn rất nhiều
Những cuộc trò chuyện lúc ăn trưa cũng có thể là cách giúp người khác hiểu ra điều gì đó
Tuy vậy, bỏ ra vài giờ làm giúp việc cho ai đó lại có thể là một câu chuyện khác hẳn
Không phải để mỉa mai mà gần với quan sát hơn, nhưng trong những tổ chức đủ lớn hoặc quan liêu, ngay cả khi ngăn chặn sự cố từ trước thì cũng khó nhận được công lao hay sự ghi nhận. Những thành quả đó bị xếp vào dạng “vốn dĩ phải làm”.
Vì thế, những người giỏi chính trị công sở thà để sự cố xảy ra rồi chọn cách khuấy động thật lớn ở phần hành động khắc phục sau đó. Mấu chốt là không để sự cố phình thành thảm họa, và đó là một công việc khá tinh vi
Nếu cứu được một hợp đồng bán hàng thì đội sales sẽ nhận tràng pháo tay, và hoa hồng cũng về tay họ. Tôi không nhận được dù chỉ một phần trong đó
Nếu để vài thứ cháy rụi, sếp của sếp của sếp sẽ nhìn thấy đám cháy đó, và có thể mọi thứ sẽ được cải thiện. Có khi đó còn là cách dễ nhất để giao tiếp với họ
Trước đây tôi từng viết dở nửa chừng một bài theo hướng này, dùng phép so sánh với RPG giả tưởng. Khi chơi nhân vật dùng mana trong những game như vậy, bạn nhanh chóng học được rằng nếu tiêu sạch mana trong mọi trận đánh lặt vặt rồi cứ lang thang với bình rỗng, thì đến lúc thực sự cần sẽ chẳng còn gì.
Năng lượng tinh thần dùng cho công việc cũng không khác nhiều. Nếu để dành lại một ít trong bình, khi chuyện bất ngờ xảy ra bạn có thể dùng nó một cách chiến lược mà không đẩy sức khỏe, tức burnout, vào tình thế nguy hiểm.
Nếu từng lập đội với một người chơi không biết quản lý mana trong những game như thế, bạn cũng sẽ biết người đó không phải là đồng đội quá tốt
Trong bất kỳ lĩnh vực nào, thời điểm năng lực của tôi đạt đỉnh là khi phía trước có đủ việc để tôi đều đặn xử lý như một cỗ máy, và tôi được tin tưởng đủ để làm việc hướng tới mục tiêu mà không bị ngắt quãng vì phải dừng lại giải thích liên tục. Kỹ năng tăng lên như cháy rừng và công việc kết thúc nhanh hơn dự kiến.
Đáng tiếc là nơi làm việc biết tận dụng cấu trúc như vậy cực kỳ hiếm. Có quá nhiều rào cản và gián đoạn khiến bạn không thể bước vào deep work thực sự
Nếu muốn làm sụp hệ thống, chỉ cần vận hành nó ở mức 100% là được. Không còn khoảng đệm và cũng không có năng lực hấp thụ nhu cầu mới, nên chỉ cần một xáo trộn nhỏ trong hệ thống là nó sẽ chuyển sang chế độ thất bại thường trực
Vấn đề của những bài viết như thế này hay các cuốn sách như Peopleware / Slack là chúng không đưa ra được chỉ số thực tế đủ sức thuyết phục để bộ phận kế toán thử một cách tiếp cận khác
Phép so sánh đã thay đổi góc nhìn của tôi là một câu trong “The Power of Full Engagement”. Đại ý là: “Bạn đang hành xử như một vận động viên sức bền đẳng cấp thế giới không hề có mùa nghỉ. Hãy dừng lại.”
Có rất nhiều sự khôn ngoan ở đây. Ngoài việc để dành một phần năng lực cho những việc thực sự có giá trị lớn khi chúng xuất hiện, tôi còn cho rằng kỹ nghệ phần mềm không phải là loại công việc có thể làm tốt chỉ bằng cách luôn luôn bận rộn.
Nếu cố viết code nhanh nhất có thể thì hiếm khi ra được thiết kế tốt. Bài này cũng không đề cập tới một khía cạnh quan trọng khác, đó là làm thế nào để làm việc ở 80% công suất mà không bị quản lý mắng.
Việc này cần một chút cẩn trọng trong giao tiếp và ước lượng công việc. Một trong những lời khuyên hay mà tôi nghe từ các lập trình viên kỳ cựu lớn tuổi ở công việc lập trình thực thụ đầu tiên của mình vẫn còn theo tôi đến giờ: sau khi ước lượng một việc sẽ mất bao lâu, hãy nhân đôi nó trước khi nói với quản lý hay người dùng.
Khi tích lũy kinh nghiệm, hệ số đó có thể giảm từ 2 lần xuống khoảng 1,5 lần, nhưng nguyên tắc vẫn vậy
Điều cần tối ưu hóa và biến thành tiền lệ là khả năng giao hàng đều đặn trong dài hạn, với tốc độ bền vững. Đây là một cuộc chơi dài, và cam kết quá mức chỉ bào mòn niềm tin. Chính niềm tin đó mới là công cụ lớn nhất để lập trình viên có được không gian mình cần.
Hãy hứa ít hơn, xây dựng niềm tin rằng bạn sẽ làm được điều mình đã nói, và giành lấy không gian để không bị burnout.
Càng lên senior, đặc biệt là khi thành lead, việc đặt ranh giới, bảo toàn sự tập trung và ngăn burnout trở thành một phần công việc. Vì có quá nhiều cách để tự hủy hoại bản thân
Ngay cả khi đã tính đến định luật Hofstadter, mọi việc vẫn luôn mất nhiều thời gian hơn dự kiến.
https://en.wikipedia.org/wiki/Hofstadter%27s_law
Với góc nhìn của người đã làm nhiều công việc tiếp xúc khách hàng, cái bẫy tệ nhất mà tôi nhiều lần gặp phải là trở nên thân thiết với khách hàng trả tiền. Ở vị thế được thuê như một chuyên gia để hỗ trợ, khi khách hàng thực sự là người tử tế thì việc từ chối trở nên khó đến điên lên.
Tệ hơn nữa là khi người đó không phải người ra quyết định, mà là người đang bị ép phải thúc đẩy một thứ gì đó lên tôi. Với tư cách một chuyên gia được tin tưởng, tôi có thể dễ dàng nói không khi chính khách hàng đưa ra ý tưởng tồi, nhưng nếu mệnh lệnh đến từ sếp của họ — người tôi chưa từng trực tiếp làm việc cùng — thì tôi bị đặt vào vị thế hoặc trông như một khoản chi phí vô dụng, hoặc trở thành một yes-man để lại phía sau một con quái vật.
Đôi khi tôi thấy ghen tị với những người chủ yếu làm công việc nội bộ. Ít nhất họ còn có cơ hội thuyết phục được ai đó ở cấp trên nào đó
Phần về công việc keo dán khá thú vị; khi làm ở một tập đoàn lớn, đây là một phần được nêu rõ trong đánh giá hiệu suất hằng năm. Google gọi nó là “citizenship”, và tôi thấy đó là cách gọi nắm rất đúng bản chất. Tức là: “bạn đã làm gì để mọi thứ tốt hơn cho những người còn lại trong công ty”
Mặt này thì có hơi kỳ. Nó không nằm trong bản mô tả công việc của tôi nên về mặt kỹ thuật là việc không được trả công, nhưng đồng thời lại là một phần trong kỳ vọng chính thức. Mặt khác, được làm việc ở nơi mọi người đều bỏ ra một ít thời gian và công sức để cải thiện môi trường cho tất cả mọi người cũng là điều tốt
Nếu biến nó thành yêu cầu rõ ràng với tất cả mọi người, thì đó cũng là cách né tránh một văn hóa độc hại kiểu “tôi là kỹ sư ngôi sao nên bận làm việc quan trọng, còn công việc keo dán thì để người khác làm”. Mà cái “người khác” đó thường là phụ nữ, và gần như chắc chắn được trả ít hơn vị kỹ sư ngôi sao kia
Bài gốc hàm ý rằng công ty nên tuyển chính thức người để làm công việc keo dán, nhưng trên thực tế nó gồm quá nhiều mảnh việc khác nhau nên gần như không thể tuyển một người rồi giao hết. Ví dụ, chức danh nào có thể bao trùm cả “viết tài liệu, phỏng vấn kỹ sư phần mềm, tổ chức sự kiện offsite của nhóm”
Nhưng tất cả những việc đó đều cần thiết, và yêu cầu về citizenship giúp chia gánh nặng công bằng hơn
Tôi nghĩ cách nói tốt hơn không phải là “đừng làm công việc keo dán”, mà là “đừng trở thành kẻ duy nhất làm công việc keo dán mà không được đền đáp”. Tức là mọi người đều nên gánh một phần, và cần thúc đẩy một văn hóa nơi điều đó được công nhận chính thức là công việc
Vận hành ở mức sử dụng 80% là một thói quen tốt, và nó hữu ích khi không có kiểu quản lý giám sát vi mô đòi bạn phải đạt 100% suốt cả ngày, mỗi ngày. Những người như vậy hay hiểu nhầm việc kỹ sư phần mềm ngồi yên, thoải mái suy nghĩ là sự lười biếng không làm gì cả
Vì vậy, làm việc từ xa là cách tốt nhất để chừa lại một phần công suất dự phòng và bảo vệ sức khỏe tinh thần
Một chút công việc keo dán có thể làm cho đời sống công việc của mọi người tốt hơn rất nhiều, và nếu không ai khác biết cách làm điều đó, nó có thể biến tôi thành nhân sự không thể thiếu hoặc thành anh hùng trong nhóm
Xét đến cách tôi chật vật với việc học, suy nghĩ và bắt đầu làm, thì mức 80% của tôi về mặt kỹ thuật hoàn toàn không giống mức 80% của một đồng nghiệp giỏi kỹ thuật hơn
Chỉ cần tính thêm một chút xu hướng đa dạng thần kinh, thì mức 80 của người này có thể là 120 của người khác