Blog

Career developmentLeadershipCommunication

จาก Dev สู่ Dev Lead: Skill ที่ขาดไปไม่ใช่เรื่อง Technical

Ratchata Nuanchan

By Ratchata Nuanchan

20 สิงหาคม 2568

จาก Dev สู่ Dev Lead: Skill ที่ขาดไปไม่ใช่เรื่อง Technical

ปัญหาที่เจอทุกวันในการทำงานจริง

  • บางครั้งทาง Business เปลี่ยน Direction
  • บางครั้งก็มี Requirement ใหม่ที่เร่งด่วนเข้ามา

กำแพงที่มองไม่เห็นของ Developer

1. กับดักด้าน Technical ของ Developer ที่เก่งแบบ Pro Player

  • Application Architecture ที่ผมวางไว้ทำให้ทุกคนทำงานต่อง่าย
  • Tech Solution ที่ผมคิดค้นช่วยให้ทีมทำงานได้ Quality
  • Testing Plan ที่ผมออกแบบทำให้ทีมไม่ต้องเจอปัญหาจุกจิก

2. กับดักด้าน Communication ที่มีแต่ช่องว่าง (Gap)

  • แปล Technical ต่างๆ ให้เป็น Business Value ที่ Product Manager เข้าใจ
  • แปล Requirement ให้เป็น Technical Plan ที่ทีมทำตามได้
  • แปล ความเสี่ยงของ Project ให้เป็น Choice ที่ฝ่ายบริหารตัดสินใจได้

3. กับดักด้าน Output ที่เปลี่ยนไป แต่ใจไม่อยากเปลี่ยนแปลง

  • แบ่งปันเทคนิค เพื่อให้เพื่อนร่วมทีมแก้ปัญหาได้เร็วขึ้น
  • สร้าง Tool ที่ทำให้การทำงานของทุกคนง่ายดายกว่าเดิม
  • สร้าง Process เพื่อลดขั้นตอนที่ซ้ำซ้อนและเปิดทางให้งานเสร็จไวขึ้น

Value ต้องวัดจาก “ทีม” ไม่ใช่ “ตัวเอง”

Mindset ของ DeveloperMindset ของ Dev Lead
✅ Clean Code✅ ความสำเร็จของ Project
✅ Architecture ที่แข็งแรง✅ การเติบโตของคนในทีม
✅ Performance ที่ยอดเยี่ยม✅ การตัดสินใจที่ถูกต้อง

Skill สำคัญที่ขาดไปสำหรับการเป็น “Multiplier”

1. Strategic Communication (สื่อสารเชิงกรยุทธ์)

  • สื่อสารขึ้นบน (Upward): คือการสรุปภาพรวมที่ซับซ้อนให้ Manager / Stakeholder เข้าใจได้อย่างชัดเจนโดยปราศจากศัพท์ Technical ที่เกินจำเป็น เพื่อให้พวกเขาสามารถตัดสินใจได้อย่างเฉียบคมและแม่นยำ การนำเสนอด้วย Written Communication คือเครื่องมือที่ทรงพลังที่สุดในสถานการณ์นี้
  • สื่อสารลงล่าง (Downward): คือการสร้างแรงบันดาลใจและทำให้ทีมเห็นภาพใหญ่ร่วมกัน แทนที่จะสั่งว่าต้องทำ 'อะไร' (What) ต้องอธิบายให้ได้ว่า 'ทำไม' (Why) จะได้ผลมากกว่า การสร้างความไว้วางใจและความสัมพันธ์ที่ดี จะทำให้การสื่อสารมีประสิทธิภาพมากขึ้น
  • สื่อสารแนวราบ (Sideways): คือการสร้างความร่วมมือกับทีมข้างเคียง (เช่น QA, Infra, Design) เพื่อให้ Project เดินหน้าไปได้อย่างราบรื่น เป้าหมายคือการลด Conflict และปัญหาคอขวดที่อาจเกิดขึ้น เคล็ดลับสำคัญคือการสื่อสารเชิงรุก โดยเตรียมข้อมูลเพื่อตอบคำถามและคลายข้อกังวลที่ทีมอื่นอาจมี

2. Influence (การโน้มน้าว)

  • เสนอทางเลือก: แทนที่จะตอบว่า “ทำได้” หรือ “ทำไม่ได้” ให้เปลี่ยนบทสนทนาเป็นการตัดสินใจร่วมกันผ่าน Trade-off ที่ชัดเจน เช่น "เรามี 2 ทางเลือกครับ: ทางเลือก A ใช้เวลา 2 Sprint แต่จะเกิด Technical Debt ในระยะยาวเพราะ... ในขณะที่ ทางเลือก B ใช้เวลา 4 Sprint แต่จะทำให้ระบบเรามั่นคงกว่าเพราะ..."
  • ปกป้องทีมจากความไม่สมเหตุสมผล: เมื่อมี Requirement ที่จะสร้าง Technical Debt มหาศาลหรือส่งผลเสียต่อระบบในระยะยาว Dev Lead ต้องกล้าที่จะทักท้วงและต่อรองอย่างมีเหตุผล โดยอ้างอิงถึงผลกระทบที่จะเกิดขึ้นกับธุรกิจ ไม่ใช่แค่ความรู้สึกส่วนตัว

