Blog

Career GrowthMindsetLeadership

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

Ratchata Nuanchan

By Ratchata Nuanchan

20 สิงหาคม 2568

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

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

ผมเคยคิดว่าทำงานในตำแหน่งที่สูงขึ้น ผมจะได้ทำอะไรที่โคตร Geek, ได้คิด Solution ที่ Advance, ได้ออกแบบระบบที่สามารถ Scalable สุดๆ หรือได้วางโครงสร้าง Application ที่ Perfect มากๆ

จนผมได้ขึ้นมาถึงตำแหน่ง Dev Lead จริงๆ ชีวิตประจำวันของผมอยู่ที่การ Meeting…

ผมได้ทำเรื่อง Technical แค่ 10% แต่ประชุมเป็น 70% ของเวลาทั้งหมด ในทุกๆ วันผมมีประชุมทั้งภายใน Scrum Team, ทั้งภายใน Dev Team, และรวมไปถึงประชุมกับ Stakeholder ด้วย

Dev Lead Bridge

หน้าที่ของ Dev Lead คือการเป็น สะพานเชื่อม ระหว่างทีม Technical และทีม Business

ตอนแรกผมรู้สึกอยู่ไม่ถูกที่มากๆ เพราะ Skill ที่ภูมิใจมาตลอดแทบไม่ได้ใช้เลย กลับต้องเสียเวลามานั่งประชุมเกือบทั้งวันเพราะ

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

ทำให้กว่าจะได้ทำงานจริงๆ ที่เป็นเรื่อง Technical ก็เกือบหมดวันแล้ว

หลังจากปรับตัวอยู่นานผมได้ตกผลึกว่า...

การประชุม ไม่ใช่ การนั่งฟัง หรือ คอยตอบปัญหา เราต่างหากที่ต้องคอย Drive ให้เกิดผลลัพธ์ที่ดีและถูกต้องกับทุกฝ่าย

หากคุณเคยรู้สึกเหมือนผมตอนแรกที่เหมือนอยู่ไม่ถูกที่ ผมอยากจะบอกจากประสบการณ์ในฐานะที่เคยเป็น Developer และ Dev Lead มานับสิบปีว่า "คุณไม่ได้รู้สึกอยู่คนเดียว"

“กำแพง” ที่มองไม่เห็นที่คุณรู้สึกมันเป็นปัญหาที่แก้ไม่ได้นั้น มันแก้ไม่ได้ด้วย Technical Skill แต่มันคือเรื่องของ การเปลี่ยนจาก “ผู้สร้าง” ไปสู่ “ผู้นำ”

Man run thought the wall

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

คุณอาจจะเคยเก่งมากๆ มาก่อนตอนที่ยังไม่ได้เป็น Lead หรือ Manager แต่เมื่อตำแหน่งสูงขึ้นจะเกิดความรู้สึกว่า “ทำไมเราไม่เก่งเลย” ปรากฎการณ์ที่เกิดขึ้นหลายๆ คนก็เป็นครับ ซึ่งมันคือ Imposter Syndrome มันเกิดจากกับดักที่ตัวคุณสร้างขึ้นมาเอง

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

Coding Person

ด้วยประสบการณ์หลายปีที่ผ่านมา ผมถูกหล่อหลอมด้วยความเชื่อที่ว่า ยิ่งเชี่ยวชาญด้าน Technical จะยิ่งไปได้ไกล ความคิดนี้ไม่ผิดเลยครับ แต่จะกลายเป็นกับดักทันที หากเราหมกมุ่นอยู่กับทักษะด้านนี้เพียงด้านเดียว จนละเลยทักษะสำคัญอื่นๆ

ผมเองก็เคยติดอยู่ในกับดักนั้นมานานหลายปี คุณค่าของผมในสายตาตัวเองถูกจำกัดอยู่แค่ด้านเดียว:

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

คุณค่าเหล่านี้คือสิ่งจับต้องได้ และทำให้ผมได้รับความเชื่อมั่นจากเพื่อนร่วมงานมาโดยตลอด... แต่น่าเสียดายที่ความมั่นใจนั้นเองกลับกลายเป็นกำแพงที่ทำให้ผมต้องพบกับ "ทางตัน" ในการเติบโต

