Staff Engineer vs Engineering Manager

xguru · 2025-04-08T11:13:01+09:00

Staff Engineer จำเป็นเมื่อใด และแตกต่างจาก Engineering Manager อย่างไร? วิศวกรและผู้จัดการจำนวนมากยังสับสนกับสองบทบาทนี้ ทั้ง EM ที่อยากหลีกเลี่ยงการบริหารคนและโฟกัสด้านเทคนิค หรือ Senior Engineer ที่อยากรับบทผู้นำทางเทคนิค ต่างก็มีคำถามนี้อยู่ สิ่งสำคัญคือการเข้าใจความรับผิดชอบและขอบเขตของแต่ละบทบาทให้ชัดเจน คำถามที่ฉันเคยได้รับ EM: "ผมอยากโฟกัสด้านเทคนิคแทนการบริหารคน Staff Engineer จะเหมาะกับผมหรือเปล่า?" Senior EM: "งานบริหารมีมากเกินไป ผมควรจ้าง Staff Engineer มารับงานด้านเทคนิคไหม?" Staff Engineer: "ตอนนี้ผมทำหน้าที่เหมือนผู้จัดการทีมอยู่จริง ๆ และก็ชอบมันดี ควรเปลี่ยนไปเป็น EM ไหม?" Senior Engineer: "ความรับผิดชอบของ Staff Engineer คืออะไร? มันดูเหมือนนักพัฒนาที่เกษียณแล้วเลย" New Staff Engineer: "‘โครงสร้างการรายงานแบบเส้นประ’ คืออะไร? ผมมี line manager อยู่แล้ว ยังต้องสนใจผู้จัดการคนอื่นอีกไหม?" Staff Engineer จำเป็นเมื่อใด? วิศวกรสร้างและดูแลเทคโนโลยี แต่เทคโนโลยีไม่ได้อยู่โดดเดี่ยวเพียงลำพัง มันคือโซลูชันของปัญหา และปัญหานั้นถูกนิยามผ่าน ผลิตภัณฑ์ ผลิตภัณฑ์ให้บริการแก่ผู้ใช้ปลายทางหรือลูกค้าภายในองค์กร ผลิตภัณฑ์คือ เครื่องมือ ในการแก้ปัญหาของผู้ใช้ ตัวอย่างเช่น: แอปที่วัดระยะการวิ่งและแชร์กับผู้ใช้อื่นได้ เว็บไซต์จองโรงแรม แพลตฟอร์มโครงสร้างพื้นฐานที่ทีมอื่นใช้งาน ระบบรายงานเวลาเข้างาน วิศวกรที่พัฒนาผลิตภัณฑ์เหล่านี้โดยทั่วไปจะอยู่ในทีมที่นำโดย Engineering Manager (EM) EM มี accountability ต่อทั้งสมาชิกในทีม (วิศวกร) และ ผลลัพธ์ทางเทคนิค (artifacts) ที่พวกเขาสร้างขึ้น แต่ในกรณีต่อไปนี้ การรับผิดชอบทุกอย่างให้ครบถ้วนทำได้ยาก: เมื่อทีมมีขนาดใหญ่มาก เมื่อเทคโนโลยีมีความซับซ้อนสูง หรือเมื่อทั้งสองอย่างเกิดขึ้นพร้อมกัน ในกรณีนี้ เวลาและพลังงาน (bandwidth) ของ EM จะไม่เพียงพอ และทำให้ยากต่อการรับผิดชอบทั้งเรื่องคนและเทคโนโลยีได้อย่างสมบูรณ์ หาก EM ทำหน้าที่รับผิดชอบได้ไม่เต็มที่ อาจพิจารณา กลยุทธ์การมอบหมาย 2 แบบ: การมอบหมายงานธุรการ: ปรับปรุงกระบวนการและเครื่องมือ HR ให้ดีขึ้น หรือ จ้างผู้ช่วยเพื่อลดภาระการบริหารคน อาจรู้สึกว่าให้ผู้ช่วยประจำทีมเดียวดูมากเกินไป แต่ก็มีกรณีที่หลายทีมแชร์ผู้ช่วยคนเดียวกัน ใช้เครื่องมือ AI ช่วยแทนงานเชิงกลบางส่วน เช่น การจัดตาราง การตอบคำถามด้านการจัดการ หรือการเก็บ feedback ระบบ HR ที่ดีสามารถลดภาระการจัดการได้อย่างมาก การมอบหมายงานเทคนิค: สามารถจ้าง Staff Engineer มาช่วยแบ่งภาระด้านเทคนิคได้ อย่างไรก็ตาม ผู้ช่วยหรือ AI ไม่สามารถแทนที่ งานที่ยึดโยงกับผู้คน ซึ่งเป็นความรับผิดชอบหลักของ EM ได้ เช่น: การสร้างทีมที่ดี การทำ mentoring การประเมินผลงาน การสรรหาบุคลากร เป็นต้น อีกด้านหนึ่ง การ โยนงานเทคนิคทั้งหมดให้ Staff Engineer ถือเป็น anti-pattern Staff Engineer ไม่ควรทำหน้าที่เป็น ล่ามทางเทคนิค ให้ EM EM ควรรักษาระดับความรับผิดชอบด้านเทคนิคไว้ให้ได้ในระดับหนึ่ง ดังนั้น Engineering Manager จำเป็นต้องรักษา technical sense ของตนไว้ และ สำหรับวิธีรักษาความสามารถทางเทคนิคของผู้นำ ดู How can engineer leaders stay technical? สถานการณ์ที่ Staff Engineer มีประโยชน์ Staff Engineer สามารถสร้าง คุณค่าที่จับต้องได้ ให้กับองค์กรได้ในกรณีต่อไปนี้: เมื่อมี ภาระทางเทคนิคที่ EM รับไม่ไหว เช่น มีเทคโนโลยี legacy จำนวนมากและต้องบำรุงรักษาอย่างต่อเนื่อง มีโซลูชันซับซ้อนที่ข้ามหลายทีมหรือจำเป็นต้องใช้ความรู้เชิงลึกด้านเทคนิค หรือแม้แต่กรณีที่ EM เองไม่ค่อยมีพื้นฐานด้านเทคนิค (แม้จะไม่ใช่รูปแบบที่แนะนำ) เมื่อสามารถมอบ accountability ที่ชัดเจนให้กับงานเทคนิคบางส่วนได้ เมื่อขอบเขตของเทคโนโลยี เกินกว่าที่ EM คนเดียวจะดูแลไหว Staff Engineer ควร รับผิดชอบต่อเทคโนโลยี ไม่ใช่ต่อคน จึงไม่รวมถึงการดูแลสมาชิกในทีม หรือการประเมินผลงาน สถานการณ์จะแตกต่างกันไปตามองค์กร ผลิตภัณฑ์ และผู้คน จึง ไม่สามารถใช้สูตรเดียวกับทุกกรณีได้ หมายเหตุ: responsibility และ accountability เป็นแนวคิดที่ต่างกันอย่างละเอียดอ่อน ดูความแตกต่างได้ที่ Accountable vs Responsible Staff Engineer ควรมีคุณลักษณะดังต่อไปนี้: มี ความเข้าใจทางเทคนิคอย่างลึกซึ้ง และ technical literacy ในระดับสูง มี accountability ทางเทคนิค ที่ชัดเจน เพราะไม่มีภาระการบริหารคน จึงมี เวลาสำหรับการลงทุนทางเทคนิค มากกว่า ในทางกลับกัน EM ก็ไม่ควรถอนตัวออกจากความรับผิดชอบด้านเทคนิคทั้งหมด ยังจำเป็นต้องมีส่วนร่วมและเข้าใจเทคโนโลยีในระดับหนึ่ง คุณค่าที่แท้จริงของ Staff Engineer มาจาก ภาวะผู้นำทางเทคนิคที่ครอบคลุมหลายทีม หากวาง Staff Engineer ไว้ภายในทีมเดียว อาจเกิดปัญหาดังนี้: ความรับผิดชอบด้านเทคนิคซ้ำซ้อน บทบาทสับสน และสุดท้ายกลายเป็นการแยกบทบาทเดียวออกเป็นหลายตำแหน่งอย่างไม่มีประสิทธิภาพ อ่านเพิ่มเติมได้ที่ Breaking a role to multiple titles กรณียกเว้นที่สามารถทำงานในระดับทีมได้ โดยทั่วไป Staff Engineer จะโฟกัสที่ภาวะผู้นำทางเทคนิคข้ามทีม แต่ ในบางสถานการณ์ก็อาจทำงานในระดับทีมได้ชั่วคราว เช่น: เมื่อ EM คนใหม่ต้องทำความเข้าใจกับ legacy tech stack อย่างรวดเร็ว เมื่อ Staff Engineer คนใหม่กำลัง onboard โดยเริ่มจากขอบเขตเล็ก ๆ เมื่อมี technical debt มากเกินไปจนตัวชี้วัดสุขภาพระบบแย่ลง เมื่อความซับซ้อนทางเทคนิคทำให้การบำรุงรักษาเป็นเรื่องยาก ในกรณีนี้ Staff Engineer ระดับทีมควรเป็นโครงสร้างชั่วคราว คุณค่าที่แท้จริงของ Staff Engineer ทำหน้าที่เป็น ตัวเชื่อมระหว่างทีม (glue) ทำงานร่วมกับวิศวกรในแนวหน้าโดยตรง และส่งต่อเสียงของพวกเขาไปยังฝ่ายบริหาร โดยปกติวิศวกรมักจะ คุยอย่างตรงไปตรงมากับเพื่อนวิศวกร มากกว่ากับคนที่มีอำนาจเรื่องเงินเดือน วันลา หรือการประเมิน ทำหน้าที่เป็น ผู้นำทางเทคนิคเชิงลึก ต่างจาก EM ที่มีประชุม, 1:1 และงานบริหารจำนวนมาก จึง สามารถโฟกัสการพัฒนาความสามารถทางวิศวกรรมและความลึกทางเทคนิคได้มากกว่า ความเสี่ยงใหญ่ที่สุด: Ivory Tower Architect กลายเป็น นักทฤษฎีนามธรรม ที่ห่างไกลจากปัญหาจริงและจากโค้ด ประเด็นนี้อธิบายไว้อย่างละเอียดใน Ivory Tower Architect บทบาทของ Staff Engineer สำหรับระบบที่ครอบคลุมหลายทีม Staff Engineer เหมาะที่สุดกับภาวะผู้นำทางเทคนิคที่ครอบคลุม ทั้งระบบ ไม่ใช่แค่ทีมเดียว ใน บทความของ Will Larson ได้เสนอ 4 archetypes ของ Staff Engineer: Tech Lead: ผู้นำทางเทคนิคภายในทีม Architect: ผู้ออกแบบสถาปัตยกรรมระบบ Solver: ผู้แก้ปัญหาทางเทคนิคที่ซับซ้อน Right Hand: มือขวาที่ช่วยสนับสนุนผู้นำองค์กรด้านเทคนิค การเรียก Tech Lead ในทีมจากแผนภาพนั้นว่า Staff Engineer อาจไม่แม่นนัก คุณค่าที่แท้จริงของ Staff Engineer อยู่ที่การประสานงานข้ามทีมและการบูรณาการทางเทคนิค ดู Introduction to Staff Engineering Staff Engineer ไม่ใช่เพียงตำแหน่งงาน แต่เป็นแนวทางที่ตั้งอยู่บนภาวะผู้นำทางเทคนิค บทบาทนี้รับผิดชอบการประสานงานทางเทคนิคและการแก้ปัญหาครอบคลุมหลายทีมและหลายผลิตภัณฑ์ สามารถสร้างอิทธิพลได้แม้ไม่มีอำนาจอย่างเป็นทางการต่อคนหรือผลิตภัณฑ์ ขับเคลื่อนกลยุทธ์และทิศทางทางเทคนิคของทั้งองค์กร ต่างจาก Engineering Manager ตรงที่สร้างคุณค่าผ่านความเชี่ยวชาญเชิงเทคนิคอย่างลึกซึ้งและการทำงานร่วมกันข้ามองค์กร มากกว่างานบริหารจัดการ ลงมือทำงานจริงอย่างใกล้ชิด และยังทำหน้าที่เป็น mentor ช่วยให้วิศวกรคนอื่นเติบโต ในองค์กรจริง ระบบเทคนิคมักไม่ได้จำกัดอยู่ในทีมเดียว แต่ กระจายอยู่หลายทีมหรือเชื่อมโยงกันอย่างแน่นแฟ้น ในกรณีนี้จำเป็นต้องมี Staff Engineer ที่รับผิดชอบทั้งระบบโดยเฉพาะ ต้องมีทั้ง มุมมองและ sense of accountability ต่อภาพรวมของระบบทั้งหมด โดยไม่ขึ้นกับว่าแต่ละทีมดูแลส่วนไหน Staff Engineer ต้องผ่านทั้งเรื่องคนและผลิตภัณฑ์ ไม่ใช่แค่เทคโนโลยี ประเด็นสำคัญ: เทคโนโลยี (tech) ไม่ได้คุยหรือรับฟังใครด้วยตัวมันเอง เทคโนโลยีไม่สามารถมีความหมายได้ด้วยตัวมันเอง แต่มีความหมายผ่าน ผู้คน (วิศวกร) และ ผลิตภัณฑ์ (ปัญหา) หาก Staff Engineer จะสร้างคุณค่าที่แท้จริง ต้องผ่านสิ่งต่อไปนี้เสมอ: ทำงานร่วมกับวิศวกร หารือกับทีมผลิตภัณฑ์ ด้วยเหตุนี้ Staff Engineer จึงมี โครงสร้างการรายงานแบบ dotted reporting lines แม้ไม่เป็นทางการ แต่เป็น จุดเชื่อมสำคัญของการทำงานข้ามองค์กรและพันธสัญญาร่วมกัน บางคนที่ช่างสังเกตอาจถามว่าทำไมลูกศรจาก Staff ถึงชี้ลงไปยังตำแหน่งที่ต่ำกว่า เหตุผลที่ 1: ภาวะผู้นำที่ดีตั้งอยู่บนความร่วมมือ ไม่ใช่อำนาจ Staff Engineer ส่ง คำขอเพื่อการปรับปรุงทางเทคนิค ไปยัง EM หรือ PM ระดับทีมด้วยวิธีแบบร่วมมือกัน ไม่ใช่การสั่งการแบบเบ็ดเสร็จ แต่เป็น การทำงานร่วมกันโดยคำนึงถึงวิศวกรและ product roadmap เหตุผลที่ 2: Staff Engineer เป็น IC (Individual Contributor) จึงไม่มีลูกน้องสายตรงอย่างเป็นทางการ หากมี ช่องทางสนทนาอย่างสม่ำเสมอ กับ EM/PM จุดประสงค์ไม่ควรเป็นแค่การรายงาน แต่ควรเป็นการคุยสองทางเกี่ยวกับ: สถานะปัจจุบันของเทคโนโลยี (status quo) วิสัยทัศน์ทางเทคนิค (vision) เพื่อแก้ปัญหาผลิตภัณฑ์ กลยุทธ์ทางเทคนิคขององค์กร (strategy) เพื่อให้เกิดสิ่งนั้น และในทั้งสามเรื่องนี้ ควรเป็นบทสนทนาแบบสองทาง เพื่อจัดระเบียบโครงสร้างการรายงานที่ซับซ้อนเช่นนี้ และช่วยให้เทคนิค/ผลิตภัณฑ์สอดประสานกันข้ามทีม เอกสารกลยุทธ์ระดับองค์กร (strategy document) มีประโยชน์มาก พื้นฐานของเรื่องนี้ดูได้ที่ Strategy basics Diagnosis ศึกษาพื้นที่ของปัญหา แล้วระบุประเด็นหลักที่ต้องแก้และเหตุผลว่าทำไม อธิบายว่าเหตุใดจึงต้องมีกลยุทธ์ ระบุทั้งอาการและรากของปัญหา พร้อมวิเคราะห์ว่าทำไมสิ่งเหล่านี้จึงสำคัญในตอนนี้ ในกลยุทธ์ที่ไม่ดี ส่วนนี้มักถูกละไว้หรือมีเพียงคำอธิบายสถานะปัจจุบัน การวินิจฉัยที่ดีต้องอาศัย การสำรวจอย่างเป็นกลางและท่าทีแบบนักสืบ Guiding Policy เป็น แนวทางระดับสูง สำหรับแก้ปัญหาที่ระบุไว้ โฟกัสที่แนวทางแก้และทำให้องค์กรทั้งองค์กรไปในทิศทางเดียวกัน ช่วยกำหนดทิศทางโดยไม่ต้องกลับมาคิดใหม่ในทุกรายละเอียดเชิงยุทธวิธี กลยุทธ์ที่ไม่ดีมักขาดการเชื่อมโยงระหว่างนโยบายนี้ (HOW) กับการวินิจฉัย (WHY) Coherent Actions คือ แผนปฏิบัติการที่เป็นรูปธรรม เพื่อแก้ปัญหาตามการวินิจฉัยภายใต้นโยบายที่กำหนด ระบุให้ชัดว่าใคร (WHO) จะทำอะไร (WHAT) เมื่อไร (WHEN) หัวใจสำคัญคือ “ความสอดคล้อง” เพื่อให้หลายทีมเดินไปในทิศทางเดียวกันอย่างกลมกลืน อีกวิธีในการลดขอบเขตทางเทคนิคให้เหลือในทีมเดียว: โมเดล Kebab vs Cake องค์กรยังสามารถออกแบบโครงสร้างให้เทคโนโลยีไม่ต้องกระจายข้ามหลายทีม แต่ ถูกแก้และดูแลภายในทีมเดียว ได้เช่นกัน ตัวอย่างที่เด่นชัดคือ โมเดล Kebab vs Cake เป็นแนวทางเชิงโครงสร้างที่จัดทีมตาม customer journey เพื่อ ลดขอบเขตความรับผิดชอบทางเทคนิค อ่านรายละเอียดเพิ่มเติมได้ที่ Kebab vs Cake organization สถาปัตยกรรมแบบ Kebab ทีมถูกจัดตามฟังก์ชันที่ให้บริการ user journey พาดผ่านผลลัพธ์ของหลายทีม ข้อดี: ความเป็นอิสระและ loose coupling ข้อเสีย: มีความเสี่ยงที่จะเกิด handover สถาปัตยกรรมแบบ Cake ทีมถูกจัดตาม user journey จัดการ cognitive load ผ่าน abstraction layers ข้อดี: ความเป็นเจ้าของแบบ end-to-end และลด handover ข้อเสีย: มีความเสี่ยงที่ cognitive load จะสูงขึ้น Staff Engineer ไม่ใช่แค่บทบาททางเทคนิคธรรมดา แต่เป็น owner ที่รับผิดชอบระบบโดยรวม และควรมี 3 สิ่งต่อไปนี้: Knowledge: เข้าใจทั้ง tech stack และปัญหาของผลิตภัณฑ์อย่างลึกซึ้ง เมื่อต้องการควรสามารถอธิบายและลงมือ implement ได้เอง Mandate: อยู่ในตำแหน่งที่สามารถออกความเห็นได้ว่าเทคโนโลยีควรพัฒนาและดูแลอย่างไร Responsibility: รับผิดชอบต่อสุขภาพของระบบ เช่น incident, technical debt, documentation, technical disconnect เป็นต้น Staff Engineer ไม่ใช่บทบาททางเทคนิคเพียว ๆ และ soft skills เป็นสิ่งจำเป็น สำหรับการขับเคลื่อนองค์กรในเชิงเทคนิค ต้องมีทั้งการสื่อสารอย่างมีอิทธิพล ความสามารถในการร่วมงานกับผู้อื่น และภาวะผู้นำ แต่หาก เอนเอียงไปที่ soft skills อย่างเดียว ก็จะเกิดปัญหาได้ เช่น นำเสนอแต่ภาพอุดมคติที่ห่างไกลจากความจริง และไม่ลงมือร่วมเขียนโค้ดหรือแก้ปัญหาจริง เสี่ยงจะกลายเป็น Ivory Tower Architect สรุปส่งท้าย ไม่ใช่ทุกองค์กรที่จำเป็นต้องมี Staff Engineer และในกรณีต่อไปนี้ก็อาจไม่มีได้: เมื่อ EM มีความสามารถทางเทคนิคเพียงพอ และสามารถนำทีมด้านเทคนิคได้ด้วยตัวเอง เมื่อ tech stack อยู่ในสภาพที่ดีและดูแลง่าย เมื่อเทคโนโลยี จบครบภายในทีมเดียว และแทบไม่มีการพึ่งพาข้ามทีม (เช่นในโมเดลการจัดองค์กรแบบ Cake) เมื่อองค์กรมีวุฒิภาวะมากพอจน สามารถดูแลทั้งระบบได้ดีแม้ไม่มี owner เฉพาะ ในทางกลับกัน หากองค์กรมี Staff Engineer ก็ควรทำให้ชัดเจนว่า: ต้องกำหนด technical ownership ให้ชัด และมอบ accountability ที่ชัดเจน ให้ Staff Engineer สำหรับความรับผิดชอบนั้น สรุปประเด็นสำคัญ: ควร หลีกเลี่ยง Ivory Tower Architect (เพราะไม่ยึดโยงกับความเป็นจริง) การแยกบทบาทเดียวออกเป็นหลายตำแหน่ง เป็นเรื่องไม่มีประสิทธิภาพ EM ที่ไม่เข้าใจเทคนิค ก็ไม่มีประสิทธิภาพเช่นกัน สุดท้าย บทความนี้ไม่ใช่กฎตายตัว แต่เป็น essay เพื่อใช้อ้างอิง องค์กร เทคโนโลยี ผลิตภัณฑ์ การปฏิบัติงาน และผู้คน ล้วนแตกต่างกัน จึง ต้องใช้วิจารณญาณอย่างยืดหยุ่นตามบริบท หลีกเลี่ยงการลอกเลียนแบบโดยไม่เข้าใจบริบท (cargo culting) → ดูบทความที่เกี่ยวข้อง

