- Bài viết đưa ra các chiến lược thực tế để kỹ sư tham gia hiệu quả vào chính trị tổ chức trong công ty công nghệ, đồng thời bàn về cách vượt qua cảm giác bất lực về mặt chính trị mà nhiều kỹ sư thường có
- Kỹ sư không phải là người chơi trong trò chơi chính trị mà là một công cụ, nhưng vẫn có thể tạo ảnh hưởng chính trị bằng cách chủ động hỗ trợ sự thành công của các dự án cấp cao hoặc đề xuất các ý tưởng kỹ thuật phù hợp với sự thay đổi ưu tiên của tổ chức
- Mối quan tâm của tổ chức thay đổi như những con sóng, vì vậy chiến lược cốt lõi là chuẩn bị trước nhiều chương trình kỹ thuật theo các hướng khác nhau như độ ổn định, trải nghiệm lập trình viên, cải thiện hiệu năng và đề xuất chúng vào đúng thời điểm
- Khi nhu cầu chính trị va chạm với việc thiếu các ý tưởng tốt, những quyết định kỹ thuật tệ nhất sẽ được đưa ra; các kỹ sư cấp cao có trách nhiệm đưa ra đúng ý tưởng vào đúng lúc
- Theo góc nhìn bi quan, đây là việc trở thành công cụ cho đấu đá quyền lực; còn theo góc nhìn lạc quan, đó là cách đạt được mục tiêu kỹ thuật của bản thân trong khi vẫn tôn trọng việc ban lãnh đạo thiết lập ưu tiên
Niềm tin phổ biến về sự bất lực chính trị của kỹ sư
- Nhiều kỹ sư phần mềm có thái độ định mệnh đối với chính trị công ty và tin rằng tham gia là vô nghĩa
- Các quyết định kỹ thuật thường được đưa ra vì những lý do hoàn toàn vị kỷ, nên kỹ sư thiện chí không thể tạo ảnh hưởng
- Những bên liên quan đầy quyền lực quá kém năng lực và rối loạn chức năng, khiến việc hiểu nhu cầu của họ và đưa ra giải pháp gần như bất khả thi
- Trò chơi chính trị phụ thuộc vào thông tin không công khai mà kỹ sư không có, nên cố tham gia chỉ dẫn đến lúng túng
- Quản lý và lãnh đạo dành phần lớn thời gian cho chính trị, trong khi kỹ sư dành cho kỹ thuật, nên kỹ sư ở thế bất lợi nghiêm trọng ngay từ đầu
- Đúng là kỹ sư phần mềm không thể chơi cuộc chơi ở cùng cấp độ với những người vận hành chính trị thực thụ
- Việc kỹ sư bắt đầu bày mưu tính kế kiểu Game of Thrones là một sai lầm khủng khiếp, và những mưu kế như vậy sẽ nhanh chóng bị phát hiện rồi bị lợi dụng ngược lại
- Để mưu tính, cần có luyện tập và quyền lực, mà kỹ sư phần mềm thì không có cả hai
Cách thực tế để tham gia chính trị
- Trong các công ty lớn, một thực tế đơn giản là kỹ sư phần mềm không phải người chơi mà là công cụ trong trò chơi chính trị, nhưng vẫn có nhiều cách tham gia mà không cần mưu mẹo
- Cách dễ nhất là chủ động làm việc để giúp một dự án nổi bật thành công
- Điều này gần như không khác mấy so với những gì nên làm trong công việc thông thường
- Nếu công ty đang đầu tư mạnh vào một dự án mới (ngày nay nhiều khả năng là dự án AI), thì dùng năng lực kỹ thuật để giúp nó thành công là một nước đi có lợi về chính trị cho VP hoặc lãnh đạo điều hành dự án đó
- Đổi lại, bạn sẽ nhận được phần thưởng mà lãnh đạo trong công ty công nghệ có thể trao, như bonus, hỗ trợ thăng chức, hoặc vị trí trong các dự án nổi bật tiếp theo
Tận dụng ý tưởng kỹ thuật cho các chiến dịch chính trị
- Một cách khó hơn nhưng đem lại nhiều quyền kiểm soát hơn là biến những ý tưởng mình ưu tiên thành thứ có thể phục vụ cho các chiến dịch chính trị đang tồn tại
- Giả sử bạn muốn tách một tính năng hiện có thành một dịch vụ riêng, sẽ có hai cách
- Cách khó: tiêu hao vốn chính trị của bản thân để tập hợp ủng hộ, làm cho quản lý thấy nó quan trọng, rồi từ từ thuyết phục những người hoài nghi để dự án được phê duyệt
- Cách dễ: để lãnh đạo dùng vốn chính trị của họ (lớn hơn nhiều) cho dự án
- Chờ đến khi có chỉ đạo trên toàn công ty về một mục tiêu phù hợp với dự án (ví dụ: sau một sự cố lớn thì nhấn mạnh vào độ ổn định)
- Sau đó đề xuất với quản lý rằng dự án của bạn có thể phù hợp với mục tiêu đó
- Nếu bạn đánh giá đúng, tổ chức sẽ ủng hộ dự án và thay vì tiêu hao vốn chính trị, bạn còn gia tăng được nó
Cưỡi trên những làn sóng ưu tiên của tổ chức
- Sự quan tâm của tổ chức đến theo từng làn sóng
- Khi bước vào giai đoạn ưu tiên độ ổn định, các VP rất sốt ruột muốn làm gì đó, muốn tìm một dự án ổn định nghe hợp lý để trình lên cấp trên, nhưng bản thân họ không đủ khả năng tự làm
- Họ thường sẵn sàng tài trợ cho bất cứ điều gì mà đội kỹ thuật đề xuất
- Ngược lại, khi sự chú ý của tổ chức dồn sang việc khác (ví dụ: ra mắt sản phẩm mới quy mô lớn), họ sẽ không muốn kỹ sư dành thời gian cho các đợt refactor nội bộ tập trung vào độ ổn định mà khách hàng không nhìn thấy
- Để hoàn thành công việc kỹ thuật trong công ty công nghệ, bạn phải chờ đúng con sóng phù hợp
- Chuẩn bị sẵn các chương trình kỹ thuật theo nhiều hướng khác nhau là một ý tưởng hay
- Kỹ sư giỏi thường tự động nhận ra các cơ hội như vậy trong quá trình làm việc bình thường
- Ví dụ về các kế hoạch:
- Di chuyển code tính cước từ chỗ gọi API có cache sang dữ liệu được cập nhật bằng webhook
- Loại bỏ pipeline build tự chế cũ và thay bằng Vite
- Viết lại một dịch vụ Python lộn xộn có lưu lượng cao bằng Golang
- Thay frontend CMS chậm dùng cho tài liệu công khai bằng một static site nhanh
Tầm quan trọng của việc đề xuất đúng thời điểm
- Khi lãnh đạo lo ngại về tính cước, bạn có thể đề xuất đợt refactor tính cước như một cải thiện về độ ổn định
- Khi họ lo ngại về trải nghiệm lập trình viên, bạn có thể đề xuất thay pipeline build
- Khi khách hàng phàn nàn về hiệu năng, bạn có thể đưa việc viết lại bằng Golang như một lựa chọn tốt
- Khi CEO kiểm tra tình trạng tài liệu công khai và hoảng hốt, bạn có thể lập luận cho việc xây lại bằng static site
- Điều quan trọng là phải luôn chuẩn bị sẵn một chương trình công việc chi tiết, hiệu quả và có thể triển khai ngay cho bất kỳ thứ gì đang là mốt trong tháng đó
Khoảnh khắc những quyết định kỹ thuật tệ nhất xuất hiện
- Dù không làm theo cách này thì một số chương trình vẫn sẽ được cấp vốn, nhưng nếu không làm vậy bạn sẽ không thể kiểm soát chương trình nào được chọn
- Đây chính là nơi công ty đưa ra những quyết định kỹ thuật tệ nhất: khi nhu cầu chính trị phải làm gì đó va chạm với việc không có ý tưởng tốt
- Khi không có ý tưởng tốt, ngay cả ý tưởng tồi cũng sẽ được dùng, nhưng không ai thực sự muốn kết quả đó
- Tệ cho lãnh đạo: họ phải bán một kết quả kỹ thuật đáng thất vọng như thể đó là thành công
- Tệ cho kỹ sư: họ phải tốn thời gian và công sức để xây thứ dựa trên một ý tưởng sai lầm
- Nếu bạn là kỹ sư rất cấp cao, các VP sẽ âm thầm trách bạn vì điều đó, và họ có lý
- Chuẩn bị đúng ý tưởng vào đúng thời điểm là trách nhiệm của bạn
Hai góc nhìn
- Góc nhìn bi quan: có thể đọc đây như lời khuyên rằng hãy trở thành công cụ tiện dụng cho những kẻ điều hành công ty trong các cuộc đấu đá quyền lực nội bộ bất tận
- Góc nhìn lạc quan: có thể đọc đây như lời khuyên rằng hãy để lãnh đạo thiết lập các ưu tiên tổng thể của công ty (vì đó là công việc của họ), rồi điều chỉnh kế hoạch kỹ thuật của bạn cho phù hợp
- Dù theo cách nào, nếu thúc đẩy đúng kế hoạch vào đúng lúc, bạn sẽ hoàn thành được nhiều mục tiêu kỹ thuật hơn
Phản ứng trên Hacker News và trích dẫn liên quan
- Bài viết này đã thu hút sự chú ý trên Hacker News và nhận phản ứng tích cực hơn hẳn so với các bài khác về chính trị
- Một bình luận nhắc đến câu nói của Milton Friedman và áp dụng ý tưởng của bài viết này vào chính sách chính trị nói chung
- "Chỉ có khủng hoảng (dù là thực hay được nhận thức) mới tạo ra thay đổi thực sự. Khi khủng hoảng đó xảy ra, các hành động được thực hiện sẽ phụ thuộc vào những ý tưởng sẵn có xung quanh. Đó là chức năng cơ bản của chúng ta: phát triển các phương án thay thế cho chính sách hiện tại, và giữ chúng tồn tại, sẵn sàng sử dụng cho đến khi điều vốn bất khả thi về mặt chính trị trở thành điều không thể tránh khỏi về mặt chính trị"
- Một số bình luận chỉ trích cách tiếp cận này là quá mang tính trò chơi và ích kỷ, nhưng tác giả cho rằng điều đó phụ thuộc vào mục tiêu
- Một bình luận tóm tắt rất hay ý chính của bài: "Thay vì chờ chỉ đạo, tỏ ra hoài nghi với các ý tưởng tồi khi có khoảng trống, và không làm điều mình muốn, tác giả duy trì một backlog các ý tưởng tốt và quan trọng để nêu ra khi người quan trọng nói rằng điều gì đó là ưu tiên. Chấp nhận thỏa hiệp về thời điểm để hoàn thành điều mình muốn"
1 bình luận
Ý kiến trên Hacker News
Ý chính của bài viết này là như sau
Điểm đầu tiên nghe có vẻ hiển nhiên, nhưng đây là điều tôi đã phải coaching nhiều lần cho không ít người ở giai đoạn đầu sự nghiệp Nhiều người từng gặp khó khăn hoặc đang đi dần tới PIP đã có bước ngoặt chỉ nhờ thực hiện tốt vòng lặp dưới đây
Tôi hiểu ý số 2 là chuẩn bị sẵn agenda của riêng mình. Ví dụ, nếu muốn làm cho codebase tối giản hơn, thì hãy chuẩn bị sẵn PoC và các chi tiết liên quan để có thể đề xuất ngay khi cơ hội đến Nhờ đã chuẩn bị, khi site gặp vấn đề về tốc độ, SEO hoặc lỗi phát sinh, ta cũng có thể đưa ý tưởng tối giản đó ra như một giải pháp Khái niệm này khá thú vị, nhưng tôi vẫn suy nghĩ nhiều về cách áp dụng nó trong thực tế. Tôi cũng thường băn khoăn có nên viết sẵn các tài liệu chuẩn bị cho tương lai hay không. Kiểu như vận hành blog vậy: liên tục ghi chép công việc của mình và chờ cơ hội tới Nhiều phần việc bổ sung có thể sẽ trở thành công cốc, nhưng thật ra tôi nghĩ mình vốn đã làm khá nhiều việc như vậy rồi
Tôi muốn thêm một điểm nữa là đừng tùy tiện làm điều gì mà những người có quyền lực chính trị lớn hơn quản lý của bạn phản đối. Trừ khi có người quyền lực hơn họ công khai chỉ đạo làm vậy Không phải là phải cố làm điều họ muốn, mà là cần cẩn thận để không vô cớ làm họ khó chịu Gần như chẳng đáng để tạo kẻ thù, và phần lớn quản lý khi vào khủng hoảng cũng có thể biến bạn thành vật tế thần để tự bảo vệ mình
Tôi thích chủ động đề xuất với quản lý về “việc nên làm”. Đưa những vấn đề quan trọng lên bàn và trình bày vì sao chúng đáng quan tâm Cần chủ động để quản lý được hưởng lợi từ chuyên môn của mình Tôi cũng chưa có quá nhiều kinh nghiệm kiểu này, nhưng đã có vài lần thành công
Lời khuyên kiểu này càng lên cấp cao càng quan trọng. Điều đó cũng đúng với engineering manager, và ngay cả khi tôi là director báo cáo trực tiếp cho CTO, tôi cũng cố áp dụng nguyên tắc này
Một trong những câu trích dẫn tôi thích là: "Chỉ khủng hoảng thực sự, hoặc khủng hoảng được nhận thức là có thật, mới tạo ra thay đổi thực sự. Hành động khi đó sẽ được quyết định bởi những ý tưởng đang lơ lửng xung quanh. Chức năng cơ bản của chúng ta là phát triển các chính sách thay thế, giữ cho chúng sống tiếp, và biến điều tưởng như bất khả thi về mặt chính trị thành điều không thể tránh khỏi về mặt chính trị" - Milton Friedman Với tôi, cách viết 1 Pager và tài liệu kỹ thuật rồi chia sẻ trước, sau đó trích lại khi khủng hoảng xảy ra, đã rất hiệu quả trong việc đẩy ý tưởng của mình lên Tôi từng dần dần thúc đẩy hướng kiến trúc mà mình mong muốn, từng bước tiến gần hơn tới mục tiêu, và việc xây dựng đồng thuận là rất quan trọng Tất nhiên cũng có nhiều lần tôi bị các VP hoặc director giỏi chính trị hơn lấn át Nhưng việc chuẩn bị sẵn một thư viện 1 Pager, chia sẻ khéo léo để chúng luôn “lơ lửng trong không khí”, rồi chờ tới khi có động lực để thực thi, đã hiệu quả hơn nhiều
Tôi đồng cảm với đoạn “thua trong cuộc chiến chính trị”. Một điều đáng ngạc nhiên mà tôi nhận ra khi lên tới cấp quản lý trung gian trở lên là việc nhân viên cấp dưới chơi trò chính trị nhìn rõ mồn một Nhiều IC hoặc EM cấp 1 thường đánh giá quá cao bản năng chính trị hay social IQ của mình Hơn nữa, độ sâu và độ rộng của giao tiếp trong tổ chức là khác nhau, nên ngay cả khi ai đó nghĩ mình đang đi thuyết phục một người, thì stakeholder đó sau cuộc nói chuyện vẫn có thể tiện thể kể lại bối cảnh cho quản lý của họ Chúng tôi trong đội ngũ quản lý đã nhiều lần chứng kiến cảnh này khi âm thầm cố kiểm soát những màn chơi chính trị vụng về
Tôi tò mò cụ thể “để 1 Pager và tài liệu kỹ thuật lơ lửng ngoài kia” là làm như thế nào
Tôi đồng tình với câu trích dẫn đó và thấy phương pháp này có vẻ hiệu quả. Chỉ là ngoài đời, thang thời gian dài đến phát điên nên rất dễ nản Hơn nữa, nhiều khi khủng hoảng còn bị phớt lờ hoàn toàn, nên rốt cuộc nó không được nhìn nhận như khủng hoảng hoặc bị bình thường hóa luôn
Tôi tò mò liệu nhờ các 1 Pager đó mà bạn được ghi nhận và thăng tiến trong sự nghiệp, hay chúng chỉ giúp biến ý tưởng thành hiện thực
Đây là cách mà tôi cho là tốt nhất
triển khai lên production thường xuyên (tập trung vào delivery thực tế hơn là công việc mang tính lý thuyết)
đạt được các kết quả có ý nghĩa (wins) theo các metric đã thống nhất
có một “người bán hàng” trong phía management hoặc PM biết quảng bá thành công của tôi Nhưng vấn đề vẫn xảy ra. Lúc nào cũng có VP hoặc lãnh đạo mới muốn chứng tỏ sự đổi mới. Đội duy trì hệ thống hiện tại sẽ bị đóng khung là sai, còn VP mới thì nhấn mạnh định hướng của mình bằng những ý tưởng tiến bộ như AI. Mã của tôi vừa deploy xong là bị xem như "legacy" Khi đó VP cứ thoải mái hứa hẹn về tương lai hào nhoáng, còn vai trò của tôi là duy trì thực tại nên không bao giờ cạnh tranh nổi. Hiện thực thì chẳng sexy cũng chẳng thú vị. Và cứ thế tôi trở thành phe cũ Cuối cùng bản chất vẫn là quan hệ đỡ đầu: giúp VP ở trên thành công, rồi khi người đó chuyển việc thì tạo vị thế để mình đi theo cùng
Tôi nghĩ điều này quá đúng. Đi sâu thêm một bước, với staff engineer thì điều quan trọng là phải thể hiện rõ rằng “tôi không phải là bản thân đoạn code đó”. Code ngay từ lúc được deploy đã là nợ / legacy rồi Tốt nhất là định vị bản thân không phải như một "người bảo vệ code", mà như một EQUAL PARTNER với lãnh đạo, sản phẩm, người ra quyết định, v.v. Đây đơn giản là vấn đề về góc nhìn / frame. Cùng một hành động như nhau, nhưng nếu tôi được nhìn như “đối tác trong công việc” thì lãnh đạo sẽ xem tôi là người hỗ trợ chủ động; còn nếu không thì tôi bị quy đổi thành một vật cản phải miễn cưỡng thuyết phục, và khác biệt là rất lớn
Tôi rất đồng cảm với ý “cần có người bên PM biết bán thành quả của tôi”. Nhìn lại thì có lẽ điều tạo ra thay đổi lớn nhất trong sự nghiệp của tôi là tốc độ rời khỏi một PM tệ PM giỏi sẽ cải thiện mọi thứ nhưng rất khó tìm. Ngược lại, nếu PM định hướng sai thì mọi thứ đều hỏng, và ngay khi PM đó biến mất thì không khí cũng đổi khác hẳn
Tôi rất thích cụm “không thể cạnh tranh với những lời hứa hẹn về tương lai”. Chuyện đó xảy ra quá thường xuyên. Thậm chí kể cả khi lời hứa đó 26 lần trước chưa từng được thực hiện, thì “tương lai huy hoàng” vẫn luôn trông rất vĩ đại
Khi làm thực tế thì khái niệm triển khai lên production thường xuyên (rep = thiên về thực thi, cấm lý thuyết) là tốt, nhưng tôi vẫn thắc mắc tại sao những lời hứa mơ hồ về tương lai từ VP lại được coi trọng hơn tính khả thi thực tế
Tôi chưa từng nghe cụm “công việc lý thuyết”, nhưng rõ ràng có những nơi deploy hằng ngày. Tuy vậy, tôi không nghĩ deploy thường xuyên luôn là lý tưởng. Tôi nghi ngờ việc có thể ship thứ gì thật sự đáng kể chỉ trong một ngày. Các dự án như của tôi, vốn tạo thêm doanh thu cho công ty, không thể hoàn thành trong một ngày. Nếu công việc có thể xong trong một ngày thì chẳng khác nào chỉ cần kỹ sư bốn lần mỗi năm. Vì thế kiểu “deploy thường xuyên” này đôi khi lại là một vanity metric
Tôi chưa từng làm ở một công ty dysfunctional nào cả, nên hoàn toàn không đồng cảm với phần đầu của bài này Theo kinh nghiệm của tôi, giao tiếp top-down lúc nào cũng rất mạnh, và kể cả khi tôi phát triển theo một hướng mình không đồng ý, thì trước đó vẫn có đủ thảo luận để tôi thấy thú vị ở chỗ vì sao đồng nghiệp thông minh lại nhìn khác mình Tôi không rõ là vì chỉ làm ở các công ty do kỹ sư sáng lập hay đơn giản là do mình may mắn
Các VP cấp cao trong tập đoàn lớn có mục tiêu rất rộng và khái niệm về phương tiện thực hiện cũng rộng hơn. Điều đó không hẳn là xấu. Có cơ hội thử nhiều phương án trước khi bị khóa chặt vào một công nghệ hay phương pháp cụ thể. Tất nhiên cũng có lãng phí, nhưng nó cũng hiệu quả trong việc phản ứng ngay với những biến động địa chấn của ngành để hoàn thành sứ mệnh mà ban điều hành đặt ra
Tôi tò mò không biết bạn từng làm ở công ty quy mô nào
"Một con đường khó hơn một chút nhưng cho phép tôi có nhiều quyền kiểm soát hơn là gắn ý tưởng của mình vào một chiến dịch chính trị đã tồn tại" Tôi đã học được kỹ năng bám vào các dự án do VP dẫn dắt. Hơi chua chát nhưng hiệu quả thì rất rõ
Trong nhóm này, lời than phiền thường gặp là kiểu “tôi đã refactor toàn bộ code một cách hoàn hảo mà chẳng ai ghi nhận” Tôi từng nghe một người quen cũ khoe rằng họ đã dọn dẹp hoàn hảo data pipeline suốt nhiều tháng nhưng không ai nhận ra giá trị của việc đó, và chuyện này khiến tôi nghĩ nhiều Là kỹ sư, tôi hiểu những việc như vậy là có giá trị, nhưng nhìn từ góc PM/EM thì nó cũng giống như việc một PM dành cả tháng chấm lại rồi sắp xếp toàn bộ tài liệu kỹ thuật nội bộ, và phản ứng nhận được sẽ là “thế việc đó tác động gì tới công ty?” Với PM, như vậy sẽ trở nên mơ hồ khi phải phân biệt giữa một kỹ sư có ảnh hưởng và một kỹ sư chỉ làm “việc định dạng đơn thuần” Cuối cùng, điều quan trọng là phải giải thích rõ trước về việc mình định làm, theo một định dạng mà khán giả không chuyên kỹ thuật có thể hiểu Trước đây tôi từng thúc đẩy unit test và integration test, nhưng vì thiếu ý chí chính trị nên lần nào cũng không thể đưa nó vào ưu tiên. Chỉ đến khi một SEV lớn thực sự xảy ra, tôi mới nói rằng "muốn ngăn chuyện kiểu này thì cần có test", và lúc đó mọi người mới đồng ý về giá trị của nó. Giờ thì ai cũng hiểu vì sao test là cần thiết
Tôi hoàn toàn đồng ý. Nếu tôi đang cố ưu tiên một hành động nào đó, thì tôi phải diễn giải nó theo logic và ngôn ngữ của người ra quyết định ưu tiên thì lời nói của tôi mới có tác dụng Ví dụ, PM thường suy nghĩ theo đơn vị tiền tệ. Nếu mục tiêu kỹ thuật của tôi như mở rộng test coverage cần 200 dev hour mỗi năm nhưng có thể tiết kiệm 400 dev hour mỗi năm, giảm 15% ticket hỗ trợ, hoặc mở ra các kịch bản kinh doanh trong tương lai, thì việc thuyết phục sẽ dễ hơn nhiều Một mẹo tôi thích là đóng gói công việc tech debt không phải như "công việc kỹ thuật", mà như một tác động kinh doanh rõ ràng, để PM tự đưa nó vào roadmap Cách này càng dễ hơn khi sự nghiệp tiến lên. Lúc đầu người ta có thể hoài nghi, nhưng theo thời gian, uy tín về ước tính và kết quả của tôi được tích lũy, và những việc trước đây cần vài cuộc họp thì giờ chỉ cần một cuộc nói chuyện 10 phút là xong
Tôi cũng đồng ý với ý kiến này. Nhưng tôi cũng cảm thấy có thể nghĩ theo chiều ngược lại Ví dụ, ở công trường xây dựng, nếu ai đó kiểm tra và duy trì kỹ hệ thống an toàn để phòng tai nạn, management nhiều khi vẫn không hề công nhận hay thưởng cho giá trị đó Việc chỉ công nhận lợi ích nào có thể biểu diễn định lượng dưới dạng ROI tự nó đã là một thất bại lớn của management, và khi an toàn gắn trực tiếp với mạng sống thì đó còn là một thất bại về đạo đức Thực tế thì đây chính là điều đang diễn ra ở Boeing lúc này
Điểm cốt lõi là diễn giải theo giá trị mà người nghe có thể hiểu. Cuối cùng đây là kỹ năng bán hàng, nhưng phần lớn developer không có kinh nghiệm và cũng khó nhận ra điều đó. Sẽ là lý tưởng nếu có một quản lý giỏi hỗ trợ tốt, và khi tôi được làm cùng một staff dev hay engineering manager có cùng tư duy, thì kết quả thực sự vượt trội Tôi luôn thấy biết ơn khi được cộng tác với những đồng nghiệp như vậy
Nếu phải giải thích cả chuyện cần rửa tay để được duyệt đầu tư thì có gì đó sai ở đội ngũ rồi. Cũng như một đầu bếp nhà hàng hạng nhất không cần phải đi thuyết phục chuyện có nên mua xà phòng hay không, tôi nghĩ được gia nhập một tổ chức mà những điều đó là hiển nhiên chính là một nấc thang trong sự nghiệp. Một SWE thành công là người làm việc ở đội ngũ mà tiêu chuẩn đó đã là mặc định
Đồng ý. Refactoring là trách nhiệm tự nhiên của developer. Chỉ cần làm kèm một cách tự nhiên trong quá trình phát triển tính năng rồi cập nhật lại tiến độ deadline, thì việc thuyết phục sẽ dễ hơn nhiều vì chủ yếu chỉ cần trao đổi giữa những người kỹ thuật với nhau, và về lâu dài chất lượng codebase sẽ tăng lên rất mạnh. Kết quả là việc bảo trì dễ hơn và phát triển tính năng mới cũng nhanh hơn
Tài sản chính trị lớn nhất tôi có thể xây là sự hiểu biết và năng lực kỹ thuật của mình. Nhưng sức mạnh đó chỉ hữu ích khi tôi dùng nó để tư vấn và thực sự delivery trong bối cảnh chiến lược tổng thể của công ty Nếu đưa ra lời khuyên phù hợp và hành động vì công ty, mọi người sẽ lắng nghe và dựa vào tôi. Cuối cùng điều đó tạo ra quyền lực để tôi định hình phương hướng Chuẩn bị sẵn một phương án quản trị rủi ro kiểu plan B riêng, rồi đề xuất và thực thi nó khi cần, là cách tốt nhất
Có một cuốn sách về sự nghiệp khá cực đoan nhưng nêu ra những điểm hay Một trong số đó là năng lực kỹ thuật đôi khi lại có thể gây hại cho sự nghiệp và quyền lực của tôi. Nếu tôi dùng thời gian và năng lượng của mình để thực sự làm ra thứ gì đó, thì một quản lý có năng lực sẽ chủ động cố giữ tôi ở đúng vị trí để tôi khó có ảnh hưởng chính trị hơn mức cần thiết Ngược lại, nếu trở thành quản lý, thì không cần trực tiếp làm gì cả, chỉ cần khởi xướng càng nhiều initiative (dự án, chính sách, thay đổi) càng tốt và khéo léo điều phối quyền lực chính trị mình có Việc các initiative đó có thực sự tạo ra giá trị hay không là không quan trọng, thậm chí chẳng cần bận tâm. Tôi đã rời khỏi bàn cờ rồi, còn những người vẫn ở lại đây và cứ bám lấy thành công hay giá trị thực tế thì sẽ tụt lại phía sau Nếu cần, quản lý còn có thể nhận công sau đó bằng cách nói “đó là do tôi làm”
Phải có các đội chuyên chuyển trạng thái theo “flavor of the month” thì công việc mới chạy được - đó là lý thuyết chính trị của tôi. Washington DC cũng vậy. Không có đại kế hoạch gì cả, chỉ có một đạo quân luôn chờ sẵn để pitch ngay khi cơ hội xuất hiện
Nếu phải luyện đấu đá chính trị và tích lũy quyền lực thì nên tìm công ty mới Bạn có thể nghĩ tôi ngây thơ, nhưng không phải công ty nào cũng như vậy. Công ty của tôi thì không