จากวิศวกรสู่ผู้จัดการ: สิ่งที่ชอบและไม่ชอบ
(thoughtspile.github.io)- หลังทำงานเป็นนักพัฒนา frontend มา 7 ปี แล้วขยับมาเป็น team lead และต่อมาเป็น Engineering Manager เต็มเวลา ทำให้ อิทธิพลต่อผลิตภัณฑ์และทีม เพิ่มขึ้น แต่งานที่ทำเปลี่ยนลักษณะไปอย่างมาก
- ผู้จัดการสามารถใช้ อำนาจทั้งอย่างเป็นทางการและไม่เป็นทางการ เข้าไปจัดการปัญหาที่เปลี่ยนแปลงได้ยากตอนเป็น IC เช่น การเขียน test, การปรับปรุง process, และการดูแลบรรยากาศของทีม
- ในเส้นทางอาชีพระยะยาว จะได้ค่าตอบแทนสูงกว่าระดับวิศวกรทั่วไป มีโอกาสกว้างกว่า staff+ IC และได้ ทักษะที่ถ่ายโอนไปใช้ได้ ซึ่งช่วยให้ย้ายไปยังสายเทคนิคอื่น ๆ, project management, product management หรือการก่อตั้งบริษัทได้ง่ายขึ้น
- ในทางกลับกัน ต้องบังคับใช้ ขั้นตอนแบบองค์กร เช่น performance review, deadline ที่ฝืนเกินไป, และนโยบายองค์กร อีกทั้งต้องแบกรับความขัดแย้ง ความไม่มั่นคงทางใจ และแรงกดดันจากการต้องพร้อมตอบสนองตลอดเวลาโดยตรง
- งานบริหารมักเห็นผลได้ยากภายในหนึ่งเดือน และแม้การเปลี่ยนแปลงที่ถูกต้อง เช่น การแยกทีม หรือการจ้างคน อาจทำให้สถานการณ์แย่ลงในระยะสั้น จึงต้องทนกับ feedback loop ที่ยาว
กระบวนการเปลี่ยนจากวิศวกรมาเป็นผู้จัดการ
- ประมาณ 2 ปีก่อนย้ายมาเป็น team lead และหลังจากทีมขยายตัวก็กลายเป็น Engineering Manager เต็มเวลา
- ก่อนหน้านั้นทำงานเป็นนักพัฒนา frontend มา 7 ปี โดยตอนแรกเลือก career track แบบ individual contributor (IC) ระดับสูง แล้วจึงเปลี่ยนมาเป็นสายบริหาร
- เส้นทางการเปลี่ยนผ่านนี้ขรุขระแต่สนุก และงานปัจจุบันก็มีทั้งด้านที่ชอบและไม่ชอบ
สิ่งที่ชอบในบทบาทผู้จัดการ
-
อำนาจในการเปลี่ยนผลิตภัณฑ์และทีม
- เมื่อเป็นผู้จัดการ จะมี อำนาจ ในการปรับปรุงสภาพโดยรวมของผลิตภัณฑ์และทีม
- ตอนเป็น IC อาจเปลี่ยนปัญหาอย่าง standup ตอนเช้ามืด คุณภาพโค้ดต่ำ หรือฟีเจอร์ใหม่ที่เข้าใจยากได้ลำบาก
- EM สามารถใช้อำนาจทั้งอย่างเป็นทางการและไม่เป็นทางการ ปรับให้ทีมและตัวเองทำงานในรูปแบบที่ดีขึ้นได้
- คำพูดเดียวกันอย่าง “เราควรเขียน test” มีน้ำหนักต่างกันเมื่อ IC เป็นคนพูดกับเมื่อ EM เป็นคนพูด และคำพูดของ EM อาจนำไปสู่การเขียน test จริง ๆ ได้
-
โอกาสทางอาชีพที่กว้างขึ้น
- Engineering Manager มอบโอกาสทางอาชีพที่กว้างกว่า track วิศวกรทั่วไป
- โดยปกติ EM ได้ค่าตอบแทนสูงกว่าระดับวิศวกรพื้นฐานในทีม เช่น junior, middle, senior
- ตำแหน่ง IC ที่สูงกว่าอย่าง staff, principal ก็มีช่วงค่าตอบแทนระดับ EM หรือสูงกว่าเช่นกัน
- อย่างไรก็ตาม งาน staff+ IC มักกระจุกตัวอยู่ในบริษัทเทคโนโลยีขนาดใหญ่ที่มีโจทย์เทคนิคยากกว่า ขณะที่แทบทุกบริษัทที่มีทีมซอฟต์แวร์ล้วนมีตำแหน่ง leadership
- บันไดอาชีพสายบริหารต่อยอดขึ้นไปได้สูงกว่า IC
- แม้โอกาสจะได้เป็น CTO อาจไม่สูง แต่ก็เปิดทางเลือกที่ IC ล้วน ๆ ซึ่งไม่มีประสบการณ์บริหารไม่มี
- ความต้องการ EM มีเสถียรภาพกว่าความต้องการวิศวกร staff+ และยังให้โอกาสมากกว่าในช่วงท้ายของอาชีพ
-
ทักษะที่ย้ายไปใช้ในสายอื่นได้ง่าย
- ทักษะการบริหารถูกนำไปใช้ได้กว้างกว่าบทบาท IC engineering เฉพาะทาง
- วิศวกร frontend ที่มีประสบการณ์ React สามารถย้ายไป framework frontend อื่น หรือยอมลดระดับตำแหน่งเล็กน้อยเพื่อเปลี่ยนไปทำ backend หรือ mobile ได้
- หากมีประสบการณ์เป็น Engineering Manager ก็รับผิดชอบทีมที่มีจุดโฟกัสต่างกันได้ง่ายขึ้น เช่น ทีม mobile developer, ทีม infrastructure, หรือทีม ML engineer
- ต้องใช้เวลาในการเข้าใจความยากทางเทคนิคหลักของทีมใหม่ แต่หลายบริษัทสามารถยอมรับการเปลี่ยนผ่านแบบนี้ได้
- ถ้าไม่อยากเป็น EM ต่อ ก็อยู่ในตำแหน่งที่เหมาะจะย้ายไปทำ project management หรือ product management
- แม้ตลาดเทคโนโลยีโดยรวมจะซบเซา ทักษะการบริหารจำนวนมากก็ยังใช้ได้ในอุตสาหกรรมอื่น
- ประสบการณ์ที่เกี่ยวข้องกับผู้คนและการตัดสินใจทางธุรกิจก็มีประโยชน์ในฐานะการฝึกก่อน ก่อตั้งบริษัท
-
ความรู้ล้าสมัยช้ากว่า
- หากรู้สึกเหนื่อยกับการตาม framework และเครื่องมือ frontend ล่าสุด บทบาทบริหารอาจช่วยลดภาระได้
- methodology แบบ agile, kanban, scrum ที่ “ใหม่” นั้นเป็นแนวคิดอายุ 20–30 ปีแล้ว และรูปแบบประชุมพื้นฐานอย่าง demo, daily, 1:1 ก็พัฒนามาเป็นเวลานาน
- แก่นของการบริหารคือ teamwork และปฏิสัมพันธ์ระหว่างมนุษย์ ซึ่งไม่ได้เปลี่ยนไปมากนักตั้งแต่ยุคแรกเริ่มของมนุษยชาติ
- ยังจำเป็นต้องติดตามการเปลี่ยนแปลงทางเทคโนโลยีต่อไป แต่มีเรื่องที่ต้องรีบลงลึกอย่างเร่งด่วนน้อยกว่าโดยเปรียบเทียบ
-
ความท้าทายใหม่ที่อยู่นอกปัญหาเทคนิคที่คุ้นเคย
- เมื่อทำงานในสายเทคนิคใดสายหนึ่งมา 4–5 ปี ปัญหาปฏิบัติจริงส่วนใหญ่ก็จะเริ่มแก้ได้เพียงพอแล้ว
- วิธีที่วิศวกรชำนาญการจะหาความท้าทายที่ใหญ่ขึ้นมีข้อจำกัด
- การเปลี่ยน stack เล็กน้อย เช่น framework frontend ตัวใหม่ เป็นวิธีที่รักษาความน่าสนใจไว้ได้นานยาก
- การเปลี่ยนที่ใหญ่กว่า เช่น ย้ายจาก frontend ไป backend อาจให้ความสนุกได้หลายปี แต่ก็มักเกิดขึ้นโดยบังเอิญหรืออาจกระทบค่าตอบแทน
- หากสร้างปัญหาขึ้นมาเอง เช่น เขียนทุกอย่างใหม่ด้วย library ใหม่ หรือพยายามรองรับ 9000 RPS เพื่ออนาคต แม้จะสนุก แต่บ่อยครั้งกลับเป็นโทษต่อทีมและธุรกิจ
- สำหรับวิศวกรที่มีประสบการณ์ การเปลี่ยนไปสายบริหารให้ เรื่องใหม่ให้เรียนรู้ มากที่สุดโดยไม่ทำให้ค่าตอบแทนลดลง
สิ่งที่ไม่ชอบในบทบาทผู้จัดการ
-
ต้องบังคับใช้ขั้นตอนแบบองค์กร
- ตอนเป็นวิศวกร เคยไม่ชอบ เรื่องไร้สาระแบบองค์กร เช่น performance review รายบุคคล deadline ที่ไร้ประโยชน์ และข้อจำกัดด้าน process หรือ tech stack ที่บริษัทบังคับ
- เมื่อเป็นผู้จัดการ จะกลายเป็นคนที่ต้องบังคับใช้แนวปฏิบัติเหล่านี้ ไม่ว่าจะเชื่อในมันหรือไม่ก็ตาม
- ในองค์กรที่มี performance calibration หัวหน้าทีมต้องระบุทุก 6 เดือนว่าใคร 1 คนทำงานไม่หนักพอ
- หากไม่เสนอสมาชิกทีมที่จะถูกสละออกไป ในขั้นตอนต่อ ๆ ไปอาจมีใครบางคนถูกเลือกแบบสุ่ม ทำให้ยากที่จะกำจัดขั้นตอนนี้
- บางขั้นตอนสามารถเจรจาหรือเลี่ยงได้ เช่น การจัดสรร “ผลงานต่ำกว่าคาด” แบบ round-robin
- จากมุมมองของทีม บางครั้งผู้จัดการอาจดูเหมือน ปีศาจองค์กร
- ยังไม่เคยเจอสถานการณ์ที่ยากกว่านี้ เช่น การเลิกจ้าง การปิดโครงการ หรือการปรับโครงสร้างองค์กร
-
ต้องจัดการความตึงเครียดระหว่างผู้คน
- จุดเริ่มต้นของการเป็น Engineering Manager คือความสามารถในการสร้างอะไรบางอย่างให้ดี และคาดว่าจะได้ช่วยตัดสินใจด้านเทคนิค ให้คำแนะนำอาชีพ ปรับ process และสร้าง automation
- แต่งานส่วนใหญ่ในความเป็นจริงคือการ debug ความตึงเครียดทางสังคมและความไม่มั่นคงทางใจของผู้คน
- ตัวอย่างสถานการณ์:
- วิศวกร junior comment out test บางตัวเพื่อ deploy feature preview
- ผู้รับผิดชอบ QA รู้สึกว่าทีมไม่เคารพบทบาทและคุณค่าของ QA และโกรธมาก
- ผู้จัดการต้องฟื้นฟูความไว้วางใจ
- อีกตัวอย่างหนึ่ง:
- Project Manager เล่นมุกที่ล้มเหลว และ designer รู้สึกเจ็บจนร้องไห้
- ผู้จัดการต้องทำให้ PM ขอโทษ
- เพราะไม่ได้เป็นนักจิตวิทยา และไม่ได้เป็นคนที่รับมือกับคนเก่งเป็นพิเศษ ส่วนนี้จึงยาก และใกล้เคียงกับกระบวนการอดทนไปจนกว่าจะคุ้นเคย
-
โครงสร้างงานที่ยากจะ offline
- ชีวิตของวิศวกรอาจมีความยืดหยุ่นค่อนข้างมาก
- หากไม่มีเรื่องเร่งด่วน อาจออกไปข้างนอกครึ่งวันเพื่อคิดถึงอนาคตของโปรเจกต์ หรือพลาดประชุมบางรายการกะทันหันก็อาจไม่เป็นปัญหาใหญ่
- หาก EM หายไปไม่กี่ชั่วโมง ปัญหาจะสะสมใน messenger
- intern ลืมวิธี
npm installจนทำงานต่อไม่ได้ - senior manager อยากคุยเรื่องฟีเจอร์ที่อาจทำ
- release ผิดแผน
- intern ลืมวิธี
- การประชุมที่ตัวเองเป็นคนดำเนินหรือจัดขึ้นนั้นข้ามได้ยากหากไม่ได้เตรียมล่วงหน้า
- เมื่อทีมเติบโตและ process ดีขึ้น เรื่องนี้อาจดีขึ้นได้ แต่โดยทั่วไปผู้จัดการจะรู้สึกถึง office hours มากกว่า
- work-life balance จะขึ้นกับความสามารถในการทำงานของตัวเองโดยตรง
-
Feedback loop ยาวและไม่เป็นเส้นตรง
- งาน engineering ส่วนใหญ่เห็นผลค่อนข้างเร็ว
- ฟีเจอร์ใหม่เห็นผลได้ภายในไม่กี่สัปดาห์ถึงไม่กี่เดือน และเมื่อแก้ bug ก็อาจเห็นปฏิกิริยาผู้ใช้ได้ในวันถัดไป
- refactoring สามารถเห็นความซับซ้อนที่ลดลงได้ภายในไม่กี่ชั่วโมง
- การกระทำของผู้จัดการแทบไม่เคยให้ผลลัพธ์ที่มองเห็นได้ภายในหนึ่งเดือน
- หากทีมใหญ่เกินไปจนต้องแยกทีม ต้องผ่านหลายขั้นตอน
- กำหนดองค์ประกอบวิศวกรที่เหมาะสมสำหรับทีมใหม่
- พูดคุยกับผู้เกี่ยวข้องเกี่ยวกับความรู้สึกต่อการเปลี่ยนแปลง
- จัดประชุมประจำชุดใหม่
- ตั้งค่า process และ communication
- จัดการงานที่เกี่ยวข้องกับ Jira
- ในบางกรณี แยก codebase ของผลิตภัณฑ์ย่อยออกมา
- หากคิดว่างานแบบนี้จะจบได้ในหนึ่งสัปดาห์ ถือว่าคิดผิด
- แม้การเปลี่ยนแปลงที่ถูกต้อง ก็อาจแย่ลงก่อนจะดีขึ้น
- หากคนไม่พอจนตัดสินใจจ้างเพิ่ม ระยะสั้นจะเสียเวลาไปกับการสัมภาษณ์จำนวนมาก และสมาชิกใหม่ก็ไม่สามารถทำความเร็วได้ทันที ต้องใช้เวลา onboarding
- การเปลี่ยนแปลงด้านบริหารใกล้เคียงกับ refactoring ขนาดใหญ่ มากกว่าการแก้ปัญหาอย่างรวดเร็ว และอาจน่าหงุดหงิดเพราะไม่เห็นการปรับปรุงทันที
สำหรับวิศวกรที่กำลังคิดจะเปลี่ยนสาย
- การย้ายจากวิศวกร IC ไปเป็นสายบริหารเป็นประสบการณ์เหมือนรถไฟเหาะที่มีทั้งด้านสว่างและด้านมืด
- ข้อดีคือมีผลกระทบต่อผลิตภัณฑ์และทีมได้กว้างขึ้น มีโอกาสและความยืดหยุ่นสูงในฐานะ career track ระยะยาว และให้ความท้าทายใหม่เมื่อเริ่มเบื่อสายเทคนิค
- ข้อเสียคือการบังคับใช้นโยบายองค์กร การจัดการความตึงเครียดทางสังคมและความไม่มั่นคงทางใจ โครงสร้างงานที่ยากจะ offline และความพึงพอใจที่ล่าช้ามากพร้อม feedback loop ที่ยาว
- หากคุณสนุกกับความท้าทายและความรับผิดชอบ และมีโอกาส ก็คุ้มค่าที่จะลอง
- สายบริหารไม่ได้เหมาะกับทุกคน แต่ก็อาจเป็นประสบการณ์ที่ช่วยขยายขอบเขตทางเทคนิค และทำให้มองงาน engineering จากมุมใหม่
- หากไม่เข้ากันจริง ๆ ก็ยังมีเวลาเหลือมากพอที่จะกลับไปเขียนโค้ด
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เคยเป็น ผู้จัดการมาแล้วสี่ครั้ง รวมถึงสองครั้งที่ FAANG แต่มีหลายส่วนที่ไม่เห็นด้วยกับต้นฉบับ
สายผู้จัดการไม่ได้สูงกว่าจริง ๆ และผู้จัดการวิศวกรรมส่วนใหญ่กระจุกอยู่ในระดับเทียบเท่า L6/Staff Engineer การเลื่อนขึ้นเป็น Senior Manager ขึ้นไปขึ้นกับสถานการณ์มากและเกิดขึ้นไม่บ่อย ในขณะที่เพื่อนร่วมงานสายวิศวกร เมื่อพร้อมแล้วก็มักได้เลื่อนตำแหน่งโดยไม่ต้องรอให้ดวงดาวเรียงตัวพอดี
คนที่เป็นผู้จัดการวิศวกรรมล้วน ๆ แล้วถูกเลิกจ้าง หลายคนยังหางานอยู่และใกล้จะถอดใจ แต่คนที่โอเคกับการกลับไปเป็น IC มักไม่ค่อยมีปัญหาในการหางาน วัฒนธรรมการบริหารของแต่ละบริษัทต่างกันมาก จึงถ่ายโอนกันโดยตรงได้ยาก และผมมองว่าทักษะที่ถ่ายโอนได้มากที่สุดในอุตสาหกรรมนี้คือ โครงสร้างภายในของ Linux
ความคิดที่ว่ามีประสบการณ์ 5 ปีก็แก้ปัญหาส่วนใหญ่ได้แล้วก็ดูแปลก แม้ทำงานมา 18 ปีแล้วก็ยังมีหลายอย่างที่ไม่รู้และต้องพัฒนาให้ดีกว่านี้ และวิศวกรเก่ง ๆ ที่มีประสบการณ์ 40 ปีก็ยังเรียนรู้อยู่เสมอ
ข้อดีที่สุดของการเป็นผู้จัดการคือได้ใช้เวลาคิดถึงอนาคตมากขึ้น และมีโอกาสมากขึ้นที่จะได้เข้าไปอยู่ใน “ห้องนั้น” ที่คุยกับระดับ C-level ในขณะเดียวกันมันก็แย่ที่สุดด้วย เพราะจะได้เห็นชัดเกินไปว่าการตัดสินใจต่าง ๆ ถูกสร้างขึ้นมาอย่างไร
ส่วนที่ต้นฉบับไม่ชอบนั้นเห็นด้วย แต่เมื่อเวลาผ่านไปจะดีขึ้น อย่างไรก็ตาม ถ้าเป็นผู้จัดการใหม่ คุณอาจยังไม่เคยเจอจุดที่จะเกลียดที่สุด นั่นคือสภาพแวดล้อมที่ ผู้บริหารระดับสูงในหลายบริษัททำตัวเหมือนกลุ่มก๊กในโรงเรียนมัธยม และปัญหาพฤติกรรมของ VP, C-level และบางครั้งแม้แต่ Director ก็ถูกยอมรับ ทั้งที่ถ้าเป็นพนักงานทั่วไปคงถึงขั้นถูกไล่ออก
วิศวกรซอฟต์แวร์ส่วนใหญ่ไปติดอยู่ที่ระดับ Senior โดยเฉพาะที่ Google ยิ่งเป็นแบบนั้น ดังนั้นการไปกระจุกที่ L6 เองก็ถือว่าเป็นอภิสิทธิ์เชิงเปรียบเทียบแล้ว การเลื่อนเป็น L6 ไม่ได้หายากสุด ๆ แต่ก็ไม่ใช่ว่าคนส่วนใหญ่จะได้ และ L7 ขึ้นไปนั้นยาก ถ้ารู้สึกว่าเพื่อนร่วมงานส่วนใหญ่ไปถึงตรงนั้นได้ตามธรรมชาติ ก็อาจเป็นเพราะตัดคนที่ไม่ได้เลื่อนตำแหน่งแล้วออกไปแล้วออกจากภาพ หรืออาจมีโอกาสสนิทกับคนที่อยู่ระดับต่ำกว่าตัวเองน้อย
เห็นด้วยว่าเส้นทางผู้จัดการวิศวกรรมไม่ได้เปิดประตูให้มากเท่าที่คนรุ่นก่อนเคยคิดกัน แต่โอกาสเลื่อนตำแหน่งก็ไม่ได้ดูแคบกว่า IC
การสร้างจาก 0 ไป 1 แทบไม่เกี่ยวกับการจัดการวิศวกรรมเลย สิ่งสำคัญที่สุดคือความสามารถในการเขียนโค้ดให้เร็วและคุยกับลูกค้าเป้าหมายได้สบาย ๆ ซึ่งทั้งสองอย่างไม่ได้เกี่ยวข้องโดยตรงกับบทบาทผู้จัดการวิศวกรรม และก็ไม่มีหลักประกันว่าจะได้จ้างคนมาบริหาร
ตำแหน่งสายบริหารโดยโครงสร้างแล้วมีน้อยกว่างานวิศวกรรมมาก และเส้นแบ่งระหว่าง Lead Engineer กับผู้จัดการด่านหน้าเองก็ค่อนข้างพร่ามัวไปได้ทั้งสองทาง ดังนั้นกลุ่มคู่แข่งจริง ๆ ก็ไม่ได้เล็กลงเท่านั้น
ที่บอกว่าถ่ายโอนได้ หมายถึงเป็นทักษะที่ยังใช้ประโยชน์ได้นอกฟองสบู่บริษัทเทคขนาดใหญ่ เงินดีจนคุณอาจไม่อยากออกไปข้างนอก แต่ก็ควรรู้ไว้ว่ามีอย่างอื่นที่ทำได้ นอกจากงานทำให้คอมพิวเตอร์ส่งเสียงบี๊บ ๆ
เช่น ความคิดที่ว่าถ้าผู้จัดการวิศวกรรมพูดว่า “ต้องทดสอบให้มากขึ้น” จะถูกนำไปพิจารณาจริงจังกว่าตอน IC พูด
ที่จริงตอนผมเป็น IC ที่เพิ่งเลื่อนขึ้นระดับ Staff ผมเองก็รู้สึกว่าความน่าเชื่อถือยังไม่พอ จึงมีส่วนที่อยากย้ายไปสายบริหารเพราะคิดว่าการซ่อนอยู่หลังตำแหน่งน่าจะช่วยได้ แต่ในความเป็นจริงไม่จำเป็นต้องทำแบบนั้น และตอนนี้ในฐานะ IC ของอีกบริษัทหนึ่ง ความคิดและฟีดแบ็กของผมได้รับการรับฟังอย่างจริงจังทั้งในระดับองค์กรและจากเพื่อนร่วมงาน
ระบบที่บังคับจัดอันดับทุกครึ่งปีเพื่อ คัดเลือกคนผลงานต่ำ เป็นวิธีที่พัง การบริหารผลงานในหลายที่มีความจริงอันน่าเศร้าแบบนั้น แต่ไม่ใช่ความจริงสากลว่าการเป็นผู้จัดการต้องทำแบบนั้นเสมอ การสนทนายาก ๆ เกี่ยวกับปัญหาผลงานจริง ๆ เป็นสิ่งที่หลีกเลี่ยงไม่ได้ในเชิงสถิติ แต่ก็มีบริษัทที่คุณไม่จำเป็นต้องคุยว่า “ครึ่งปีนี้ทุกคนในทีมทำได้ดีกว่าคุณ” หรือ “ต้องเลือกใครสักคน รอบนี้เลยเป็นคุณ”
ผมชอบ การแก้ปัญหาและการมองภาพใหญ่ และชอบค้นหาทางออกเพื่อคลี่คลายอุปสรรค บทบาทที่เหมาะกับผมที่สุดคือ “สถาปนิก” แต่ดูเหมือนว่าชื่อตำแหน่งนี้กำลังค่อย ๆ หายไป อย่างไรก็ตาม ความจริงที่ว่างานแบบนั้นยังจำเป็นก็ไม่ได้เปลี่ยนไป
ผมเคยทำบทบาททีมลีด/ผู้จัดการ, Scrum Master และผู้จัดการผลิตภัณฑ์ด้วย แต่ทักษะที่ผู้จัดการที่ดีต้องมีนั้นต่างจากวิศวกรมาก แก่นสำคัญคือ มีความวิตกกังวลต่ำมาก กล่าวคือ ความสามารถในการตัดสินใจที่ดีแม้อยู่ภายใต้ความเครียดเป็นเวลานาน และยังคงภาพลักษณ์ภายนอกที่สงบและมีเหตุผลได้
ผู้จัดการระดับล่าง 90% ไม่มีคุณลักษณะนี้ และเมื่อเครียดก็จะทำให้ทีมและบริษัทเสียหาย ถ้าอยากเป็นผู้จัดการ ต้องประเมินตัวเองอย่างตรงไปตรงมาว่าตอบสนองต่อความเครียดที่ยืดเยื้ออย่างไร เรื่องที่ดูน่าเบื่ออย่างเช่น คุณตะคอกใส่คนรอบตัวหรือไม่ หลบหรือชะงักจนตัดสินใจไม่ได้หรือเปล่า โทษคนอื่นเพื่อรักษาชื่อเสียงตัวเองไหม สิ่งเหล่านี้คือความแตกต่างที่แท้จริงระหว่างผู้จัดการที่มีประสิทธิภาพกับคนที่เหลือ
โดยทั่วไปจะรวมถึงงานที่ไม่สนุก เช่น หยิบปัญหาที่ทุกคนหลีกเลี่ยงขึ้นมา ปล่อยให้ผู้คนระบายความไม่พอใจต่อการตัดสินใจของผมกันเป็นกลุ่ม และยังคงเข้าไปมีส่วนร่วมต่อไปแม้อีกฝ่ายจะถอยห่างและผลักไส
สำหรับผม งานบริหารรู้สึกเหมือนเป็นงานที่เรียกร้องพลังทั้งหมดที่มีแล้วยังเรียกร้องเพิ่มอีก แต่ผมคิดว่านี่ใกล้เคียงกับปัญหาความเหมาะสมระหว่างผมกับงาน มากกว่าจะเป็นแก่นแท้ของการบริหาร ตามแบบสำรวจบนอินเทอร์เน็ต ผมมีระดับความวิตกกังวลปานกลาง แต่ผมไม่ถนัดกับการหยุดแค่ “ดีพอแล้ว” และรู้สึกว่าขอบเขตความรับผิดชอบที่กว้างขึ้นของงานบริหารสร้างปัญหาด้านการขยายตัวทางอารมณ์
กุญแจในการแก้ปัญหา crunch และ burnout อาจเป็นการสร้างสภาพแวดล้อมด้านกฎระเบียบที่ทำให้ชีวิตความเป็นอยู่ทั้งหมดของแรงงาน—เช่น สุขภาพ ค่าเช่า การชำระคืนเงินกู้นักศึกษาของมหาวิทยาลัยรัฐ—ไม่ต้องขึ้นอยู่กับการรักษางานไว้เพียงอย่างเดียว
ถ้าเป็น IC คุณสามารถเติบโตในอาชีพได้ด้วยการเรียนรู้เทคโนโลยีหรือโดเมนใหม่ ๆ แต่สำหรับผู้จัดการ การพัฒนาอาชีพจะยิ่งผูกกับการเติบโตส่วนบุคคล เช่น ความเป็นผู้ใหญ่ มุมมอง และความสามารถในการฟื้นตัวทางอารมณ์มากขึ้นเรื่อย ๆ นี่อาจเป็นเหตุผลที่ความอาวุโสเพิ่มขึ้นพร้อมกับความสนใจในสิ่งอย่างการทำสมาธิแบบ mindfulness
HN คงไม่ชอบ แต่แม้ผมจะเป็นโสด ผมก็สงสัยว่าพ่อแม่อาจกลายเป็นผู้จัดการที่ดีกว่าหรือไม่ เพราะอาจมีโอกาสน้อยกว่าที่จะเสียมุมมองและเครียดกับเรื่องที่ไม่สำคัญในภาพใหญ่ น่าแปลกที่ดูเหมือนว่าผมบริหารได้ดีที่สุดเมื่อถอยห่างทางอารมณ์ออกมาหนึ่งก้าว
พอมารู้ทีหลัง ผมค่อนข้างอ่อนไหวโดยพื้นนิสัย จึงกังวลเป็นการส่วนตัวว่าอาจไม่เหมาะกับตำแหน่งบริหารโดยโครงสร้างนิสัยก็ได้ ลักษณะที่บางครั้งดูเสแสร้งอย่าง “ไม่ใช่การควบคุม แต่เป็นการสร้างแรงจูงใจ” ก็ยากสำหรับผมเช่นกัน ผมแค่อยากเร่ร่อนไปในองค์กรเพื่อแก้ปัญหา ทำให้กระบวนการเรียบง่ายขึ้น และจัดระบบงานใหม่
ผมเป็นวิศวกรซอฟต์แวร์มาปีที่ 12 แล้ว แต่ไม่มีความอยากเป็นผู้จัดการเลย ผมแค่อยากสร้างอะไรบางอย่าง ไม่ได้อยากบริหาร
ผมทำงานใกล้ชิดกับผู้จัดการและเห็นว่างานเป็นอย่างไร แต่ไม่รู้สึกว่าน่าดึงดูดเลย ในฐานะวิศวกรอาวุโส คำพูดของผมก็มักมีอิทธิพล แต่ผมชอบที่ไม่ต้องแบกรับความรับผิดชอบมหาศาลแบบผู้จัดการ ผมไม่อยากเพิ่มความเครียดในชีวิต
อาชีพอีก 30 ปีข้างหน้าของผมก็คงอยู่ในตำแหน่งคล้ายเดิม
เมื่อไม่กี่ปีก่อนผมก็คล้ายกัน หัวหน้าชอบผมและมีเครือข่ายกว้าง จึงแชร์ข้อมูลทั้งหมดให้ผม นั่งผมไว้ในวงตัดสินใจ ขอความเห็นเกี่ยวกับทิศทาง และบอกว่าถ้าจำเป็นให้พูดแทนตัวเขาหรือผู้จัดการคนอื่นได้ โดยเขาจะหนุนหลังให้
ตอนนี้มีโครงสร้างการบริหารชุดใหม่ทั้งหมดเข้ามา และเป็นแบบสั่งการจากบนลงล่างมาก มีอีโก้สูง และไม่อยากรับฟังฟีดแบ็ก ผู้จัดการระดับล่างหรือวิศวกรที่ออกเสียงถูกผลักออกไปเรื่อย ๆ และอิสระกับสิทธิ์ในการแสดงความคิดเห็นที่ผมเคยมีก็แทบหายไป
แม้แต่หลายเรื่องที่ผมคิดว่าเป็นการตัดสินใจทางวิศวกรรมก็ถูกพรากไป ผมต้องการ X สำหรับบริการที่จะสร้าง จึงทำโซลูชันอัตโนมัติขึ้นมาและมันทำงานได้ดี แต่ไม่กี่เดือนต่อมากลับถูกบอกว่าพวกเขามีแผนอื่นสำหรับ X และผมทำผิด พร้อมสั่งให้ลบโซลูชันที่อัตโนมัติเต็มรูปแบบออก แล้วเปลี่ยนไปใช้กระบวนการองค์กรแบบทำมือของอีกทีมหนึ่ง งานนั้นมักถูกพลาดบ่อย ๆ จนลดเสถียรภาพของบริการของผม
ผมดีใจที่ไม่ได้เป็นผู้จัดการที่ต้องต่อสู้กับคนพวกนี้ ถ้าเป็นอย่างนั้น ตอนนี้ผมคงเสียงานและถูกแทนที่ด้วยเพื่อนของพวกเขาไปแล้ว อย่างไรก็ตาม อิทธิพลของวิศวกรอาวุโสอาจเปลี่ยนไปมากในระยะยาว แม้อยู่ในบริษัทและทีมเดียวกัน
ยังมีตำแหน่งสายเทคนิคที่สูงกว่านี้ซึ่งไม่มีความรับผิดชอบด้านการบริหาร หรือมีน้อยมาก เช่น senior principal engineer, architect เป็นต้น และขึ้นอยู่กับว่าบริษัทมองว่าคุณมีคุณค่าแค่ไหน
ตัวอย่างที่ดีที่สุดที่ผมเคยเห็นคือวิศวกรที่มีปริญญาเอกและประสบการณ์หลายสิบปี ทำงานเป็นกูรูด้านวิจัย/สถาปัตยกรรม ใช้ Matlab เยอะ ไม่มีทีมหรือลูกน้องสายตรง และเป็น “VP of technology” ในบริษัทขนาดหลายร้อยคน
สิ่งที่ยากไม่ใช่แค่การเรียนรู้เองหรือผู้คน แต่เป็นบริบทรอบ ๆ มันด้วย การมีมุมมองด้านการบริหารช่วยได้มากในการเข้าใจว่าเรากำลังสร้างอะไรและทำไม เหตุใดงานจึงดูไม่มีประสิทธิภาพและพัง และยังทำให้เกิด insight เกี่ยวกับทางออกและบริบทที่ไม่ได้ถูกสื่อสารอย่างเหมาะสมด้วย
ตอนนี้ผมเป็นนักพัฒนาระดับซีเนียร์ และกำลังสัมภาษณ์ในตำแหน่ง ทีมลีด ของสตาร์ตอัป ผมคิดว่าตัวเองมีทักษะด้านเทคนิคสูง แต่สิ่งที่น่าอึดอัดที่สุดในชีวิตประจำวันคือปัญหาเกี่ยวกับทีมเวิร์ก
เช่น การขาดความเชื่อใจ สมาชิกทีมที่ไม่อยากคุยกัน ซีเนียร์คนอื่นที่ทำงานต่ำกว่ามาตรฐานแล้วยังปล่อยผ่านไป การไม่มีเป้าหมายทีมและวิสัยทัศน์ผลิตภัณฑ์ที่ชัดเจน รวมถึงการไม่เห็นพ้องกันเรื่องแนวปฏิบัติทางวิศวกรรมร่วมกัน ถ้าได้เป็นผู้จัดการคน ไม่ว่าจะดีหรือร้าย ปัญหาเหล่านี้ก็จะเข้ามาอยู่ในขอบเขตที่ผมต้องมีอิทธิพลและรับผิดชอบ
แต่พอได้เป็นทีมลีดจริง ๆ กลับพบว่าขอบเขตที่เราสามารถมีอิทธิพลได้นั้นเล็กกว่าที่คิดมาก มีคนจำนวนมาก รวมถึงหัวหน้าของผมเอง ที่อยากลงมาคุมทุกอย่างเอง และคาดหวังให้ผมแค่ประทับตราอนุมัติ
กลายเป็นว่าผมลำบากกว่าเดิม เพราะต้องเป็นคนพูดแทนในเรื่องที่คนในทีมกลัวจะพูดออกมา เช่น “ถ้าจะให้สตอรี่พร้อม ต้องนิยาม API ก่อน” ถ้ายังไม่รู้ด้วยซ้ำว่าต้องทดสอบอะไร QA จะสร้าง automated test แบบทำขนานกันได้อย่างไร
Scrum Master, product owner, manager และ architect ต่างก็พูดสิ่งที่เข้าทางตัวเองในวันนั้นราวกับเป็นความจริงที่ชัดเจนอยู่แล้ว แล้ววันรุ่งขึ้นก็มาบ่นว่าทำไมการทดสอบถึงช้า
สุดท้ายก็กลายเป็นการเมืองว่าใครต้องรับผิดชอบต่อสภาพปัจจุบัน และคนที่เลือกทิศทางกับกลยุทธ์แบบนั้นก็มักมีคอนเน็กชันดีและโยนความรับผิดชอบเก่ง
ครั้งหนึ่งผมเคยยืนอยู่ในออฟฟิศ หลังจากหัวหน้าในตอนนั้นโทรไปขอให้อีกแผนกช่วยทำงานบางอย่างได้สำเร็จ
หัวหน้าเงยหน้าจากโต๊ะมามองผม ยิ้มนิด ๆ แล้วพูดด้วยน้ำเสียงงง ๆ ว่า “แค่ตำแหน่งเปลี่ยนจาก ‘Specialist’ เป็น ‘Manager’ ไม่ได้ทำให้ฉันดูดีขึ้นหรอกนะ แต่ช่วยให้งานเดินได้จริง ๆ” นั่นคือช่วงเวลาที่ พลังของตำแหน่ง ทำงานจริง
manager มักถูกเมินได้ง่าย เว้นแต่จะขู่ด้วยผลเสียจริง ๆ และไพ่แบบนั้นควรเก็บไว้ใช้เท่าที่จำเป็น
ผมเริ่มเป็น engineering manager เมื่อไม่กี่ปีก่อนในฐานะ CTO ของสตาร์ตอัปเล็ก ๆ และชีวิตก็เปลี่ยนไปมาก ผมรู้สึกแบบเดียวกันกับทุกด้านที่ต้นฉบับบอกว่ารักและเกลียด
คำแนะนำเพิ่มเติมคือให้ทำสมาธิจริง ๆ ก่อนจะตัดสินใจเรื่องสำคัญและมีผลกระทบสูงที่อาจเป็นอันตรายต่อผู้คน ต้องนั่งเงียบ ๆ ให้นานพอจนสมองดับลง
ช่วงแรกมันจะกลายเป็นความสัมพันธ์แบบพ่อแม่กับเด็กอัจฉริยะอยู่บ้าง ต้องยอมรับผู้คนและเข้าใจวิธีของพวกเขา ยิ่งวางการควบคุมมากเท่าไร การควบคุมจริง ๆ ก็ยิ่งลดลงเท่านั้น พวกเขาจะพยายามเลี่ยงและต่อต้านระบบราชการที่ไม่จำเป็น และพูดตรง ๆ ผมเองก็คงทำแบบนั้นเหมือนกัน
คำแนะนำข้อที่สองคือให้ ทำตัวเหมือนคนที่จะจากไปพรุ่งนี้เสมอ แบบนั้นทีมและเพื่อนร่วมงานจะพร้อม และวิถีชีวิตของตัวเองก็ดีขึ้นด้วย
พวกเขาเติบโตเร็วมาก และการได้เห็นว่าองค์กรยังเดินได้แม้ไม่มีผมก็ทำให้รู้สึกสบายใจอย่างประหลาด ขณะเดียวกันก็เหมือนพวกเขาเติบโตเร็วขึ้นตอนผมไม่อยู่ จนสงสัยว่านี่เป็นสัญญาณหรือเปล่าว่าผมกำลังทำอะไรผิด
บางวันรู้สึกเหมือนกำลังใช้ทักษะที่เรียนรู้จากที่ทำงานมาจัดการครอบครัว
พื้นหลังของผมตรงกันข้าม ผมเป็น software engineer ธรรมดา แต่ ทักษะในการรับมือกับคน ค่อนข้างดี
ผมมีประสบการณ์พอที่จะรู้ว่าอะไรใช้เวลา และส่วนไหนของระบบสำคัญกว่า มีวิศวกรซีเนียร์อยู่หลายคนที่ผมตั้งใจฟังจริง ๆ และให้ความเชื่อใจรวมถึงอำนาจอย่างมาก
ผมไม่ใช่คนตัดสินใจด้านการออกแบบ พวกเขาเป็นคนตัดสินใจ ส่วนผมช่วยเสริมความคิดเห็น ถ้าล้มเหลวผมรับผิดชอบและเรียนรู้ ถ้าสำเร็จก็ยกเครดิตให้ทีม พูดอย่างถ่อมตัว ผมมองว่าบทบาทผู้จัดการเป็นเรื่องของคนเหนือสิ่งอื่นใด
เหตุผลเดียวที่อยากย้ายจากบทบาท coder/IC ไปสายบริหาร คือ การสัมภาษณ์ whiteboard ที่ต้องเจอทุกครั้งเวลาเปลี่ยนงาน
แทบจะทรมานที่ต้องเตรียมตัวใหม่ตั้งแต่ศูนย์ทุกครั้ง และถึงจะมีบทบาทที่ไม่มีกระบวนการแบบนั้นอยู่บ้าง แต่ก็หายากมาก พอนึกถึงการเตรียมตัวแบบนั้น หลายครั้งก็คิดว่า “โอ๊ย ขอร้อง ยังต้องเอาอีกเหรอ?” แล้วก็อยู่ที่เดิมต่อไป
engineering manager ที่แย่สามารถสร้างความเสียหายได้มากกว่า IC ที่แย่หลายเท่า ผมคิดว่าเรื่องนี้ไม่ได้ถูกพูดถึงบ่อยพอ
ตลอดอาชีพที่ยาวนาน ผมเคยเจอ manager ที่ยอดเยี่ยม 1 คน manager ที่พอใช้ได้ไม่กี่คน และ manager ที่แย่มากจำนวนมาก manager ที่แย่มากทำให้งานยากขึ้นมาก และบางครั้งก็ทำให้ทุกอย่างน่าสังเวชไปเลย
การจับคู่กันระหว่าง engineering manager ที่แย่กับ junior IC อาจแย่เป็นพิเศษ เมื่ออายุมากขึ้น ผมก็ได้รู้ว่าตัวเองสามารถทำงานกับ manager ที่แย่และขยับสถานการณ์ไปในทางที่ดีขึ้นได้ หรือถ้ารู้สึกว่าไม่มีหวังก็ออกมาได้
ช่วงนี้ความรับผิดชอบด้านการจัดการของผมเพิ่มขึ้น เลยอยากรู้
ครั้งหนึ่งผมเคยนำทีมที่ประกอบด้วย IC ระดับปริญญาเอก ต้องหางานให้พวกเขาทำ กันพวกนักฝันกลางวันออกไป และรักษาให้พวกเขามีความสุข
ไม่ได้ล้อเล่นนะ ผมเคยนั่งคุยกับแต่ละคนครั้งละหกชั่วโมง ทำหน้าที่เหมือนที่ปรึกษาเส้นทางอาชีพและคนปลอบใจ ไม่เคยคิดเลยว่างานแบบนั้นจะกลายมาเป็นหน้าที่ของผม
สมาชิกทีมคนหนึ่งช่วยคว้า สัญญาแยกกันสองฉบับ มูลค่า 1 พันล้านดอลลาร์ ได้ ดังนั้นเวลาของผมก็คุ้มค่าแล้ว