(blog.alexewerlof.com)

31 คะแนน โดย xguru 2025-04-08 | 4 ความคิดเห็น | แชร์ทาง WhatsApp

Staff Engineer จำเป็นเมื่อใด และแตกต่างจาก Engineering Manager อย่างไร?
- วิศวกรและผู้จัดการจำนวนมากยังสับสนกับสองบทบาทนี้
ทั้ง EM ที่อยากหลีกเลี่ยงการบริหารคนและโฟกัสด้านเทคนิค หรือ Senior Engineer ที่อยากรับบทผู้นำทางเทคนิค ต่างก็มีคำถามนี้อยู่
สิ่งสำคัญคือการเข้าใจความรับผิดชอบและขอบเขตของแต่ละบทบาทให้ชัดเจน

คำถามที่ฉันเคยได้รับ

EM: "ผมอยากโฟกัสด้านเทคนิคแทนการบริหารคน Staff Engineer จะเหมาะกับผมหรือเปล่า?"
Senior EM: "งานบริหารมีมากเกินไป ผมควรจ้าง Staff Engineer มารับงานด้านเทคนิคไหม?"
Staff Engineer: "ตอนนี้ผมทำหน้าที่เหมือนผู้จัดการทีมอยู่จริง ๆ และก็ชอบมันดี ควรเปลี่ยนไปเป็น EM ไหม?"
Senior Engineer: "ความรับผิดชอบของ Staff Engineer คืออะไร? มันดูเหมือนนักพัฒนาที่เกษียณแล้วเลย"
New Staff Engineer: "‘โครงสร้างการรายงานแบบเส้นประ’ คืออะไร? ผมมี line manager อยู่แล้ว ยังต้องสนใจผู้จัดการคนอื่นอีกไหม?"

