CTO מתוך הטכנולוגיה אל שולחן ההנהלה: איך נראה המעבר בפועל

מה בדיוק משתנה כשה-CTO עובר מהמעבדה לחדר הישיבות?

השינוי הראשון שנהל טכנולוגי שעולה להנהלה מרגיש אותו הוא שינוי ביחידת הניהול. בעבר הוא ניהל טכנולוגיה: ארכיטקטורה, תשתיות, תוצרים. כעת הוא מנהל אנשים שמנהלים טכנולוגיה. ההשלכה של זה אינה סמנטית. כשהוא עומד מול בעיה, הפתרון שלו חייב לעבור דרך שני שכבות ניהול לפחות לפני שהוא מגיע לביצוע בפועל. זה אומר שכישורי ניהול אנשים, הקצאת עדיפויות ותקשורת בין-תפקודית הופכים קריטיים הרבה יותר מהיכולת להכיר כל שורת קוד.

ממד שני של השינוי הוא מסגרת קבלת ההחלטות. בתפקידים טכניים, הקריטריון המרכזי להחלטה טובה הוא בדרך כלל אלגנטיות פתרון, ביצועים טכניים, יציבות ומדרגיות. בהנהלה, הקריטריון המרכזי הוא תוצאה עסקית: הכנסות, שביעות רצון לקוחות, עמידה בלוחות זמנים, מיצוב תחרותי. מנהל R&D שעולה להנהלה ומגלה שבישיבות ההנהלה אף אחד לא מעוניין בפתרון הטכני שהוא מציע, אלא רק בהשפעה שלו על הלקוח ועל ההכנסות, חווה את השינוי הזה בצורה חדה. הדרך לנווט אותו היא לאמץ זווית רוחבית ולוותר על המומחיות העמוקה כנקודת הייחוס המרכזית.

אילו כישורים ה-CTO חייב לפתח לפני שעולה לתפקיד?

שלושה תחומים מרכזיים עומדים בבסיס המוכנות להנהלה, ושלושתם אינם נרכשים בדרך כלל בתפקידים טכניים.

חשיבה פיננסית בסיסית: זו לא אומרת שה-CTO צריך להיות רואה חשבון. אבל הוא חייב לדעת לקרוא מודל עסקי, להבין תמחור, לבנות ביסוס ל-ROI על השקעות טכנולוגיות ולתרגם עלויות פיתוח לשפה תקציבית שנשמעת הגיונית לאנשי כספים.

יכולת תרגום: CTO שמדבר בפני דירקטוריון או משקיעים צריך לוותר על השפה של ארכיטקטורה ולאמץ שפה של סיכון, הזדמנות וצמיחה. התרגום הזה הוא כישור שניתן לפתח, אבל הוא לא מגיע אוטומטית עם הניסיון הטכני.

ניהול stakeholders: מנהל טכנולוגי מקצועי עובד בעיקר בתוך הפונקציה שלו. CTO בהנהלה צריך לבנות קואליציות עם Sales, Finance, Marketing ולקוחות. הטעות הנפוצה ביותר בשלב הזה היא להניח שהישגים טכניים מדברים בעד עצמם. בפועל, CTO שלא ידע לשווק את הערך שהוא מייצר בתוך הארגון נשאר "מומחה שמציג" ולא "מנהל שמוביל".

איך נראה שיתוף הפעולה בין ה-CTO לשאר ההנהלה בפועל?

התפקיד של CTO בהנהלה ממוקם בנקודת חיתוך בין האסטרטגיה לביצוע. זה אומר שהוא מקבל כיוון מהמנכ"ל, מתרגם אותו לתוכנית טכנולוגית ומתאם את ביצועה מול VP R&D, VP Product ו-VP Engineering. בתיאוריה, חלוקת האחריות נראית ברורה. בפועל, גבולות האחריות עלולים להיטשטש במהירות.

