כללי

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

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

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

מה תפקידו של Engineering Manager? איך מעריכים Engineering Manager?

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

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

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

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

ננסה לענות על שתי שאלות חשובות:

  • "אני מנהל הנדסי, איך אני יודע אם אני עושה עבודה גרועה / סבירה / טובה / מצוינת? אלו דגשים עלי להפעיל כדי לעשות עבודה טובה יותר?"
  • "אני מנהל של מנהלים הנדסיים, איך אני מבין מי המנהלים הטובים ביותר שלי? איך אני עוזר לכל המנהלים שלי להשתפר ולהתקדם?"
צלעהתנהלות בקצה הנמוךהתנהלות בקצה הגבוה
מומחיות מקצועית
(בחברה טכנולוגית, וככל שקרובים יותר לעשיה / למהנדסים, קשה מאוד להגיע להישגים משמעותיים ללא הבנה עמוקה של המקצוע: הנדסת תוכנה)		* מוביל לא פעם דיוני Design למקומות לא טובים, או לסירוגין: מרחיק עצמו מהחלטות מקצועיות חשובות. נסמך על אחרים שייקחו את ההחלטות במקומו.
* "נאלץ" לשחרר פיצ'רים באופן שמסבך את המערכת, מוסיף לה מקרי קצה ו/או כפילויות. הוא והצוות לא נוהגים להשאיר קוד "נקי יותר מכפי שהיה לפני שעברו דרכו"
* מאשר PRs עם קוד הזקוק לשיפור, בלי להעיר דבר.
* לו היה חוזר להיות מתכנת – היה מהמתכנתים הפחות טובים בצוות.		* "מציל" לא פעם Designs מטעויות גדולות / כיוונים שגויים.
* מצליח לאזן בין שחרור "פיצ'רים" למערכת פשוטה, עקבית, ושקל להבין / לעקוב אחריה.
* מעלה לדיון ולשיפור פרקטיקות לא טובות ברמת הקוד – ומצליח להוביל לשיפור מתמשך.
* מפגין הבנה עמוקה בבעיות טכנולוגיות מורכבות. סמכות מקצועית כלפי הצוות, ובכלל.
הדרכה מקצועית
(המנהל לא רק מקצועי בעצמו, אלא נמצא במערכה תמידית ואקטיבית לשפר את המקצועיות של חברי הצוות שלו – זו עבודה שדורשת השקעה רבה)
הערה: מכל הצלעות, זו כנראה הצלע שהכי נפוץ להזניח. המנהדסים הם משמעותיים ויקרים, ואי-השקעה אמיתית בהם תוביל את הארגון לבינוניות.
הערה: כלל האצבע שיש להימנע מניהול ישיר של יותר מ-6 אנשים נובע מהצלע הזו: כמעט בלתי אפשרי לנהל וגם להדריך מקצועית יותר מ 6 אנשים.		* לא יודע לאבחן את הפערים המקצועיים של אלו שהוא מנהל. מסתמך על "סקר" שנתי כדי לתת פידבק לעובדים – ולא פידבק שוטף.
* פיתוח עובדים שנתי מסתכם בשליחה לקורס או גיוון בפרויקטים. אין פידבק קונרטי ומתמשך.
* עובדים תחת המנהל המקצועי לא משתפרים – בראייה של הצוותים הסובבים אותם. תלונות על חברי צוות חוזרות על עצמן לאורך זמן.
* "סומך" על המנדסים במאה אחוז, ולא מאתגר אותם. הם ילמדו מניסיונם האישי, או מאנשים אחרים בארגון – לא מהמנהל.
* מנהל שיודע הרבה, אבל לא מעניין אותו כ"כ ללמד ולקדם אחרים. "שומר את הידע אצלו"		* נותן פידבק משמעותי ותכוף לעובדים תחתיו – פידבק שהם יודעים להעריך כמשמעותי.
* פניות למנהל המקצועי לגבי תפקוד העובדים שלו – מסתיימות בדרך כלל בשביעות רצון לאורך זמן (או בהבנה מדוע הפנייה לא נכונה)
* מעלה מסביבו את הרף המקצועי, בתחום הנדסת תוכנה.
* מפגין תשוקה לקדם את המצוינות המקצועית, תורם הרבה להשכלה, דיונים, והכשרה של עובדים.
הבנה מוצרית
(רכיב קריטי ביצירת אימפקט ויעילות אמיתית של הצוות)		* "Yes Man" של אנשי המוצר. ממלא הוראות.
* מפספס היבטים לא הגיוניים ברמת המוצר/ביזנס/משתמשים בפיצ'רים – ולא מצליח לעצור / לשנות אותם בזמן הפיתוח.		* מאתגר את אנשי המוצר בעניינים של מוצר / ביזנס / לקוחות – ומוביל למוצר טוב יותר.
* יוצר שותפות אמיתית ועמוקה עם אנשי המוצר שעובד איתם (DevProd)
מנהיגות
(מילה גדולה, אך יש לה בסיס. הצלע הזו היא לרוב זו שמובילה את המנהל לשלב הבא בקריירה שלו – בעוד שאר הצירים הם התומכים)		* נקבר תחת השוטף / ריאקטיבי – לא יוזם מהלכים משמעותיים.
* הצוות שתחתיו ב Engagement בינוני או נמוך כלפי הארגון ומטרותיו. ציניות ותסכול אינם נדירים.
* עסוק ב"הגנה על הטריטוריה" ושמירת סטטוס-קוו שהולך והופך לפחות רלוונטי לארגון.		* המנהל ההנדסי מפנה זמן מהעבודה השוטפת להכנה של מה שידרש לשוטף של התקופה הבאה: ניהולי, טכנולוגי, תהליכי.
* הצוות מחובר למטרות הארגון וזה ניכר בעבודתו.
* עושה סדר היכן שחסר, מתווה כיוון היכן שאחרים מבולבלים או מתקדמים לכיוון שגוי מבלי להבין.
* שואל שאלות עמוקות, ומאתגר את הארגון.
ניהול אנשים
(יש אנשים, והם לא תמיד יודו בזה: אבל הם זקוקים לאבא ולאמא – וזה במקרה המנהל ההנדסי)		* אנשים בצוות מתפספסים (למשל: תסכול, קשיים שלא נפתרים, בעיות בתוך הצוות) וזה מתבטא בתפקוד נמוך של הצוות / עזיבה / טיפול ע"י HR / מובילים שאינם המנהל ההנדסי.
* כל חברי הצוות הם באותה הרמה: "בסדר" או "מצוינים", אין בולטים לטובה ואין חלשים.
* עסוק בלרצות את חברי הצוות הרבה יותר מאשר לאתגר ולדרוש מהם.		* הצוות במוטיבציה גבוהה, מעריך את המנהל, ועובד טוב בינו לבין עצמו. מעט עזיבות.
* אנשים חזקים בולטים מהצוות ומוכרים בארגון, אנשים חלשים – מטופלים.
* מנהל בהצלחה אנשים מגוונים, עם אופי וסגנון שונה.
האצלת / פיזור סמכויות
(האימפקט של המנהל ההנדסי תמיד יהיה חסום ביכולת שלו לייצר מכפילים (multipliers). אנשי הצוות הם המועמדים הטבעיים והעיקריים להיות המכפילים)		* המנהל ההנדסי שולט ביד רמה בכל מה שקורה. קולו נשמע בכל דיון, וכולם מחכים לו / מנסים להשיג אותו, או לסירוגין: המנהל ההנדסי מצטרף לישיבות ולא ברור אם הוא יותר מאורח. קולו לא נשמע.
* אין כמעט נושאים שמקודמים בצורה עצמאית ע"י חברי צוות או לסירוגין: יש הרבה כאלו – אך הם לא מתנהלים היטב.
* המנהל ההנדסי תמיד עסוק. שבועיים חופש שלו – מסתמנים כפגיעה משמעותית בעבודה השוטפת.		* רוב הנושאים בצוות מובלים ע"י חברי צוות, ורוב חברי הצוות מובילים משהו – תוך שרובם מצליחים, בעוד המנהל ההנדסי יודע בדיוק מתי להתערב ובאיזו מידה. הדבר מאפשר למנהל ההנדסי להוביל יותר נושאים – ממנהלים שלא עושים זאת.
* המנהל ההנדסי זמין לדיונים חשובים: הוא לא נעול back to back בישיבות, אלא תמיד יש לו איזשהו זמן פנוי למה שחשוב.
תפעוליות / ביצועיות
(ללא תקשורת טובה, ארגון אישי, והתנהלות ארגונית נכונה – כל העבודה של המנהל ההנדסי והצוות שלו – עשויים לרדת לטמיון)		* אין אמון במנהל ההנדסי שמה שהבטיח עומד להתקיים (זמנים / איכות). ישנם פספוסים רבים של תיאום, תקשורת, ותכנון שנוגעים צוות שלו.
* תלונות על חוסר עירוב של גורמים / צוותים אחרים במקומות הנחוצים.
* לממשקים (צוותים אחרים) ולמנהל שמעל – אין נראות טובה על מה שקורה בצוות, איך הוא מתקדם, ומה האתגרים העיקריים שעומדים לפתחו.
* למנהל יש נטייה להמשיך ולהצעיד נושאים / את הצוות בפרויקטים ארוכים, בלי לשים לב שהמטרה השתנתה, או שניתן "לגלח" עבודה משמעותית.		* מצב הצוות והפרויקטים שהוא מוביל מתוקשרים בצורה ברורה ושוטפת לכל הממשקים מסביב. קל לאנשים מסביב להבין מה האתגרים / בעיות, מה נעשה, ומה יעשה – ולמה.
* למנהל יש רצף של Deliveries שמוסכמים בארגון. צובר עם הזמן עוד ועוד "קבלות ביצוע".
* המנהל ההנדסי קשוב לנושאים שהוא מוביל, יודע לזהות ולהגיב לשינויים – לא פעם גם לפני שיש הכרה רחבה שזה המצב.
כמטאפורה: הכנפיים נושאות ומאזנות, החרטום מרים למעלה

המודל הזה אינו מושלם:

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

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

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

סיכום

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

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

Published