Staff Engineer จำเป็นเมื่อใด?

วิศวกรสร้างและดูแลเทคโนโลยี แต่เทคโนโลยีไม่ได้อยู่โดดเดี่ยวเพียงลำพัง
มันคือโซลูชันของปัญหา และปัญหานั้นถูกนิยามผ่าน ผลิตภัณฑ์
ผลิตภัณฑ์ให้บริการแก่ผู้ใช้ปลายทางหรือลูกค้าภายในองค์กร
ผลิตภัณฑ์คือ เครื่องมือ ในการแก้ปัญหาของผู้ใช้ ตัวอย่างเช่น:
- แอปที่วัดระยะการวิ่งและแชร์กับผู้ใช้อื่นได้
- เว็บไซต์จองโรงแรม
- แพลตฟอร์มโครงสร้างพื้นฐานที่ทีมอื่นใช้งาน
- ระบบรายงานเวลาเข้างาน
วิศวกรที่พัฒนาผลิตภัณฑ์เหล่านี้โดยทั่วไปจะอยู่ในทีมที่นำโดย Engineering Manager (EM)
EM มี accountability ต่อทั้งสมาชิกในทีม (วิศวกร) และ ผลลัพธ์ทางเทคนิค (artifacts) ที่พวกเขาสร้างขึ้น
แต่ในกรณีต่อไปนี้ การรับผิดชอบทุกอย่างให้ครบถ้วนทำได้ยาก:
- เมื่อทีมมีขนาดใหญ่มาก
- เมื่อเทคโนโลยีมีความซับซ้อนสูง
- หรือเมื่อทั้งสองอย่างเกิดขึ้นพร้อมกัน
ในกรณีนี้ เวลาและพลังงาน (bandwidth) ของ EM จะไม่เพียงพอ และทำให้ยากต่อการรับผิดชอบทั้งเรื่องคนและเทคโนโลยีได้อย่างสมบูรณ์
หาก EM ทำหน้าที่รับผิดชอบได้ไม่เต็มที่ อาจพิจารณา กลยุทธ์การมอบหมาย 2 แบบ:
- การมอบหมายงานธุรการ:
  - ปรับปรุงกระบวนการและเครื่องมือ HR ให้ดีขึ้น หรือ
  - จ้างผู้ช่วยเพื่อลดภาระการบริหารคน
  - อาจรู้สึกว่าให้ผู้ช่วยประจำทีมเดียวดูมากเกินไป แต่ก็มีกรณีที่หลายทีมแชร์ผู้ช่วยคนเดียวกัน
  - ใช้เครื่องมือ AI ช่วยแทนงานเชิงกลบางส่วน เช่น การจัดตาราง การตอบคำถามด้านการจัดการ หรือการเก็บ feedback
  - ระบบ HR ที่ดีสามารถลดภาระการจัดการได้อย่างมาก
