Startup CTO's Handbook - คู่มือสำหรับ CTO สตาร์ทอัพ
(github.com/ZachGoldberg)- นำเสนอเนื้อหาหนังสือ Startup CTO's Handbook เวอร์ชันล่าสุด โดยสามารถอ่านเนื้อหาได้ในรูปแบบ Markdown
- สามารถซื้อหนังสือได้ที่ Amazon และ Audible
- ลิงก์สำหรับเรนเดอร์เวอร์ชัน Markdown ล่าสุดเป็น PDF ยังอยู่ในสถานะ Coming Soon และต้นฉบับเดิมในปัจจุบันมีอยู่เป็นเวอร์ชันเก่าบน Google doc
- สนับสนุนให้มีส่วนร่วมผ่าน issue และ pull request เพื่อสะท้อนการเพิ่มเติม การเปลี่ยนแปลง ข้อเสนอแนะ และคำวิจารณ์ในฉบับต่อ ๆ ไป
- ไลเซนส์อนุญาตให้คัดลอก แก้ไข และแจกจ่ายต่อได้ โดยมีเงื่อนไขว่าไม่ขายต่อ ต้องคงชื่อผู้เขียนและการระบุเจ้าของลิขสิทธิ์ไว้ และเผยแพร่เวอร์ชันต่อ ๆ ไปภายใต้ไลเซนส์ที่คล้ายกันหรือเหมือนกัน
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
มีบางส่วนที่เห็นด้วยอย่างชัดเจน เช่น ผมเห็นด้วยกับการ บันทึกวิดีโอการประชุมทั้งหมด แต่ก็มีหลายส่วนที่โดยส่วนตัวไม่เห็นด้วย เช่น เรื่องการบริหารผลงาน[0]
ไม่ได้หมายความว่าจะวิจารณ์เสียทีเดียว แต่หมายความว่าแต่ละขอบเขตปัญหาอาจต้องใช้วิธีเข้าถึงและสไตล์ภาวะผู้นำที่ต่างกัน อยากให้ไม่รับคู่มือนี้เหมือนเป็นสิ่งศักดิ์สิทธิ์แตะต้องไม่ได้ ถ้าเนื้อหาในนี้ไม่ตรงกับประสบการณ์ของคุณ ผมแนะนำให้เชื่อประสบการณ์ของตัวเองมากกว่า
[0] https://twitter.com/bcantrill/status/1216491216356823040
ในฐานะ CTO จะทำคำขอนั้นโดยไม่ให้มีลักษณะกดดันได้อย่างไรกัน
แต่ในทางปฏิบัติ มักมีกรณีที่มีช่องว่างด้านทักษะจริง ๆ และผมคิดว่าถ้าผู้จัดการทำหน้าที่เป็นโค้ช ก็ช่วยให้การเติบโตและผลงานของใครบางคนเร็วขึ้นได้
ฝั่งนั้นพูดถึง การบริหารผลงานเชิงมองไปข้างหน้า ว่าจะปรับปรุงผลงานในอนาคตอย่างไร แต่ในบริษัทส่วนใหญ่ การประเมินผลงานใกล้เคียงกับ การประเมินย้อนหลัง ที่จัดอันดับผลงานในอดีตเพื่อกระบวนการจัดสรรค่าตอบแทนและการเลื่อนตำแหน่ง
กระบวนการเชิงมองไปข้างหน้านั้นยอดเยี่ยม แต่ท้ายที่สุดก็ยังจำเป็นต้องมีการให้คะแนนผลงานในอดีตในระดับหนึ่ง
ผมเคยมีโอกาสทำงานกับผู้เขียนในสองบริษัท และยากจะบอกเป็นคำพูดได้ว่าสิ่งที่เขียนไว้ที่นี่สร้างความแตกต่างได้มากแค่ไหนเมื่อถูกนำไปใช้จริง
ผลกระทบไม่ได้หยุดอยู่แค่ในผลิตภัณฑ์หรือวิศวกรรม แต่แพร่ไปทั่วทั้งองค์กร ไม่ว่าจะเป็นระบบหรือข้อแนะนำใด ๆ สุดท้ายก็ต้องปรับให้เข้ากับองค์กรของตัวเอง แต่ผมแนะนำให้ใช้ วิธีที่ Zach สอน ให้มากที่สุดเท่าที่ทำได้
ผมค่อนข้างชอบการบันทึกวิดีโอการประชุม ไม่ใช่เพื่อใช้เป็นหลักฐานเมื่อทีมเริ่มโทษกันไปมา แต่เพราะการได้กลับไปดูการประชุมและการอภิปรายอีกครั้งนั้นดีมากจริง ๆ
ถ้าเป็นสถานการณ์ที่ต้องใช้ความสามารถของผมค่อนข้างมากในประเด็นสำคัญหรือการประชุมเพื่อจัดแนวทางร่วมกัน การจดจ่อกับหัวข้อไปพร้อมกับจดโน้ตและจำทุกอย่างให้ได้เป็นเรื่องยาก การรู้ว่ามีการบันทึกไว้ทำให้ระหว่างประชุมผมทุ่มสมาธิไปกับการโฟกัส ถามคำถามดี ๆ และตรวจสอบสมมติฐานได้เต็มที่
วันถัดมา ผมสามารถกลับไปฟังสายสนทนา หยุดเป็นช่วง ๆ ฟังที่ความเร็ว 2x·3x ทำโน้ตส่วนตัว เขียนบันทึกการประชุมหรือสรุปภายใน ค้นพบความไม่สอดคล้องทางความคิด หรือให้ เครื่องมือจดโน้ต AI ทำงานตามตารางเวลาของผมได้
ยังช่วยได้ในกรณีที่มีคนป่วย ต้องไปรับแม่ยายที่สนามบิน มีประชุมอื่นพร้อมกัน หรือเพิ่งเข้าร่วมทีมหนึ่งสัปดาห์หลังจากการประชุมจัดแนวทางสำคัญ ถ้าเป็นการประชุมที่ไม่สำคัญ ก็แค่ไม่ต้องสนใจ และตั้งกฎลบอัตโนมัติที่สมเหตุสมผลก็พอ
ผมไม่คิดว่าจริง ๆ แล้วผู้คนจะใช้เวลาแอบค้นสิ่งที่ตัวเองไม่ควรเข้าไปดู ดังนั้นจึงไม่มองว่านั่นเป็นปัญหาใหญ่
การประชุมทีมยังทำให้บทสนทนาเอนเอียงไปทางคนที่มั่นใจในการพูดด้วย โดยเฉพาะอย่างยิ่งไม่เป็นธรรมต่อคนที่เพิ่งเข้าร่วมหรือคนที่ไม่ได้ใช้ภาษาหลักเป็นภาษาแม่
ผมไม่ได้คัดค้านการประชุมเอง บางคนชอบสื่อสารด้วยเสียงมากกว่าการเขียนมาก และทีมที่ดีควรสามารถรองรับวิธีทำงานที่สมาชิกแต่ละคนชอบได้
แต่ถ้าเป็นการประชุมทีมที่สำคัญและเรียกร้องความสามารถของผู้เข้าร่วมสูงมาก มันไม่ควรเป็นการประชุมเลย ควรประชุมก็ต่อเมื่อผู้เข้าร่วมทุกคนตัดสินว่า การประชุมเป็นสื่อที่ดีที่สุดสำหรับบทสนทนานั้น ๆ เท่านั้น
การประชุมเหมือนนั่งอยู่หน้าสายยางฉีดน้ำ รายละเอียดต่าง ๆ จะหลุดหายไป
เราย้ายไป Google Workspace เพราะบันทึกและค้นหาการประชุมได้ง่าย เช่น มีวิดีโอบันทึกฝังอยู่ในอีเวนต์ปฏิทิน
ถ้าการประชุมไม่สำคัญพอที่จะบันทึกไว้ ก็มีโอกาสสูงว่าอาจไม่คุ้มที่จะจัดตั้งแต่แรก
โดยส่วนตัวแล้ว ผมใส่เวลาในแต่ละวันมากกว่าคนอื่น แต่สิ่งนั้นไม่ได้เกิดขึ้นพร้อมกันแบบ synchronous การประชุมสำคัญอาจชนกันได้ และถ้าอ่านแค่บันทึกการประชุม นัยละเอียดจำนวนมากจะหายไป แถมผู้คนก็ไม่ค่อยอ่านบันทึกการประชุมกันด้วย
ถึงอย่างนั้น หากบันทึกการประชุมไว้ ก็ช่วยให้ตรวจทานบันทึกการประชุมได้อย่างรวดเร็วและถูกต้อง จึงมีประโยชน์มาก ผมเลยผลักดันการบันทึกการประชุมค่อนข้างหนัก
ยิ่งเข้าใจสาเหตุที่แท้จริงได้เร็วเท่าไร ก็ยิ่งแก้ปัญหาได้เร็วเท่านั้น เพื่อทำความเข้าใจแนวคิดนี้และวิธีนำไปใช้กับบริษัท ผมขอแนะนำอย่างยิ่งให้อ่าน Extreme Ownership ของ Jocko Willink และ Leif Babin อดีต Navy SEAL
การเข้าร่วมประชุมแบบอะซิงโครนัสดีมากด้วยเหตุผลที่กล่าวไว้ข้างต้น มันทำให้ข้อมูลในที่ประชุมค้นหาได้ ตอนนี้การประชุมสามารถใส่ซับไตเติลด้วยการประมวลผลภาษาธรรมชาติได้แล้ว และเนื้อหานั้นก็ทำให้ LLM ค้นเจอได้
ตอนนี้เรากำลังฝึกแชตบอตภายในด้วยคอนเทนต์จาก Confluence และกำลังจะขยายไปยังคอนเทนต์จากการประชุมที่บันทึกไว้ด้วย
ขอโปรโมตเล็กน้อย ผมกำลังทำเครื่องมือ https://designpro.ai ที่เปลี่ยนอินพุตจากหลายแหล่งให้เป็น insight และงานต่าง ๆ เคยใช้ดึง insight จาก transcript ของการโทร และรู้ว่ามันใช้งานได้จริง
เพิ่งได้เป็น CTO เมื่อไม่นานมานี้ และหนึ่งในความยากที่สุดคือการสื่อสารกับ CEO เรื่องนี้อาจมีอยู่ในหนังสือแล้ว แต่ผมอ่านแค่ดัชนี
ตลอด 8 เดือนที่ผ่านมา CEO ไม่ต้องการประชุมเพื่อจัดแนวทางร่วมกัน ไม่อยากวางแผนอะไรเลย ไม่พยายามขับเคลื่อนวิสัยทัศน์ และต้องการโฟกัสแต่ ฟีเจอร์เด็ด เท่านั้น
เขาไม่อยากทำ mockup หรือ prototype เพื่อให้ผู้ใช้ทดสอบ และถ้าจะทำก็ต้องสวยงาม งานที่ใช้เวลาเกินหนึ่งสัปดาห์เขาก็ไม่อยากทำ และยังปฏิเสธการประชุมที่มีประสิทธิภาพด้วย
สิ่งที่ผมอยากพูดคือ สิ่งที่ไม่มีอยู่ในหนังสือนั่นแหละคือสิ่งที่ผมโหยหา อ้อ พวกเราเป็น co-founder กันแค่ 3 คน
CTO เป็น “คนดูแลเทคโนโลยี” ของ CEO และเป็นเหมือนคนดูแลเทคโนโลยีที่เก่งที่สุดหรือสำคัญที่สุดในกลุ่ม เลยได้ตำแหน่ง CTO มา
ฟังแล้วน่าเสียดาย แต่คุณควรพิจารณาความเป็นไปได้ว่า CEO อาจมองคุณเป็นแค่พนักงานอีกคนที่มีตำแหน่งเท่ ๆ เท่านั้น ถ้ามีกรอบคิดแบบนั้น จากมุมของ CEO การดึงคุณเข้าไปร่วมตัดสินใจก็จะรู้สึกเหมือนเป็นการเสียเวลา
ผมยังจำคำตอบของ Marc ได้แม่นยำ “ถ้ามีข้อสงสัย ก็ไม่จำเป็นต้องสงสัยแล้ว”
ผมรู้ว่านี่เป็นการตัดสินใจที่ใหญ่มากจนไม่ควรถูกโน้มน้าวด้วยคอมเมนต์ใดคอมเมนต์หนึ่งบนอินเทอร์เน็ต แต่ถึงอย่างนั้นก็ขอพูดว่า ผ่านมา 8 เดือนแล้ว คุณน่าจะลองทุกอย่างที่คุ้มจะลองเพื่อแก้ไขแล้ว
ยังมีอะไรที่ยังไม่ได้ลองเหลืออยู่อีก? ตามเหตุผลแล้วคุณคาดหวังให้เกิดอะไรขึ้นที่นี่? ควรคิดดูว่าคุณวางแผนจะลงทุนชีวิตกับสถานการณ์แบบนี้ต่อไปอีกนานแค่ไหน ทั้งที่สามารถย้ายไปอยู่ที่ที่ทำงานได้เกิดผลมากกว่าได้ไม่ยาก
พูดจริงจังแล้ว สิ่งที่คุณชนอยู่ตอนนี้ก็คือจุดที่ทำให้งานนี้ยากนั่นแหละ
อย่างแรก ลองนัด 1:1 กับผู้บริหารคนอื่น ๆ ดู ถ้ามีผู้บริหารที่คุณทำงานด้วยนอกเหนือจาก CEO คุณจะได้บริบทมากขึ้นว่าตัวเองเข้ามาอยู่ในสถานการณ์แบบไหน เมื่อเข้าใจความต้องการของพวกเขา ก็จะเห็นความต้องการขององค์กรในภาพกว้างขึ้นด้วย
คุณถูกจ้างมาเพื่อกำจัดปัญหาของ CEO แม้ CEO จะไม่ได้ร้องขอก็ตาม ความสามารถในการกลมกลืนเข้ากับทีมผู้บริหารเป็นหนึ่งในวิธีที่ดีที่สุดในการพิสูจน์ฝีมือ และสิ่งที่ต้องใช้คือความสม่ำเสมอ ความจริงใจ เปิดใจ และท่าทีที่อยากถามคำถามที่ช่วยได้จริง ๆ
อย่างที่สอง ถ้า CEO กับทีมผู้บริหารพบกันเป็นประจำ ก็ขอเข้าร่วม และถ้าไม่มี ก็ลองวางแผนขึ้นมาเอง ตามอุดมคติแล้วควรจัดแนวกับผู้บริหารคนอื่น ๆ นอกจาก CEO ก่อน ต่อให้ CEO มาไม่ได้ทุกครั้งหรือมาไม่ได้ส่วนใหญ่ เขาก็น่าจะขอบคุณความเป็นฝ่ายริเริ่มนั้น และความไว้วางใจก็จะค่อย ๆ สร้างขึ้น
ในเมื่อคุณบอกแล้วว่าเขาไม่ต้องการการประชุมแบบนั้น คุณอาจต้องขยับแบบอ้อม ๆ ผ่านผู้บริหารคนอื่นที่มีอิทธิพลต่อ CEO ก่อน
อย่างที่สาม ถ้าคุณเป็น CTO อย่างน้อย CEO ก็น่าจะอยากมี 1:1 เป็นประจำระดับหนึ่ง แม้เพียงเพื่อให้แน่ใจว่าคุณจะไม่ลาออกก็ตาม จะเป็นรายสัปดาห์ สองสัปดาห์ครั้ง รายเดือน หรือรอบไหนที่เข้ากับตารางของ CEO ก็ได้
จุดประสงค์ของการประชุมนี้คือการจัดแนวกับ CEO และรับ feedback เกี่ยวกับส่วนที่ทำได้ดีและส่วนที่ควรปรับปรุง ถ้าจัดประชุมนี้ไม่ได้ ผมแนะนำให้มองว่านี่ไม่ใช่สภาพแวดล้อมที่คุณจะประสบความสำเร็จได้ และควรออกมา
ถ้าการนัดประชุมนี้ยาก ก็ควรผลักดันสองแนวทางก่อนหน้าเพื่อสร้างความสัมพันธ์ก่อน แล้วค่อยลองอีกครั้ง หากคุณไม่สามารถหาเวลาประจำกับ CEO และผู้บริหารคนอื่น ๆ ได้เลย ไม่ว่าจะถี่แค่ไหน คุณก็ไม่ได้เป็น CTO จริง ๆ และควรพิจารณาออกมา
ผมเคยเขียนเรื่องความแตกต่างนั้นไว้ที่นี่: https://www.mooreds.com/wordpress/archives/2555
อย่างไรก็ตาม การขาดการวางแผนและการไม่ผลักดันวิสัยทัศน์เป็นเรื่องน่ากังวล ทั้งสองอย่างเป็นแกนหลักของบทบาท CEO ในระยะเริ่มต้น คุณรู้ไหมว่าทำไมเขาถึงโฟกัสแต่เรื่องระยะสั้นขนาดนั้น? เขากำลังเร่ง MVP เพื่อระดมทุนหรือขายอยู่หรือเปล่า หรือว่าไม่มีวิสัยทัศน์? ผมคงเจาะลงไปตรงนั้นเพื่อเข้าใจเหตุผล หรือไม่ก็อย่างที่คนอื่นบอก คือออกมา
คุณไปถึงขั้นที่สรุปขั้นตอนระยะสั้นที่จำเป็นจริง ๆ ให้เขา แล้ว CEO พูดว่า “โอเค ดี สิ่งที่เราจะทำคืออันนี้” แล้วหรือยัง?
หรือเป็นขั้นที่เจ๋งกว่านั้น คือพอคุณผลักดันการรับรอง SOC2 แล้ว CEO บอกว่า “ยังไม่ใช่ตอนนี้” แต่ใน sales pitch กลับพูดว่า “เรากำลังมุ่งหน้าไปสู่ การรับรอง SOC2” อยู่?
ไม่ต้องกังวล ไม่ใช่คุณหรอกที่เป็นคนสับสนแบบจิตแตก
Wikipedia อธิบาย DevOps ว่าเป็นแนวปฏิบัติที่ผสานการพัฒนาซอฟต์แวร์เข้ากับการปฏิบัติการ IT แต่การแปลความหมายเป็น “งานทุกอย่างที่ทำให้ซอฟต์แวร์ธุรกิจรันได้ในที่ที่ไม่ใช่เครื่องของนักพัฒนา” ดูเป็นการตีความที่แปลกและค่อนข้างต่างจากนิยามเดิม
โดยเฉพาะตรงที่ว่า ผู้เชี่ยวชาญ DevOps
ผมจะลองเขียนใหม่ให้สื่อเรื่องนั้นได้ดีกว่านี้
ผมไม่รู้จักบริษัทหรือคนที่กล่าวถึงในนี้เลย อยากรู้ว่าคนอื่นรู้จักกันไหม
ก่อนจะใช้เวลาอ่าน ขอพูดก่อนว่าโดยพื้นฐานแล้วผมมีความระแวงตามสัญชาตญาณต่อคนที่เรียกว่า “ประธานเจ้าหน้าที่ฝ่ายเทคโนโลยี” อยู่แล้ว มันคุ้มอ่านไหม?
กลุ่มผู้อ่านเป้าหมายดูเหมือนจะเป็นคนที่มีประสบการณ์ทำงานจริงน้อยมากหรือแทบไม่มีเลย แต่ได้รับตำแหน่ง CTO มาเพราะเป็น co-founder ฝ่ายเทคโนโลยีของสตาร์ทอัพ
ผมเป็น CTO ในสามบริษัทตลอด 10 ปีที่ผ่านมา และตอนนี้อาจจะแค่แก่ลงและความอดทนน้อยลงก็ได้ แต่เหมือนที่คนอื่น ๆ พูด มันดูเหมือนเป็นหนังสือสำหรับคนเพิ่งเรียนจบที่เพิ่งได้เป็น CTO ในฐานะ co-founder มากกว่า ผมกำลังให้คำปรึกษาด้านเทคนิคกับคนแบบนั้นอยู่
จากประสบการณ์ของผม ยิ่งทำบทบาทนี้นานเท่าไร ก็ยิ่งมองหาข้อมูลที่เฉพาะเจาะจงมากขึ้น อย่างเช่นหนังสือ Accelerate
เทคโนโลยีที่น่าเบื่อ สำคัญมากจริง ๆ สตาร์ทอัพภาคเอกชนนั้นเป็นสิ่งที่ไม่มั่นคงอยู่แล้ว แล้วจะเพิ่มความเสี่ยงด้วยเทคโนโลยีที่ยังไม่ผ่านการพิสูจน์ไปทำไม?
ตัวอย่างเช่น ช่วงระหว่างปี 2013 ถึง 2016 มีช่วงหนึ่งที่ MongoDB กลายเป็นเหมือนฐานข้อมูลมาตรฐานโดยพฤตินัยอย่างอธิบายได้ยาก ดูเหมือนว่าสตาร์ทอัพราวหนึ่งในสามย้ายจาก MySQL หรือ Postgres ไปใช้ MongoDB มันเป็นความโกลาหลครั้งใหญ่และเป็นหายนะที่โง่เขลาจริง ๆ
ในกรณีแบบนั้นนึกเหตุผลที่จะเลือก Mongo แทบไม่ออกเลย นอกจากช่วงแรกของการพัฒนาจะเร็วขึ้นเล็กน้อยไม่กี่วัน เพราะไม่ต้องสร้างและอัปเดตสคีมา
ปัญหาคือทันทีที่ข้อมูลซับซ้อนขึ้นและเริ่มต้องการสิ่งอย่าง BI ก็จะต้องจ่ายคืนข้อได้เปรียบช่วงแรกนั้นพร้อมดอกเบี้ยมหาศาล
อย่างไรก็ตาม แม้ข้อมูลจะไม่ใช่แบบ relational JSON ของ Postgres ก็ยังทำงานได้ดีกว่า Mongo
เทคโนโลยีใหม่บางอย่างจะหายไป และบางอย่างจะอยู่รอด
ช่วงต้นอาชีพของผม SQL เคยเป็นเทคโนโลยีใหม่แวววาว ผมผลักดันอย่างหนักให้บริษัททิ้งฐานข้อมูลแบบ network database แล้วไปใช้ SQL และผลลัพธ์ก็ออกมาดีมาก
การเขียนโปรแกรมเชิงวัตถุเมื่อเทียบกับ C แบบดั้งเดิมก็เช่นกัน
บางเทคโนโลยีสุดท้ายก็ไปไม่ถึงคำสัญญาที่ให้ไว้ และกลายเป็นโซ่ตรวนขององค์กรที่นำไปใช้
เคยมีช่วงที่ยังเร็วเกินไปที่จะนำเทคโนโลยี LLM มาใช้อย่างรับผิดชอบ แต่ไม่นานจะถึงเวลาที่บอร์ดถามว่าทำไมถึงยังไม่เอามาใช้ กรณีใช้งานภายนอกอาจจะเป็นแบบนั้น ส่วนกรณีใช้งานภายในมีโอกาสเป็นเช่นนั้นแน่นอน
หนึ่งในโจทย์ยากของ CTO คือการตัดสิน จังหวะการนำเทคโนโลยีใหม่มาใช้ ต้องตัดสินว่าเมื่อไรเทคโนโลยีที่น่าเบื่อคือทางเลือกที่ดีที่สุดสำหรับบริษัท เมื่อไรสามารถนำเทคโนโลยีระยะเริ่มต้นเข้ามาได้ และเมื่อไรเทคโนโลยีใหม่กลายเป็นตัวเร่งที่ใหญ่เกินกว่าจะไม่ใช้ไม่ได้
การแบ่ง CTO ออกเป็นสามประเภท คือเน้นเทคโนโลยี เน้นคน และเน้นภายนอก น่าสนใจดี
สตาร์ทอัพระยะเริ่มต้นมาก ๆ กำลังเสนอให้รับบทบาท CTO ตอนนี้ยังไม่มีผลิตภัณฑ์ มีแค่เดโมพื้นฐานไม่กี่ตัว และกำลังเตรียมระดมทุน pre-seed
เลยสงสัยว่าบทบาทนี้ต้องการอะไรมากที่สุด เป็น CTO สายเทคนิค หรือ CTO สายคน? ช่วงแรกคงเป็นบทบาทด้านเทคนิคเป็นหลัก เพราะต้องพัฒนาผลิตภัณฑ์ก่อน แต่ก็สงสัยว่าจะถึงจุดเปลี่ยนไปเป็น CTO ที่เน้นคนเมื่อไร ถ้ามี insight หรือประสบการณ์ที่เกี่ยวข้องก็อยากฟัง
ให้คุณเป็นบทบาทนั้นเป็นหลัก ส่วนที่เหลือก็ประคองไปพอประมาณ แล้วเมื่อส่วนนั้นมีงานมากเกินไปหรือสำคัญเกินไป ก็ค่อยจ้างคนมาดูแลอีกสองด้านหรือมากกว่านั้น
คำถามที่สองซึ่งตอบยากกว่าคือ พวกเขา หรือ CXO คนอื่น ๆ อยากให้คุณเป็นอะไร เรื่องนี้อาจมาขวางข้อแรกได้ บางกรณีคือ CTO ที่ไม่มี C เป็นเพียงคนดูแลเทคโนโลยีที่ถูกสั่งให้ทำสิ่งที่ต้องทำ รันเดโมไว้โชว์ และไม่ได้ยิน “ทำไม” ของธุรกิจ
ผมมีลิงก์ที่บุ๊กมาร์กไว้เกี่ยวกับ “CTO คืออะไรกันแน่” อยู่สองสามอัน
http://www.startuplessonslearned.com/2008/09/what-does-start...
https://www.allthingsdistributed.com/2007/07/the_different_c...
ขอแนะนำ The Manager’s Path ของ Camille Fournier ด้วย
แม้จะบอกว่า “การชำระหนี้ล่วงหน้าเป็นการลงทุนที่จำเป็นต่อสุขภาพโดยรวมของงานวิศวกรรม” แต่ หนี้ทางเทคนิค บางอย่าง การผิดนัดชำระอาจถูกกว่าโดยรวมมากกว่าการจ่ายคืน
ตราบใดที่ผู้จัดการผลิตภัณฑ์ไม่พยายามมาตามทวงหนี้น่ะนะ
แต่การที่โปรเจกต์ซึ่งมีขนาดและความซับซ้อนระดับหนึ่งไปถึงภาวะล้มละลายทางเทคนิคได้นั้น จะเกิดขึ้นก็ต่อเมื่อไม่ได้ทำตามคำแนะนำในหนังสือเท่านั้น ถ้าเพิกเฉยต่อหนี้ทางเทคนิคเพื่อปล่อยฟีเจอร์ การออกรีลิสจะยิ่งยากขึ้นเรื่อย ๆ และบั๊กก็จะเกิดบ่อยขึ้นเรื่อย ๆ
ยินดีด้วยกับการตีพิมพ์หนังสือ
ผมกำลังเขียน Opinionated Launch(https://opinionatedlaunch.com) เพื่อแบ่งปันไอเดียเชิงปฏิบัติจากประสบการณ์ในฐานะ CTO ของสตาร์ทอัพขนาดเล็ก และ VPoE ของบริษัทจดทะเบียน
พอเริ่มเขียนก็รู้ว่าหัวข้อแบ่งออกเป็นสองสาย คือด้านการจัดการ·ทีม·คน กับด้านเทคนิค ผมลงเอยด้วยการโฟกัสที่ ด้านเทคนิค ซึ่งเป็นด้านที่ผมมีแพสชันมากกว่า และดีใจที่มีคนมาทำส่วนที่เหลือให้