ผมกลายเป็น Expert ที่แก้ปัญหา Technical ได้ทุกอย่าง แต่กลับล้มเหลวในการแก้ปัญหาเรื่อง "คน" และ "ทีม" เพราะไม่เคยเปิดโอกาสให้ตัวเองได้พัฒนาทักษะความเป็นผู้นำเลย จากความผิดพลาดที่ผ่านมาทำให้ผมรู้ว่า...

Dev Lead ไม่ได้จำเป็นต้องเป็น Pro Player แต่ต้องเป็น Coach ที่พัฒนาทีมเพื่อสร้าง Pro Player ต่างหาก

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

Developer ส่วนใหญ่ไม่สามารถสื่อสารได้ดี ไม่ใช่เพราะเขาไม่เก่ง แต่เป็นเพราะเรื่องที่ต้องพูดมันซับซ้อน ทำให้ส่วนใหญ่เราสื่อสารกันด้วย Developer Language (ภาษาที่คนทั่วไปไม่เข้าใจ) เช่นเรื่อง Coding, Algorithm และ Software Architecture แต่ Dev Lead ที่ดีต้องสื่อสารได้หลายภาษา เราจำเป็นต้อง “แปล”:

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

การที่ติดอยู่ในโลก Technical อย่างเดียว ทำให้เกิดช่องว่างนี้ขึ้น

ส่วนตัวกับดักนี้เป็นกับดักที่ผมก้าวผ่านมาได้แล้วสนุกที่สุด มันปลดล็อกทำงานผมในหลายๆ ด้าน ปัญหาที่ผมเคยเจอสมัยยังไม่ได้เป็น Lead ก็แก้ปัญหาได้ด้วยจุดเริ่มต้นของ Skill นี้เป็นส่วนใหญ่

Team Celebrating

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

ในวันที่เป็น Developer เราจะถูกวัดผลจากงานส่วนบุคคล ไม่ว่าจะเป็นการ Code ได้เร็วกว่าคนอื่น, Solution ที่เฉียบคมกว่า, หรือแก้ปัญหาซับซ้อนได้ในเวลาอันสั้น คุณค่าที่สร้างจากการแข่งขันกับ Time และ Performance ของตัวเองแบบนี้ เราเรียกว่า การบวก (Addition)

แต่เมื่อก้าวสู่บทบาท Dev Lead ความสำเร็จของคุณไม่ใช่แค่การ บวก แต่คือการ คูณ (Multiplication) คุณคือผู้ที่:

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

ลองจินตนาการดูว่า... Impact จากการที่เพื่อนร่วมทีม 5 คนให้ทำงานเร็วขึ้นคนละ 40% นั้น จะมหาศาลกว่าคุณที่เก่งที่สุดในทีมเพียงคนเดียวขนาดไหน? นี่คือหัวใจของ Impact ที่แท้จริงในฐานะ Leader

มันจะส่งผลกระทบกับ Project โดยรวมมากกว่าที่คนเดียวทำได้หรือเปล่า?

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

Senior VS Lead

การเปลี่ยนแปลงที่ยากที่สุดไม่ใช่ Skill ใหม่ แต่คือการเปลี่ยนมุมมองใหม่ต่อ “คุณค่า” ของตัวเองโดยสินเชิง

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

ผมขอเปรียบเทียบกับร้านอาหารได้เห็นภาพกันง่ายๆ

Senior คือ Head Chef ที่ทำอาหารได้อร่อยไร้ที่ติ

Lead คือ Executive Chef ที่ออกแบบเมนู, ควบคุณคุณภาพวัตถุดิบ, สอนเทคนิคให้ Chef คนอื่นๆ และบริหารให้ทั้งครัวทำงานได้อย่างราบรื่น เพื่อให้ร้านอาหารประสบความสำเร็จในภาพรวม

การเปลี่ยนผ่านนี้คือการยอมรับว่า Value ของคุณที่เคยทำอาหารอร่อยไม่ได้ลดลง แต่กำลังถูกยกระดับไปอีกขั้นผ่านความสำเร็จของคนอื่นด้วยความช่วยเหลือของคุณต่างหาก

If you are a leader, the people are your work.

Gerald M. Weinberg

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