- การมอบหมายงานเทคนิค:
  - สามารถจ้าง Staff Engineer มาช่วยแบ่งภาระด้านเทคนิคได้
อย่างไรก็ตาม ผู้ช่วยหรือ AI ไม่สามารถแทนที่ งานที่ยึดโยงกับผู้คน ซึ่งเป็นความรับผิดชอบหลักของ EM ได้ เช่น:
- การสร้างทีมที่ดี
- การทำ mentoring
- การประเมินผลงาน
- การสรรหาบุคลากร เป็นต้น
อีกด้านหนึ่ง การ โยนงานเทคนิคทั้งหมดให้ Staff Engineer ถือเป็น anti-pattern
- Staff Engineer ไม่ควรทำหน้าที่เป็น ล่ามทางเทคนิค ให้ EM
- EM ควรรักษาระดับความรับผิดชอบด้านเทคนิคไว้ให้ได้ในระดับหนึ่ง
ดังนั้น Engineering Manager จำเป็นต้องรักษา technical sense ของตนไว้ และ
- สำหรับวิธีรักษาความสามารถทางเทคนิคของผู้นำ ดู How can engineer leaders stay technical?

สถานการณ์ที่ Staff Engineer มีประโยชน์

Staff Engineer สามารถสร้าง คุณค่าที่จับต้องได้ ให้กับองค์กรได้ในกรณีต่อไปนี้:
- เมื่อมี ภาระทางเทคนิคที่ EM รับไม่ไหว
  - เช่น มีเทคโนโลยี legacy จำนวนมากและต้องบำรุงรักษาอย่างต่อเนื่อง
  - มีโซลูชันซับซ้อนที่ข้ามหลายทีมหรือจำเป็นต้องใช้ความรู้เชิงลึกด้านเทคนิค
  - หรือแม้แต่กรณีที่ EM เองไม่ค่อยมีพื้นฐานด้านเทคนิค (แม้จะไม่ใช่รูปแบบที่แนะนำ)
