“เราคิดว่าคุณพร้อมที่จะเป็น Tech Lead แล้ว” นี่เป็นคำกล่าวจาก Technical Leaders ทั้ง 4 คนของคุณ Marisa Hoenig เนื่องจากพวกเขาได้เห็นศักยภาพของคุณ Marisa ซึ่งทำงานเป็น Software Developer มาได้เพียง 2 ปี 5 เดือน โดยประโยคนี้ทำให้เธอรู้สึกทึ่งและไม่อยากเชื่อว่า จะได้เป็น Tech Lead ทั้งทำงานมาได้ไม่นาน และบทความนี้จะมา ถอด 7 บทเรียนจาก Tech Lead มือใหม่ ฉบับคุณ Marisa Hoenig
1. “วางกลยุทธ์” ไม่ใช่โต้ตอบ
ในฐานะ Tech Lead นั้น คุณเหมือนจะมีคนโยนลูก Baseball ใส่ตลอดเวลา แน่นอนว่าคุณ Marisa ก็เคยโดนมาแล้ว เช่น มีคนออกจาก Project, มี External Process ที่ใช้เวลานานกว่าที่คาดไว้ หรือไม่มีใครสังเกตเห็น Bug ก่อนที่จะสายเกินไป
นี่เป็นเพียงแรงกระแทกเล็ก ๆ น้อย ๆ บนเส้นทางอาชีพที่ยาวไกล ซึ่งง่ายต่อการตอบสนองต่อทุกสิ่งแบบ Realtime คุณคิดว่าคุณต้องตอบทุกข้อความทันที หรือต้องจัดการทุกอย่างทันทีที่เกิดปัญหา แต่จริง ๆ แล้วงานของคุณ คือ “การวางกลยุทธ์”
คุณต้องคิดในระยะยาวตั้งแต่เริ่มต้น คุณต้องเข้าใจเป้าหมายโดยรวมของ Technical Decision ที่ได้รับ และแรงกระแทกทั้งหมดที่จะเข้ามา ซึ่งพวกมันจะถูกวัดว่า มันส่งผลอย่างไรต่อกลยุทธ์โดยรวม ซึ่งถ้าคุณไม่วางแผน คนอื่นก็จะวางแผนให้คุณ และจะทำให้ Roadmap ของคุณได้รับความสำคัญน้อยกว่า ปัญหาต่าง ๆ ที่เกิดขึ้น
ตัวอย่างเช่น หากคุณกำลังสร้าง App สำหรับผู้บริโภคจำนวนมาก ในขณะที่คุณต้องเข้าใจเกี่ยวกับ Use Cases และความเร่งด่วนที่แตกต่างกัน คุณยังต้อง Focus ไปที่กลยุทธ์ในการทำให้ App บรรลุผลสำเร็จ หากผู้บริโภคถามถึง Features ขึ้นมา คุณก็ควรที่จะคิดออกว่า คุณจะสร้าง Features ในกลยุทธ์ที่มีอยู่ได้อย่างไร (ซึ่งไม่ใช่การเปลี่ยนหรือแทนที่)
2. Focus ไปยัง “สิ่งที่ยังไม่รู้จัก”
เราจะสร้าง API นี้ได้อย่างไร? Timeline จากทีมอื่นเป็นอย่างไรบ้าง?
นี่เป็นเพียง 2 คำถามจากหลาย ๆ ข้อที่คุณอาจพบได้ในขณะที่เป็น Tech Lead “สิ่งที่ไม่รู้” อาจทำให้คุณรู้สึกเหนื่อย นอนไม่หลับ กระสับกระส่าย หรือคิดเกี่ยวกับ Architecture Decision ซึ่งไม่น่าเชื่อว่ามันทำให้คุณเป็นไปได้ถึงขนาดนั้น
คุณ Marisa Hoenig เล่าว่า เธอจมอยู่กับ “ความไม่รู้” ในช่วงเวลาที่เธอเป็น Tech Lead เธอมักจะเจอกับ “สิ่งที่ไม่รู้จัก” ประมาณ 3 เรื่องแทบทุกสัปดาห์ และทุกครั้งที่เจอกับ “สิ่งที่ไม่รู้จัก” เธอจะรู้สึกเหมือนต้องทำงานกับทีมใหม่ ๆ, ต้องค้นหากลยุทธ์ใหม่ ๆ และมี Architecture Decision Record ให้ต้องเขียนใหม่
เธอมักถูกครอบงำโดย “สิ่งที่ไม่รู้จัก” ซึ่งเธอเริ่มเก็บไว้กับตัวเอง แทนที่จะบอกกับทีม ในหัวของเธอก็วนเวียนอยู่กับคำถามอยู่ตลอดเวลา เธอกลัวที่จะยอมรับว่า เธอไม่ได้รู้ในทุก ๆ เรื่อง โดยเฉพาะอย่างยิ่ง คำถามที่โผล่ออกมาจากที่ไหน/ใครก็ไม่รู้ ที่อาจทำลาย Architecture Plans หรือ Completed Research ของเธอ
โชคดีที่เธอคิดได้ว่า เธอจะต้องจดบันทึกและหากลยุทธ์ โดยเธอจับคู่คำถามที่เกิดขึ้นกับ Architecture Diagram ของทีม จากนั้นก็นำไปเสนอต่อทีม จากนั้นทีมก็สามารถเริ่มทำงานกันต่อได้
ในขณะที่ “สิ่งที่เราไม่รู้จัก” นั้นดูน่ากลัว ขอแนะนำให้คุณลองเขียนสิ่งที่คุณรู้ หากคุณรู้ว่า มีสิ่งใดบ้างที่คุณ “ไม่รู้จัก” นั่นก็เพียงพอแล้วที่คุณจะเริ่มตรวจสอบสิ่งเหล่านั้น อย่าเก็บคำถามไว้ในหัวของคุณ เพราะจะไม่มีใครรู้ถึงความสำคัญของคำถามเหล่านั้นเลย
3. คำว่า “ฉันไม่รู้” เป็นเหมือน พลังพิเศษ
การยอมรับว่า คุณไม่รู้ในบางสิ่ง ถือเป็นความกล้าหาญอย่างแท้จริง
ในฐานะ Tech Lead คุณไม่จำเป็นต้องรู้ในทุก ๆ อย่าง แต่คุณอยู่ในตำแหน่งสำคัญที่จะชี้ให้ทีมของคุณ ไปยังจุดที่พวกเขาสามารถหาคำตอบได้
มันมีพลังที่ซ่อนมากมายจากคำพูดที่ว่า “ฉันไม่รู้ แต่ฉันรู้ว่าใครจะทำได้” หรือ “ฉันไม่รู้ แต่มาทำความเข้าใจด้วยกันเถอะ”
กับ “ฉันไม่รู้ แต่…” คุณกำลังบอกว่า ถึงฉันไม่รู้ก็ไม่เป็นไรหรอก นั่นหมายถึง คุณกำลังยอมรับว่า คุณไม่ใช่พจนานุกรมที่สมบูรณ์แบบของมนุษย์ เชื่อเถอะว่า ผู้นำก็มีข้อบกพร่องได้เหมือนกัน
อย่ากดดันตัวเองมากเกินไปเพียงเพราะ “ความไม่รู้” ขอให้มองว่า มันเป็นช่วงเวลาเพื่อเรียนรู้สิ่งใหม่ ๆ และสามารถสอนวิธีแก้ไขให้ผู้อื่นในครั้งต่อไปได้
4. เป็นผู้นำที่มุ่งไปที่ “ผลลัพธ์ของงาน”
หากสมาชิกในทีมของคุณกำลังบ่นเกี่ยวกับบางเรื่อง มันไม่ใช่หน้าที่ของคุณในการช่วยหาวิธีแก้ปัญหาที่สมบูรณ์แบบที่สุด เพราะคุณไม่ใช่ “เทวดาหรือผู้วิเศษ” ที่สามารถเสกทุกตามต้องการได้
ในทางกลับกัน คุณควรหาทางเปลี่ยนการบ่นของพวกเขา เป็นการหาวิธีการแก้ปัญหานั้นแทน โดยถามสมาชิกในทีมของคุณว่า “เราสามารถเปลี่ยนแปลงอะไรได้บ้าง เพื่อปรับปรุงสถานการณ์นี้ให้ดีขึ้น”
คุณควรนำทีมของคุณไปสู่ “Brainstorm Solutions” เนื่องจาก Developers คือนักแก้ปัญหา ไม่ว่าจะเป็นการเขียน Code หรือเรื่องอื่น ๆ ก็ตาม สำหรับ Developers ที่ต้องการเติบโตในสายอาชีพ พวกเขาไม่สามารถคาดหวังให้คนอื่นมาแก้ปัญหาให้ได้ตลอดเวลา และถึงแม้คุณจะเป็น Tech Lead แต่คุณก็ไม่สามารถรับผิดชอบต่อทุกปัญหาที่เกิดขึ้นได้เช่นกัน
ลองให้ทีมของคุณ ลองแก้ปัญหาบางอย่างด้วยตัวพวกเขาเอง มันจะทำให้พวกเขาจดจำวิธีแก้ไขปัญหาเหล่านั้นได้ขึ้นใจเลยแหละ
5. อย่า! ทำให้ตัวเองไม่สามารถ “ถูกแทนที่ได้”
สุดท้ายแล้ว คุณไม่ไดเป็น Product ของตัวคุณเอง และ Product ของคุณ ก็ไม่ใช่ตัวคุณ
ในฐานะ Tech Lead คุณคงมีส่วนร่วมในแทบทุกส่วนของ Project อีกทั้งคุณยังต้องเข้าใจวิธีการทำงานเกี่ยวกับ Design และ Product ดังนั้นคุณจึงเป็นเหมือนดั่ง “แหล่งข้อมูลสำรอง” (คุณจะทำความเข้าใจว่าส่วนประกอบทั้งหมดเชื่อมโยงกันอย่างไร)
แม้ว่าการศึกษาและเรียนรู้ Project โดยรวมนั้นจะเป็นเรื่องดี แต่คุณไม่ควรรู้และเข้าใจอยู่เพียงแค่คนเดียว หากคุณรู้ข้อมูลบางอย่างอยู่แค่คนเดียว นั่นล่ะคือปัญหา ดังนั้น เปิดโอกาสให้ผู้อื่นได้เรียนรู้และเติบโตไปด้วยกัน ดูจะเป็นทางเลือกที่ดีกว่า
เมื่อถึงจุดหนึ่ง คุณจะตัดสินใจได้ว่า ถึงเวลาออกจาก Project แล้ว เพราะท้ายที่สุดแล้ว Software มีอายุยืนยาวกว่าคนที่ทำงานกับมัน (โอเค ความหวังคือ Software ยังอยู่ตลอดไปใช่ไหม?) คุณคงอยากให้ผู้อื่นสามารถทำบางอย่างแทนคุณได้ด้วย
ดังนั้น คุณควรตรวจสอบให้แน่ใจอยู่เสมอว่า ผู้อื่น ๆ สามารถลองสวมหมวกหลายใบแบบที่คุณสวมใส่อยู่ และความรู้ของคุณควรถูกบันทึกไว้ในระดับหนึ่ง ซึ่งจะทำให้คนต่อไปสามารถเข้ามารับบทบาทแทนคุณได้ง่ายขึ้น และคุณจะไม่รั้งตัวเองจากโอกาสที่จะเข้ามาในอนาคต
6. หากเครื่องมือที่ใช้ ไม่เหมาะกับคุณก็ควร “แก้ไข”
ในฐานะ Tech Lead คุณต้องติดตามสิ่งที่ Developers ของคุณกำลังทำและสิ่งที่จะเกิดขึ้นในอนาคต แม้ว่าความรับผิดชอบบางอย่างจะถูกแบ่งให้กับ Project Manager และ Product Manager แล้ว แต่ในท้ายที่สุด คุณต้องรับผิดชอบต่องานที่ Developers ได้รับและช่วยเหลือเมื่อพวกเขาต้องเจอกับปัญหา
สำหรับเครื่องมือต่าง ๆ ที่ใช้ในแต่ละวัน คุณควร Customize ให้เหมาะกับความต้องการของคุณ เช่น Issue Tracking Board (JIRA, Trello, Zenhub เป็นต้น) ควรช่วยให้คุณมองเห็นภาพรวมคร่าว ๆ สำหรับสิ่งที่จะเกิดขึ้น มันควรช่วยจัดระเบียบ Sprints ที่กำลังจะเกิดขึ้น และควรให้ข้อมูลที่เพียงพอแก่ Developers ของคุณ แต่หากไม่เป็นเช่นนั้น ก็ควรแก้ไขซะ
ในฐานะ Tech Lead คุณ Marisa ต้องใช้เวลาอย่างมากแต่ละครั้งในการวางเมาส์เหนือ Icon ของ Github Profile ของสมาชิกในทีม เพื่อดูว่าใครทำงานบน Card ไหน ไม่มีใครที่คิดจะตั้งรูป Profile มันเลยกลายเป็น Patterns ทั่วไปที่เป็นแค่รูปสี่เหลี่ยม เธอจึงขอให้พวกเขาช่วยใส่รูปภาพ เพื่อให้เธอไม่ต้องมานั่งงงหาอยู่ว่าใครเป็นใคร
คุณ Marisa ยังได้เพิ่ม Labels, Columns และอื่น ๆ เพื่อช่วยจัดระเบียบ Board นอกจากนี้เครื่องมือต่าง ๆ ที่คุณใช้ ก็ควรถูก Customize เพื่อช่วยให้คุณและทีมงาน สามารถทำงานได้ง่ายขึ้น
7. ความสำเร็จของ “Project ไม่ได้ขึ้นอยู่กับคุณ” เท่านั้น
ในฐานะ Tech Lead มือใหม่ คุณ Marisa พบว่ามันง่ายมากที่จะทำให้คิดว่าความสำเร็จของ Project นั้นขึ้นอยู่กับเธอ แม้ว่าทุกคนในทีมจะมีบทบาทสำคัญ แต่สิ่งต่าง ๆ มันก็ทำให้เธอรู้สึกเหนื่อยหน่าย และพยายามที่จะแก้ปัญหาทุกอย่าง ซึ่งมันไม่ยั่งยืนหรือสมเหตุสมผลเอาซะเลย
คุณไม่ได้ถูกวัดคุณค่าจากความสำเร็จของ Project เพียงอย่างเดียว เพราะหาก Project ล้มเหลว นั่นก็ไม่ได้หมายความว่า คุณเป็น Tech Lead ที่ล้มเหลว
แทนที่จะกดดันตัวเอง ก็ให้พึ่งพาสมาชิกในทีมเพื่อให้พวกเขาช่วยเหลือคุณ อาจจะพูดคุยกันแบบตัวต่อตัว และให้ความสำคัญกับการดูแลเอาใจใส่สุขภาพของตัวคุณเองด้วย เพราะทีมของคุณต้องการคุณใน Project นี้ แต่ขณะเดียวกัน พวกเขาก็คงต้องการให้คุณดูแลตัวเองด้วย
สุดท้ายนี้ เชื่อว่าสิ่งสำคัญต่าง ๆ ที่คุณได้เรียนรู้จากบทความ ถอด 7 บทเรียนจาก Tech Lead มือใหม่ จะเป็น Guideline ในการปรับปรุงแนวคิดในการทำงานของคุณให้ดีและมีประสิทธิภาพขึ้นกว่าเดิม
จงทำตามสัญชาตญาณและเชื่อมั่นในตัวเอง คุณสามารถเพิ่มทักษะของคุณได้ในแบบที่คาดไม่ถึง ด้วยการลองทำในบทบาทใหม่ ๆ แล้วคุณล่ะ พร้อมที่จะเริ่มบทบาทใหม่แล้วหรือยัง? หากวันนั้นมาถึง อย่าลืมติดต่อ ISM Technology Recruitment หรือส่ง Resume ของคุณมาได้ที่ https://www.ismtech.net/submit-your-resume แล้วคุณจะพบว่าอนาคตและโอกาสที่ก้าวหน้า กำลังรอคุณอยู่
ISM เชี่ยวชาญในธุรกิจ IT Recruitment & IT Outsourcing โดยเฉพาะ เปิดทำการมากว่า 30 ปี มีพนักงานทุกสายและทุกระดับทางด้าน IT ที่ได้ร่วมงานกับลูกค้าองค์กรใหญ่ที่มีชื่อเสียงและบริษัทข้ามชาติมากมาย
Source: https://betterprogramming.pub/