ฉันคือวิศวกรสต๊าฟที่ไม่ไล่ตามสปอตไลต์

 (lalitm.com)
1 คะแนน โดย GN⁺ 2025-12-05 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • วัฒนธรรมการพัฒนาแบบเน้นผลิตภัณฑ์ของบริษัทยักษ์ใหญ่ด้านเทคโนโลยี ให้ความสำคัญกับผลลัพธ์ระยะสั้นและการมองเห็นเป็นพิเศษ ในขณะที่ด้าน โครงสร้างพื้นฐานและเครื่องมือสำหรับนักพัฒนา ความต่อเนื่องและการดูแลระบบ กลับเป็นค่านิยมหลัก
  • ผู้เขียนอยู่ในทีม เครื่องมือสำหรับนักพัฒนาและโครงสร้างพื้นฐาน ของ Google และให้ความสำคัญกับ ความเชื่อมั่นและประสิทธิภาพของลูกค้าในฐานะวิศวกร มากกว่าการได้รับความสนใจจากผู้บริหาร
  • การสะสมบริบทและประสบการณ์ผ่าน การดูแลระบบ (stewardship) ระยะยาว ก่อให้เกิดนวัตกรรมให้กับโครงการขนาดใหญ่เช่น Bigtrace
  • แทนที่จะไล่ตามความสว่างไสวระยะสั้น เขาเลือกสะสม ความไว้วางใจและอิทธิพลทางเทคนิค เป็นสินทรัพย์ และรักษา ทุนทางการเมือง เพื่อพูดคำว่า “ไม่” ได้เมื่อมีความจำเป็น
  • แม้ว่าธุรกิจเทคโนโลยีจะหมุนเร็วมาก แต่เส้นทาง ความลึกและความยั่งยืน ก็ยังมีอยู่ และเป็นแบบจำลองทางเลือกในการสร้างอิทธิพลระยะยาว

วิศวกรรมในโลกที่ต่างกัน

  • ทีมผลิตภัณฑ์มีลูกค้าเป็นภายนอกและประเมินผลผ่านตัวชี้วัดระยะสั้นอย่าง รายได้และ MAU
    • ในสภาพแวดล้อมนี้ ความคล่องแคล่วและ การมองเห็นได้ (spotlight) เป็นสิ่งจำเป็นในการดึงดูดความสนใจจากผู้บริหาร
  • ในทางกลับกัน ทีมโครงสร้างพื้นฐานและเครื่องมือสำหรับนักพัฒนาเลือกใช้ วิศวกรภายใน เป็นลูกค้า และสร้าง เครื่องมือและระบบ เพื่อสนับสนุนประสิทธิภาพและการดีบัก
    • ความสนใจจากผู้บริหารมีจำกัด และเนื่องจากโครงสร้างที่รับบุคลากร PM ทำได้ยาก จึงเกิดรูปแบบการดำเนินงานแบบ bottom-up ซึ่งขับเคลื่อนจากวิศวกรเป็นหลัก
    • ทีมสามารถกำหนดปัญหาที่ตนเองจะสร้างผลกระทบสูงสุดได้เอง แล้วแก้ไข ส่วนผู้บริหารทำหน้าที่ตรวจสอบผลกระทบ

อานิสงส์ทบต้นของการดูแล (stewardship)

  • ในโลกผลิตภัณฑ์ ความเร็ว คือสกุลเงินหลัก แต่ในโลกโครงสร้างพื้นฐาน บริบท (context) คือสกุลเงินสำคัญ
    • หากมองวิศวกรว่าเป็นทรัพยากรที่แทนที่ได้ บริบทจะหายไป และความรู้โดยนัยในระบบจะสูญหายตามไปด้วย
  • ประโยชน์แรกของการดูแลระยะยาวคือ ประสิทธิภาพจากการรับรู้รูปแบบ (pattern recognition)
    • หากอยู่กับโดเมนเดิมเป็นเวลานาน คำขอใหม่ย่อมเชื่อมโยงกับกรณีเดิมได้ ทำให้แก้ปัญหาได้เร็วขึ้น
  • ประโยชน์ที่สองคือ นวัตกรรมเชิงระบบ
    • มีเพียงปัญหาบางอย่างที่เปิดเผยต่อเมื่อสังเกตแบบระยะยาวได้ และผลลัพธ์คือ Bigtrace
      • ในต้นปี 2023 ทีมต่าง ๆ ภายใน Google สังเกตว่า หลายทีมไม่สามารถจัดการ ข้อมูลการติดตามประสิทธิภาพขนาดเทราไบต์~เพตะไบต์ ได้
      • หลังจากวิจัยต้นแบบและเก็บข้อเสนอแนะเป็นเวลา 1 ปี จึงสร้าง Bigtrace ในช่วงต้นปี 2024
      • ขณะนี้ระบบรองรับการประมวลผล มากกว่า 2 พันล้าน traces ต่อเดือน และมีผู้ใช้กว่า 100 วิศวกร
    • ถ้าเลือกย้ายโครงการระยะสั้นอย่างต่อเนื่อง Bigtrace ก็อาจไม่เคยเกิดขึ้น

