- บทความนี้นำเสนอกลยุทธ์เชิงปฏิบัติที่ช่วยให้ วิศวกรในบริษัทเทคมีส่วนร่วมกับการเมืองในองค์กรได้อย่างมีประสิทธิภาพ โดยพูดถึงวิธีเอาชนะความรู้สึกไร้อำนาจทางการเมืองที่วิศวกรจำนวนมากมีอยู่
- วิศวกรไม่ใช่ผู้เล่นในเกมการเมือง แต่เป็นเครื่องมือ อย่างไรก็ตาม พวกเขายังสามารถใช้อิทธิพลทางการเมืองได้ด้วยการ สนับสนุนความสำเร็จของโปรเจกต์ระดับผู้บริหารอย่างแข็งขัน หรือ เสนอไอเดียด้านเทคนิคให้สอดคล้องกับการเปลี่ยนแปลงของลำดับความสำคัญในองค์กร
- เพราะความสนใจขององค์กรเปลี่ยนไปเหมือนคลื่น กลยุทธ์สำคัญคือ เตรียมโปรแกรมด้านเทคนิคหลายทิศทางไว้ล่วงหน้า เช่น ความเสถียร ประสบการณ์นักพัฒนา และการปรับปรุงประสิทธิภาพ แล้วเสนอในจังหวะที่เหมาะสม
- เมื่อความจำเป็นทางการเมืองปะทะกับการไม่มีไอเดียที่ดีพอ จะนำไปสู่ การตัดสินใจทางเทคนิคที่แย่ที่สุด และวิศวกรอาวุโสมีหน้าที่ต้องเสนอไอเดียที่ถูกต้องในเวลาที่เหมาะสม
- ในมุมมองแบบถากถาง นี่คือการเป็นเครื่องมือในเกมแย่งชิงอำนาจ แต่ในมุมมองเชิงบวก มันคือวิธี บรรลุเป้าหมายทางเทคนิคของตนเองโดยเคารพลำดับความสำคัญของผู้บริหาร
ความเชื่อทั่วไปเรื่องความไร้อำนาจทางการเมืองของวิศวกร
- วิศวกรซอฟต์แวร์จำนวนมากมี ทัศนคติแบบจำนนต่อชะตา ต่อการเมืองในบริษัท และเชื่อว่าการเข้าไปมีส่วนร่วมนั้นไร้ความหมาย
- การตัดสินใจทางเทคนิคมักเกิดจากเหตุผลที่เห็นแก่ตัวล้วน ๆ จนวิศวกรที่หวังดีไม่อาจมีอิทธิพลได้
- ผู้มีส่วนได้ส่วนเสียที่ทรงอิทธิพลทั้งไร้ความสามารถและทำงานแบบผิดเพี้ยนเกินไป จนแทบเป็นไปไม่ได้ที่จะเข้าใจความต้องการของพวกเขาและหาทางออกให้
- เกมการเมืองพึ่งพา ข้อมูลวงในที่ไม่เปิดเผย ซึ่งวิศวกรไม่มี ดังนั้นการพยายามเข้าไปเล่นมีแต่จะทำให้ดูเก้ ๆ กัง ๆ
- ผู้จัดการและผู้บริหารใช้เวลาส่วนใหญ่ไปกับการเมือง ขณะที่วิศวกรใช้เวลาไปกับงานวิศวกรรม ทำให้วิศวกรเสียเปรียบทางการเมืองอย่างหนักตั้งแต่ต้น
- เป็นความจริงที่ว่าวิศวกรซอฟต์แวร์ไม่สามารถเล่นเกมได้ในระดับเดียวกับนักการเมืองตัวจริงในองค์กร
- การที่วิศวกรเริ่มวางแผนคบคิดแบบ Game of Thrones ถือเป็น ความผิดพลาดร้ายแรง และแผนพวกนั้นมักถูกจับได้ทันทีแล้วถูกใช้ย้อนกลับมาทำร้ายตัวเอง
- การจะเล่นแผนชั้นเชิงแบบนั้นต้องมีทั้งประสบการณ์และอำนาจ ซึ่งวิศวกรซอฟต์แวร์ไม่มีทั้งสองอย่าง
วิธีปฏิบัติในการมีส่วนร่วมทางการเมือง
- ในบริษัทใหญ่ ความจริงง่าย ๆ คือวิศวกรซอฟต์แวร์ไม่ใช่ผู้เล่นในเกมการเมือง แต่เป็น เครื่องมือ ถึงอย่างนั้นก็ยังมีหลายวิธีในการมีส่วนร่วมโดยไม่ต้องเล่นแผน
- วิธีที่ง่ายที่สุดคือ ทำงานอย่างแข็งขันเพื่อให้โปรเจกต์ที่มีโปรไฟล์สูงประสบความสำเร็จ
- เรื่องนี้แทบไม่ต่างจากสิ่งที่ควรทำอยู่แล้วในงานปกติ
- หากบริษัทกำลังลงทุนอย่างมากในโปรเจกต์ใหม่สักอย่าง (ทุกวันนี้มักเป็นโปรเจกต์ AI) การใช้ความสามารถทางวิศวกรรมทำให้มันสำเร็จถือเป็น การขยับที่เป็นประโยชน์ทางการเมือง สำหรับ VP หรือผู้บริหารที่เป็นเจ้าของโปรเจกต์นั้น
- และคุณก็จะได้รับผลตอบแทนเป็นโบนัส ช่วยเรื่องการเลื่อนตำแหน่ง หรือโอกาสไปอยู่ในโปรเจกต์เด่น ๆ ครั้งถัดไป ซึ่งเป็นรางวัลที่ผู้บริหารในบริษัทเทคมอบให้ได้
การใช้ไอเดียทางเทคนิคให้เข้ากับแคมเปญทางการเมือง
- วิธีที่ยากขึ้นเล็กน้อยแต่ให้การควบคุมมากกว่า คือ ทำให้ไอเดียที่คุณอยากผลักดันนำไปใช้กับแคมเปญทางการเมืองที่มีอยู่แล้วได้
- สมมติว่าคุณอยากแยกฟีเจอร์เดิมออกไปเป็นบริการอีกตัวหนึ่ง มีอยู่สองทาง
- ทางยาก: ใช้ทุนทางการเมืองของตัวเองรวบรวมแรงสนับสนุน ทำให้ผู้จัดการเห็นความสำคัญ และค่อย ๆ โน้มน้าวคนที่สงสัยจนโปรเจกต์ผ่านอนุมัติ
- ทางง่าย: เปิดทางให้ผู้บริหารใช้ทุนทางการเมืองของตัวเองที่มีมากกว่ามากกับโปรเจกต์นั้น
- รอให้มีคำสั่งหรือแรงผลักดันระดับทั้งองค์กรในเป้าหมายที่สอดคล้องกับโปรเจกต์ก่อน (เช่น หลังเหตุการณ์สำคัญแล้วองค์กรหันมาเน้นเรื่องความเสถียร)
- จากนั้นค่อยเสนอผู้จัดการว่าโปรเจกต์ของคุณอาจตอบโจทย์สิ่งนั้นได้
- ถ้าคุณประเมินถูก องค์กรก็จะสนับสนุนโปรเจกต์นี้ และแทนที่จะใช้ทุนทางการเมือง คุณจะ ยิ่งสะสมมันเพิ่มขึ้น
โต้คลื่นความสนใจขององค์กร
- ความสนใจขององค์กรนั้น มาเป็นระลอกเหมือนคลื่น
- เมื่อถึงช่วงที่ทุกคนให้ความสำคัญกับความเสถียร VP ต่าง ๆ จะกระตือรือร้นอย่างมากที่จะต้องทำอะไรสักอย่าง และอยากหาโปรเจกต์ด้านความเสถียรที่ดูดีพอจะเอาไปแสดงต่อหัวหน้าได้ แต่ไม่มีความสามารถพอจะทำเอง
- โดยทั่วไปพวกเขามักยินดีสนับสนุนงบให้กับสิ่งที่ทีมวิศวกรรมเสนอ
- ในทางกลับกัน เมื่อความสนใจขององค์กรไปอยู่ที่อื่น (เช่น การเปิดตัวผลิตภัณฑ์ใหม่ครั้งใหญ่) พวกเขาจะไม่อยากให้วิศวกรใช้เวลากับการ refactor ภายในที่ลูกค้ามองไม่เห็นซึ่งเน้นเรื่องความเสถียร
- หากอยากทำงานด้านเทคนิคให้สำเร็จในบริษัทเทค คุณต้อง รอคลื่นที่เหมาะสม
- เป็นความคิดที่ดีที่จะ เตรียมโปรแกรมด้านเทคนิคหลายแนวทางไว้ล่วงหน้า
- วิศวกรที่แข็งแกร่งมักมองเห็นสิ่งเหล่านี้ได้เองโดยอัตโนมัติระหว่างการทำงานปกติ
- ตัวอย่างแผน เช่น
- ย้ายโค้ดระบบเรียกเก็บเงินจากการเรียก API แบบแคช ไปเป็นข้อมูลที่เก็บไว้ซึ่งอัปเดตด้วย webhook
- ถอด build pipeline แบบทำมือเก่าทิ้งแล้วแทนที่ด้วย Vite
- เขียนบริการ Python ที่เละเทะและรับทราฟฟิกสูงใหม่ด้วย Golang
- เปลี่ยนฟรอนต์เอนด์ CMS ที่ช้าและใช้รองรับเอกสารสาธารณะ ให้เป็นเว็บไซต์แบบ static ที่เร็วกว่า
ความสำคัญของการเสนอให้ถูกจังหวะ
- เมื่อผู้บริหารกังวลเรื่องระบบเรียกเก็บเงิน คุณสามารถเสนอการ refactor ระบบเรียกเก็บเงินในฐานะ การปรับปรุงความเสถียร
- เมื่อพวกเขากังวลเรื่องประสบการณ์นักพัฒนา คุณสามารถเสนอการเปลี่ยน build pipeline ได้
- เมื่อลูกค้าบ่นเรื่องประสิทธิภาพ คุณสามารถเสนอการเขียนใหม่ด้วย Golang ว่าเป็นตัวเลือกที่ดี
- เมื่อ CEO เข้ามาดูสภาพเอกสารสาธารณะแล้วตกใจ คุณก็สามารถเสนอเหตุผลในการสร้างใหม่เป็นเว็บไซต์แบบ static ได้
- สิ่งสำคัญคือ ไม่ว่ากระแสของเดือนนั้นจะเป็นอะไร คุณต้องมีแผนงานที่ลงมือทำได้ทันที มีรายละเอียดครบ และได้ผลจริง เตรียมไว้อยู่แล้ว
ช่วงเวลาที่การตัดสินใจทางเทคนิคที่แย่ที่สุดถือกำเนิดขึ้น
- ต่อให้ไม่ใช้แนวทางนี้ บางโปรแกรมก็ยังจะได้รับงบประมาณอยู่ดี แต่ถ้าคุณไม่ทำแบบนี้ คุณจะ ควบคุมไม่ได้ ว่าโปรแกรมไหนจะเป็นฝ่ายได้ไป
- ตรงนี้เองคือจุดที่บริษัทตัดสินใจทางเทคนิคได้ แย่ที่สุด: เมื่อความจำเป็นทางการเมืองที่ว่า “ต้องทำอะไรสักอย่าง” ปะทะกับการไม่มีไอเดียที่ดี
- เมื่อไม่มีไอเดียดีพอ ก็จำเป็นต้องใช้ไอเดียแย่แทน ซึ่งไม่มีใครอยากได้ผลลัพธ์แบบนั้น
- แย่สำหรับผู้บริหาร: ต้องพยายามขายผลลัพธ์ทางเทคนิคที่น่าผิดหวังให้ดูเหมือนเป็นความสำเร็จ
- แย่สำหรับวิศวกร: ต้องทุ่มเวลาและแรงไปกับการสร้างสิ่งที่เป็นไอเดียผิด ๆ
- ถ้าคุณเป็นวิศวกรระดับอาวุโสมากพอ VP จะโทษเรื่องนี้กับคุณเงียบ ๆ และพวกเขาก็พูดถูก
- การเตรียมไอเดียที่ถูกต้องให้พร้อมในเวลาที่เหมาะสมคือความรับผิดชอบของคุณ
สองมุมมอง
- มุมมองแบบถากถาง: คุณอาจอ่านสิ่งนี้ว่าเป็นข้อเสนอให้กลายเป็นเครื่องมือที่หยิบใช้สะดวกสำหรับพวกไซโคพาธที่บริหารบริษัท ในสงครามแย่งชิงอำนาจภายในที่ไม่มีวันจบ
- มุมมองแบบมองโลกในแง่ดี: คุณอาจอ่านสิ่งนี้ว่าเป็นข้อเสนอให้ปล่อยให้ผู้บริหารเป็นคนกำหนดลำดับความสำคัญโดยรวมของบริษัท (เพราะนั่นคืองานของพวกเขา) แล้วนำแผนทางเทคนิคของคุณไปจัดให้สอดคล้องกับสิ่งนั้น
- ไม่ว่าจะมองแบบไหน การผลักดันแผนที่ถูกต้องในเวลาที่เหมาะสมจะช่วยให้คุณบรรลุเป้าหมายทางเทคนิคได้มากขึ้น
กระแสตอบรับบน Hacker News และคำพูดที่เกี่ยวข้อง
- บทความนี้ได้รับความสนใจบน Hacker News และได้รับกระแสตอบรับเชิงบวกมากกว่าบทความเรื่องการเมืองบทอื่น ๆ อย่างชัดเจน
- มีคอมเมนต์หนึ่งอ้างถึงคำพูดของ Milton Friedman และนำแนวคิดในบทความนี้ไปปรับใช้กับนโยบายการเมืองทั่วไป
- "มีเพียงวิกฤตเท่านั้น (ไม่ว่าจะเกิดขึ้นจริงหรือเป็นเพียงการรับรู้) ที่ก่อให้เกิดการเปลี่ยนแปลงอย่างแท้จริง และเมื่อวิกฤตนั้นเกิดขึ้น การลงมือทำที่ตามมาจะ ขึ้นอยู่กับไอเดียที่มีอยู่รอบตัว นี่คือหน้าที่พื้นฐานของเรา: พัฒนาทางเลือกแทนนโยบายที่มีอยู่ และทำให้มันยังมีชีวิตและพร้อมใช้งาน จนกระทั่งสิ่งที่เป็นไปไม่ได้ทางการเมือง กลายเป็นสิ่งที่หลีกเลี่ยงไม่ได้ทางการเมือง"
- คอมเมนต์บางส่วนวิจารณ์ว่าแนวทางนี้เป็นการเล่นเกมมากเกินไปและเห็นแก่ตัวเกินไป แต่ผู้เขียนมองว่าสุดท้ายแล้วมันขึ้นอยู่กับเป้าหมาย
- มีคอมเมนต์หนึ่งสรุปใจความของบทความนี้ได้ดีว่า: "แทนที่จะรอรับคำสั่ง แล้วพอมีช่องว่างก็เอาแต่ประชดไอเดียแย่ ๆ และไม่ได้ทำสิ่งที่ตัวเองต้องการ ผู้เขียนเลือกเก็บ แบ็กล็อกของไอเดียที่ดีและสำคัญ ไว้ เพื่อหยิบขึ้นมาเสนอเมื่อคนสำคัญบอกว่ามีบางอย่างเป็นเรื่องเร่งด่วน ยอมประนีประนอมเรื่องจังหวะเวลา เพื่อให้ทำสิ่งที่อยากทำสำเร็จ"
1 ความคิดเห็น
ความเห็นจาก Hacker News
ประเด็นหลักของโพสต์นี้คือ
ข้อแรกอาจฟังดูเหมือนเรื่องพื้นฐาน แต่เป็นเรื่องที่ผมเคยต้องโค้ชคนช่วงต้นอาชีพหลายครั้งมาก หลายคนที่กำลังเจอปัญหาหรือกำลังจะไปถึงขั้น PIP พลิกสถานการณ์ได้เพียงแค่ทำลูปนี้ให้ดี
ผมตีความข้อ 2 ว่าเป็นการเตรียม agenda ของตัวเอง เช่น ถ้าอยากทำให้ codebase มินิมอลขึ้น ก็เตรียม PoC และรายละเอียดที่เกี่ยวข้องไว้ เพื่อจะได้เสนอได้ทันทีเมื่อโอกาสมาถึง เพราะเตรียมไว้ล่วงหน้า พอเกิดปัญหาเรื่องความเร็วเว็บ, SEO หรือบั๊กขึ้นมา ก็สามารถเสนอไอเดียความมินิมอลนั้นเป็นทางออกได้ แนวคิดนี้น่าสนใจ แต่ผมก็ยังคิดเยอะว่าในทางปฏิบัติจะเอาไปใช้ยังไงดี บ่อยครั้งก็คิดว่าจะทำเอกสารเตรียมไว้สำหรับใช้ในอนาคต เหมือนทำบล็อก คอยบันทึกงานของตัวเองอย่างต่อเนื่องแล้วรอโอกาส งานเพิ่มที่ทำไว้หลายอย่างอาจจบลงแบบเสียเปล่า แต่จริง ๆ ผมก็คิดว่าเราทำเรื่องแบบนั้นกันอยู่แล้วเยอะมาก
อีกอย่างที่อยากเสริมคือ อย่าไปทำเรื่องที่คนซึ่งมีอำนาจทางการเมืองมากกว่าผู้จัดการของเราคัดค้านอยู่ ยกเว้นว่าจะมีคนที่อำนาจมากกว่านั้นสั่งมาอย่างเปิดเผย ไม่ได้หมายความว่าต้องทำทุกอย่างตามที่พวกเขาต้องการ แต่ควรระวังอย่าไปทำให้คนพวกนั้นไม่พอใจโดยไม่จำเป็น แทบไม่มีเหตุผลไหนคุ้มค่าพอที่จะสร้างศัตรู และผู้จัดการส่วนใหญ่ก็พร้อมจะโยนเราเป็นแพะรับบาปเพื่อปกป้องตัวเองเมื่อเกิดวิกฤต
ผมชอบเป็นฝ่ายเสนอให้ผู้จัดการตรง ๆ ว่า “เราควรทำอะไร” มากกว่า ยกประเด็นสำคัญขึ้นมาบนโต๊ะและอธิบายว่าทำไมมันสำคัญ ต้องออกตัวเชิงรุกเพื่อให้ผู้จัดการได้ประโยชน์จากความเชี่ยวชาญของเรา ผมเองก็ยังมีประสบการณ์แบบนี้ไม่มากนัก แต่ก็มีตัวอย่างที่สำเร็จอยู่บ้าง
คำแนะนำแบบนี้ยิ่งสำคัญขึ้นเมื่อขึ้นไปอยู่ระดับที่สูงขึ้น ใช้ได้กับ engineering manager เช่นกัน และตอนที่ผมเป็น director ซึ่งรายงานตรงกับ CTO ผมก็พยายามยึดหลักนี้
มีคำคมหนึ่งที่ผมชอบมาก: "มีเพียงวิกฤตจริง หรือวิกฤตที่ผู้คนรับรู้เท่านั้น ที่ก่อให้เกิดการเปลี่ยนแปลงอย่างแท้จริง และการกระทำที่เกิดขึ้นในเวลานั้นจะถูกกำหนดโดยไอเดียที่ลอยอยู่รอบตัว หน้าที่พื้นฐานของเราคือพัฒนานโยบายทางเลือก ทำให้มันยังมีชีวิตอยู่ต่อไป และทำให้สิ่งที่ดูเป็นไปไม่ได้ทางการเมือง กลายเป็นสิ่งที่เลี่ยงไม่ได้ทางการเมือง" - Milton Friedman การเขียน 1 Pager และเอกสารทางเทคนิคไว้ล่วงหน้าแล้วแชร์เอาไว้ จากนั้นค่อยหยิบมาอ้างอิงอีกครั้งเมื่อเกิดวิกฤต เป็นวิธีที่มีประสิทธิภาพในการดันไอเดียของผม ผมเคยค่อย ๆ ผลักดันทิศทางสถาปัตยกรรมที่ตัวเองต้องการแบบทีละนิด จนเข้าใกล้เป้าหมายมากขึ้นเรื่อย ๆ และการสร้างฉันทามติเป็นเรื่องสำคัญ แน่นอนว่าหลายครั้งผมก็แพ้ให้กับ VP หรือ director ที่เก่งเกมการเมืองกว่าผม แต่การมีคลัง 1 Pager เตรียมไว้ คอยแชร์แบบเนียน ๆ ให้มัน “ลอยอยู่ในอากาศ” และรอจนกว่าจะมีแรงจูงใจให้ลงมือทำ กลับได้ผลกว่ามาก
เห็นด้วยกับส่วนที่ว่า “แพ้เกมการเมือง” สิ่งที่น่าประหลาดใจตอนผมขึ้นมาเป็นผู้จัดการระดับกลางขึ้นไป คือมันมองออกง่ายมากเมื่อพนักงานระดับล่างกำลังเล่นการเมือง IC และ EM ระดับ 1 หลายคนประเมินสัญชาตญาณทางการเมืองหรือ social IQ ของตัวเองสูงเกินไป อีกทั้งความลึกและความกว้างของการสื่อสารในองค์กรก็ต่างกัน ดังนั้นถึงจะคิดว่าตัวเองกำลังโน้มน้าวใครบางคนอยู่ ผู้มีส่วนได้ส่วนเสียคนนั้นอาจเดินไปกระซิบบอกผู้จัดการหลังจบการคุยก็ได้ เราเคยเห็นภาพแบบนี้หลายครั้ง ขณะทีมผู้บริหารพยายามควบคุมเกมการเมืองที่ไม่เนียนอย่างเงียบ ๆ
ผมสงสัยว่าในทางปฏิบัติ “ทำให้ 1 Pager กับเอกสารเทคนิคลอยไปทั่ว” นี่ทำกันแบบไหน
เห็นด้วยกับคำคมนั้น และคิดว่าวิธีนี้น่าจะได้ผล เพียงแต่ในโลกจริงสเกลเวลามันยาวจนน่าหมดแรง อีกอย่าง หลายครั้งวิกฤตก็ถูกเมินไปเลย จนไม่ได้ถูกรับรู้ตามปกติหรือกลายเป็นเรื่องที่ถูกทำให้ชินชาไปแล้ว
ผมสงสัยว่า 1 Pager ช่วยให้คุณได้รับการยอมรับและเลื่อนขั้นในอาชีพด้วยไหม หรือแค่ช่วยให้ไอเดียถูกนำไปทำจริง
นี่คือวิธีที่ผมคิดว่าดีที่สุด
deploy ขึ้น production บ่อย ๆ (เน้นส่งมอบของจริงมากกว่างานเชิงทฤษฎี)
ทำผลลัพธ์ที่มีความหมาย (wins) ให้ได้จริง (วัดด้วย metrics ที่ตกลงกันไว้)
มี “salesman” ในฝั่ง management หรือ PM ที่ช่วยขายความสำเร็จของผมเก่ง ๆ แต่ถึงอย่างนั้นปัญหาก็ยังเกิดอยู่ดี เพราะจะมี VP หรือผู้นำคนใหม่ที่อยากแสดงให้เห็นว่านี่คือการเปลี่ยนแปลงของตัวเองเสมอ ทีมที่ดูแลรักษาระบบเดิมจะถูกปักป้ายว่าผิด ส่วน VP คนใหม่ก็จะเน้นแนวทางของตัวเองด้วยไอเดียล้ำ ๆ อย่าง AI เป็นต้น ทันทีที่โค้ดของผม deploy มันก็ถูกมองเป็น "legacy" จากนั้น VP ก็จะพร่ำสัญญาถึงอนาคตอันสวยหรู ซึ่งบทบาทของผมที่ต้องคอยประคองความจริงในปัจจุบันไม่มีทางแข่งขันได้ เพราะความจริงมันไม่ได้ดูเซ็กซี่หรือสนุกเลย สุดท้ายก็กลายเป็นคนของยุคเก่า ท้ายที่สุดแล้ว แก่นของเรื่องคือความสัมพันธ์แบบมีผู้อุปถัมภ์ คือช่วยให้ VP ที่อยู่เหนือเราประสบความสำเร็จ แล้วสร้างตำแหน่งที่ทำให้เราย้ายตามเขาไปได้ตอนเขาเปลี่ยนงาน
ผมคิดว่าจริงมาก และถ้าลงลึกอีกขั้น ในฐานะ staff engineer สิ่งสำคัญคือการทำให้คนเห็นชัดว่า "ผมไม่ใช่ตัวโค้ดนั้นเอง" โค้ดจะกลายเป็นหนี้หรือ legacy ทันทีที่ deploy สิ่งที่ดีที่สุดคือไม่วางตัวเป็น "ผู้พิทักษ์โค้ด" แต่เป็น EQUAL PARTNER กับผู้นำ ฝ่ายผลิตภัณฑ์ และผู้มีอำนาจตัดสินใจ นี่เป็นเรื่องของมุมมองหรือ frame ล้วน ๆ ต่อให้ทำพฤติกรรมเดียวกัน แต่ถ้าผมถูกมองว่าเป็น ‘คู่ร่วมงานทางธุรกิจ’ ผู้นำจะเห็นผมเป็นผู้ช่วยเชิงรุก แต่ถ้าไม่ใช่ ผมก็จะถูกตีความเป็นอุปสรรคที่ต้องฝืนโน้มน้าว ซึ่งต่างกันมาก
เห็นด้วยมากกับประโยคที่ว่า “ต้องมีคนใน PM ที่ขายผลงานของผมได้เก่ง” พอย้อนกลับไปดู สิ่งที่สร้างความเปลี่ยนแปลงในอาชีพผมมากที่สุดอาจเป็นการหนีออกจาก PM ที่แย่ให้เร็วพอ PM ที่ดีทำให้ทุกอย่างดีขึ้น แต่หาได้ยาก ในทางกลับกัน ถ้า PM พาทิศทางผิด ทุกอย่างจะพัง และทันทีที่ PM คนนั้นหายไป บรรยากาศทั้งหมดก็เปลี่ยนทันที
ชอบประโยคที่ว่า “แข่งกับคำสัญญาในอนาคตไม่ได้” มาก มันเกิดขึ้นบ่อยเกินไปจริง ๆ ต่อให้คำสัญญานั้น 26 ครั้งก่อนหน้านี้ก็ไม่เคยทำได้ “อนาคตอันรุ่งโรจน์” ก็ยังฟังยิ่งใหญ่อยู่ดีเสมอ
เวลาทำงานจริง แนวคิดเรื่อง deploy ขึ้น production บ่อย ๆ (rep=เน้นลงมือจริง ห้ามทฤษฎี) เป็นเรื่องดี แต่ผมก็สงสัยว่าทำไมคำสัญญาอนาคตลอย ๆ ของ VP ถึงถูกให้ค่ามากกว่าความเป็นไปได้ที่จะทำสำเร็จจริง
ผมไม่เคยได้ยินคำว่า ‘งานเชิงทฤษฎี’ แต่แน่นอนว่ามีที่ที่ deploy ทุกวัน อย่างไรก็ตาม ผมไม่คิดว่าการ deploy บ่อย ๆ จะเป็นอุดมคติเสมอไป ผมสงสัยว่าคุณจะ deploy อะไรที่มีสาระจริงได้อย่างไรภายในวันเดียว สำหรับโปรเจกต์แบบที่สร้างรายได้เพิ่มให้บริษัทอย่างงานที่ผมทำ มันจบในวันเดียวไม่ได้ ถ้างานจบวันเดียวได้ ก็เท่ากับบริษัทต้องการวิศวกรแค่ปีละสี่ครั้ง ดังนั้นการ ‘deploy บ่อย’ แบบนี้อาจเป็น Vanity Metric มากกว่า
ผมเองไม่เคยทำงานในบริษัทที่ dysfunctional มาก่อน เลยไม่อินกับช่วงแรกของบทความนี้เลย จากประสบการณ์ของผม การสื่อสารแบบ top-down มีอยู่ตลอด และแม้เราจะพัฒนาไปในทิศทางที่ผมไม่เห็นด้วย ก็มีการถกกันล่วงหน้ามากพอจนเกิดมุมที่น่าสนใจว่าทำไมเพื่อนร่วมงานที่ฉลาดถึงมองต่างจากผม ไม่แน่ใจว่าเป็นเพราะผมทำงานแต่กับบริษัทที่ก่อตั้งโดยวิศวกร หรือแค่โชคดีเฉย ๆ
VP ระดับสูงในบริษัทใหญ่มักมีเป้าหมายที่กว้าง และนิยามของ “วิธีการ” ก็กว้างตามไปด้วย ซึ่งไม่ใช่เรื่องแย่เสมอไป เพราะทำให้มีโอกาสลองหลายแนวทางก่อนจะยึดติดกับเทคโนโลยีหรือ methodology ใดเป็นพิเศษ แน่นอนว่ามีความสิ้นเปลืองอยู่บ้าง แต่ก็มีประสิทธิภาพสำหรับการตอบสนองต่อการเปลี่ยนแปลงเชิงโครงสร้างของอุตสาหกรรมได้ทันที เพื่อให้บรรลุภารกิจของผู้บริหาร
อยากรู้ว่าคุณเคยทำงานกับบริษัทขนาดไหนมาบ้าง
"อีกวิธีหนึ่งที่ยากกว่าเล็กน้อยแต่ให้การควบคุมมากกว่าคือ เอาไอเดียของตัวเองไปผูกเข้ากับแคมเปญทางการเมืองที่มีอยู่แล้ว" ผมเองก็พอชำนาญในการไปเกาะโปรเจกต์ที่ VP เป็นคนผลักดัน แม้จะขมขื่น แต่ได้ผลจริง
เสียงบ่นที่ได้ยินบ่อยในกลุ่มนี้คือ “ฉันรีแฟกเตอร์โค้ดทั้งก้อนอย่างสมบูรณ์แบบแล้ว แต่ไม่มีใครเห็นค่า” ผมเคยได้ยินคนรู้จักคนหนึ่งภูมิใจมากที่ใช้เวลาหลายเดือนทำความสะอาด data pipeline จนเนี้ยบ แต่ไม่มีใครเห็นคุณค่าของมัน ทำให้ผมคิดหลายอย่าง ในฐานะวิศวกร ผมรู้ว่าสิ่งนี้มีคุณค่า แต่จากมุมมองของ PM/EM มันก็คล้ายกับกรณีที่ PM ใช้เวลาหนึ่งเดือนมาติดแท็กและจัดเรียงเอกสารวิศวกรรมทั้งหมดภายในบริษัท แล้วคนอื่นถามว่า “แล้วมันส่งผลอะไรกับบริษัทล่ะ?” ในมุมของ PM มันก็เลยแยกยากว่าใครคือวิศวกรที่มีอิทธิพลจริง กับใครที่ทำแค่งาน “จัดฟอร์แมต” สุดท้ายสิ่งสำคัญคือการอธิบายงานที่วางแผนจะทำให้ชัดเจนล่วงหน้า ในรูปแบบที่เหมาะกับผู้ฟังที่ไม่ใช่สายเทคนิค เมื่อก่อนผมพยายามผลักดัน unit test และ integration test แต่เพราะแรงผลักดันทางการเมืองไม่พอ มันเลยไม่เคยถูกจัดเป็นลำดับความสำคัญ จนกระทั่งเกิด SEV ใหญ่จริง ๆ แล้วผมพูดว่า “ถ้าอยากป้องกันเรื่องแบบนี้ เราต้องมี test” ทุกคนถึงค่อยเห็นตรงกันว่ามันมีคุณค่า ตอนนี้ทุกคนเข้าใจความจำเป็นของ test แล้ว
เห็นด้วยมาก ถ้าผมเป็นคนที่พยายามผลักดันบางอย่างให้เป็นลำดับความสำคัญ ผมต้องอธิบายมันด้วยตรรกะและภาษาของคนที่ตัดสินใจลำดับความสำคัญนั้น ถึงจะโน้มน้าวได้ เช่น โดยทั่วไป PM มักคิดเป็นหน่วยเงิน ถ้าเป้าหมายทางเทคนิคของผม เช่น การขยาย test coverage ต้องใช้ 200 dev hour ต่อปี แต่ช่วยประหยัดได้ 400 dev hour ต่อปี ลด support ticket ได้ 15% หรือเปิดทางให้สถานการณ์ทางธุรกิจในอนาคตเกิดขึ้นได้ แบบนี้จะโน้มน้าวง่ายกว่ามาก กลเม็ดที่ผมชอบคือ แพ็กงาน tech debt ไม่ให้ดูเป็น "งานเทคนิค" แต่ให้เป็นผลลัพธ์ทางธุรกิจที่ชัดเจน จน PM เป็นฝ่ายเอามันไปใส่ใน roadmap เอง วิธีแบบนี้จะยิ่งง่ายขึ้นเมื่อมีประสบการณ์มากขึ้น แม้ตอนแรกคนจะสงสัย แต่เมื่อเวลาผ่านไป ความน่าเชื่อถือในประมาณการและผลงานของผมจะสะสมขึ้น เรื่องที่เมื่อก่อนต้องประชุมหลายรอบ เดี๋ยวนี้อาจจบในบทสนทนา 10 นาที
ผมก็เห็นด้วยกับความเห็นนี้ แต่ก็รู้สึกว่าน่าจะมองกลับด้านได้เหมือนกัน ยกตัวอย่างเช่น ในไซต์ก่อสร้าง ต่อให้มีใครสักคนตรวจสอบและดูแลระบบความปลอดภัยอย่างละเอียดจนป้องกันอุบัติเหตุได้ ฝ่ายบริหารก็มักไม่ยอมรับคุณค่านั้นและไม่ให้รางวัลอยู่ดี การที่ไม่ยอมรับประโยชน์ใด ๆ เลยหากมันไม่ได้แสดงเป็น ROI เชิงปริมาณ ถือเป็นความล้มเหลวครั้งใหญ่ของฝ่ายบริหาร และถ้าความปลอดภัยเกี่ยวข้องกับชีวิตคน ก็ถือเป็นความล้มเหลวทางศีลธรรมด้วย ในความเป็นจริง นี่แหละคือสิ่งที่กำลังเกิดขึ้นกับ Boeing ตอนนี้
ประเด็นคืออธิบายเป็นคุณค่าที่ผู้ฟังเข้าใจได้ ซึ่งสุดท้ายก็คือทักษะการขาย แต่ผมคิดว่านักพัฒนาส่วนใหญ่ไม่มีประสบการณ์และสังเกตเรื่องนี้ได้ยาก ถ้ามีผู้จัดการที่ดีคอยสนับสนุนก็จะดีที่สุด และถ้ามี staff dev หรือ engineering manager ที่คลื่นความคิดตรงกับเราอยู่ด้วย ผลลัพธ์จะดีมากจริง ๆ ผมรู้สึกขอบคุณเสมอเวลาได้ร่วมงานกับเพื่อนร่วมทีมแบบนี้
ถ้าต้องคอยอธิบายความจำเป็นของการล้างมือเพื่อขอให้มีการลงทุน แสดงว่าทีมนั้นมีบางอย่างผิดปกติ เหมือนกับที่เชฟร้านอาหารระดับท็อปไม่จำเป็นต้องถูกโน้มน้าวเรื่อง “จะซื้อสบู่ดีไหม” การได้เข้าไปอยู่ในองค์กรที่สิ่งเหล่านี้เป็นเรื่องปกติ น่าจะเป็นอีกขั้นของอาชีพ คนที่เป็น SWE ที่ประสบความสำเร็จก็คือคนที่ได้ทำงานในทีมที่มีมาตรฐานระดับนั้นเป็นพื้นฐานอยู่แล้ว
เห็นด้วย การรีแฟกเตอร์เป็นความรับผิดชอบตามธรรมชาติของนักพัฒนาอยู่แล้ว ถ้าทำควบคู่ไปกับการพัฒนาฟีเจอร์และอัปเดต timeline ไปพร้อมกัน การสื่อสารก็จะอยู่แค่ในหมู่คนเทคนิคและโน้มน้าวง่ายกว่าเยอะ และในระยะยาวคุณภาพของ codebase จะดีขึ้นแบบก้าวกระโดด ส่งผลให้ดูแลรักษาง่ายขึ้นและพัฒนาฟีเจอร์ใหม่ได้เร็วขึ้น
ทุนทางการเมืองที่มากที่สุดที่ผมสร้างได้คือความเข้าใจและความสามารถด้านเทคนิคของตัวเอง แต่พลังนี้จะมีประโยชน์ก็ต่อเมื่อมันถูกใช้เพื่อให้คำแนะนำและส่งมอบงานจริงภายในบริบทและกลยุทธ์ของทั้งบริษัท ถ้าผมให้คำแนะนำที่เหมาะสมและลงมือทำเพื่อบริษัท ผู้คนก็จะเริ่มฟังและพึ่งพาผม สุดท้ายมันจะกลายเป็นอำนาจที่ทำให้ผมกำหนดทิศทางได้ การเตรียมแผนสำรองด้านการบริหารความเสี่ยงไว้ต่างหาก แล้วเสนอและลงมือทำเมื่อถึงเวลาที่เหมาะสม เป็นวิธีที่ดีที่สุด
มีหนังสือด้านอาชีพเล่มหนึ่งที่ค่อนข้างแรงแต่มีประเด็นที่ดี หนึ่งในนั้นคือ ความสามารถทางเทคนิคอาจกลับมาทำร้ายอาชีพและอำนาจของตัวเองได้ เพราะถ้าผมเอาเวลาและพลังไปใช้ทำงานจริง ผู้จัดการที่เก่งจะพยายามอย่างเต็มที่เพื่อมัดผมไว้กับบทบาทเดิมและไม่เปิดโอกาสให้มีอิทธิพลทางการเมืองมากนัก ในทางกลับกัน ถ้ากลายเป็นผู้จัดการ ก็ไม่ต้องลงมือทำอะไรจริงเลย แค่เริ่ม initiative ให้มากที่สุดเท่าที่จะทำได้ ไม่ว่าจะเป็นโปรเจกต์ นโยบาย หรือการเปลี่ยนแปลง แล้วใช้ทักษะทางการเมืองจัดการมันอย่างคล่องแคล่ว ไม่สำคัญเลยว่า initiative เหล่านั้นจะสร้างคุณค่าจริงได้หรือไม่ และไม่จำเป็นต้องสนใจด้วยซ้ำ เพราะผมออกจากเกมนั้นไปแล้ว ส่วนคนที่ยังมัวหมกมุ่นกับความสำเร็จและคุณค่าจริง ๆ ที่นี่ก็กำลังตามไม่ทัน ถ้าจำเป็น ผู้จัดการก็สามารถมาเก็บเครดิตทีหลังด้วยการพูดว่า ‘นี่เป็นผลงานของฉัน’ ได้
ต้องมีทีมเฉพาะทางที่คอยปรับท่าตาม "flavor of the month" งานถึงจะเดินได้ — นี่คือทฤษฎีการเมืองของผม วอชิงตัน ดี.ซี. ก็เหมือนกัน ไม่มีแผนยักษ์อะไรหรอก แค่มีคนกลุ่มหนึ่งพร้อมยืนรอเพื่อ pitch ทันทีเมื่อโอกาสมาถึง
ถ้าต้องมาฝึกเกมการเมืองและสะสมอำนาจแบบนี้ ก็ถึงเวลาหาบริษัทใหม่แล้ว คุณอาจคิดว่าผมไร้เดียงสา แต่ไม่ใช่ทุกบริษัทจะเป็นแบบนั้น บริษัทของผมไม่เป็นแบบนั้น