- Tulisan ini menyajikan strategi praktis agar engineer di perusahaan teknologi dapat terlibat secara efektif dalam politik organisasi, serta membahas cara mengatasi rasa tidak berdaya secara politik yang dimiliki banyak engineer
- Engineer bukanlah pemain dalam permainan politik, melainkan alat, tetapi mereka tetap bisa menjalankan pengaruh politik dengan secara aktif mendukung keberhasilan proyek-proyek level eksekutif atau mengusulkan ide teknis yang selaras dengan perubahan prioritas organisasi
- Karena perhatian organisasi berubah seperti gelombang, strategi kuncinya adalah menyiapkan lebih dulu berbagai program teknis dalam beragam arah seperti stabilitas, pengalaman pengembang, dan peningkatan performa, lalu mengusulkannya pada saat yang tepat
- Ketika kebutuhan politik bertabrakan dengan tidak adanya ide yang baik, lahirlah keputusan teknis terburuk, dan engineer senior memiliki tanggung jawab untuk menyajikan ide yang tepat pada waktunya
- Secara sinis, ini bisa dilihat sebagai menjadi alat dalam perebutan kekuasaan, tetapi secara optimistis, ini bisa dipandang sebagai cara untuk mencapai tujuan teknis sendiri sambil menghormati penetapan prioritas oleh manajemen
Keyakinan umum tentang ketidakberdayaan politik engineer
- Banyak software engineer memiliki sikap fatalistis terhadap politik perusahaan dan percaya bahwa keterlibatan itu tidak ada gunanya
- Keputusan teknis sering dibuat karena alasan yang sepenuhnya egoistis, sehingga engineer yang berniat baik tidak bisa memberi pengaruh
- Pemangku kepentingan yang kuat terlalu tidak kompeten dan disfungsional, sehingga memahami kebutuhan mereka dan menyediakan solusi menjadi nyaris mustahil
- Permainan politik bergantung pada informasi tertutup yang tidak dimiliki engineer, sehingga upaya untuk ikut terlibat hanya berujung pada kepanikan tanpa arah
- Manajer dan eksekutif menghabiskan sebagian besar waktunya untuk politik, sedangkan engineer untuk engineering, sehingga engineer sejak awal berada pada posisi politik yang sangat tidak menguntungkan
- Memang benar bahwa software engineer tidak bisa bermain di level yang sama dengan operator politik sungguhan
- Engineer yang mulai berintrik ala Game of Thrones melakukan kesalahan yang mengerikan, dan tipu daya semacam itu akan segera terbongkar lalu dipakai untuk merugikan mereka
- Untuk berintrik, dibutuhkan latihan dan kekuasaan, dan software engineer tidak punya keduanya
Cara praktis untuk ikut terlibat dalam politik
- Di perusahaan besar, software engineer pada dasarnya memang adalah alat, bukan pemain dalam permainan politik, tetapi ada banyak cara untuk ikut terlibat tanpa intrik
- Cara termudah adalah secara aktif bekerja demi keberhasilan proyek-proyek berprofil tinggi
- Ini hampir sama dengan apa yang memang seharusnya dilakukan sebagai bagian dari pekerjaan biasa
- Jika perusahaan banyak berinvestasi pada proyek baru (belakangan ini kemungkinan besar proyek AI), menggunakan kemampuan engineering untuk membuatnya berhasil adalah langkah yang menguntungkan secara politik bagi VP atau eksekutif yang memimpin proyek tersebut
- Sebagai imbalannya, Anda akan mendapat kompensasi yang memang bisa diberikan eksekutif di perusahaan teknologi, seperti bonus, bantuan promosi, atau posisi pada proyek-proyek berprofil tinggi berikutnya
Memanfaatkan ide teknis dalam kampanye politik
- Cara yang sedikit lebih sulit tetapi memberi lebih banyak kendali adalah membuat ide pilihan Anda dapat dimanfaatkan oleh kampanye politik yang sudah ada
- Misalkan Anda ingin memisahkan fitur yang sudah ada menjadi layanan terpisah, ada dua cara
- Cara sulit: menghabiskan modal politik Anda sendiri untuk menggalang dukungan, menjelaskan pentingnya kepada manajer, dan perlahan meyakinkan para skeptis agar proyek disetujui
- Cara mudah: membiarkan eksekutif menggunakan modal politik mereka sendiri yang (jauh lebih besar) untuk proyek itu
- Menunggu sampai ada arahan tingkat perusahaan tentang sasaran yang selaras dengan proyek tersebut (misalnya penekanan pada stabilitas setelah insiden besar)
- Lalu mengusulkan kepada manajer bahwa proyek Anda mungkin cocok dengan sasaran itu
- Jika penilaian Anda tepat, organisasi akan mendukung proyek tersebut, dan alih-alih menghabiskan modal politik, Anda justru menambahnya
Menunggangi gelombang perhatian organisasi
- Perhatian organisasi datang seperti gelombang
- Ketika tiba masa fokus pada stabilitas, para VP sangat ingin melakukan sesuatu dan mencari proyek stabilitas yang terdengar meyakinkan untuk ditunjukkan kepada atasan mereka, tetapi mereka sendiri tidak punya kemampuan untuk mengerjakannya
- Mereka umumnya bersedia mendanai apa pun yang diusulkan tim engineering
- Sebaliknya, ketika perhatian organisasi tertuju ke hal lain (misalnya peluncuran besar produk baru), mereka tidak ingin engineer menghabiskan waktu untuk refactor internal berfokus stabilitas yang tidak terlihat oleh pelanggan
- Untuk menyelesaikan pekerjaan teknis di perusahaan teknologi, Anda harus menunggu gelombang yang tepat
- Menyiapkan lebih dulu program teknis dalam beberapa arah berbeda adalah ide yang bagus
- Engineer yang kuat biasanya akan menemukan hal-hal seperti ini secara otomatis dalam alur kerja normal
- Contoh rencana:
- Memigrasikan kode billing dari pemanggilan API yang di-cache menjadi data tersimpan yang diperbarui melalui webhook
- Menghapus pipeline build lama buatan sendiri dan menggantinya dengan Vite
- Menulis ulang layanan Python yang berantakan dan bertrafik tinggi ke Golang
- Mengganti frontend CMS yang lambat untuk dokumentasi publik dengan situs statis yang cepat
Pentingnya usulan yang tepat waktu
- Saat para eksekutif mengkhawatirkan billing, Anda dapat mengusulkan refactor billing sebagai peningkatan stabilitas
- Saat mereka mengkhawatirkan pengalaman pengembang, Anda dapat mengusulkan penggantian pipeline build
- Saat pelanggan mengeluh soal performa, Anda dapat mempresentasikan penulisan ulang ke Golang sebagai opsi yang baik
- Saat CEO memeriksa kondisi dokumentasi publik dan panik, Anda dapat menyampaikan argumen untuk membangunnya ulang sebagai situs statis
- Yang penting adalah menyiapkan program kerja yang rinci, efektif, dan bisa langsung dijalankan, apa pun tren bulan itu
Momen ketika keputusan teknis terburuk dibuat
- Bahkan tanpa mengikuti pendekatan ini, beberapa program tetap akan mendapat pendanaan, tetapi tanpa cara ini Anda tidak bisa mengendalikan program mana yang akan dipilih
- Di sinilah perusahaan membuat keputusan teknis terburuk: ketika kebutuhan politik untuk melakukan sesuatu bertabrakan dengan tidak adanya ide yang baik
- Saat tidak ada ide bagus, ide buruk pun akan dipakai, meski tak seorang pun sebenarnya menginginkan hasil itu
- Buruk bagi eksekutif: mereka harus menjual hasil teknis yang mengecewakan seolah itu keberhasilan
- Buruk bagi engineer: mereka harus menghabiskan waktu dan tenaga untuk membangun ide yang salah
- Jika Anda engineer yang sangat senior, para VP akan diam-diam menyalahkan Anda untuk hal ini, dan mereka benar
- Menyiapkan ide yang tepat pada waktu yang tepat adalah tanggung jawab Anda
Dua sudut pandang
- Sudut pandang sinis: ini bisa dibaca sebagai ajakan untuk menjadi alat yang berguna bagi para sosiopat yang menjalankan perusahaan dalam perebutan kekuasaan internal tanpa akhir
- Sudut pandang optimistis: ini bisa dibaca sebagai saran untuk membiarkan para eksekutif menetapkan prioritas menyeluruh perusahaan (karena memang itu pekerjaan mereka), lalu menyelaraskan rencana teknis Anda dengan prioritas tersebut
- Bagaimanapun juga, mendorong rencana yang tepat pada saat yang tepat akan membantu Anda mencapai lebih banyak tujuan teknis
Reaksi Hacker News dan kutipan terkait
- Artikel ini mendapat perhatian di Hacker News dan menerima respons yang jauh lebih positif dibanding tulisan lain tentang politik
- Salah satu komentar menyebut kutipan Milton Friedman dan menerapkan gagasan dalam artikel ini pada kebijakan politik umum
- "Hanya krisis (baik nyata maupun yang dipersepsikan) yang benar-benar menciptakan perubahan. Ketika krisis itu terjadi, tindakan yang diambil bergantung pada ide-ide yang tersedia di sekitarnya. Inilah fungsi dasar kita: mengembangkan alternatif terhadap kebijakan yang ada, serta menjaganya tetap hidup dan tersedia sampai sesuatu yang secara politik mustahil menjadi sesuatu yang secara politik tak terelakkan"
- Beberapa komentar mengkritik pendekatan ini karena dianggap terlalu gamified dan egoistis, tetapi penulis menilai hal itu bergantung pada tujuannya
- Salah satu komentar merangkum inti artikel ini dengan baik: "Alih-alih menunggu instruksi, bersikap sinis terhadap ide buruk saat ada kekosongan, dan tidak mengerjakan apa yang diinginkan, penulis menjaga backlog ide-ide bagus dan penting yang bisa diajukan ketika orang penting mengatakan sesuatu menjadi prioritas. Ia tetap menyelesaikan hal yang diinginkan dengan berkompromi pada timing"
1 komentar
Opini Hacker News
Inti dari postingan ini menurut saya adalah sebagai berikut
Poin pertama mungkin terdengar jelas, tetapi ini adalah topik yang sudah berkali-kali saya coaching ke banyak orang di awal karier mereka Banyak orang yang sedang kesulitan atau menuju PIP mengalami titik balik hanya dengan menjalankan loop berikut dengan baik
Saya menafsirkan nomor 2 sebagai menyiapkan agenda saya sendiri. Misalnya, jika saya ingin membuat codebase lebih minimal, saya menyiapkan PoC dan detail terkait agar bisa langsung saya usulkan saat ada kesempatan Karena sudah siap, ketika ada masalah kecepatan situs, isu SEO, atau bug, saya bisa mengusulkan ide minimal itu sebagai solusi Konsep seperti ini memang menarik, tetapi saya masih banyak berpikir tentang bagaimana menerapkannya dalam praktik. Saya juga sering berpikir untuk membuat dokumen persiapan yang bisa dipakai di masa depan. Mirip mengelola blog, saya mendokumentasikan pekerjaan saya secara konsisten sambil menunggu kesempatan Banyak pekerjaan tambahan seperti ini mungkin berakhir sia-sia, tetapi sebenarnya saya rasa saya sudah sering melakukan hal seperti itu
Satu hal lagi yang ingin saya tambahkan: jangan sembarangan mengerjakan hal yang ditentang oleh orang-orang yang punya kekuatan politik lebih besar daripada manajer saya. Kecuali, tentu saja, jika ada orang yang lebih berkuasa dari mereka yang secara terbuka memberi arahan sebaliknya Maksudnya bukan harus melakukan apa pun yang mereka mau, tetapi penting untuk berhati-hati agar tidak membuat mereka kesal tanpa perlu Hampir tidak pernah ada gunanya punya musuh, dan kebanyakan manajer juga akan menjadikan saya kambing hitam demi melindungi diri mereka sendiri saat krisis
Saya lebih suka langsung mengusulkan ke manajer "apa yang sebaiknya dikerjakan". Saya mengangkat isu penting ke meja dan menjelaskan alasannya Saya harus proaktif agar manajer mendapatkan manfaat dari keahlian saya Saya sendiri juga belum terlalu banyak pengalaman seperti ini, tetapi sudah ada beberapa contoh sukses
Nasihat seperti ini makin penting semakin tinggi posisi kita. Ini juga berlaku untuk engineering manager, dan saat saya menjadi director yang melapor langsung ke CTO, saya juga berusaha menerapkan prinsip ini
Salah satu kutipan favorit saya adalah: "Hanya krisis yang nyata, atau yang dipersepsikan, yang menghasilkan perubahan sejati. Tindakan yang diambil pada saat itu bergantung pada ide-ide yang beredar di sekitarnya. Fungsi dasar kita adalah mengembangkan kebijakan alternatif, menjaganya tetap hidup dan tersedia sampai yang tampak mustahil secara politik menjadi tak terelakkan secara politik" - Milton Friedman Menulis 1 Pager dan dokumen teknis lalu membagikannya lebih dulu, kemudian mengutipnya kembali saat krisis datang, cukup efektif untuk mengangkat ide saya Pernah ada saat saya mendorong arah arsitektur yang saya inginkan secara bertahap dan makin mendekati tujuan, dan membangun konsensus itu penting Tentu saja, saya juga sering kalah oleh VP atau director yang jauh lebih piawai dalam politik organisasi dibanding saya Namun, menyiapkan pustaka 1 Pager, membagikannya secara halus, lalu membiarkannya "beredar di udara" sampai ada motivasi untuk mengeksekusinya, jauh lebih efektif
Saya relate dengan bagian "saya kalah dalam pertarungan politik". Salah satu hal mengejutkan yang saya sadari setelah menjadi middle manager ke atas adalah betapa terlihatnya manuver politik dari karyawan level bawah Banyak IC atau EM level 1 terlalu melebih-lebihkan insting politik atau social IQ mereka sendiri Selain itu, karena kedalaman dan jangkauan komunikasi di dalam organisasi berbeda-beda, seseorang bisa merasa sedang meyakinkan seorang stakeholder, padahal setelah itu stakeholder tersebut diam-diam memberi konteks ke manajernya Kami di tim manajemen beberapa kali melihat adegan seperti ini sambil berusaha secara diam-diam mengendalikan manuver politik yang canggung
Saya penasaran, secara konkret seperti apa maksud dari "membiarkan 1 Pager dan dokumen teknis beredar"
Saya setuju dengan kutipan itu dan metode ini tampaknya efektif. Hanya saja dalam kenyataannya, skala waktunya bisa sangat panjang sampai melelahkan Selain itu, sering juga krisis sepenuhnya diabaikan, sehingga tidak pernah benar-benar dipersepsikan sebagai krisis atau malah dinormalisasi
Saya penasaran apakah 1 Pager membantu Anda mendapatkan pengakuan dan promosi karier, atau hanya membantu agar ide Anda benar-benar diwujudkan
Menurut saya ini cara terbaik
Sering deploy ke production (berfokus pada delivery nyata, bukan pekerjaan teoretis)
Mencapai hasil yang berarti (
wins) (dengan metrik yang disepakati)Memiliki "salesman" di manajemen atau PM yang pandai menjual keberhasilan saya Tapi masalah tetap muncul. Selalu ada VP atau pemimpin baru yang ingin terlihat inovatif. Tim yang memelihara sistem yang sudah ada akan dicap salah, dan VP baru akan menonjolkan garisnya sendiri dengan ide-ide progresif seperti AI. Begitu kode saya dirilis, langsung dianggap "legacy" Lalu VP melempar janji-janji masa depan yang gemerlap, sementara peran saya yang menjaga realitas saat ini tidak mungkin bersaing. Realitas itu tidak seksi dan tidak menyenangkan. Jadilah saya pihak status quo Pada akhirnya, esensinya adalah hubungan patronase: membantu VP di atas saya sukses, lalu menciptakan posisi untuk ikut pindah bersama mereka saat mereka berganti pekerjaan
Saya benar-benar merasa ini tepat. Kalau didalami satu tingkat lagi, sebagai staff engineer penting untuk menegaskan bahwa "saya bukanlah kode itu sendiri". Begitu kode dirilis, ia langsung menjadi utang/legacy Yang terbaik adalah memosisikan diri saya bukan sebagai "pembela kode", melainkan sebagai MITRA SETARA dengan leadership, produk, para pengambil keputusan, dan lain-lain. Ini soal perspektif/frame. Dengan tindakan yang sama pun, jika saya dipandang sebagai "mitra dalam pekerjaan", para pemimpin akan melihat saya sebagai pendukung proaktif; jika tidak, saya akan dianggap hambatan yang harus dipaksa setuju, dan perbedaannya besar
Saya sangat setuju dengan kalimat "harus ada orang di PM yang pandai menjual keberhasilan saya". Kalau dipikir-pikir kembali, mungkin hal yang paling mampu membuat perubahan besar dalam karier saya adalah seberapa cepat saya bisa menjauh dari PM yang buruk PM yang bagus memperbaiki segalanya, tetapi sulit ditemukan. Sebaliknya, kalau PM salah arah, semuanya rusak, dan begitu PM itu pergi, suasananya bisa berubah drastis
Saya sangat suka ungkapan "tidak bisa bersaing dengan janji masa depan". Itu terlalu sering terjadi. Bahkan jika janji itu 26 kali sebelumnya tidak pernah ditepati, “masa depan yang gemilang” tetap selalu terdengar hebat
Dalam praktik kerja nyata, konsep sering deploy ke production (rep = berorientasi eksekusi, tanpa teori) memang bagus, tetapi saya heran kenapa janji masa depan mengawang dari VP sering dinilai lebih tinggi daripada kemungkinan realisasinya
Saya belum pernah mendengar istilah "pekerjaan teoretis", tetapi memang ada tempat yang deploy setiap hari. Namun saya rasa deploy terlalu sering tidak selalu ideal. Saya bertanya-tanya bagaimana sesuatu yang substantif bisa di-deploy hanya dalam sehari. Proyek seperti yang saya kerjakan, yang menambah pendapatan perusahaan, tidak bisa selesai dalam sehari. Kalau pekerjaan selesai dalam sehari, itu sama saja berarti perusahaan hanya butuh engineer empat kali setahun. Jadi "sering deploy" seperti ini justru terasa seperti vanity metric
Saya juga belum pernah bekerja di perusahaan yang dysfunctional, jadi saya sama sekali tidak relate dengan bagian awal tulisan ini Dalam pengalaman saya, komunikasi top-down selalu aktif, dan bahkan ketika pengembangan berjalan ke arah yang tidak saya setujui, kami tetap mendiskusikannya dengan cukup matang sebelumnya, sehingga muncul hal-hal menarik tentang kenapa rekan kerja cerdas bisa melihatnya berbeda dari saya Saya tidak tahu apakah ini karena saya hanya pernah bekerja di perusahaan yang didirikan engineer, atau memang saya hanya beruntung
VP senior di perusahaan besar punya tujuan yang lebih luas, dan konsep tentang cara mencapainya juga lebih luas. Itu tidak selalu buruk. Ada ruang untuk mencoba berbagai pendekatan sebelum terpaku pada satu teknologi atau metodologi tertentu. Tentu ada pemborosan, tetapi ini juga efisien untuk merespons pergeseran besar di industri secara cepat demi memenuhi misi para eksekutif
Saya penasaran pernah bekerja di perusahaan dengan skala seperti apa
"Jalan yang sedikit lebih sulit tetapi memberi lebih banyak kontrol adalah dengan menempelkan ide saya ke kampanye politik yang sudah ada" Saya sudah menguasai seni menumpang pada proyek yang dipimpin VP. Rasanya pahit, tetapi efektivitasnya nyata
Keluhan yang sering terdengar di kubu ini adalah, “saya sudah merapikan seluruh refactor kode dengan sempurna tetapi tidak ada yang menghargainya” Dulu saya pernah mendengar kenalan membanggakan bagaimana dia menghabiskan berbulan-bulan membersihkan data pipeline dengan sempurna, tetapi tidak ada yang memahami nilainya, dan itu membuat saya berpikir banyak hal Sebagai engineer, saya tahu pekerjaan seperti itu berharga, tetapi dari sudut pandang PM/EM, ini mirip dengan jika seorang PM menghabiskan sebulan memberi tanda titik dan mengurutkan semua dokumen engineering internal, lalu responsnya adalah “jadi dampaknya apa bagi perusahaan?” Dari sudut pandang PM, jadi kabur bagaimana membedakan engineer yang benar-benar berdampak dan engineer yang "hanya melakukan formatting" Pada akhirnya, penting untuk menjelaskan dengan jelas sebelumnya apa yang ingin dikerjakan, dalam format yang cocok untuk audiens non-teknis Dulu saya mendorong unit test dan integration test, tetapi karena kemauan politiknya kurang, itu berkali-kali gagal masuk prioritas. Setelah SEV besar benar-benar terjadi dan saya mengatakan "untuk mencegah ini, kita butuh test", barulah semua orang setuju akan nilainya. Sekarang semua orang memahami kenapa test itu perlu
Sangat setuju. Jika saya sedang mendorong suatu tindakan sebagai prioritas, saya harus menjelaskannya dengan logika dan bahasa yang dipakai orang yang menentukan prioritas itu Misalnya, PM biasanya berpikir dalam satuan uang. Jika target teknis saya seperti memperluas test coverage membutuhkan 200 dev hour per tahun tetapi bisa menghemat 400 dev hour per tahun, mengurangi support ticket 15%, memungkinkan skenario bisnis masa depan, dan sebagainya, maka itu jauh lebih mudah untuk dijual Trik yang saya suka adalah mengemas pekerjaan tech debt bukan sebagai "pekerjaan teknis", tetapi sebagai dampak bisnis yang jelas, sehingga PM justru memasukkannya sendiri ke roadmap Cara ini makin mudah seiring bertambahnya pengalaman. Awalnya orang mungkin skeptis, tetapi lama-lama kepercayaan terhadap estimasi dan hasil kerja saya terbangun, dan hal-hal yang dulu butuh beberapa rapat sekarang cukup selesai lewat percakapan 10 menit
Saya juga setuju dengan pendapat ini. Tetapi menurut saya kita juga bisa membalik cara pandangnya Misalnya, di proyek konstruksi, ada orang yang teliti memeriksa dan memelihara sistem keselamatan sehingga kecelakaan bisa dicegah, tetapi manajemen sering sama sekali tidak mengakui nilainya dan tidak memberi imbalan Jika manfaat yang tidak bisa ditunjukkan secara kuantitatif dalam ROI dianggap tidak ada, itu sendiri adalah kegagalan besar manajemen, dan jika menyangkut keselamatan jiwa, itu juga kegagalan moral Sebenarnya itulah yang sedang terjadi di Boeing saat ini
Intinya adalah menjelaskan dengan nilai yang dapat dipahami audiens. Ini pada akhirnya adalah skill sales, dan saya rasa sebagian besar developer tidak punya pengalaman atau tidak mudah menyadarinya. Akan ideal jika didukung manajer yang bagus, dan ketika ada staff dev atau engineering manager yang pola pikirnya selaras dengan saya, hasilnya benar-benar besar Saya selalu merasa bersyukur saat bisa bekerja sama dengan rekan-rekan seperti itu
Jika Anda harus menjelaskan perlunya cuci tangan hanya untuk mendapatkan keputusan investasi, maka ada sesuatu yang salah dengan tim itu. Seperti chef restoran kelas atas yang tidak perlu diyakinkan apakah perlu membeli sabun atau tidak, menurut saya masuk ke organisasi yang menganggap hal seperti itu sebagai sesuatu yang wajar adalah salah satu tahap dalam karier. SWE yang sukses adalah orang yang bekerja di tim yang standar dasarnya memang sudah setinggi itu
Setuju. Refactoring memang tanggung jawab alami developer. Saat mengembangkan fitur, lakukan saja secara natural sambil ikut memperbarui target deadline; kalau komunikasinya cukup antar teknisi, persuasinya jadi jauh lebih mudah, dan dalam jangka panjang kualitas codebase bisa meningkat tajam. Hasilnya, maintenance jadi lebih mudah dan pengembangan fitur baru jadi lebih cepat
Modal politik terbesar yang bisa saya bangun adalah pemahaman dan kemampuan teknis saya. Namun, kekuatan ini baru berguna ketika saya memberi saran dan benar-benar bisa delivery dalam konteks strategi dan situasi perusahaan secara keseluruhan Jika saya memberi saran yang tepat dan bertindak untuk perusahaan, orang-orang akan mendengarkan saya dan bergantung pada saya. Pada akhirnya itu menciptakan otoritas bagi saya untuk menentukan arah Menyiapkan semacam Plan B sebagai manajemen risiko, lalu mengusulkan dan menjalankannya saat dibutuhkan, adalah cara terbaik
Ada buku karier yang cukup ekstrem tetapi memuat poin-poin bagus Salah satunya adalah bahwa kemampuan teknis justru bisa merugikan karier dan kekuasaan saya. Jika saya memakai waktu dan energi untuk benar-benar mengerjakan sesuatu, manajer yang kompeten akan secara aktif berusaha menahan saya di posisi saya agar saya tidak punya terlalu banyak pengaruh politik Sebaliknya, kalau saya menjadi manajer, saya tidak perlu benar-benar mengerjakan apa pun, cukup memulai sebanyak mungkin inisiatif (proyek, kebijakan, perubahan), lalu dengan lincah mengatur kekuatan politik yang saya punya Tidak penting apakah inisiatif itu benar-benar berhasil menciptakan nilai; bahkan saya tidak perlu peduli. Saya sudah meninggalkan papan permainan itu, sementara orang-orang yang masih terobsesi dengan kesuksesan dan nilai nyata di sini akan tertinggal Jika perlu, manajer cukup mengambil kredit di belakang hari dan mengklaim "itu hasil saya"
Harus ada tim khusus yang siap berputar mengikuti "flavor of the month" agar pekerjaan berjalan - itu teori politik saya. Washington DC juga begitu. Tidak ada grand plan, hanya ada pasukan yang selalu siap pitching begitu peluang muncul
Jika saya harus berlatih bertarung politik dan membangun kekuasaan, lebih baik cari perusahaan baru Anda mungkin menganggap saya naif, tetapi tidak semua perusahaan seperti itu. Perusahaan saya tidak seperti itu