- เมื่อสามารถมอบ accountability ที่ชัดเจนให้กับงานเทคนิคบางส่วนได้
- เมื่อขอบเขตของเทคโนโลยี เกินกว่าที่ EM คนเดียวจะดูแลไหว
Staff Engineer ควร รับผิดชอบต่อเทคโนโลยี ไม่ใช่ต่อคน
- จึงไม่รวมถึงการดูแลสมาชิกในทีม หรือการประเมินผลงาน
สถานการณ์จะแตกต่างกันไปตามองค์กร ผลิตภัณฑ์ และผู้คน จึง ไม่สามารถใช้สูตรเดียวกับทุกกรณีได้
หมายเหตุ: responsibility และ accountability เป็นแนวคิดที่ต่างกันอย่างละเอียดอ่อน
- ดูความแตกต่างได้ที่ Accountable vs Responsible
Staff Engineer ควรมีคุณลักษณะดังต่อไปนี้:
- มี ความเข้าใจทางเทคนิคอย่างลึกซึ้ง และ technical literacy ในระดับสูง
- มี accountability ทางเทคนิค ที่ชัดเจน
- เพราะไม่มีภาระการบริหารคน จึงมี เวลาสำหรับการลงทุนทางเทคนิค มากกว่า
ในทางกลับกัน EM ก็ไม่ควรถอนตัวออกจากความรับผิดชอบด้านเทคนิคทั้งหมด
- ยังจำเป็นต้องมีส่วนร่วมและเข้าใจเทคโนโลยีในระดับหนึ่ง
คุณค่าที่แท้จริงของ Staff Engineer มาจาก ภาวะผู้นำทางเทคนิคที่ครอบคลุมหลายทีม
หากวาง Staff Engineer ไว้ภายในทีมเดียว อาจเกิดปัญหาดังนี้:
- ความรับผิดชอบด้านเทคนิคซ้ำซ้อน
- บทบาทสับสน และสุดท้ายกลายเป็นการแยกบทบาทเดียวออกเป็นหลายตำแหน่งอย่างไม่มีประสิทธิภาพ
  - อ่านเพิ่มเติมได้ที่ Breaking a role to multiple titles