พลังของคำว่า “ไม่”

  • โครงการที่มีการมองเห็นสูง แม้จะดึงทรัพยากรและความสนใจ แต่ก็พามาพร้อมความเสี่ยงด้านความผันผวนทางการเมืองและการลดทอนคุณภาพ
  • ทุนความไว้วางใจที่ก่อตัวจากการดูแลระยะยาว มอบพลังในการปฏิเสธการยึดติดกับสปอตไลต์
    • ตัวอย่างเช่น แม้กระแส AI จะทำให้เกิดคำขอให้ผสาน LLM เข้ากับ Perfetto ผู้เขียนเลือกตอบด้วยความระมัดระวัง โดยยึดถือ ความแม่นยำ (precision) เป็นค่านิยมหลัก
    • ในการดีบักเคอร์เนล เวลาประทับ (timestamp) ที่แม่นยำมีความสำคัญ และไม่สามารถยอมรับความผิดพลาดจากการคาดเดาเกินจริงแบบ hallucination ได้
    • อย่างไรก็ตาม นี่ไม่ใช่ “ปฏิเสธตลอดไป” แต่คือ “รอจนกว่าจะทำได้อย่างถูกต้อง”

สกุลเงินทางเลือกของอิทธิพล

  • เมื่อหลุดออกจากสปอตไลต์ การมองเห็นจากผู้บริหารอาจลดลง แต่จะได้ สกุลเงินทางเลือก ในรูปแบบความเชื่อถือและความมีประโยชน์ทางเทคนิค
  • Shadow Hierarchy (ลำดับชั้นเงา)
    • ในองค์กรโครงสร้างพื้นฐาน สิ่งสำคัญคือการได้รับการยอมรับจาก หัวหน้าหน่วยลูกค้า มากกว่าหัวหน้าทันทีของตน
    • ตัวอย่างเช่น หากทีม Pixel บอกว่า “ไม่สามารถดีบักได้ถ้าไม่มี Perfetto” อิทธิพลดังกล่าวจะส่งผ่านสายการบริหารขึ้นไป
    • นี่คือการสนับสนุนที่ตั้งอยู่บนความไว้วางใจทางเทคนิค ไม่ใช่การเมือง และยังเป็นหลักฐานสำคัญในการประเมินการเลื่อนตำแหน่ง
  • Utility Ledger (บัญชีความคุ้มค่า)
    • Utility: เมื่อเครื่องมือถูกนำไปใช้ระหว่างการแก้บั๊ก จะยืนยันได้ถึงประโยชน์บริสุทธิ์ที่แท้จริง
    • Criticality: เชื่อมโยงโดยตรงกับความสำเร็จของทีมผลิตภัณฑ์หลัก
    • Ubiquity: หลายองค์กรร่วมกันใช้ traces เดียวกันและทำงานร่วมกัน
    • Scale: การประมวลผลข้อมูลระดับเพตะไบต์ยืนยันความแข็งแกร่งของสถาปัตยกรรม
    • การผสานตัวชี้วัดเหล่านี้ช่วยให้สร้าง อิทธิพลที่คงอยู่ต่อเนื่อง ได้ แม้ผ่านการปรับโครงสร้างองค์กร