3. การสอนงาน (Mentoring)

  • การสอนงาน = การลงทุน: ใช้เวลา 2 ชั่วโมงสอนงานคนอื่น อาจทำให้งานช้าลงไปบ้างในช่วงแรก แต่อีก 2-3 เดือนข้างหน้า คุณจะได้ Dev อีกคนที่เก่งขึ้นมาช่วยแบ่งเบาภาระงาน นี่คือการลงทุนเพื่อลด “คอขวด”
  • การมอบหมายงาน = การสร้างความเชื่อใจ: การ Delegate งานที่ Challenge แต่ไม่เกินตัวให้กับทีม คือการแสดงความเชื่อใจและเปิดโอกาสให้เติบโต หน้าที่คุณคือ “ตั้งเป้าหมาย” และ “สนับสนุน” อย่าลงไปคุมเองหมดเพราะนั่นคือการ Micromanage

4. Mindset ด้านธุรกิจ (Business Mindset)

  • วัดผลทางธุรกิจให้เป็น: คุณรู้ไหมว่า Feature ที่ทำอยู่ช่วยอะไรกับธุรกิจ? ลด Churn Rate, เพิ่ม Conversion Rate หรือลด Customer Acquisition Cost ได้อย่างไร การเข้าใจโจทย์ธุรกิจที่เป็นจุดเริ่มต้นของ Feature ที่ Developerment จะช่วยให้ตัดสินใจทาง Technical ได้เฉียบคมขึ้น
  • คิดแบบ User: การที่เราจินตนาการออกว่า User คิดอย่างไรช่วยให้เรานำเสนอ Solution ที่แก้ Pain Point ได้จริง ให้พูดคุยกับทีม Product บ่อยๆ หรือดูข้อมูล stat การใช้งานจะช่วยได้ในเบื้องต้น

เติบโตให้ได้ด้วยแผนที่ทำได้จริง

Step 1: Start Small

  • Code Review ที่พัฒนาคน: อย่าแค่ตรวจให้ Functional ถูกต้องเฉยๆ แต่ต้องตรวจให้คนในทีมได้เรียนรู้ได้ลึกขึ้น ลองตั้งคำถามที่ลึกขึ้นดู เช่น "เราจะ Test เคสนี้ให้ครอบคลุมได้ยังไง?"
  • อาสาเป็น Mentor น้องใหม่: เป็น Buddy ให้ Junior Developer ที่เพิ่งเข้ามา ช่วยให้เขาเข้าใจ Culture การทำงานและ Codebase ของทีม

Step 2: Think Bigger

  • ถามให้บ่อยขึ้น: ก่อนจะเริ่ม Coding ลองถาม Product Manager ดูสิครับว่า “ทำไมถึงควรต้องทำ feature นี้”, “เราคาดหวังว่าพฤติกรรมผู้ใช้จะเปลี่ยนไปยังไง?” คุณจะเข้าใจในมุม Product มากขึ้นเพื่อนำไปตัดสินใจเรื่องอื่นๆ ต่อ
  • มีส่วนร่วมกับการวางแผน: อย่าเป็นแค่ผู้ตาม แต่ให้ลองเสนอแนวทางหรือชี้ให้เห็นถึงความเสี่ยงที่คุณมองเห็นในที่ประชุมดูครับ

Step 3: Be Visible

  • เสนอตัวเอง: ลองอาสานำเสนอ Demo ของฟีเจอร์ที่ทีมทำเสร็จ หรือสรุปเรื่อง Technical ที่น่าสนใจใน Knowledge Sharing ของบริษัท
  • คุยกับ Manager: คุยกับ Manager ตรงๆ ว่าอยากเติบโตมากกว่านี้ อธิบายเป้าหมายของคุณเอง และถามว่าคุณควรพัฒนาทักษะด้านใดบ้าง วิธีนี้คือ The best ที่จะทำให้ Manager รับรู้ถึงความตั้งใจของคุณ

ตาคุณแล้ว

เรื่องอื่นๆ ที่คุณอาจจะสนใจ

People Skill for dev

Subscribe to our Email & Follow us on Social Media

อัปเดตความรู้เกี่ยวกับ People, Product, Process และ Tech ได้ก่อนใคร!

Subscribe