กรณียกเว้นที่สามารถทำงานในระดับทีมได้

โดยทั่วไป Staff Engineer จะโฟกัสที่ภาวะผู้นำทางเทคนิคข้ามทีม แต่ ในบางสถานการณ์ก็อาจทำงานในระดับทีมได้ชั่วคราว เช่น:
- เมื่อ EM คนใหม่ต้องทำความเข้าใจกับ legacy tech stack อย่างรวดเร็ว
- เมื่อ Staff Engineer คนใหม่กำลัง onboard โดยเริ่มจากขอบเขตเล็ก ๆ
- เมื่อมี technical debt มากเกินไปจนตัวชี้วัดสุขภาพระบบแย่ลง
- เมื่อความซับซ้อนทางเทคนิคทำให้การบำรุงรักษาเป็นเรื่องยาก
ในกรณีนี้ Staff Engineer ระดับทีมควรเป็นโครงสร้างชั่วคราว
คุณค่าที่แท้จริงของ Staff Engineer
- ทำหน้าที่เป็น ตัวเชื่อมระหว่างทีม (glue)
- ทำงานร่วมกับวิศวกรในแนวหน้าโดยตรง และส่งต่อเสียงของพวกเขาไปยังฝ่ายบริหาร
  - โดยปกติวิศวกรมักจะ คุยอย่างตรงไปตรงมากับเพื่อนวิศวกร มากกว่ากับคนที่มีอำนาจเรื่องเงินเดือน วันลา หรือการประเมิน
- ทำหน้าที่เป็น ผู้นำทางเทคนิคเชิงลึก
  - ต่างจาก EM ที่มีประชุม, 1:1 และงานบริหารจำนวนมาก จึง สามารถโฟกัสการพัฒนาความสามารถทางวิศวกรรมและความลึกทางเทคนิคได้มากกว่า
ความเสี่ยงใหญ่ที่สุด: Ivory Tower Architect
- กลายเป็น นักทฤษฎีนามธรรม ที่ห่างไกลจากปัญหาจริงและจากโค้ด
- ประเด็นนี้อธิบายไว้อย่างละเอียดใน Ivory Tower Architect

บทบาทของ Staff Engineer สำหรับระบบที่ครอบคลุมหลายทีม

Staff Engineer เหมาะที่สุดกับภาวะผู้นำทางเทคนิคที่ครอบคลุม ทั้งระบบ ไม่ใช่แค่ทีมเดียว
ใน บทความของ Will Larson ได้เสนอ 4 archetypes ของ Staff Engineer:
- Tech Lead: ผู้นำทางเทคนิคภายในทีม
- Architect: ผู้ออกแบบสถาปัตยกรรมระบบ
- Solver: ผู้แก้ปัญหาทางเทคนิคที่ซับซ้อน
- Right Hand: มือขวาที่ช่วยสนับสนุนผู้นำองค์กรด้านเทคนิค
การเรียก Tech Lead ในทีมจากแผนภาพนั้นว่า Staff Engineer อาจไม่แม่นนัก
- คุณค่าที่แท้จริงของ Staff Engineer อยู่ที่การประสานงานข้ามทีมและการบูรณาการทางเทคนิค
- ดู Introduction to Staff Engineering
  - Staff Engineer ไม่ใช่เพียงตำแหน่งงาน แต่เป็นแนวทางที่ตั้งอยู่บนภาวะผู้นำทางเทคนิค
  - บทบาทนี้รับผิดชอบการประสานงานทางเทคนิคและการแก้ปัญหาครอบคลุมหลายทีมและหลายผลิตภัณฑ์
  - สามารถสร้างอิทธิพลได้แม้ไม่มีอำนาจอย่างเป็นทางการต่อคนหรือผลิตภัณฑ์
  - ขับเคลื่อนกลยุทธ์และทิศทางทางเทคนิคของทั้งองค์กร
  - ต่างจาก Engineering Manager ตรงที่สร้างคุณค่าผ่านความเชี่ยวชาญเชิงเทคนิคอย่างลึกซึ้งและการทำงานร่วมกันข้ามองค์กร มากกว่างานบริหารจัดการ
  - ลงมือทำงานจริงอย่างใกล้ชิด และยังทำหน้าที่เป็น mentor ช่วยให้วิศวกรคนอื่นเติบโต
