CTO הם ראשי תיבות של Chief Technology Officer — מנהל הטכנולוגיה הבכיר בחברה. אבל ההגדרה הזו לא מסבירה כלום, כי בפועל התפקיד נראה אחרת לגמרי בסטארטאפ של חמישה אנשים, בחברה עם מאה עובדים, ובעסק מסורתי שרק עכשיו מדיגיטל את עצמו.
במאמר הזה אסביר מה CTO באמת עושה ביום-יום, איך התפקיד משתנה לפי גודל החברה, מתי בכלל צריך אחד, ומתי הפתרון הנכון הוא לא לגייס אלא לשכור ראש טכנולוגי בכיר לפי הצורך.
מה CTO עושה בפועל
אם לצמצם לשורה אחת: CTO אחראי שההחלטות הטכנולוגיות ישרתו את המטרות העסקיות, ולא להפך. זה מתפרק לארבעה תחומים.
1. החלטות ארכיטקטורה ובחירת טכנולוגיה
מה בונים ומה קונים, על איזו תשתית, ואיך זה ייראה כשהעסק יגדל פי שלושה. אלה החלטות שקשה מאוד לשנות בדיעבד — ולכן הן שוות הכי הרבה כשמקבלים אותן נכון.
2. ניהול הצוות הטכני
מי מגייסים, איך עובדים, ואיך מודדים תפוקה של פיתוח בלי לספור שורות קוד. גם כשהצוות הוא ספק חיצוני, מישהו צריך לנהל את הקשר הזה מקצועית.
3. ניהול סיכונים
אבטחת מידע, גיבויים, עמידה ברגולציה, ומה קורה כשהמפתח היחיד שמכיר את המערכת עוזב. זה החלק הכי פחות זוהר ובדרך כלל הכי יקר כשמזניחים אותו.
4. תרגום בין העסק לטכנולוגיה
להסביר להנהלה מה אפשרי ובאיזה מחיר, ולהסביר למפתחים למה משהו חשוב לעסק. הרבה כישלונות טכנולוגיים הם בעצם כישלונות תקשורת.
איך התפקיד משתנה לפי גודל החברה
עד 10 עובדים: ה-CTO כותב קוד בעצמו. הוא בעיקר מפתח בכיר שגם מקבל החלטות.
10–50: נקודת המעבר. הוא מפסיק לכתוב ומתחיל לנהל, לתעדף ולבנות תהליכים. זה גם השלב שבו הכי הרבה חברות נכשלות, כי המפתח הראשון קודם לתפקיד שהוא לא רצה ולא אומן אליו.
50+: תפקיד ניהולי מלא — אסטרטגיה, תקציב, ומנהלים שמדווחים אליו. הקשר לקוד כמעט נעלם.
עסק לא-טכנולוגי בכל גודל: שונה לגמרי. אין צוות פיתוח, יש מערכות שצריך לבחור, לחבר ולתחזק. הצורך הוא בשיקול דעת, לא בניהול מפתחים — וזה בדיוק המקרה שבו משרה מלאה כמעט אף פעם לא מוצדקת.
מתי חברה באמת צריכה CTO
ארבעה סימנים מובהקים. החלטות טכנולוגיות נדחות כי אף אחד לא מרגיש מוסמך להכריע. הספקים מובילים אתכם ולא להפך — כל הצעה נשמעת הגיונית ואין מי שיאתגר אותה. הכל תלוי באדם אחד שאם יעזוב, אף אחד לא יידע איך המערכת עובדת. הפיתוח לא מתקדם ואין דרך להסביר למה.
אם אף אחד מהארבעה לא נכון אצלכם — כנראה שלא צריך, ומספיק ייעוץ נקודתי כשעולה החלטה גדולה.
CTO במיקור חוץ — מה זה בעצם
ראש טכנולוגי בכיר שעובד עם החברה בהיקף חלקי וקבוע: יום בשבוע, יומיים בחודש, או לפי אבני דרך. הוא לא יועץ שנותן דוח והולך, והוא לא עובד שכיר — הוא נמצא לאורך זמן, מכיר את המערכות ואת האנשים, ואחראי על התוצאה.
ההבדל מייעוץ נקודתי הוא הרציפות. יועץ עונה על שאלה; CTO במיקור חוץ חי עם ההשלכות של התשובה ומתקן בדרך. ההבדל מגיוס הוא העלות והזמינות — לא צריך לחכות חצי שנה לגיוס, ולא צריך להצדיק משרה מלאה.
מתי מיקור חוץ עדיף על גיוס
- העסק לא טכנולוגי בליבתו. יש מערכות ויש החלטות, אבל אין מוצר תוכנה. משרה מלאה תהיה מנופחת לצורך.
- אין מספיק עבודה למשרה מלאה, אבל ההחלטות שכן מגיעות הן כבדות ויקרות לטעות בהן.
- שלב מעבר. לפני גיוס, בזמן חיפוש, או אחרי עזיבה — כדי שהחברה לא תיעצר.
- צריך אובייקטיביות. מישהו בלי אינטרס בספק מסוים ובלי היסטוריה פוליטית בארגון.
- פרויקט מוגדר — בחירת מערכת מרכזית, מעבר לענן, בניית תשתית — שדורש ראש בכיר לתקופה.
מתי דווקא לגייס: כשיש צוות פיתוח שדורש ניהול יומיומי, כשהטכנולוגיה היא המוצר, או כשצריך נוכחות רציפה בהחלטות שמתקבלות כל יום. אז חלקיות היא חיסרון אמיתי.
שלוש טעויות שעולות הכי הרבה כשאין ראש טכנולוגי
נעילה אצל ספק. בוחרים מערכת בלי לבדוק מה קורה ביום שרוצים לצאת ממנה — האם הנתונים ניתנים לייצוא, מי הבעלים של הקוד, ומה עלות המעבר. שנתיים אחר כך מגלים שהיציאה יקרה יותר מהמערכת עצמה, ומשלמים מחיר מנופח כי אין חלופה.
בנייה מותאמת כשתוכנת מדף הספיקה. או בדיוק ההפך — דחיסה של תהליך ייחודי לתוך כלי גנרי, ואז עשרות שעות של עקיפות ידניות בכל חודש. שתי הטעויות נובעות מאותו מקום: אין מי שיעצור וישאל אם ההחלטה מתאימה לגודל ולצורך. הרחבתי על ההכרעה הזו במאמר על בחירת ספק תוכנה.
סיכונים שלא נבדקו עד שקרה משהו. גיבוי שאף אחד לא ניסה לשחזר, הרשאות שנשארו לעובד שעזב, מערכת קריטית שרצה על שרת שאיש לא מתחזק. אלה דברים שלא מייצרים כאב עד הרגע שבו הם מייצרים משבר, ולכן הם תמיד נדחקים.
המשותף לשלושתן: אף אחת מהן לא נובעת מחוסר בכישרון טכני בארגון. הן נובעות מכך שאין מי שתפקידו לחשוב על זה מראש.
מודלים ותמחור
ריטיינר חודשי — היקף קבוע של שעות או ימים, מתאים כשיש רצף עבודה. פרויקט — היקף ותוצרים מוגדרים, מתאים למשימה חד-פעמית כמו בחירת מערכת. שעות ייעוץ — הכי גמיש, מתאים לליווי דליל.
מה שחשוב לסכם מראש הוא לא רק המחיר אלא סמכות: האם הוא מאשר החלטות או ממליץ עליהן, האם ספקים מדווחים אליו, ומי מכריע במחלוקת. CTO בלי סמכות הוא יועץ יקר. כתבתי על מודלי התמחור בהרחבה במאמר על עלות יועץ טכנולוגי.
CTO, יועץ טכנולוגי ומנהל פרויקט — מי עושה מה
שלושת התפקידים האלה מתבלבלים כל הזמן, וההבדל ביניהם מעשי מאוד.
יועץ טכנולוגי נכנס לשאלה מוגדרת, נותן המלצה מנומקת, ויוצא. הוא אחראי על איכות ההמלצה, לא על התוצאה בשטח. מתאים כשיש הכרעה אחת גדולה.
מנהל פרויקט אחראי שהפרויקט יגיע ליעד בזמן ובתקציב. הוא לא מכריע מה נכון טכנולוגית — הוא מוודא שמה שהוחלט מתבצע.
CTO אחראי על התמונה לאורך זמן: לא רק ההחלטה הנוכחית אלא איך היא משתלבת בכל השאר, ומה זה אומר בעוד שנתיים. הוא זה שאמור להגיד "הפרויקט הזה יצליח אבל הוא מכניס אותנו לתלות שלא נרצה".
בעסק בינוני אותו אדם יכול למלא את שלושת התפקידים בזמנים שונים, אבל כדאי לדעת באיזה כובע הוא נמצא בכל רגע — כי הציפיות והאחריות שונות.
איך בוחרים
- ניסיון בגודל שלכם. מי שניהל ארגון של 200 מפתחים לא בהכרח מתאים לעסק עם 15 עובדים ושלוש מערכות. זה כישור אחר.
- אי-תלות בספקים. אם הוא מגיע עם ספק קבוע, תבינו למה.
- יכולת לומר לא. CTO טוב יגיד לכם שהפרויקט שאתם רוצים לא שווה את זה. מי שמסכים לכל דבר לא מגן עליכם.
- העברת ידע. מה יישאר בחברה כשהוא לא יהיה — תיעוד, נהלים, ואנשים שיודעים.
- שפה מובנת. אם אתם לא מבינים את ההסברים שלו, גם ההנהלה לא תבין, וזה יחזור אליכם בהחלטות.
מה לצפות בשלושת החודשים הראשונים
CTO במיקור חוץ שמתחיל נכון עושה שלושה דברים לפני שהוא משנה משהו. מיפוי — אילו מערכות יש, מה עולה כמה, מי תלוי במי, ואיפה הסיכונים. סדר עדיפויות — רשימה קצרה של מה דחוף באמת, מופרדת ממה שרק מרגיש דחוף. ניצחון מהיר אחד — משהו שמשתפר תוך שבועות, כדי לבנות אמון לפני השינויים הגדולים.
אם אחרי שלושה חודשים אין מפה, אין סדר עדיפויות ואין שיפור אחד מוחשי — משהו לא עובד, וכדאי לדבר על זה מוקדם.
מאיפה מתחילים
לא חייבים להתחייב לריטיינר כדי לבדוק אם זה מתאים. שיחת אבחון אחת שממפה את המערכות ואת ההחלטות הפתוחות נותנת תמונה ברורה — גם על מה שדחוף, וגם על השאלה אם בכלל צריך ליווי רציף או שמספיק ייעוץ טכנולוגי נקודתי.
קראו גם על ליווי טכנולוגי לפרויקט ועל ייעוץ אסטרטגי-טכנולוגי, שהם שני המודלים הקרובים ביותר.