หลังปรับ Mindset ได้แล้ว Next Step คือการสร้าง Skill ที่จำเป็น ซึ่งในที่นี้ผมขอแนะนำให้เริ่มด้วย People Skills

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

Communication คือทักษะที่ทรงพลังและซับซ้อนที่สุดในฐานะ Leader มันไม่ใช่แค่การ "พูดให้รู้เรื่อง" แต่คือศิลปะของการส่งสารให้ "ถูกคน ถูกที่ และถูกเวลา"

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

ถึงเป็นการสื่อสารเหมือนกันแต่จะเห็นได้ว่า Meaning และ Feeling ที่ต้องการสื่อสารออกไปนั้นแตกต่างกันอย่างสิ้นเชิง ดังนั้นจึงควรใช้ให้ถูกบริบท

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

บทบาทของ Dev Lead ไม่ใช่ Messenger ที่รับคำสั่งมาแล้วส่งต่อ แต่เป็น Technical Advisor ที่น่าเชื่อถือของทีม Product และ Business ต่างหาก

การโน้มน้าวใจนี้มีสิ่งสำคัญ 2 อย่าง:

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

Meeting to select choice

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

กับดักที่หลายคนทำบ่อยเลยคือ “ทำเองเร็วกว่า” ซึ่งเป็นความคิดที่อันตรายมากต่อการเติบโตของคุณเอง ลองเริ่มปรับที่ 2 Mindset นี้:

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

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

หากถามผมว่าความต่างของ Good Dev Lead และ Great Dev Lead คืออะไร? มันคือ Mindset ด้านธุรกิจ

ทักษะนี้คือความสามารถที่เชื่อมโยงทุกอย่างให้เข้าสู่เป้าหมายของธุรกิจได้อย่างแท้จริง

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

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

คุณไม่จำเป็นต้องรอให้ได้ตำแหน่ง Dev Lead ก่อนถึงจะเริ่มคิดเรื่องเหล่านี้ แต่คุณสามารถมี Mindset แบบ Dev Lead ได้ตั้งแต่วันนี้เพราะ Dev Lead ที่แท้จริงไม่ใช่ตำแหน่ง แต่คือ Mindset และสองมือต่างหาก

Step 1: Start Small

คุณไม่ต้องคิดการใหญ่ การปรับเปลี่ยนอะไรที่อลังการที่อำนาจคุณยังไม่ถึง แต่ลองเปลี่ยนเรื่องเล็กๆ ใกล้ตัวก่อน ทำตามตัวอย่างเหล่านี้ดูครับ:

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

Step 2: Think Bigger

หากอยากไปสู่อีกระดับต้องมี Ownership ลองคิดดูว่าเราจะ Improve จะอะไรได้และทำให้มันเกิดขึ้น เช่น:

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

Step 3: Be Visible

อย่าปิดทองหลังพระ มีความสามารถอะไรต้องแสดงให้เห็นและต้องนำเสนอให้เป็น ลองเริ่มง่ายๆ ครับ:

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

ตาคุณแล้ว

จาก Dev สู่ Dev Lead คือการเปลี่ยนแปลงตัวเอง เปลี่ยนจาก Tech Expert เป็น Tech Leader ต้องอาศัยความกล้าที่จะออกจาก Comfort Zone และต้องถ่อมตนที่จะเรียนรู้อะไรใหม่ๆ ที่ไม่คุ้นเคย

บทความนี้เป็นเพียงจุดเริ่มต้นเท่านั้น การเติบโตจริงต้องอาศัยการลงมือทำและเรียนรู้อย่างสม่ำเสมอ หากคุณอ่านถึงตรงนี้และอยากได้ไอเดีย, เทคนิค, และเรื่องเล่าจากสนามจริงไปปรับใช้ให้เร็วขึ้น ติดตามเราได้บน Social Media เราจะแชร์เนื้อหาเข้มข้นที่นำไปใช้ได้จริงสำหรับเส้นทางนี้โดยเฉพาะ

ถึงเวลาทลายกำแพงที่มองไม่เห็น และปลดล็อกความเป็น Leader ที่อยู่ในตัวคุณแล้ว

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

E-Book People Skill for Dev

©2025 Achi Innovation Co., Ltd. All Rights Reserved.