ในองค์กรจริง ระบบเทคนิคมักไม่ได้จำกัดอยู่ในทีมเดียว แต่ กระจายอยู่หลายทีมหรือเชื่อมโยงกันอย่างแน่นแฟ้น
- ในกรณีนี้จำเป็นต้องมี Staff Engineer ที่รับผิดชอบทั้งระบบโดยเฉพาะ
- ต้องมีทั้ง มุมมองและ sense of accountability ต่อภาพรวมของระบบทั้งหมด โดยไม่ขึ้นกับว่าแต่ละทีมดูแลส่วนไหน

Staff Engineer ต้องผ่านทั้งเรื่องคนและผลิตภัณฑ์ ไม่ใช่แค่เทคโนโลยี

ประเด็นสำคัญ: เทคโนโลยี (tech) ไม่ได้คุยหรือรับฟังใครด้วยตัวมันเอง
- เทคโนโลยีไม่สามารถมีความหมายได้ด้วยตัวมันเอง แต่มีความหมายผ่าน ผู้คน (วิศวกร) และ ผลิตภัณฑ์ (ปัญหา)
หาก Staff Engineer จะสร้างคุณค่าที่แท้จริง ต้องผ่านสิ่งต่อไปนี้เสมอ:
- ทำงานร่วมกับวิศวกร
- หารือกับทีมผลิตภัณฑ์
ด้วยเหตุนี้ Staff Engineer จึงมี โครงสร้างการรายงานแบบ dotted reporting lines
- แม้ไม่เป็นทางการ แต่เป็น จุดเชื่อมสำคัญของการทำงานข้ามองค์กรและพันธสัญญาร่วมกัน
บางคนที่ช่างสังเกตอาจถามว่าทำไมลูกศรจาก Staff ถึงชี้ลงไปยังตำแหน่งที่ต่ำกว่า
- เหตุผลที่ 1: ภาวะผู้นำที่ดีตั้งอยู่บนความร่วมมือ ไม่ใช่อำนาจ
  - Staff Engineer ส่ง คำขอเพื่อการปรับปรุงทางเทคนิค ไปยัง EM หรือ PM ระดับทีมด้วยวิธีแบบร่วมมือกัน
  - ไม่ใช่การสั่งการแบบเบ็ดเสร็จ แต่เป็น การทำงานร่วมกันโดยคำนึงถึงวิศวกรและ product roadmap
- เหตุผลที่ 2: Staff Engineer เป็น IC (Individual Contributor) จึงไม่มีลูกน้องสายตรงอย่างเป็นทางการ
  - หากมี ช่องทางสนทนาอย่างสม่ำเสมอ กับ EM/PM จุดประสงค์ไม่ควรเป็นแค่การรายงาน แต่ควรเป็นการคุยสองทางเกี่ยวกับ:
    - สถานะปัจจุบันของเทคโนโลยี (status quo)
    - วิสัยทัศน์ทางเทคนิค (vision) เพื่อแก้ปัญหาผลิตภัณฑ์
    - กลยุทธ์ทางเทคนิคขององค์กร (strategy) เพื่อให้เกิดสิ่งนั้น
    - และในทั้งสามเรื่องนี้ ควรเป็นบทสนทนาแบบสองทาง
เพื่อจัดระเบียบโครงสร้างการรายงานที่ซับซ้อนเช่นนี้ และช่วยให้เทคนิค/ผลิตภัณฑ์สอดประสานกันข้ามทีม
- เอกสารกลยุทธ์ระดับองค์กร (strategy document) มีประโยชน์มาก
- พื้นฐานของเรื่องนี้ดูได้ที่ Strategy basics
  - Diagnosis
    - ศึกษาพื้นที่ของปัญหา แล้วระบุประเด็นหลักที่ต้องแก้และเหตุผลว่าทำไม
    - อธิบายว่าเหตุใดจึงต้องมีกลยุทธ์
    - ระบุทั้งอาการและรากของปัญหา พร้อมวิเคราะห์ว่าทำไมสิ่งเหล่านี้จึงสำคัญในตอนนี้
    - ในกลยุทธ์ที่ไม่ดี ส่วนนี้มักถูกละไว้หรือมีเพียงคำอธิบายสถานะปัจจุบัน
    - การวินิจฉัยที่ดีต้องอาศัย การสำรวจอย่างเป็นกลางและท่าทีแบบนักสืบ
  - Guiding Policy
    - เป็น แนวทางระดับสูง สำหรับแก้ปัญหาที่ระบุไว้
    - โฟกัสที่แนวทางแก้และทำให้องค์กรทั้งองค์กรไปในทิศทางเดียวกัน
    - ช่วยกำหนดทิศทางโดยไม่ต้องกลับมาคิดใหม่ในทุกรายละเอียดเชิงยุทธวิธี
    - กลยุทธ์ที่ไม่ดีมักขาดการเชื่อมโยงระหว่างนโยบายนี้ (HOW) กับการวินิจฉัย (WHY)
  - Coherent Actions
    - คือ แผนปฏิบัติการที่เป็นรูปธรรม เพื่อแก้ปัญหาตามการวินิจฉัยภายใต้นโยบายที่กำหนด
    - ระบุให้ชัดว่าใคร (WHO) จะทำอะไร (WHAT) เมื่อไร (WHEN)
    - หัวใจสำคัญคือ “ความสอดคล้อง” เพื่อให้หลายทีมเดินไปในทิศทางเดียวกันอย่างกลมกลืน