לדוגמה: כשה-VP Product דוחף פיצ'ר שדורש מאמץ טכנולוגי גדול, וה-VP Engineering חולק על הכדאיות, ה-CTO הוא זה שצריך לפשר, לסמן עדיפויות ולהחליט. אם הוא אינו מצוייד בסמכות ניהולית מוכרת ובמהימנות שנבנתה עם שותפיו בהנהלה, הוא ימצא את עצמו בעמדה של בורר ולא של מוביל. תרחיש נפוץ: כשה-CTO וההנהלה העסקית חולקים על עדיפויות, ומי שמחליט הוא המנכ"ל, CTO שלא ידע להציג את עמדתו בשפה עסקית יפסיד את הוויכוח, ולא בגלל שהוא טועה מבחינה טכנית.

מה עושה את ההבדל בין CTO שמשפיע לבין CTO שנשאר "מנהל טכני מתקדם"?

אחת הדרכים הטובות להבין כיצד ה-CTO בונה סמכות הנהלתית היא להשוות לאופן שבו תפקידים בכירים אחרים עושים זאת. CFO בונה את סמכותו דרך שליטה בנתונים הפיננסיים, גישה לדירקטוריון ויכולת לסגור עסקאות. CTO נדרש לבנות סמכות מקבילה בתחומו: שליטה בנתוני הטכנולוגיה, גישה לשיחות אסטרטגיות והיכולת להשפיע על תוכנית החברה.

שלושה סממנים מבדילים בין CTO שמשפיע לבין כזה שנשאר ברמה הניהולית-טכנית:

יוזמות אסטרטגיות: CTO שמשפיע לא מחכה שיגיע אליו briefing, הוא מציע נקודות מבט טכנולוגיות שמשפיעות על כיוון החברה.

קשרי לקוחות: CTO שנכנס לשיחות עם לקוחות מרכזיים ומייצג את החברה מהצד הטכנולוגי בונה מהימנות שחורגת מהפונקציה הפנימית.

פיתוח מנהלים: CTO שגייס ופיתח VP Engineering חזק, שבנה מנהלי R&D עצמאיים, הוא CTO שמשחרר לעצמו פנאי לחשיבה אסטרטגית. CTO שמחזיק בידיו את כל ההחלטות הטכניות ממשיך להיות מנהל טכני, אפילו אם כרטיס הביקור שלו אומר משהו אחר.

טיפ מעשי: CTO שרוצה לבנות יחסי עבודה עם הדירקטוריון עוד לפני שהוא נדרש לדווח לו, יכול לבקש להציג בפניהם פעם ברבעון עדכון טכנולוגי. זו דרך להיכנס לדיאלוג אסטרטגי בנקודת זמן שאין בה לחץ, ולבנות מהימנות מבלי לחכות למשבר.

כיצד הארגון יכול לזהות שה-CTO שלו מוכן לשולחן ההנהלה?

ארגונים לא תמיד יודעים לזהות מוכנות להנהלה. הם לרוב מדדים על פי ביצועים בתפקיד הנוכחי, שזה כלי לא מספיק. הסימנים שמעידים על מוכנות אמיתית הם דווקא ברמה ההתנהגותית.

CTO שמציג בעצמו בפני לקוחות בלי שנדרש לכך, שמעלה שאלות תקציביות בישיבות תכנון, שיוזם שיח על הצמיחה של הארגון ולא רק על הטכנולוגיה שלו, הוא מועמד שמוכן.

ההבדל בין "להיות מומחה בחדר" לבין "להיות שותף להחלטה" הוא ההבדל שהארגון צריך לזהות. מומחה בחדר עונה על שאלות. שותף להחלטה שואל שאלות ומשפיע על הכיוון. CTO שעשה את המעבר הזה, גם לפני שקיבל את התפקיד רשמית, הוא זה שיצליח לנצל אותו כשיגיע.

המסקנה לארגון: אם אתם מחפשים לקדם CTO לשולחן ההנהלה, תסתכלו לא על מה שהוא עשה בפונקציה שלו, אלא על האופן שבו הוא פועל מחוצה לה. שם תמצאו את התשובה.