ประเภทและการเลือกของวิศวกรสต๊าฟ

  • ตามหนังสือ『Staff Engineer』ของ Will Larson ระบุว่าวิศวกรสต๊าฟมีได้หลายประเภท เช่น Solver/Right Hand และ Architect/Tech Lead
    • แบบแรกคือผู้แก้ปัญหาที่ปฏิบัติตามเจตนาผู้บริหาร ส่วนอีกแบบคือเจ้าของความรับผิดชอบระยะยาวในโดเมนเฉพาะ
  • ผู้เขียนจัดตัวเองอยู่กลุ่มหลัง โดยให้ความสำคัญกับ บริบททางเทคนิคที่ลึกและความรับผิดชอบระยะยาว
  • แนวทางนี้มักเกิดได้ในสภาพแวดล้อมองค์กรขนาดใหญ่ที่ทำกำไร และมีทั้ง โชคและการเลือก เข้ามาเกี่ยวข้อง
    • การได้พบทีมที่ดีเป็นเรื่องโชค แต่ การอยู่ทิ้งท้ายเป็นเวลานานและเติบโตสู่บทบาทการเป็นผู้จัดการ คือการเลือก
    • ทีมเหล่านี้อาจไม่เป็นที่รู้จักจากภายนอก แต่ยังคงรักษาพันธกิจระยะยาวและวัฒนธรรมวิศวกรรมที่มั่นคง

