- แม้ CTO หลายคนจะเปลี่ยนไปโฟกัสด้านการจัดการ แต่ยังคงรักษาแนวทางในการเขียนโค้ดและพัฒนาผลิตภัณฑ์ด้วยตัวเอง
- สร้าง leverage สูงภายในองค์กรผ่านงานพัฒนา 3 ประเภท ได้แก่ โปรเจ็กต์เชิงทดลอง คำขอลูกค้าเร่งด่วน และการแก้บั๊ก
- การเขียนโค้ดอย่างต่อเนื่องช่วยให้สัมผัสได้โดยตรงถึงประโยชน์ใช้จริงและข้อจำกัดของเครื่องมือ AI และทำให้การตัดสินใจทางเทคนิคอยู่บนพื้นฐานความเป็นจริง
- ให้ความสำคัญและมีแพสชันกับการแก้ปัญหาและการสร้างผลิตภัณฑ์มากกว่าการจัดการ และออกแบบโครงสร้างองค์กรให้รองรับแนวทางนี้
- บทบาท CTO ไม่มีกรอบตายตัว และหัวใจสำคัญคือการหารูปแบบความเป็นผู้นำที่เหมาะกับจุดแข็งของตนเองและสถานการณ์ของบริษัท
เหตุผลที่ผมยังเขียนโค้ดต่อในฐานะ CTO
- CTO หลายคนหยุดเขียนโค้ดเมื่อเวลาผ่านไป แต่ผมยังคงทำงานแบบพัฒนาฟีเจอร์และ deploy ด้วยตัวเอง
- ตลอด 12 เดือนที่ผ่านมาได้ปล่อยฟีเจอร์สำคัญหลายรายการโดยไม่มีทีมที่รายงานตรงกับผม
- ไม่ใช่แค่ระดับงานอดิเรก แต่ทำหน้าที่เป็นผู้พัฒนาฟีเจอร์หลักที่ถูกนำไปใช้จริงในผลิตภัณฑ์
- ผมมองว่านี่คือ “หนึ่งในกิจกรรมที่มี leverage สูงที่สุดในฐานะผู้นำด้านเทคนิค”
โปรเจ็กต์ 3 ประเภทที่ผมสร้างจริง
1. โปรเจ็กต์เชิงทดลองระยะยาว (Long-horizon experimental projects)
- ในองค์กร คนที่สามารถสร้างผลิตภัณฑ์ใหม่ขึ้นมาจริง ๆ ได้มีอยู่อย่างจำกัดมาก
- เพราะองค์กรส่วนใหญ่โฟกัสกับการดูแลและขยายผลิตภัณฑ์เดิม
- มีเพียงผู้ก่อตั้ง ผู้บริหารบางคน และ individual contributor (IC) ที่มีผลงานสูงบางรายเท่านั้นที่พอมีพื้นที่ให้ลองทำผลิตภัณฑ์ใหม่
- ด้วยโครงสร้างองค์กร แรงจูงใจจาก roadmap และงบประมาณความเสี่ยงที่จำกัด ทำให้วิศวกรส่วนใหญ่ไม่สามารถผลักดันโปรเจ็กต์ที่ไม่แน่นอนได้เป็นเวลาหลายเดือน
- CTO อยู่ในตำแหน่งที่พิเศษ เพราะมีความเข้าใจเชิงลึกทั้ง pain point ของลูกค้าและสถาปัตยกรรมระบบ จึงสามารถผลักดันโปรเจ็กต์ทดลองที่มีความไม่แน่นอนสูงได้อย่างรวดเร็ว
- แม้จะมีบางกรณีที่ล้มเหลว แต่ก็มีความสำเร็จครั้งใหญ่เช่นกัน
- กรณีผลิตภัณฑ์ AI chat: เป็นโปรเจ็กต์ที่ทีมเห็นคุณค่า แต่ถูกเลื่อนออกไปเพราะไม่มีเวลาและช่องว่างมากพอ จึงพัฒนา prototype ระหว่างช่วงวันหยุด Thanksgiving
- หลังจากนั้นร่วมมือกับทีมและทำให้กลายเป็นผลิตภัณฑ์เชิงพาณิชย์ที่สร้าง ARR หลายล้านดอลลาร์ได้สำเร็จ
2. การรับมือคำขอลูกค้าเร่งด่วน (Critical customer asks)
- บางครั้งฟีเจอร์ที่ลูกค้ารายสำคัญต้องการอย่างเร่งด่วนจะกลายเป็นตัวขวางการปิดดีลใหญ่หรือการต่อสัญญา
- แทนที่จะดึงวิศวกรที่กำลังทำงานอยู่ในสปรินต์ปัจจุบัน CTO สามารถลงมือจัดการเองโดยอาศัยการตัดสินใจที่รวดเร็วและความเข้าใจทั้งระบบ
- ตัวอย่างจริง: คำขอฟีเจอร์data redaction เพื่อรองรับ compliance ของลูกค้าที่จ่ายปีละหนึ่งล้านดอลลาร์
- จากการประเมินเบื้องต้นของทีม คาดว่าลูกค้าอาจต้องสร้าง API integration เอง หรือจำเป็นต้องมีหลายรอบประชุมระหว่าง product, legal และ engineering
- แต่ CTO สร้างและ deploy เวอร์ชันที่ใช้งานได้จริงภายในวันเดียว ทำให้รักษาความสัมพันธ์กับลูกค้าไว้ได้
3. การแก้บั๊ก (Bugfixes)
- หลายคนอาจแปลกใจ แต่การแก้บั๊กเป็นหนึ่งในวิธีโปรดในการรักษา mental map ของ codebase
- ไม่ว่าจะเป็นการไล่หาสาเหตุว่าทำไม pagination พังในหน้าที่ 3 ของผลการค้นหา หรือทำไมการเชื่อมต่อ WebSocket ถึงหลุดพอดีหลัง 60 วินาที มันทำให้ต้องวิ่งผ่านระบบทั้งหมด
- ได้มาซึ่งความเข้าใจเชิงสัญชาตญาณต่อ technical debtที่ยากจะได้จากแค่ code review หรือการคุยเรื่องสถาปัตยกรรม
- ประสบการณ์แบบนี้ช่วยรักษาสัญชาตญาณที่จำเป็นต่อการตัดสินใจทิศทางและลำดับความสำคัญของการลงทุนด้านเทคนิค
เหตุผลที่ยังเขียนโค้ดต่อ
1. เพื่อให้รู้ว่าเทคโนโลยีอะไรใช้ได้จริง
- การได้ใช้งานเครื่องมือ AI ทุกวันอย่าง Claude Code, Codex และ Cursor ทำให้สามารถแยกความจริงออกจากกระแส hype ได้เวลาต้องตัดสินใจเรื่องเครื่องมือและกลยุทธ์การจ้างงาน
- ตัวอย่างล่าสุด: เคยลองทำฟีเจอร์ที่ไปแตะ integration ซับซ้อนด้วยการ vibe-coding แต่ไม่คืบหน้า พอลงมือเขียนเองกลับไปได้เร็วกว่าอย่างมาก
- ปริมาณโค้ดไม่ได้เยอะมาก แต่ต้องการตรรกะที่แม่นยำ ซึ่งเป็นจุดที่ LLM เปราะบาง
- ในทางกลับกัน ฟีเจอร์ขนาดใหญ่อีกตัวหนึ่งแทบพัฒนาทั้งหมดด้วย Claude Code
- การรู้ว่าAI เก่งตรงไหน (CRUD, tests, boilerplate) และพลาดตรงไหน (ความแม่นยำ, nuance ของระบบ) ดีกว่าการตัดสินใจจากกระแสบน Twitter
- เมื่ออยู่ในโค้ดโดยตรง จะสามารถรับรู้ได้ว่าควรกดดันหรือผ่อนคลายตอนไหน
- มองออกว่าสถาปัตยกรรมเริ่มซับซ้อนเกินไปเมื่อไร หรือ technical debt เริ่มกลายเป็นปัญหาจริงเมื่อไร
- ผู้จัดการที่พึ่งแต่รายงานอาจพลาดหลายอย่างไป
2. เพื่อโฟกัสกับสิ่งที่ตัวเองเก่งและชอบจริง ๆ
- ผมไม่ได้ชอบการสร้างองค์กรและการบริหารคนเป็นพิเศษ
- การจัดการทีมวิศวกรรมต้องอาศัยพลวัตด้านความสัมพันธ์ระหว่างคน การประเมินผลงาน และการออกแบบองค์กร
- มันเป็นหน้าที่สำคัญ แต่ไม่ใช่พื้นที่ที่ผมมีจุดแข็ง
- เพราะอย่างนั้นจึงจ้าง engineering manager และผู้นำที่เก่ง
- เพราะพวกเขาทำได้ดีกว่าและสนุกกับมันมากกว่า
- ทำให้ CTO สามารถโฟกัสกับการพัฒนาผลิตภัณฑ์ การแก้ปัญหาทางเทคนิค และการเขียนโค้ดได้
- สตาร์ตอัปก็เหมือน “มาราธอนแบบสปรินต์” จึงออกแบบบทบาทให้ยึดกับงานที่ช่วยให้ยังคงสนุกและวิ่งได้เร็วไปอีกนาน
- นี่คือวิธีที่ยั่งยืนในระยะหลายปี และสำคัญมากต่อบริษัท
3. เพราะเครื่องมือ AI ขยาย leverage ได้มากขึ้น
- เมื่อไม่กี่ปีก่อน การหาเวลาเขียนโค้ดไปพร้อมกับจัดการงานเชิงกลยุทธ์เป็นเรื่องยาก
- เมื่อบริษัทเติบโตขึ้น ก็ต้องติดอยู่ในประชุมทั้งวันและทำงานนอกพื้นที่ที่ตัวเองถนัด
- นั่นเป็นหนึ่งในช่วงที่ยากที่สุดในชีวิตการทำงาน
- เครื่องมือ AI สมัยใหม่เปลี่ยนสมการนี้ไปอย่างสิ้นเชิง (โดยเฉพาะในช่วงไม่กี่เดือนที่ผ่านมา)
- ผลิตภาพเพิ่มขึ้น 2–3 เท่าเมื่อเทียบกับเดิม
- เครื่องมือเหล่านี้ไม่ได้แทนที่วิจารณญาณหรือความรู้ทางเทคนิค แต่กลับทำให้ทักษะเหล่านั้นมีคุณค่ามากขึ้น
- หากสั่งเครื่องมือ AI ว่า "สร้าง data export ที่ต้องตรงกับฟอร์แมต CSV export เดิม แต่เพิ่มอีก 3 ฟิลด์จากตาราง user profile" มันจะสร้างโค้ดส่วนใหญ่ได้ถูกต้อง
- เพราะเรามีบริบทเชิงลึกว่าต้องการอะไรแน่และควรไปหาได้จากที่ไหน
- วิศวกรที่ไม่คุ้นกับ codebase ส่วนนั้นอาจต้องใช้เวลาพอสมควรในการไล่หารายละเอียด
- งานจึงเปลี่ยนจาก "เขียนโค้ดทุกบรรทัด" ไปเป็น**"ให้บริบท ตัดสินใจ และประเมินทางแก้"**
- ซึ่งโชคดีที่ผมมีบริบทเหล่านั้นอยู่มาก
ค้นหาแนวทางที่เหมาะกับตัวเอง
- ตอนนิยามบทบาท CTO ผมอ้างอิง โพสต์บล็อกของ Greg Brockman ว่าด้วยการนิยามบทบาท CTO ที่ Stripe
- หลังจากคุยกับ CTO หลายคน ก็พบว่ารูปแบบของบทบาทนี้แตกต่างกันอย่างมาก
- CTO บางคนเป็นนักวางวิสัยทัศน์เทคโนโลยี บางคนเป็นผู้สร้างองค์กร บางคนเน้นโครงสร้างพื้นฐาน
- สิ่งที่เหมือนกันคือ CTO ที่ยอดเยี่ยมจะรู้ว่าต้องไปสร้างคุณค่าให้มากที่สุดตรงไหน โดยพิจารณาจากทักษะเฉพาะตัว ความสนใจ และสถานการณ์ของบริษัท
- สำหรับผู้เขียน นั่นหมายถึงการเขียนโค้ดจำนวนมาก
- ชอบสร้างซอฟต์แวร์มากกว่าการออกแบบองค์กร
- มีประสิทธิภาพเป็นพิเศษจากความรู้เชิงลึกเกี่ยวกับลูกค้าและ codebase
- และจ้าง engineering manager ที่แข็งแกร่ง
- แต่นี่คือเส้นทางส่วนบุคคล ไม่ใช่สูตรสำเร็จ
- บทบาท CTO มีความยืดหยุ่นสูง
- ไม่ว่าจะเป็นการสร้างองค์กร การวางกลยุทธ์ผลิตภัณฑ์ หรือด้านอื่น ๆ ภาวะผู้นำทางเทคนิคสามารถหลากหลายได้ตามจุดแข็ง แหล่งพลังงาน และความต้องการของบริษัท
- สำหรับวิศวกรที่กังวลว่าการเป็นผู้นำหมายถึงการต้องทิ้งงานเทคนิคไป: ยังมีเส้นทางอีกมาก
- หัวใจสำคัญคือการค้นหาพื้นที่ที่คุณโดดเด่นอย่างมีเอกลักษณ์
5 ความคิดเห็น
ผมเป็น CTO ที่กำลังทำงานอยู่ และไม่ค่อยเห็นด้วยกับบทความนี้อย่างมาก
ผมเห็นด้วย 100% ว่าไม่ควรละทิ้งการเขียนโค้ด แต่ไปทำโอเพนซอร์สที่ไม่เกี่ยวกับผลิตภัณฑ์ของบริษัทก็พอแล้ว ผมคิดว่านี่เป็นมุมมองที่ใช้ได้เฉพาะในกรณีที่ต้องทำงานแบบรอบด้านในฐานะ technical founder ของสตาร์ทอัพระยะเริ่มต้นเท่านั้น
เจ้าตัวก็คงดีอยู่หรอก… แต่บริษัทล่ะ?
ก็ควรทำงานให้สมกับเงินเดือนที่ได้รับ…
ค่อนข้างแปลกใจที่ CTO ลงมือทำโปรเจกต์เชิงทดลองด้วยตัวเอง ถ้าให้เวลาทีมปฏิบัติการอย่างเพียงพอ พวกเขาก็น่าจะทำออกมาได้ดีอยู่แล้ว สิ่งที่น่าแปลกใจที่สุดคือการที่โปรเจกต์เชิงทดลองระยะยาวต้องให้ CTO เป็นคนดำเนินการเพียงคนเดียว หากเจ้าตัวมีอำนาจในการใช้ทรัพยากรอยู่แล้ว ก็น่าจะจัดหาทรัพยากรสำหรับโปรเจกต์เชิงทดลองแยกต่างหาก แล้วให้เวลาทีมปฏิบัติการอย่างเพียงพอก็น่าจะพอแล้ว
เส้นทางส่วนตัว.. คงต้องบริหารจัดการให้ดีเพื่อไม่ให้งานด้านการจัดการองค์กรเพิ่มขึ้นเรื่อย ๆ สินะ..
ความคิดเห็นจาก Hacker News
ถ้าฉันกำลังคิดอยู่ว่าจะสมัครเข้าบริษัทไหนดี แล้วเห็นโพสต์บล็อกที่ CTO อวดว่าคอมมิตโค้ดทุกสุดสัปดาห์ ฉันคง เตรียมวิ่งหนี
หน้าที่ของผู้นำคือการสร้าง วัฒนธรรมองค์กร ที่ดีต่อสุขภาพ แต่การอวดว่าทำงานวันหยุดเป็นสิ่งตรงกันข้าม
ยิ่งไปกว่านั้น การพูดต่อสาธารณะว่าข้ามขั้นตอนตรวจสอบด้านกฎหมายหรือวิศวกรรมแล้วแก้ปัญหาลูกค้าได้ภายในวันเดียว เป็นสัญญาณอันตราย
ในสตาร์ตอัประยะแรก วัฒนธรรมต่างกันโดยสิ้นเชิง และบทความแบบนี้กลับทำหน้าที่เป็น ตัวกรองคัดคนที่เหมาะสม ได้
โค้ดที่ฉันเขียนส่วนใหญ่ใช้เพื่อปรับปรุง DevEx ภายใน หรือจัดการ technical debt
ฉันไม่เคยข้ามการตรวจสอบด้านกฎหมาย และจะทำแค่ระดับ PoC มากกว่าโค้ดโปรดักชัน
สำหรับ CTO ผู้ก่อตั้ง การอยู่ใกล้ชิดกับโค้ดเป็นเรื่องสำคัญ แต่หัวใจคืออย่าเสียสมดุล
บทบาทของ CTO ต่างกันไปในแต่ละบริษัท
เหมือนกรณีของ Greg Brockman ที่ Stripe บาง CTO เป็น นักวางวิสัยทัศน์ด้านเทคโนโลยี บางคนเป็น ผู้ออกแบบองค์กร และบางคนเน้นโครงสร้างพื้นฐาน
สำหรับฉัน ฉันสนุกกับการเขียนโค้ดและมีส่วนร่วมลึกกับทั้งลูกค้าและ codebase ดังนั้นนั่นจึงเป็นวิธีสร้างคุณค่าที่มากที่สุดของฉัน
ตำแหน่ง “CTO” เป็นตำแหน่งที่นิยามได้คลุมเครือ
CTO บางคนมาจากผู้ก่อตั้งและเขียนโค้ดได้อย่างอิสระ ขณะที่บางคนทำงานแบบยึดลูกค้าเป็นศูนย์กลางจนสูญเสียสิทธิ์เข้าถึงโค้ด
ในทางกลับกันก็มี CTO แบบเผด็จการอยู่เช่นกัน
สุดท้ายต้องทำให้ชัดก่อนว่าเป็น CTO แบบไหน คำถามว่า ‘ทำไมถึงเขียนโค้ด’ จึงจะมีความหมาย
ในกรณีนี้ชื่อ CTO เป็นเพียงการแบ่งบทบาทเท่านั้น
CTO โฟกัสที่กลยุทธ์และทิศทาง ส่วน VP โฟกัสการบริหารงานวิศวกรรมประจำวัน
จะทำผ่านการสร้างองค์กรหรือการลงมือเขียนโค้ดเองก็ได้
ถ้าผู้บริหารลงมือเขียนโค้ดเอง อาจทำให้ code review บิดเบี้ยว และทำให้ทีมสับสนได้
สุดท้ายคนคนนั้นอาจไม่ใช่ CTO แต่ในใจยังเป็น นักพัฒนา อยู่มากกว่า
ฉันไม่ได้คัดค้านการที่ CTO เขียนโค้ดโดยสิ้นเชิง แต่ในกรณีนี้มันดูเหมือน ทำหน้าที่ CTO ได้ไม่เพียงพอ
ภาวะผู้นำทางเทคนิคที่แท้จริงกลับถูกแบกรับโดยวิศวกรผู้ก่อตั้ง ทั้งที่ได้รับผลตอบแทนน้อยกว่ามาก ซึ่งเป็นปัญหา
CTO ที่ไม่มีสายการรายงานและเอาแต่เขียนโค้ด น่าจะใกล้กับ บทบาทนักพัฒนาระดับซีเนียร์ มากกว่าบทบาทเชิงกลยุทธ์
ฉันเองก็เคยได้รับข้อเสนอแบบนั้น แต่สุดท้ายมันก็เป็นเพียง ตำแหน่งเชิงพิธีการ
ถ้าองค์กรใหญ่ขึ้น บทบาทก็น่าจะเปลี่ยนไป
ในสตาร์ตอัปเล็ก ๆ ฉันทำสปรินต์ไปพร้อมกับทีม และถ้ากำหนดการล่าช้า หน้าที่ของฉันคือแก้ต้นตอของปัญหาและดูแลคนที่หมดไฟ
แต่ถ้าดูจากบทความแล้ว ทีมอยู่ในโครงสร้างที่ ไม่มีแม้แต่เวลาจะลองโปรเจกต์ AI ที่กำลังร้อนแรง นั่นคือปัญหาเชิงองค์กร
CTO ควรแก้ คอขวดเชิงระบบ แบบนี้ ไม่ใช่ลงมือเขียนโค้ดเอง
ในแต่ละบริษัท บทบาทของ “Senior” หรือ “Head” ต่างกันอย่างสิ้นเชิง
ปัญหาที่เกิดขึ้นเมื่อ CTO หมกมุ่นกับการเขียนโค้ดมากเกินไปนั้นชัดเจน
เช่น PR review บิดเบี้ยว ละเลยงานหลัก บทบาทสับสน และกระทบต่อความเป็นอิสระของทีม
แนวคิดที่ว่า “CTO ไม่ควรเขียนโค้ดและควรทำแต่กลยุทธ์” เป็น ความคิดแบบเครื่องจักร
แก่นของบริษัทเทคโนโลยีคือ การส่งมอบคุณค่า และบางครั้งการที่ CTO ลงมือสร้างฟีเจอร์ใหญ่ได้ภายในวันเดียว อาจเป็นงานที่มีคุณค่ามากที่สุดก็ได้
มันอาจเป็นหนึ่งวันที่มีประสิทธิผลมากกว่าการประชุม KPI เสียอีก
บางครั้งผู้บริหารระดับ C ก็จำเป็นต้องกลับไปทบทวน ความรู้สึกหน้างานจริง ด้วยตัวเอง
บางคนอาจได้เป็น CTO ก็เพียงเพราะเป็น ผู้ร่วมก่อตั้ง
ถ้านำแนวทางแบบนี้ไปเข้าบริษัทอื่น ก็อาจยังไม่ถึงระดับ Staff Engineer ด้วยซ้ำ
สุดท้าย เรื่องที่ว่าใน หน้าราคา ของเว็บไซต์บริษัทไม่มีราคาจริงอยู่เลย อาจทำให้สับสนได้ จึงควรแก้ไข