สรุปสิ่งที่น่าสนใจจาก Webinar: Act like a tech lead
วันก่อนมีโอกาสได้เข้าไปดู Webinar: Act like a tech lead: Transition of a developer who works with code to collaborate with a team ของเพื่อนร่วมงาน ขณะที่เรากำลังเขียนบทความนี้แม้เรายังไม่ได้เป็น tech lead แต่ก็มีโอกาสที่จะต้อง lead งานบางอย่าง เช่น feature หรือ slice of values ชิ้น ๆ นึง ทำให้เราคิดว่าเราได้ประโยชน์จาก webinar นี้ นอกจากนั้นแล้วเรายังสามารถนำคำแนะนำที่น่าสนใจสำหรับการเป็นมือใหม่หัด lead ไปใช้ในการให้ feedback เพื่อนร่วมงานได้อีกด้วย
ความรู้สึกแรกเมื่อมาสวมหมวก tech lead
- งงมากเลย ไม่รู้ว่าต้องทำอะไร ควรหรือไม่ควรจะทำอะไร เนื่องจากขอบเขตการทำงานและอำนาจในการตัดสินใจไม่ชัดเจน
- ยากที่ต้องคุยกับคนหลาย ๆ คน หลาย ๆ ทีมเพราะคนคือตัวแปรสำคัญที่สุดในการพัฒนาส่งมอบ software
- รูปแบบการทำงานที่เคย work กับ project นึงกลับไม่ work กับ project อื่น ๆ
ความรู้สึกเมื่อสวมหมวก tech lead ไปสักระยะนึง
- ความรับผิดชอบย้ายจากการเขียน code ไปที่ภาพรวมใหญ่ของการส่งมอบ software มากขึ้น
- แต่ละวันยุ่งมาก งานเต็มมือ ประชุมเยอะ ไม่มีอะไรเสร็จเป็นชิ้นเป็นอันสักกะอย่าง
- ต้องตัดสินใจโดยที่ไม่มีข้อมูลหรือมีไม่ครบ กลัวผิดพลาดไปหมด เพราะถ้าเราตัดสินใจผิดขึ้นมา ทีมจะเดือดร้อน โดยเฉพาะถ้าทีมไม่ได้สนิทกันมากจะยิ่งรู้สึกเจ็บปวด
- เราไม่รู้ว่าสิ่งที่เราทำลงไปดีไหม ปัญหาที่เรากำัลงแก้มันเป็นปัญหาจริง ๆ ไหม
- เราคิดว่าทุกอย่างเป็นหน้าที่ความรับผิดชอบของเราหมด ถ้าให้คนอื่นทำ จะเกิดความคิดว่าเราดูไม่ทำอะไร
สิ่งที่ได้เรียนรู้จากการเป็น tech lead
- ในบางครั้งปัญหาของคนอื่นมักแก้ง่ายกว่าปัญหาของตนเอง
- เราไม่ต้องเก่งไปซะทุกอย่างเพราะมันท้าทายมากกกกก ขอแค่ทำให้คนในทีมของเราเก่งมากพอที่เมื่อเราไม่รู้พวกเขาจะยังพอช่วยเราได้บ้าง
- ถ้าเราทำงานเองทั้งหมดเราเนี่ยแหละจะกลายเป็นคอขวดของทีมเพราะความรู้และทักษะมาตกอยู่ที่เราคนเดียว
- ถ้าทีมตัดสินใจผิด ทีมจะช่วยกันแก้ปัญหา ในทางกลับกันถ้าเราตัดสินใจผิด เราต้องมาโน้มน้าวให้ทุกคนมาแก้ปัญหาของเรา
- คนส่วนใหญ่จะกรีดร้องเมื่อปัญหาที่เกิดมีผลระทบกับเขา
- การประชุมคือการสร้างความเข้าใจว่าปัญหาอยู่ตรงไหน เราจะช่วยเหลือทีมได้อย่างไร
คำแนะนำกับการเป็น tech lead
- หาที่ปรึกษา (mentor หรือ buddy) การมีคนมาช่วยจะเปิดมุมมองอื่น ๆ ในการแก้ปัญหาและช่วยย่อยปัญหาออกมาเป็นรูปธรรมชัดเจนเพื่อให้เรา focus ไปกับการแก้ปัญหาที่ใช่
- เป็น champion สักสายนึงเพื่อเข้าใจ tradeoff ในการเลือกสิ่งที่ดีสุดในช่วงเวลา ณ ขณะนั้น
- เรียนรู้วิธีการทำงานร่วมกับ role อื่น ๆ ในทีมหรือองค์กรให้ได้ดีที่สุด พูดภาษาเดียวกันกับพวดเขาเพื่อใช้เป็นเครื่องมิือที่ช่วยให้ทุกคนเข้าใจปัญหาตรงกันที่อาจจะมองจากคนละมุม ทำให้เขาสามารถช่วยเหลือเราได้
- เรียนรู้วิธีจัดการเรื่องการเมืองภายในโดยการ balance ความต้องการของ KPI ต่าง ๆ ที่เกิดจากที่แต่ละทีมหรือฝั่งในองค์กรต่างก็อยากได้สิ่งที่ตนต้องการโดยไม่ได้สนใจว่าคนอื่นจะเกิดผลกระทบอะไรบ้าง
- เมื่อรู้สึกยุ่งมากให้จัดลำดับความสำคัญของงาน (เช่นใช้ Eisenhower Matrix) แต่เผื่อใจไว้เลยว่าลำดับมันจะไม่เป็นแบบนั้นเป๊ะ ๆ หรอกเพราะมีปัจจัยภายนอกเข้ามา เช่น งานแทรก งานกรรมเก่าของคนอื่น งานฟ้าประทาน เป็นต้น
- แบ่งงานให้คนอื่นทำ (delegate) และช่วยให้คนอื่นทำงานนั้นโดยง่ายที่สุดแทน เช่น ไปหาอะไรที่เขาต้องการในการทำงานนั้นให้สำเร็จมาให้ เป็นต้น
- เลือกข้อมูลที่จะปล่อยไหลลงไปหาทีม อย่าปล่อยไปทั้งหมด เพราะทีมจะเกิดการขัดจังหวะจนไม่ได้ focus กับงานที่เกิดขึ้นตรงหน้า ในขณะเดียวกันก็อย่าปิดบังอะไรที่สำคัญ ๆ เกิดทีมมารู้ทีหลังทีมจะไม่เชื่อใจเรา
- อย่าปล่อยให้ของทุกอย่างตกลงมาที่เราคนเดียว ให้คนหรือทีมที่มีข้อมูลมีความเข้าใจในปัญหามากกว่าเป็นคนตัดสินใจ
- ก่อนจะแก้ปัญหา ให้คุยกับทีมเยอะ ๆ เพื่อทำความเข้าใจว่าปัญหาที่กำลังจะแก้เป็นปัญหาสำหรับเขาจริง ๆ ใช่ไหม แล้วมันเป็นปัญหาที่มีร่วมกันยังไง เพื่อที่จะได้แก้ปัญหาที่ใช่
- Focus ไปที่ outcome มากกว่า output คิดก่อนทำว่าทำไปแล้วมันคุ้มกับผลลัพธ์ที่ดีที่จะขึ้นกับทีมไหม ทำไปแล้วทีมเคลื่อนที่ไปข้างหน้าได้มากแค่ไหน
- หาความสำเร็จเล็ก ๆ ในแต่ละวันให้เรามีกำลังใจ เช่น เอากระดาษมาจด meeting notes อย่างน้อยก็ได้กระดาษติดมือมา
ถึงแม้จะได้คำแนะนำมาหลายอัน แต่เราก็ไม่ได้คิดว่ามันทำให้การเป็น tech lead มันง่ายขึ้นเลย ฮ่า ๆๆ ดังนั้นก่อนจะมาเป็น tech lead เราต้อง Act like a tech lead เพื่อทำการฝึกทักษะและสั่งสมประสบการณ์อย่างต่อเนื่อง เมื่อก้าวขึ้นมาเป็น tech lead จะได้ไม่รู้สึกมันหนักจนเกินไป