บทสรุป

  • อุตสาหกรรมเทคโนโลยีเน้นข้อความว่า “ขยับให้เร็ว” แต่เส้นทางของ ความลึกและความอดทน ก็ยังคงอยู่
  • ไม่จำเป็นต้องไล่ตามสปอตไลต์จึงยังสามารถสร้าง อาชีพที่มีความหมายและอิทธิพล ได้
  • การอยู่กับพื้นที่ปัญหาอย่างยาวนานและสร้าง ระบบที่ยั่งยืน คือทางเลือกที่ทะเยอทะยานที่สุด

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-12-05
ความเห็นจาก Hacker News

  • สิ่งที่ได้เรียนรู้จากการทำงานมากว่า 25 ปีคือ ถ้าเราไม่เป็นเจ้าของเรื่องราวและผลงานของตัวเองโดยตรง ก็จะมีคนอื่นหยิบมันไปแทน
    โดยเฉพาะในบริษัทใหญ่ คนที่เป็นที่นิยมมักแย่งเอาความดีความชอบไปได้บ่อย
    ไม่จำเป็นต้องออกไปรับสปอตไลต์เสมอไป แต่สิ่งสำคัญคือ การทิ้งบันทึกไว้
    ควรทำให้ผลงานที่เรามีส่วนร่วมชัดเจนผ่านเอกสารภายในหรือการนำเสนอภายนอก

    • เรื่องแบบนี้ไม่ได้เกิดแค่ในบริษัทอเมริกัน แต่คล้ายกันในทุกองค์กร
      ถ้าไม่เป็นที่นิยม ต่อให้เป็นทีมเบสบอลก็อาจได้นั่งม้านั่งสำรอง และในระดับบัณฑิตศึกษาหรือคอมมูนิตี้ ML ก็เช่นกัน
      โลกหมุนไปเหมือนเป็นระบบ การแข่งขันด้านความนิยม แบบหนึ่ง
    • เพราะโครงสร้างทางการเมืองแบบนี้ ฉันจึงอยากออกห่างจากชีวิตในบริษัท
      ถ้ามันไม่ใช่แค่โครงสร้างที่ทำงานแล้วได้ผลตอบแทน แต่ต้องมี การโปรโมตตัวเอง เป็นสิ่งจำเป็น ก็สู้ไปเป็นเจ้าของงานของตัวเองและควบคุมมันโดยตรงน่าจะดีกว่า
    • แต่ไม่ใช่ว่าทุกอาชีพจะถูกสร้างจากโปรเจกต์ที่อยู่ใต้สปอตไลต์
      ฉันคิดว่า ความไว้วางใจ คือสกุลเงินที่สำคัญที่สุดในบริษัท
      ถ้าเกี่ยวข้องกับหลายโปรเจกต์ที่ประสบความสำเร็จมาเป็นเวลานาน สุดท้ายฝ่ายผู้นำก็จะมองเห็นจุดร่วมเหล่านั้น
      การเลื่อนขั้นอาจช้า แต่เมื่อ ชื่อเสียงและเครือข่าย สะสมขึ้น ก็จะนำไปสู่การเติบโตที่มั่นคง
    • ใน FAANG พอถึงระดับหนึ่งแล้วถ้าเข้าสู่สภาวะ ‘rest & vest’ ก็จะเลิกใส่ใจปัญหาแบบนี้
      เพราะหาเงินมาได้มากพอแล้ว จึงไม่สนใจ เครดิต
    • ฉันเองก็เคยได้โอกาสหลายครั้งเพราะ ความสัมพันธ์ที่ดี มากกว่าฝีมือ และในทางกลับกันก็เคยเสียประโยชน์เพราะความสัมพันธ์แย่
      ตอนนี้มันค่อนข้างสมดุลแล้ว แต่ดูเหมือนคนส่วนใหญ่จะไม่ได้เป็นแบบนั้น

  • บทความนี้เขียนได้ดีมาก
    อย่าไปโฟกัสแค่น้ำเสียงว่า “ไม่ชอบการเมือง” แต่ควรเข้าใจ โครงสร้างทางการเมืองของ Infra และ DevEx
    ฉันเคยทำงานเป็น PM ด้านอินฟราที่ Slack อยู่ 5 ปี และเพิ่งมาเรียนรู้กระบวนการเปิดตัวโปรดักต์ตอนปีที่ 4
    หัวใจสำคัญคือการช่วยให้ลูกค้าภายใน (วิศวกรฝั่งโปรดักต์) ประสบความสำเร็จ และ ฟีดแบ็กแบบ ‘Shadow Hierarchy’ คือกุญแจของการเลื่อนขั้น
    ถ้าปรับการทำงานเพื่อเพิ่มโอกาสความสำเร็จภายในแบบนี้ ก็จะได้ผลตอบแทนทั้งด้านความมั่นคงและเส้นทางอาชีพ
    แต่ก็ไม่ใช่ สูตรโกง ที่จะใช้ข้ามธรรมชาติของธุรกิจได้

    • แม้แต่ในบริษัทขนาดกลาง โครงสร้างการเมืองภายในและฟีดแบ็ก แบบนี้ก็ทำงานเหมือนกัน

  • ผู้เขียนจับประเด็นเรื่องความต่างของการประเมินผลงานระหว่างวิศวกรรมโปรดักต์กับวิศวกรรมอินฟราได้ดี
    แต่การสรุปภาพรวมจาก สภาพแวดล้อมเฉพาะของ Google ก็ดูไร้เดียงสาไปหน่อย
    ถ้าสภาพตลาดหรือความสำคัญที่ฝ่ายผู้นำให้เปลี่ยนไป คุณค่าที่เราสั่งสมมาก็ต้องถูกนิยามใหม่เช่นกัน

    • ผู้เขียนต้นฉบับก็ตระหนักถึงจุดนั้นอยู่แล้ว
      เขาย้ำว่าบทความของตัวเอง ไม่ใช่คู่มือความสำเร็จแบบใช้ได้ทั่วไป และบอกไว้ว่าสภาพแวดล้อมอื่นต้องใช้กลยุทธ์ที่ต่างออกไป
    • ผู้อ่านอีกคนก็โต้ว่า “ข้อสังเกตแบบนั้นถูกพูดถึงไว้แล้วตอนท้ายบทความ” จึง ไม่ได้ไร้เดียงสา

  • ในบริษัทใหญ่ การประเมินแบบ โหวตความนิยม เป็นเรื่องที่พบได้บ่อย
    หลายครั้งคนถูกประเมินด้วยเกณฑ์คลุมเครืออย่าง “ภาวะผู้นำในคอมมูนิตี้”
    แต่ฉันคิดว่าคุณค่าที่แท้จริงคือการทำงานดี ๆ อย่างเงียบ ๆ และคอยช่วยคนอื่น

    • รู้สึกว่าการหาสมดุลระหว่าง ‘คุณค่าเชิงนามธรรม’ แบบ VC กับ ‘ความหมกมุ่นกับ ROI’ แบบ MBA เป็นเรื่องยาก
    • งานเทคนิคเชิงลึก ที่ไม่ค่อยสะดุดตามักถูกประเมินต่ำเกินไป และถ้าจัดการผิด ระบบทั้งระบบอาจพังได้
    • ทุกวันนี้มี ผู้จัดการที่ประเมินคุณภาพโค้ดไม่ได้ อยู่มาก สุดท้ายจึงตัดสินกันด้วยความนิยม
      วิศวกรเลยติดอยู่ในภาวะกลืนไม่เข้าคายไม่ออกว่าจะเลือกเขียนโค้ดแข็งแรงหรือเลือกโปรโมตตัวเอง
    • ในอดีตจะได้รับคำชมก็ต่อเมื่อแก้ปัญหาได้ ส่วนผลงานที่ทำได้สม่ำเสมอกลับถูกมองว่าเป็นเรื่องปกติ
      สุดท้ายแล้ว การออกแบบแรงจูงใจที่เหมาะสม คือหัวใจของการบริหารองค์กร

  • ในอาชีพตลอด 25 ปีที่ผ่านมา ฉันย้ายบริษัทแทบทุก 2 ปี แต่ที่บริษัทปัจจุบันทำมา 4 ปีแล้ว
    ฉันกำลังสร้างแพลตฟอร์มภายในและ แก้ปัญหาของลูกค้าจริง ซึ่งสิ่งนี้เองที่ทำให้ฉันอยากลุกขึ้นมาทำงานทุกวันโดยไม่เกี่ยวกับเรื่องการเมือง

    • ความสำเร็จแบบ bottom-up เช่นนี้พบได้ไม่บ่อย แต่ถ้าเกิดขึ้นสักครั้งมันจะให้พลังอย่างมหาศาล

  • ฉันอยู่ทีมเดียวมานานในฐานะวิศวกรอินฟราและทูลลิง และสิ่งที่บทความนี้พูดก็ตรงกับความจริงมาก
    บางครั้งก็มีผลงานที่ได้มาง่าย ๆ อยู่บ้าง แต่ส่วนใหญ่คือ งานเทคนิคประจำวันแบบนิ่ง ๆ และน่าพอใจ

  • ฉันเองก็ชอบทำงานในทีมอินฟรามากกว่าทีมโปรดักต์
    มันเป็นอิสระจากความเปลี่ยนใจของฝ่ายผู้นำ และทำให้โฟกัสกับ ความสมบูรณ์ทางเทคนิค ได้
    ตอนนี้ฉันมีความสุขกับการค่อย ๆ ปรับปรุงอินฟราของทีมอื่นอย่างเงียบ ๆ ในบริษัทขนาดกลางแห่งหนึ่ง

  • การที่ต้องออกมาเขียนอะไรแบบนี้เพื่อปกป้องคุณค่าของตัวเอง ก็ ไม่ใช่สัญญาณที่ดีนัก อยู่แล้ว
    แน่นอนว่าการโปรโมตตัวเองและคาริสม่าช่วยให้เลื่อนขั้นได้ง่ายขึ้น แต่ก็ไม่จำเป็นต้องทำถึงขั้นทำให้โลกแย่ลง
    เรายังต้องการ คนที่ตั้งใจทำงานเงียบ ๆ แบบ Wozniak ด้วย

  • ที่ผู้เขียนหลบเลี่ยงสปอตไลต์ได้ เป็นเพราะเขา เป็น Staff Engineer อยู่แล้ว
    ตอนอยู่สตาร์ตอัป เขาได้รับความไว้วางใจจึงไม่จำเป็นต้องแสดงตัวมากนัก แต่ใน BigTech การเมืองหนักกว่ามาก
    ฉันเคยตั้งเป้าว่าจะเข้าไปหาเงินแล้วออกมาในระยะสั้น แต่สิ่งที่ยากกว่าคือ การช่วยให้อินเทิร์นรุ่นน้องได้รับการยอมรับ
    ตอนนี้ตัวโปรเจกต์ของฉันเองให้ visibility อยู่แล้ว จึงไม่จำเป็นต้องโปรโมตมันเพิ่ม

    • แต่ก็มีคนอื่นที่ไม่เห็นด้วยกับเรื่องนี้
      เขาบอกว่าตอนอยู่ Google ตั้งแต่ระดับ L3 เขาก็ไม่เคยไล่ตามสปอตไลต์ และยังได้รับการยอมรับเพียงพอผ่าน การแบ่งปันและการร่วมมือกับวิศวกรคนอื่น

  • ถ้ามี ทุนเพียงพอ (ไม่ว่าจะเป็นทางสังคมหรือทางการเงิน) ก็จะประคองตัวได้ 3 ปี และถ้าปีที่ 2 เริ่มมีผลงาน ความผิดพลาดช่วงแรก ๆ ก็จะถูกลืมไป
    ปัญหาคือ ความเสี่ยงตอนที่เราคิดผิด

    • อีกความเสี่ยงหนึ่งคือ ต่อให้คุณป้องกันปัญหาใหญ่ไว้ล่วงหน้า ก็อาจไม่มีใครรู้คุณค่าของมันเลย
      ต่อให้พยายามเพื่อให้ออกรีลีสแบบไม่มีบั๊ก สุดท้ายคนที่ได้คำชมกลับเป็น คนที่ทำโอทีเพื่อแก้ปัญหา
    • แต่ถ้าคุยกับลูกค้าให้มากพอและเข้าใจบริบทของตลาด ก็ ลดความเสี่ยงได้
      แน่นอนว่าโชคก็มีส่วน แต่ฉันเชื่อว่าโอกาสจะมาหาคนที่เตรียมตัวพร้อม