อีกวิธีในการลดขอบเขตทางเทคนิคให้เหลือในทีมเดียว: โมเดล Kebab vs Cake

องค์กรยังสามารถออกแบบโครงสร้างให้เทคโนโลยีไม่ต้องกระจายข้ามหลายทีม แต่ ถูกแก้และดูแลภายในทีมเดียว ได้เช่นกัน
ตัวอย่างที่เด่นชัดคือ โมเดล Kebab vs Cake
- เป็นแนวทางเชิงโครงสร้างที่จัดทีมตาม customer journey เพื่อ ลดขอบเขตความรับผิดชอบทางเทคนิค
- อ่านรายละเอียดเพิ่มเติมได้ที่ Kebab vs Cake organization
- สถาปัตยกรรมแบบ Kebab
  - ทีมถูกจัดตามฟังก์ชันที่ให้บริการ
  - user journey พาดผ่านผลลัพธ์ของหลายทีม
  - ข้อดี: ความเป็นอิสระและ loose coupling
  - ข้อเสีย: มีความเสี่ยงที่จะเกิด handover
- สถาปัตยกรรมแบบ Cake
  - ทีมถูกจัดตาม user journey
  - จัดการ cognitive load ผ่าน abstraction layers
  - ข้อดี: ความเป็นเจ้าของแบบ end-to-end และลด handover
  - ข้อเสีย: มีความเสี่ยงที่ cognitive load จะสูงขึ้น
Staff Engineer ไม่ใช่แค่บทบาททางเทคนิคธรรมดา แต่เป็น owner ที่รับผิดชอบระบบโดยรวม และควรมี 3 สิ่งต่อไปนี้:
- Knowledge:
  - เข้าใจทั้ง tech stack และปัญหาของผลิตภัณฑ์อย่างลึกซึ้ง
  - เมื่อต้องการควรสามารถอธิบายและลงมือ implement ได้เอง
- Mandate:
  - อยู่ในตำแหน่งที่สามารถออกความเห็นได้ว่าเทคโนโลยีควรพัฒนาและดูแลอย่างไร
- Responsibility:
  - รับผิดชอบต่อสุขภาพของระบบ เช่น incident, technical debt, documentation, technical disconnect เป็นต้น
Staff Engineer ไม่ใช่บทบาททางเทคนิคเพียว ๆ และ soft skills เป็นสิ่งจำเป็น สำหรับการขับเคลื่อนองค์กรในเชิงเทคนิค
- ต้องมีทั้งการสื่อสารอย่างมีอิทธิพล ความสามารถในการร่วมงานกับผู้อื่น และภาวะผู้นำ
แต่หาก เอนเอียงไปที่ soft skills อย่างเดียว ก็จะเกิดปัญหาได้ เช่น
- นำเสนอแต่ภาพอุดมคติที่ห่างไกลจากความจริง และไม่ลงมือร่วมเขียนโค้ดหรือแก้ปัญหาจริง
- เสี่ยงจะกลายเป็น Ivory Tower Architect

สรุปส่งท้าย

ไม่ใช่ทุกองค์กรที่จำเป็นต้องมี Staff Engineer และในกรณีต่อไปนี้ก็อาจไม่มีได้:
- เมื่อ EM มีความสามารถทางเทคนิคเพียงพอ และสามารถนำทีมด้านเทคนิคได้ด้วยตัวเอง
- เมื่อ tech stack อยู่ในสภาพที่ดีและดูแลง่าย
- เมื่อเทคโนโลยี จบครบภายในทีมเดียว และแทบไม่มีการพึ่งพาข้ามทีม (เช่นในโมเดลการจัดองค์กรแบบ Cake)
- เมื่อองค์กรมีวุฒิภาวะมากพอจน สามารถดูแลทั้งระบบได้ดีแม้ไม่มี owner เฉพาะ
ในทางกลับกัน หากองค์กรมี Staff Engineer ก็ควรทำให้ชัดเจนว่า:
- ต้องกำหนด technical ownership ให้ชัด
- และมอบ accountability ที่ชัดเจน ให้ Staff Engineer สำหรับความรับผิดชอบนั้น
สรุปประเด็นสำคัญ:
- ควร หลีกเลี่ยง Ivory Tower Architect (เพราะไม่ยึดโยงกับความเป็นจริง)
- การแยกบทบาทเดียวออกเป็นหลายตำแหน่ง เป็นเรื่องไม่มีประสิทธิภาพ
- EM ที่ไม่เข้าใจเทคนิค ก็ไม่มีประสิทธิภาพเช่นกัน
สุดท้าย บทความนี้ไม่ใช่กฎตายตัว แต่เป็น essay เพื่อใช้อ้างอิง
- องค์กร เทคโนโลยี ผลิตภัณฑ์ การปฏิบัติงาน และผู้คน ล้วนแตกต่างกัน จึง ต้องใช้วิจารณญาณอย่างยืดหยุ่นตามบริบท
- หลีกเลี่ยงการลอกเลียนแบบโดยไม่เข้าใจบริบท (cargo culting) → ดูบทความที่เกี่ยวข้อง

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

kuthia 2025-04-09

รู้สึกเหมือนเป็นแขนขาของ CTO เลยนะ

bus710 2025-04-09

สตาฟฟ์เอนจิเนียร์: คนที่จะไปก่อกวนตอนที่ลองทำทุกทางแล้วก็ยังไม่ได้ผล

bobross0 2025-04-10

โคตรจริง 55555

ethanhur 2025-04-08

แม้จะไม่ค่อยเกี่ยวกับเนื้อหาของบทความโดยตรงนัก แต่ช่วงนั้นผมกำลังครุ่นคิดเรื่อง accountability กับ responsibility อยู่พอดี เลยรู้สึกลิงก์ต่อไปนี้ช่วยได้มากครับ

https://blog.alexewerlof.com/p/accountable-vs-responsible