על Engineering Managers (חלק ב')

בפוסט הקודם (על Engineering Managers – חלק א') הגדרנו מהו מנהל הנדסי והצגנו מודל להערכת מנהל שכזה – מה נדרש ממנו, וכיצד להעריך אם הוא בקצה הגבוה או הנמוך של העשייה הניהולית-הנדסית.

סיימנו את הפוסט בדילמה שיש מנהלים טובים, שאינם חזקים בכל הצלעות. שני המקרים הטיפוסיים: מנהלים שאינם טובים בתפעול / ניהול פרויקטים ומנהלים שטובים באלו – אך אינם טכנולוגיים. ננסה לפרק (deconstruct) ולהרכיב מחדש תיאור של המנהלים הללו, ולהציע כיצד לפצות (mitigate) על הצלעות החלשות שלהם.

"מנהל טכנולוגי" מול "מנהל אנשים"

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

בהיתוך הזה יש Tradeoff בין שתי חלופות קיצוניות:

• לשכור ארבעה מנהלים => משכורת מנהל × 4, אבל יותר גרוע: תקורת התקשורת וההסכמה בין 4 מנהלים לגבי פעילות הצוות => קבלת החלטות איטית יותר, והחלטות פחות אמיצות (כי צריך לפשר בין כולם).
• לתת את כל העבודה למנהל יחיד, משמע קושי ממשי למצוא אדם בעל כל היכולות (קושי בהשמה / גיוס). בנוסף: אותו האדם יעמוד בעומס גדול מאוד של נושאים בהם הוא צריך לטפל / להתמקצע (ולהישאר מעודכן).

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

אם כך, בהכרה שהמנהל הבא שלנו לא יכול "לסחוב" את כל ארבעת התפקידים: היכן "חותכים" את התפקיד? מה התפקיד הראשון להוציא מהמשוואה ולהציב כמנהל נפרד?

הקונצנזוס הוא בהחלט על מומחיות המוצר, בדמות Product Manager / Expert כתפקיד נפרד. חשוב עדיין למנהל ההנדסי להבין ולדעת על המוצר – אבל הוא לא יוביל ולא יהיה המומחה הראשי לראיית המוצר. לעתים יש נטייה להעביר למנהל המוצר גם ניהול פרויקטים – מה שלרוב עובד לא-טוב. כתבתי על זה בפוסט על DevProd.

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

התחום שיש לגביו את הקונצנזוס שבכל מקרה עליו להישאר אצל המנהל ההנדסי הוא תחום ניהול האנשים. מלבד SCRUM שבתאוריה דורשת שה SCRUM Master לא ינהל אנשים (מה שלא קורה לרוב בפועל, לפחות לא בחברות ישראליות) – בכל הגישות המקובלות האחרות – ניהול האנשים נותר בידי המנהל ההנדסי. אין מה לעשות: להיות המנהל של המהנדסים נותן למנהל Leverage משמעותי בהשפעה על חברי-הצוות. שווה לציין ש SCRUM הולך ונעלם מהחברות המובילות ונותר (ביחד עם וריאנטים כמו SAFE) בעיקר בחברות פחות-טכנולוגיות / סוכנויות ייעוץ. הנה סקירה 1 וסקירה 2 של המגמות האלו (בקישורים דנים גם בנושא הפוסט: כיצד לחלק את ההיבטים השונים של הניהול ההנדסי). על דעיכת הסקראם בחברות המובילות כתבתי בעבר (עוד לפני שהבנתי שזו מגמה רחבה) בפוסט על NoSCRUM.

אז ניהול האנשים נותר בידי המנהל ההנדסי, ולרוב הוא מקבל תמיכה בתפקיד הזה מהמנהל שלו ו/או מחלקת ה People/HR בדמות תפקיד שנקרא Busines Partner. סיכום ביניים:

• ניהול אנשים נמצא בידי המנהל ההנדסי – בתמיכה קלה מבחוץ (Coaching/Mentoring)
• ניהול המוצר – נמצא לרוב בחוץ, אך נדרש מהמנהל ההנדסי להבין בתחום בכדי להיות חוליה מקשרת משמעותית של הצוות לניהול המוצר.
• נשארו שני תחומים שהם באזור האפור / לא חד-משמעי: ניהול פרויקטים והובלה טכנולוגית.

אולי הכי טבעי להפריד את ניהול הפרויקטים? הרי יש תפקיד כזה בתעשייה: "מנהל פרויקטים" (Project manage).

אם קראתם את הקישורים למעלה, ובכלל אם אתם ערים לנעשה בתעשייה, אתם בוודאי שמים לב שתפקיד "מנהל הפרויקט" הוא פרקטיקה שהולכת ונעלמת, לפחות בארגונים המובילים. הסיכויים של מנהל פרויקט, ללא הבנה טכנולוגית, להוביל פרויקט טכנולוגי ביעילות גבוהה – היא נמוכה. לרוב הוא "יתרוצץ" עם הגנט (Gantt) ויציע הצעות מאוד הגיוניות ברמת הגנט – אך לא הגיוניות ברמה הטכנולוגית. הוא לא יצליח לאתגר את המהנדסים ו/או להוביל כמעט לפריצות דרך בתוכנית הפרויקט. הוא תלוי לחלוטין בתובנות של המהנדסים – וזה לא מצב שתומך בהצלחה.

החלופה שכן נראה שמצליחה לעבוד היא תפקיד בשם מנהל פרויקטים טכנולוגי (Technical Project Managers או TPM): מהנדס בעל יכולות ניהול פרויקטים שמבצע ניהול פרויקטים טכנולוגי (בקיא ומבין את ההיבטים הטכנולוגים של הפרויקט והעשייה ההנדסית בכלל) – וכך מוריד עומס מהמנהל ההנדסי. TPM, לא פעם, זו עבודה במשרה מלאה – כלומר: ה TPM, למרות שהוא מהנדס לא ישתתף בכתיבת קוד – אך בהחלט ישתתף בדיונים טכניים שנוגעים לפרויקט (אינטגרציות, צווארי בקבוק, וכו').

עבור פרויקטים פשוטים / קטנים – מהנדס מהצוות יכול לקחת את התפקיד באחוז קטן של משרה, ולפנות את המנהל ההנדסי. בפרויקטים מורכבים – מקובל שה TPM הוא משרה מלאה.

כדרך אגב: מודל נוסף ששווה לציין הוא ה Single Threaded Owner (בקיצור STO), מודל שהגיע מאמזון ובו המנהל ההנדסי הוא אחראי על כל פעילות הצוות (כל 4 התחומים), אבל ע"פ הצורך – הוא ממנה איש מוצר או TPM בכדי לעזור לו. הכוונה היא ליצור צוות אוטונומי באמת, בלי תלות בגורמים חיצוניים, רעיון שמתחבר חזק עם תרבות ה DevProd.

התפקיד השני שיכול להוריד מעמסה מהמנהל ההנדסי ולתמוך בו הוא תפקיד המוביל הטכנולוגי (Tech Lead) – תפקיד שיש לו וריאציות רבות (חבר צוות, מקביל לראשי הצוותים, וכו'), וננסה לתת דגשים כיצד הוא יכול לעבוד ולתמוך בראש צוות פחות טכנולוגי.

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

המנהל ההנדסי הטכנולוגי לרוב לא יהיה פנוי לניהול פרויקטים מורכבים, ולכן יסתייע ב TPM. זה יכול להיות חבר צוות (מהנדס) שמונה להוביל פרויקט קטן (או כמה כאלו במקביל), או מישהו בתפקיד שלם כזה (נתקלתי בטייטלים כמו Flow Owner, Feature Owner או Squad Lead – שבפועל היו דומים מאוד ל TPM). כמובן שאין צורך ב TPM ייעודי לניהול כל פרויקט – רק פרויקטים מורכבים שמעבר ליכולתו של חבר-צוות לנהל. ניהול של פרויקטים פנימיים של הצוות / קטנים ע"י TPM, הם bad smell של חוסר delegation של המנהל ההנדסי. ברגע שיש TPM במשרה מלאה, שעושה את עבודתו היטב, הוא יכול להדריך / לחנוך מפתחים בצוות שרוצים עוד אחריות, וללוות אותם בהובלת פרויקטים קטנים.

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

מודל שני: המנהל ההנדסי הפרויקטאלי (בנקרא בחוסר דיוק: People Manager – אבל שימו לב שהם לרוב מקדישים תשומת לב העיקרית שלהם לניהול פרויקטים, ולא לצדדים "האנושיים"):

המנהל ההנדסי הפרויקטאלי יוביל בעצמו את הפרויקטים המורכבים של הצוות, אבל לא יהיה פנוי / אין לו את העומק להוביל את הצוות מקצועית. בחירות טכנולוגיות, Design Reviews, ליווי המערכת וזיהוי של עיוותים / כפילויות / חוסר סדר והובלה לתיקון – יגיעו מתוך מהוביל המקצועי ולא ראש הצוות. חשוב שלמנהל הפרויקטאלי תהיה אינטואיציה הנדסית טובה, ושהוא לא יהיה שבוי / מובל ע"י המוביל הטכנולוגי לגמרי. מקרה כזה הוא בהחלט bad smell. עליו להבין מספיק טכנולוגיה בכדי להיות מסוגל לבקר / לאזן את המוביל הטכנולוגי ברמת הצורך. כל מצב בו צד אחד מוביל לחלוטין את הצד השני – אינו בריא. חשוב שהיה אתגור הדדי, ושיתוף פעולה.

תפקיד ה Tech Lead (וגם "ארכיטקט") הוא מאוד גמיש לפרשנות ושונה בין ארגונים. לא מספיק לתת למהנדס טייטל של "מוביל טכנולוגי" – ולקבור את הראש בחול. מוביל טכנולוגי הוא לא האדם שבקיא ביותר בטכנולוגיה החדשה ביותר, או צופה שעות בכנסים על טכנולוגיה.

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

מה עם מנהלים הנדסיים שעובדים מצד אחד עם TPM, ומצד שני עם Tech Lead – והם מתמקדים רק בניהול האנשים, הבנה מוצרית, ומנהיגות? זה נראה אפשרי (ואולי נחוץ) ברמת ה Executive (נניח VP R&D) – אך תפל וחסר טעם ברמה של מנהל זוטר או דרג ביניים. עובדים בכל הרמות זקוקים למישהו שיבין לעומק מה הם עושים, יציב להם מראה ופערים היכן יכלו לעשות טוב יותר – וילווה אותם לשיפור. אם המנהל שלי לא תורם לי בזה, וכל הפידבק המשמעותי שאני מקבל מגיע מאנשים אחרים (מפתחים אחרים, TPM, Tech Lead) – נראה לי שמשהו גדול חסר. למה אני כעובד, או הארגון – זקוקים למנהל שרק מנהל "תנאי שירות"?!

ברצינות?! זה הכול? [אכזבה צפויה]

היו לא מעט הערות על הפוסט הקודם. אנשים שציפו לפוסט הזה – ומה שיש לי לתת בו.

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

אם זו הייתה הציפיה – אני מתנצל. אין לי פתרון טוב יותר מהפתרון ההגיוני והטריוויאלי: הבינו את הפערים של המנהלים שלכם – ודאגו שהם יפוצו.

ישנן יכולות שניתן לפתח מהר ויש כאלו שלוקחות זמן. יש כאלו שבקושי ישתנו (להלן מודל החשילות). פיצוי (mitigation) בעזרת הוספת אדם הוא כלי חזק כי הוא מכניס למשוואה סט יכולות חדשות שייתכן שלאורך שנים לא תוכלו להכניס באופן אחר, ויחסית ניתן להפעיל אותו מהר (חודשים בודדים). ברור ששני האנשים: המנהל ההנדסי וה TPM או Tech Lead יצטרכו להתגמש ולפתח מערכת יחסים בריאה ויעילה – ושיש כאן אתגר.

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

איך לעשות את זה נכון?

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

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

• "הראש צוות הזה לא מבין מהחיים שלו. בסדר, הוא ימשיך לטעון שאין פה בעיה וכל המוצר הזה לא יעבוד יהיו טונות של באגים. הוא מוביל לזה – שיאכל את התוצאות (נאמר ע"י Tech Lead)".
• "חחחח… לא. זה עניין של ניהול פרויקטים. דברו עם ה TPM ותסתדרו איתו. לא עובד? אנא פנו ל chief TPM. אני לא הכתובת (נאמר ע"י מנהל הנדסי)".
• "תגיד בדיוק מה הדרישות הטכנולוגיות שלך – ונעשה אותן, אבל אני צריך הכול רשום עד לראשון לחודש – ובלי חרטות ושינויים (נאמר ע"י מנהל הנדסי למוביל הטכני)".

כתבתי לא מזמן פוסט על DevProd – ונראה לי שרוב מה שכתוב שם (הרי פיצינו את המנהל ההנדסי במומחה / מנהל מוצר שיעבוד איתו) נכון גם כאן. חבל לי לחזור על הדברים.

חשוב שתהיה שותפות אמיתית ואחריות משותפת. גבולות אחריות מעט מטושטשים – זה דווקא דבר בריא בקשר בין מנהל הנדסי ומנהל-תומך (TPM, Tech Lead).

לאנשים נוח עם גבולות גזרה ברורים ומקובעים משפטית, אבל חשוב לא לאפשר ליצור "קשר של ספק-לקוח" (עם חוזה שנוסח ע"י עו"ד) בין המנהל ההנדסי ל TPM / Tech Lead. מנהל הנדסי ש"מפיל את הכדור" ומשאיר אותו למישהו אחר – זה אידקטור לתפקוד לא-טוב. חשוב שהמנהל ההנדסי יפעל כאילו זה מצב זמני לחלוטין, ואוטוטו הוא לוקח את האחריות הזו מהמנהל התומך. הוא רוצה להבין ולהגדיל נוכחות – לא להקטין אותה. במקרים מסוימים זה יהיה המצב – ומנהלים הנדסיים יתפתחו בעקבות העבודה המשותפת עם מנהל-תומך – למקום שלם יותר.

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

צלע	התנהלות בקצה הנמוך	התנהלות בקצה הגבוה
האצלת / פיזור סמכויות (ה TPM אחראי לייצר מכפילים (multipliers) – אך המנהל ההנדסי הטכנולוגי צריך לתמוך בו. אנשי הצוות הם המועמדים הטבעיים והעיקריים להיות המכפילים)	* ה TPM משקיע את מירב זמנו בדיונים עם ראש הצוות הטכנולוגי – מכיוון שראש הצוות דורש להיות מעורב בכל החלטה טכנולוגית משמעותית. המנהל ההנדסי "אינו משחרר". * ראש הצוות ההנדסי לא תומך בצורה ברורה / מופגנת ביעדים של ה TPM ומעקב deliveries פעם אחר פעם "כדי לשמור על הארכיטקטורה". * היבטים טכנולוגיים חשובים בפרויקטים "נופלים" כי ראש הצוות ההנדסי לא היה מעורב / מיודע ולא הצליח להשפיע. המנהל ההנדסי לא מודע למה העובדים שלו עושים טכנולוגית, גם דברים משמעותיים.	* ה TPM וראש הצוות ההנדסי הם שותפים טובים. הם מבינים זה את זה, יש אמון גבוה, ושיתוף פעולה. ה TPM מכבד את דעתו של ראש הצוות ההנדסי ונותן לדעתו מקום משמעותי בתוכניות העבודה. * המנהל ההנדסי מלווה וחונך את המהנדסים בעבודה מול ה TPM, במקום לעבוד ישירות מול ה TPM בעצמו "ולפתור את הבעיה". * המנהל ההנדסי מבין את עבודת ה TPM, מאתגר אותו פרויקטלית, וככל שהזמן עובר מרגיש נוח לקחת ממנו נושאים ולהוביל אותם פרויקטלית.
תפעוליות/ביצועיות (ללא תקשורת טובה, ארגון אישי, והתנהלות ארגונית נכונה – כל העבודה של הצוות – עשויים לרדת לטמיון)	* ישנם פספוסים רבים של תיאום, וחוסר-תקשורת בין המנהל ההנדסי וה TPM.	* הדיונים בין ראש הצוות ההנדסי וה TPM הם אפקטיביים: ראש הצוות, כמוביל טכנולוגי, מצליח לחדד נקודות חשובות ולזקק את הנושאים להבנת ה TPM. * ראש הצוות ההנדסי זמין ל TPM במקומות החשובים, חוסך לו זמן, ועוזר לו להצליח.

בואו ננסה לעשות את אותו התרגיל למנהלים הנדסיים פרויקטליים המלווים במוביל טכני (Tech Lead):

צלע	התנהלות בקצה הנמוך	התנהלות בקצה הגבוה
הבנה מקצועית (המנהל הפרויקטלי נסמך אל מוביל מקצועי, אך הוא צריך להבין ולבקר אותו כל הזמן, ולא להיות "לקוח שבוי או נרפה".)	* מתמקד ב Delivery ומגדיל בעקביות חוב-טכני עמוק על מנת לקדם אג'נדה עסקית קצרת טווח. * מוותר על הצלע המקצועית, ואינו מעורב בצד המקצועי של עבודת הצוות. עושה "מיקור חוץ" של הטכנולוגיה למוביל הטכנולוגי – ולא מבין שזה תנאי מספיק לעשות "מיקור חוץ" לו עצמו, כמנהל הנדסי 🙂 * לא מודע למגבלות שלו ולוקח החלטות טכנולוגיות בלי גיבוי / בדיקה מספיקה מהיועץ הנאמן שלו. "זו החלטה ניהולית" – היא לא גישה טובה.	* בונה קשר פעיל ופורה עם המוביל הטכנולוגי, ונותן לו מקום להשפעה אמיתית בצוות. דורש ממנו, ומגבה אותו היכן שצריך. * דואג שהצוות מאוזן בין deliveries, פשטות הארכיטקטורה וחוב-טכני. * עוקב ומקשה על המוביל הטכנולוגי – מוודא שהוא מעורב בנקודות הקריטיות, ומאמת / מצליב את דבריו והחלטותיו מול המהנדסים.
אחריות להדרכה מקצועית (המנהל אינו מקצועי בעצמו, אך זו אחריות שלו שהעובדים שלו יפותחו מקצועית, וברמה גבוהה)	* לא לוקח אחריות אמתית על הפיתוח המקצועי של העובדים שלו. מוסר את הנושא למוביל הטכנולוגי, במתכונת "שגר ושכח". מוריד מעצמו אחריות. * עובדים תחת המנהל המקצועי לא משתפרים – בראייה של הצוותים הסובבים אותם. תלונות על חברי צוות חוזרות על עצמן לאורך זמן.	* מוודא שהעובדים תחתיו זוכים לפידבק משמעותי ותכוף מהמוביל הטכנולוגי – פידבק שהעובדים יודעים להעריך ככזה. דואג לעקוב ולהבין את הפידבק ומוודא שהעובדים "עובדים" על הפידבק בצורה יעילה. * מעורב בפניות ודילמות לגבי מקצועיות של העובדים, ומוודא שהן מטופלות כמו שצריך: עובדים שיש להם פערים – מודעים לזה ועובדים על הנקודות הנתונות. הטרדה של עובדים בתלונות שווא – מזוהות ונהדפות.

מה עדיף? מנהלים הנדסיים טכנולוגיים או פרויקטליים?

נניח ואין ברשותנו מספיק מנהלים הנדסיים "well rounded" – מה עדיף? להתמקד במנהלים הנדסיים טכנולוגיים או פרויקטליים? את מי לקדם? מה לגייס?

אין כמובן תשובה אחת, נכונה בהחלט, וכוללנית – אבל נראה שהמפתח הוא איזון + התאמה לצרכים.

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

לגבי התאמה לצרכים: יש ארגונים שהם יותר טכנולוגיים מאחרים ב core business שלהם. הארגון שמפתח את בסיס הנתונים MySQL כנראה זקוק להטיה טכנולוגית חזקה יותר מחברה שעוסקת בבילינג (הרבה פרויקטים מול לקוחות ספציפיים, פחות hardcore technlogy). מצד שני יש גם עניין של ביקוש והיצע: היינו מעדיפים מנהלים הנדסיים "well rounded" לכל תפקיד – אך אין לנו. לפעמים אנחנו מעדיפים מנהלים טכנולוגים – אבל לא מוצאים אותם. פעמים אחרות אנחנו מעדיפים מנהלים פרויקטליים – אך מתקשים למצוא אותם (בארגון או בראיונות).

ההנחה המקובלת היא שיש יתרון משמעותי לראשי צוותים (אלו שמנהלים מהנדסים ישירות) שהם מנהלים טכנולוגיים, כלומר מנהלים טכנולוגיים שמגובים ב TPMs, יביאו את הצוותים (ומכאן: הארגון) למקום טוב יותר מאשר מנהלים פרויקטליים מגובים ב Tech Leads:

• מהנדסים נוטים להעריך יותר, ולהיות מרוצים יותר תחת מנהלים שמבינים היטב, ומעורבים – בעבודה שלהם.
• ניהול ישיר הוא עמדה עדיפה ל Mentoring / Coaching מאשר Tech Lead רוחבי. אולי זה עניין של מחויבות של המנהל לעובדים שלו, מול החלופה של Tech Lead שיותר חופשי עם מי נוח לו לעבוד?
• "תרבות הנדסית" (Engineering Culture) הוא דבר חמקמק שקשה יותר לטפח מדרגים גבוהים. אם המנהלים הישירים של המהנדסים לא "חיים", משדרים, ומדגימים את תרבות הנדסית – הסיכוי של הארגון לטפח "תרבות הנדסית" ברמה-גבוהה – הרבה יותר נמוך.

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

ביקוש והיצע – וכיצד הארגון משפיע עליהם?

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

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

כלומר: גם אם א-פריורית ישנם 50% מהנדסים שיהפכו למנהלים טכנולוגים ו 50% מהנדסים שיהפכו למנהלים פרויקטליים – יש סיכוי טוב שכמות המהנדסים בעלי פוטנציאל בצד הפרויקטלי שיביעו עניין במשרת ראש צוות היא גדולה יותר (אנחש: 50-100% גבוהה יותר). אם בתרבות הארגונית ראשי צוותים נמדדים פחות על הובלה טכנולוגיות ו/או מנטורינג טכנולוגי משמעותי של עובדים – הנטייה יכולה לגדול אפילו יותר.

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

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

סיכום

בחלק השני, ניסיתי להתמודד עם הדילמות:

• איך מפצים על חלקים חלשים בתפקוד של המנהל ההנדסי. איך לא הופכים את החוסר הזה ל"בעיה של הצוות / מוצר / מערכת" וצוברים נזקים מתמשכים.
• "מנהלים טכנולוגיים" מול "מנהלי אנשים פרויקטליים" – איך לבחון ולאזן ביניהם.

הייתי שמח להציג סט כלים רחב ומגוון יותר ממה שהצגתי לדילמות האלו – אבל אני לא מצליח לחשוב על כאלו. אולי אתם, בתגובות, תעזרו לי למצוא עוד גישות וכלים מעשיים להתמודדות עם הדילמות הללו?