שנה: 2022

על מובילות-הנדסית

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

מדוע אני לא מתרגם את המונח ל״מנהיגות טכנולוגית״?

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

למה לכתוב פוסט על הנושא?

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

“ליאור, ה Tech Leadership זה התפקיד של ה Tech Lead בחברה, נכון? זה שלהם?״

חחח.. 😄😄

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

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

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

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

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

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

בואו נצלול ונדבר בפירוט על כל התנהגות.

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

״האם אתם יודעים מדוע אלוהים ברא בני אדם עם שתי אוזניים, אבל רק פה אחד? – בכדי שיקשיבו יותר ממה שהם מדברים.״

סימן ראשוני חיובי לפוטנציאל (יָכְלָה בעברית) להובלה הנדסית היא הנטייה לשאול ״שאלות טובות״: שאלות שמראות עומק, סקרנות, הבנה, והשתחררות מדּוֹגְמוֹת חשיבה מקובלות.

⚠️ מנהלים לפעמים מזהים את התכונה הזו – ו״פוטרים״ אותה: ״הוא שואל שאלות מעניינות, אבל הוא עדיין ג׳וניור…״. זה פספוס!
כדאי לאתר את האנשים שמציגים את ההתנהגות הזו (במידה והיא חוזרת על עצמה, ואינה חד-פעמית), לשים לב אליהם, ולנסות לאתגר אותם בהתנהגות הבאה: סיכום ופיזור ידע.

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

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

  • האדם מראה התעניינות כנה בנושאים שונים במערכת / עבודה, גם כאלו שאינם זקוק להם לצורך המשימות השוטפות. בנוסף: הוא מראה עניין בנושאים שעשויים להיות רלוונטיים.
    • אין משהו רע בהתעניינות בקריפטו, ב Deep Learning, או מחשוב קוואנטי. מצד שני: אם אלו אינם נושאים שקשורים לעבודה שלכם – הסקרנות הזו כנראה תמשיך להיות מקבילה לעבודה, ולא כדאי להסיק ממנה על התנהגות האדם בנושאי-עבודה.
  • האדם מפתיע ב״שאלות טובות״, במיוחד אם לא ציפינו שהניסיון שלו ו/או הידע שלו מספיק כדי לשאול אותן.
  • האדם קשוב לתשובות, ויכול לשנות את דעתו – אבל גם להמשיך ולפתח את הרעיון ולהמשיך לשאול שאלות טובות בהמשך הדיון (כלומר: אינו “one trick pony״).

סימנים מחלישים:

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

התנהגות ליבה: לזקק ולפשט ידע – ולפזר אותו לאחרים.

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

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

⚠️ אם אתם מנהלים ואתם מקדמים למרכז הבמה את ה״מרשימנים״ (שהרבה פעמים הם אנשים אינטליגנטים ובאמת מרשימים) ולא את ״המפשטים״ – שהופכים נושאים גדולים => לעניינים קטנים ומובנים, אזי אתם עושים עוול לא רק ל״מפשטים״, אלא גם לארגון.

סימנים מחזקים:

  • לאדם יש יכולת לתמצת דברים בכל מסגרת זמן נתונה: רבע שעה, דקה, או משפט. כתרגיל מחשבתי: בקשו מהם להסביר בציוץ טוויטר משהו – והם יכולים לעשות זאת.
    • היכולת הזו אינה מובנת מאליה בכלל, וחשוב להעריך ולפתח אותה. מי שיודע לפעמים לתמצת – בקשו ממנו לעשות את זה יותר. בהתחלה זו עבודה קשה, אבל עם הזמן מיומנות התמצות והביאור משתפרת – וזה הופך לתהליך קל, טבעי, ואפילו – אוטומטי.
Thread מוצלח, מעבר לדוגמה שבתמציתיות
  • כשהאדם מעביר ידע, הוא לא מעביר אותו בדיוק כפי שקיבל אותו – אלא מוסיף לו ערך ע״י תימצות, המחשה, דוגמאות משופרות, וכו׳.
    • היכולת של Martin Folwer לקחת את ספר ה UML User Guide בן 500 עמודים, ולהפוך אותו לספר קליל של 200 עמודים. לצמצם את מספר סוגי הדיאגרמות לשימוש ב UML מ 14 ל 8 => זה פישוט אמיתי. הספר UML Distilled הפך מיד למקור המקובל ל UML, וסיפק המון ערך לכלל התעשייה.
  • הרצון הכן, לא לשמור ידע בבטן, אלא להפיץ את הידע לאחרים – שעשויים ליהנות ממנו.
  • דוגמה טבעית מאוד ליכולת לזקק ידע ולהפיץ אותו – היא הנטייה לשפר קוד, ולא קוד שהאדם הוא דווקא הכותב המקורי שלו: שינוי קוד מורכב כך שיהיה פשוט יותר, החלפת שמות משתנים לשמות משמעותיים יותר, שימוש בקונבנציות ברורות יותר, וכו׳.

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

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

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

סימנים מחלישים:

  • האדם טוען לא פעם את הטענות ש ״הנושא הזה מסובך מדי כדי להבין״ ו/או ״חבל על הזמן שלך לנסות להבין את זה״.
    • למרות שהדבר יכול להתפרש שדאגה כנה לזמן והבריאות הקונטיבית של המאזין, לרוב מדובר בחוסר יכולת לפשט ולהסביר נושאים, ו/או חוסר עניין לשתף לעומק. פעמים רבות, זה נעשה באופן מאוד נחמד וידידותי, שמקשה עלינו להצביע על הבעיה.
    • ככל שנושא מסובך יותר – כל יש יותר ערך בפישוט שלו. אדם בעל נטייה לפשט לא יוותר על ההזדמנות הנהדרת כזו להשתמש ביכולות שלו ולספק ערך.
  • חוסר יכולת לארגן ידע, בעל-פה ו/או בכתב – הוא אינדקטור שלילי ברור. אם מישהו לא מסוגל לכתוב פסקה שתיים על נושא, ליצור דיאגרמה פשוטה שמסבירה את העניין – גם לאורך ימים, כנראה שהוא: א. לא יודע, ולא מודע לזה מספיק טוב. ב. בעל קושי ״לארגן את הדברים בראש״, יכולת מאוד חשובה להתמודדויות מורכבות בהנדסת תוכנה. לפעמים זה עניין של מיומנות, ולעתים עניין של יכולת.
  • ארגון מידע טרחני, לפעמים נתפס כ״יכולת לארגון ידע״ – אך הוא לא אותו הדבר. האדם שכותב מסמכים של עשרות עמודים היכן שהיה ניתן להסתפק במסמך באורך מספר חד-ספרתי של עמודים, מפספס משהו. אולי יש לו רצון כן לשתף ידע, אך ללא יכולת זיקוק, ארגון, ושיפור הידע – הערך קטן משמעותית. הסיבה לכך היא שזיקוק ידע מוביל ליעילות גבוהה יותר, וגם לפריצות דרך וחדשנות. פישוט + פישוט + פישוט => פריצת דרך אפשרית.
    • אני לא טוען שארגון ידע ״טרחני״ הוא חסר ערך. הוא פשוט בעל ערך נמוך יותר. זו לא המיומנות שאנו שואפים אליה.
  • בקוד: הנטייה להציג פתרונות קוד סבוכים ומרשימים (Clever but not very clear) – היא סימן אזהרה למישהו שאין לו יכולות או מוטיבציה לפישוט. לא פעם יהיה בקוד הזה רעיון מתוחכם (רקורסיה משולשת שחוסכת את הצורך ב storage) או מרשים (פיתחתי שפה ל Dependency Injection) – אבל זו רק הסוואה לחוסר היכולת לפתור את הבעיה בעזרת ארגון מידע – ושימוש בכלים פשוטים וסטנדרטיים של שפת התכנות.
    • לפעמים זה עניין של מוטיבציה: הרצון להרשים שגדול יותר מהרצון באמת לעזור לאחרים (במחיר קוד לא מובן / קשה לשינוי => עוול).
    • כאשר יש רצון אמיתי ותמידי לפשט דברים, גם קוד מסובך (כי לא הצלחנו לכתוב קוד פשוט בסיבוב הראשון) – הופך לפשוט (refactoring) עם הזמן.

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

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

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

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

על הנושא הזה דיברתי בפוסטי עבר בלי-סוף, ולכן אנסה לקצר.

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

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

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

יש את ה “Beneficial Clerks״ – אנשים המכירים את הנהלים / סטנדרטים / מערכת / ארגון / ביזנס, אכפת להם מהמתרחש והם יפעלו לפעול לפי הכללים וגם לשפר אותם. הם בהחלט מועילים וחשובים לארגון – אך פחות משמעותיים מאלו שמאתגרים את המערכת. Benefitial Clerks הם לא מובילים טכנולוגיים, או לפחות כאלו רק במידה הפחותה של המושג. מיקרו-מובילים.

יתרה מכך, כאשר באים לבצע שינויים בארגון, לא פעם ה Benefitial Clerks הם המתנגדים לשינוי. באופיים הם שומרים על הקיים, בעוד השינוי לא פעם נאלץ לדלג ולחליף את הקיים.

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

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

סימנים חיוביים:

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

סימנים מחלישים:

  • נטייה של האדם להשמיע את קולו בצורה לא עניינית, ללא חשיבה לפחות על ״הצעד הבא״ עלולה לבלבל: האם יש פה מובילות לא בשלה? או שלאדם חשוב יותר להישמע מאשר להשפיע?
    • קשה לי לענות בצורה גנרית, אבל אני נוטה לראות בהשמעת קול ללא התעמקות כסימן מחליש. עקבתי אחרי מספר אנשים כאלו לאורך שנים, שלמרות התקווה שיתפתחו להיות מובילים איכותיים – זה פשוט לא קרה. נראה התעמקות היא לא יכולת לא שגְּדֵֵלָה מעצמה ב cubicals של משרדי הייטק, והיא זקוקה משהו מעבר.
  • אנשים שמתלוננים בדיעבד על מה שנעשה – לפעמים רק רוצים לשחרר תסכולים. אם לא הגיבו בזמן שהדברים קרו, והם באים עם תלונה / תסכול – אך ללא תוכנית פעולה / רעיון לשיפור, יותר סביר שאתם חוזים בסגנון של שחרור קיטור, ולא בניצנים של מובילות.
  • לא מעט מנהלים מנסים לשמר את ״האווירה השלווה בצוות״, ותוך כדי כך מתנגדים לביקורת, מתוך היותה ביקורת. סביבה בה מנהלים שמים יותר משקל ומאמץ על ״שלווה״ מאשר על ״מצוינות״ – היא סביבה בה קשה במיוחד למובילים להתפתח.
    • מנהלים שמעדיפים ״שלווה״, כמובן, ינסו לנמק ולשכנע שזה הצעד הניהולי הנכון, וירבו להדגיש רגישויות של עובדים בצוות, כשיקול העיקרי לעניין.

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

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

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

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

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

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

לווֹלוֹדימיר זֵלֶנסקי, כך נראה, לא הייתה תוכנית או פתרון למקרה של פלישה רוסית מאסבית – היא הגיעה לאוקראינים דיי בהפתעה. הוא לא איבד עשתונות, גם כשהמודיעין המצוין של המערב צפה כשלון. גם כשארה״ב הציעה לו להתפנות מאוקראינה – הוא סירב. כנראה שלא תעמדו מול משבר אדיר-מימדים שכזה, אבל נסו לזכור מהמקרה – שהנהגה פועלת גם כאשר הכל נראה אבוד, וגם כאשר אין תשובות טובות. קודם מארגנים את השורות – התשובות מגיעות (בשאיפה), בהמשך הדרך.

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

סימנים מחזקים:

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

סימנים מחלישים:

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

סיכום

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

אם יש לכם אנשים מוכשרים בארגון, שמראים סימנים של הובלה, מאוד הייתי מעדיף שתפתחו את הצד הזה בהם, מאשר שתשלחו אותם ללמוד Framework נוסף… 😬

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

שיהיה בהצלחה!

על 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% גבוהה יותר). אם בתרבות הארגונית ראשי צוותים נמדדים פחות על הובלה טכנולוגיות ו/או מנטורינג טכנולוגי משמעותי של עובדים – הנטייה יכולה לגדול אפילו יותר.

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

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

סיכום

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

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

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

על Engineering Managers (חלק א’)

מנהלים הנדסיים (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 מזיק שאסור להתעלם ממנו.

סיכום

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

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

איך לגדול כארגון – מבלי לאבד את המהירות? (על מִקּוּד)

  • “כשהיינו חצי מהאנשים היום – נדמה לי שעשינו בערך אותה כמות של דברים”
  • “כשחברה מגייסת עוד הרבה עובדים, היא לא הופכת לגדולה יותר – היא הופכת לשמנה יותר”
  • “אי אפשר לזוז פה… כל היום יש רק ישיבות. איפה הימים של פעם, שכתבנו קוד רוב היום?!”

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

איך טווטיר / פייסבוק / Whatever – נתנו בשנים הראשונות ערך, שנראה לא רחוק מהערך היום, אבל עם שבריר מהעובדים שיש להם היום?

לתופעה הזו יש כמה הסברים פשוטים:

  • כשהארגון הוא קטן – מתמקדים ביכולות (“פיצ’רים”) שהם Low-hanging fruits, מעט השקעה – והמון ערך. הפיצ’רים הללו נגמרים די מהר – ונשארים רק פיצ’רים שדורשים השקעה גדולה יותר.
    • לחברה צעירה (מעט לקוחות/רווחים) לא משתלם להשקיע בפיצר’ים עם ערך לא גבוה. פיצ’ר שיוסיף עוד 1% הכנסות – לא שווה יריקה. כשהחברה גדלה – פיצ’ר שיוסיף עוד 1% הכנסות יכול להיות שווה שנות עבודה רבות, ובצדק.
  • מערכות תוכנה נוטות להסתבך ולהיות קשות יותר להרחבה ככל שהן גדלות / הזמן עובר. אם בשנה הראשונה של החברה פיצ’ר חדש צריך להשתלב עם 4 פיצ’רים קיימים, לאחר כמה שנים כל פיצ’ר חדש צריך להשתלב עם 20-30 או יותר פיצ’רים קיימים – ויש הרבה יותר עבודה כך שלא יפריעו / יסתרו זה את זה. כתבתי על כך בפוסטים: איך לנצח את הסיבוכיות? ו סיבוכיות: מקבלים את זה בחינם.
  • ביצוע (Execution) – הופך לקשה יותר ככל שהארגון גדול יותר:
    • ארגון גדול הוא מורכב יותר, וכמות האנשים המעורבים בכל פיצ’ר היא גדולה יותר. נדרשים יותר תיאומים ותקשורת.
    • צמצום פוקוס / פיזור הפעילות: ארגונים גדולים נוטים לפזר את כוחם על יותר נושאים, ולרוב נגררים לפיזור-יתר, שלא היה בזמן שהיו קטנים. פיזור היתר גורם לפרויקטים להתמשך, לא לעמוד בלוחות הזמנים – ואז תחת לחץ של עמידה ביעדים => להסתיים בצורה רדודה יותר, מה שיוצר חוב טכני / תפעולי – שמאט עוד את המערכת.

בפוסט הזה אתמקד בבעיות הביצועים של ארגונים גְּדֵלִים: ארגונים גדולים, אם שרדו, כנראה הצליחו להתמודד (לפחות חלקית) עם בעיות הביצועים שלהם. ארגונים גְּדֵלִים, החווים זו בפעם הראשונה – יכולים להגיע “להיתקע”, ואולי אף לא לצלוח יפה את הצמיחה.

צמצום פוקוס – איך זה קורה?

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

  • גודל הארגון (למשל: מספר האנשים) – מספק תחושת יכולת. כל אותם דברים שאמרנו לעצמנו “אנחנו ארגון קטן, אין לנו זמן לעשות את זה” – עולים עכשיו על השולחן לדיון מחודש.
    • חלק מהדברים הללו, אולי אפילו חלק גדול מהם – עדיין לא נכון לעשות, אבל הכשל הלוגי הוא הצמדה של הדחייה לטיעון “אבל אנחנו רק 20 אנשים”, וברגע שהפיתוח כולל כבר 50 אנשים – התנאים השתנו ויש לנהוג אוטומטית אחרת.
    • בכל זאת, אנחנו רוצים “לצ’פר” את האנשים הטובים שהביאו אותנו לכאן ולעזור לקדם דברים שהם מאמינים בהם. בכל זאת – הם צודקים: עכשיו יש לנו יותר אנשים.
    • “התמורה לא מצדיקה עדיין את ההשקעה” – הוא קישור לוגי נכון יותר, שיכול להיות תקף גם בחברה של 500 או 1000 עובדים.
  • כשהארגון גדול, כבר אין קיום (כמעט) לפרשים בודדים. מעטים הם האנשים / המשימות שאדם יוכל לבצע אותן לבדו – מבלי להזדקק לעזרה, בניגוד לארגון קטן.
    • למשל:
      • איש ה Security לא יוכל לקדם דברים משמעותיים – בלי השקעה משמעותית של מפתחים.
      • איש ה Performance שבא לשפר את המערכת – לא יוכל להתקדם הרבה בלי השקעה משמעותית של מפתחים.
      • איש ה Training – לא יוכל לקדם תוכניות הדרכה בלי מעורבות / השקעה משמעותית של המפתחים הטובים שמבינים בעניין.
    • בכל שלושת הדוגמאות הבאנו לארגון “מומחה שיקדם נושא” – אבל שכחנו להעריך את ההשקעה הנוספת הנדרשת מהפיתוח בכדי לקדם ברצינות את האג’נדה. התוצאות הן לרוב:
      • פיזור הכוח על יותר חזיתות ממה שנכון לארגון.
      • אי קידום רציני של האג’נדות – מה שמבאס את מי שאמור להוביל אותן, ואת מי שקיווה מהן לשיפור ממשי. פגיעה במורל ואולי אף יותר: בהרגל החשוב לסיים את מה שהתחלנו => מקור לעוד התדרדרות ב Execution.
    • אותו מקרה בדיוק קורה גם ביוזמות שהן nice-to-have, למשל:
      • מעבר לטכנולוגיות / ספריות חדשות שנראות טובות יותר (אך הארגון יכול “לסחוב” בסדר עוד כמה שנים בלעדיהן) – הערכה ראשונית היא שמפתח ל x שבועות יבצע את המעבר – אך הוא “מפריע” לפיתוחים אחרים ואף דורש שיתוף פעולה שלא תוכנן.
      • השקעה בתשתית שהציקה לנו והגבילה אותנו, כך שלא תגביל בעתיד (אך מחיר ההשקעה הוא גבוה מדי לתמורה) – לאחר שמתחילים את ההשקעה לפעמים “תחושת החיוניות” של השינוי יורדת – אך לא מרגיש נכון / קשה להפסיק באמצע, וכך ממשיכים גם כאשר החשיבות נראית פחותה.
      • הקמת בלוג / ארגון כנסים / יוזמות חברתיות / וכו’ – אנו נוטים להעריך בחסר את המחיר האמיתי של היוזמה בשעות מפתחים בפועל + קשה מאוד להפסיק אותן בפועל כדי לא לאכזב את האנשים הטובים שהתמסרו להן.
    • תופעות הלוואי העיקריות של “פרשים בודדים” שנדרשו לעזרה מכוח העבודה העיקרי הן:
      • התעכבות בפרויקטים – וגם בפרויקטים הקריטיים לארגון.
      • שחיקה של אנשים, בלי שהם יודעים לתאר הרבה פעמים מדוע: הם רוצים לעזור, היוזמות השונות נראות להן הגיוניות – אבל ה context switch, ואי קיום תחושת ההתקדמות שהם רגילים לה – שוחקים.
  • ריבוי תהליכים שטרם הגיע זמנם – כולם יודעים שארגון לא יצליח לגדול בלי תהליכים ונהלים טובים הבנויים ל Scale, אבל לא פעם תהליכים שנדרשים לארגון של 2000 מושתתים על ארגון של 500 עובדים, ותהליכים המתאימים לארגון של 500 עובדים מושתתים על ארגון של 100 אנשים. משלמים היום על צרכים עתידיים – כמו משפחה ששוכרת דירה בת 6 חדרים כאשר הילד הראשון נולד…
    • דוגמאות נפוצות הן:
      • נהלים אחידים ונוקשים ברחבי הארגון, כאשר יחידה לא מסוגלת להתאים אותו לצרכיה – גם כאשר הדבר גורם לתקורה ניכרת.
      • תהליכים “למופת” – היכן שלא נדרש: “צריך כבל USB? הגש בקשה – קבל אישור של המנהל שלך ומנהל ה IT ואז תקבל ביום המחרת”. כבל USB אנחנו לא צריכים הרבה, אבל תהליכי Design, קוד רביו, ושחרור לפרודקשיין גם הם יכולים להסתבך מתוך היגיון שעדיין לא מצדיק את עצמו.
  • כל הדוגמאות הנ”ל גרומות לארגון להיות אטי, לדרוש יותר תקשורת / תשומת לב / פעלתנות – בכדי להשיג אותו הדבר.
  • פיזור הכוח על מספר רב של חזיתות – נותן את אותותיו:
    • הפרויקטים מתארכים ולא מסתיימים בזמן
    • אנשים נשחקים יותר – כי הם צריכים לעשות יותר בכדי להשיג תוצאה דומה
    • העדיפות בפועל של הפרויקטים הקריטיים יורדות: המפתח המוביל בפרויקט החשוב ביותר בארגון עוזר קצת ליוזמה X, מעדכן את הסביבה שלו לתשתית החדשה, עונה על כמה סקרים, משתתף בקבוצת חשיבה וממלא אחר כמה נהלים חדשים. לכאורה כל אלו בעדיפות שנייה – אך בפועל כל הפעילויות הללו נעשות על חשבון הפרויקט הקריטי ביותר בחברה: כלומר הן הפכו לעדיפות העליונה.
  • במקביל: ההנהלה בארגון גדול יותר מנותקת מהפרטים והשטח – ולא מבינה מה מתרחש. תוצאות שליליות אפשריות הן:
    • תחושה שאנשים פחות משקיעים – וצריך לדרבן אותם יותר. דרישה “לחזק כוחות – ולעמוד ביעדים” – לרוב תוביל לתוצאה צפויה, ולא רצויה: ירידה באיכות / בדיוק / ובסגירת הנושאים.
    • ההנהלה בעיקר רואה עמידה / אי-עמידה בלוחות הזמנים (מה שקל למדוד) ורואה פחות ופחות דיוק ואיכות (מה שקשה למדוד, במיוחד מגבוה).
    • התוצאה הטבעית היא ירידה באיכות במקומות הפחות נראית (חובות טכניים) => מה שגורם לאיטיות מצטברת ולמעגל העצמה של הבעיה.
      • הצוותים בשטח לא משקפים עד-הסוף את האיכות היורדת – אבל נאלצים לשלם את מחיריה בהתנהלות השוטפת – מה שפותח להם חזית נוספת לעבודה, ומפזר את הכוח של החברה על מרחב גדול אפילו יותר של פעילויות: התמודדות עם חובות טכניים שאינם על השולחן.
    • בארגון מפתחת שחיקה, תסכול, וציניות = מה שמדרדר עוד את היעילות של הארגון, ופוגע עוד ביכולת של ההנהלה להבין בדיוק מה קורה כאן…
  • רוצים להוסיף עוד קצת שמן למדורה? שלחו את ראשי הצוותים שלכם להדרכה על “ניהול זמן”. זה בטח עומד לפתור את הבעיה!
    • קביעת “שעות ללא פגישות” הן וריאציה מוצלחת מעט יותר – אך עדיין לא פוגעת בבעיה העיקרית: ריבוי החזיתות שיש להתמודד איתן.

האם באמת מדובר בבעיית פוקוס?

ביצועיות (Execution) מושפעת ממספר גורמים בארגון: מעורבות (Engagement), כישרון, אפשור (Empowerment) וכו’. פגיעה בכל אחד הנ”ל – יפגע ביכולת ה exection. אם הארגון היה בסדר בכל הדברים, והוא בתהליך גדילה – פיזור הפוקוס הוא המועמד הסביר ביותר לתאר רגרסיה ב Execution. בואו ננסה להציב עוד כמה מאפיינים של בעיית פיזור הפוקוס, בכדי לאשש שאכן בה מדובר:

  • פרויקטים הולכים ומתארכים (הערכות הזמנים), בד בבד עם פרויקטים שפחות ופחות עומדים בזמנים. כאשר צוות נדרש להרבה חזיתות – אחוז הזמן שהוא משקיע בפרויקט העיקרי – הולך ופחות.
    • שערוך של שעות העבודה נטו על קוד / דזיין ביום – יכולות לעזור לזהות ירידה בפוקוס. קושי: יש להתחיל בשערוך כשהמצב עוד “טוב”.
  • יעדים לא מושגים, או שמתברר בדיעבד שלא הושגו: חשבנו ששיפרנו חוב טכני / חווית משתמש – אבל חודשים אח”כ מתברר שהתוצאה לא הושגה – ואולי יש לחזור ולהשקיע באזור.
    • כשאנחנו מפזרים את הפוקוס – אנחנו יכולים פחות להקפיד שאכן הדברים נסגרו. כשיש פרויקט אחד שהוא עיקר תשומת הלב שלנו – יותר קל וסביר שנסגור דברים “עד הסוף”.
  • מאבק עקוב מדם על משאבים (כלומר: אנשים) – הרבה צוותים שמרגישים שאין להם את כוח האדם שהם זקוקים לו בכדי להתקדם / להשיג את היעדים. ש”אם רק היינו מקבלים עוד 2 מפתחים – הכל היה מסתדר”.
  • עבודה קשה ו/או היכולת לסיים דברים היא המדד העיקרי להערכת עובדים, בפועל (ולא למשל: עבודה מצוינת וחכמה). זה אומר ש:
    • אנשים כנראה באמת עובדים קשה, וזה יכול להיות סימן שלא עובדים כ”כ יעיל.
    • המנהלים כבר לא מסוגלים להיות בפרטים, ולהבין את העבודה שנעשית – ונאלצים לבצע הערכת עובדים ע”פ “מי נשאר עד מאוחר בערב / מתלונן יותר על הקשיים”.
  • אי אפשר להשיג את אנשי המפתח (ראשי צוותים, Tech Leads, וכו’) להתייחסות על נושאי-הליבה. היומן שלהם סגור 8:00 עד 8:00 וניתן להשיג אותם רק בטווח של כמה ימים ל”איזו חצי שעה”.
    • חשוב שאנשי-מפתח יהיו זמינים לדברים החשובים ביותר. אם הם לא – הם ייגרמו לעיכובים מתגלגלים ובעייתיים מאוד – דווקא בפרויקטים הקריטיים.
  • לא ברור בארגון מהם הפרויקטים החשובים ביותר. כל אחד חושב שהוא “הכי חשוב” או שמסכימים ש”כולם חשובים” => אף אחד לא מקבל באמת עדיפות => אין תעדוף אפקטיבי.
  • צוותים מסוימים משלמים על חוב טכני משמעותי, ולא תמיד שנגרם בגללם. לא אמירות כלליות (שתמיד יהיו; כל פרויקט שרק נגמר “סוחב” חוב טכני כלשהו) – אלא בזבוז זמן ניכר, שקל למדוד ולהעריך.

סיפור לדוגמה הוא שיטת ה prioritization של חברת פנדורה – שהתפרסמה כמודל לחיקוי. השיטה מציגה מנגנון תעדוף ע”פ תקציב (budget). כל stakeholder / איש-מוצר מקבל “תקציב” (נניח $100) של פיתוח – אותו הוא יכול להקצות ל”פיתוחים” לפי ראות עיניו. לכאורה זה מאוד הוגן, נוח, ומסיר חיכוכים – כל אחד מצביע לפי הבנתו, בלי צורך להתווכח בדרך לקונצנזוס. מצד שני: אין מנגנון שווידא ש stakeholders מושכים לאותו הכיוון, לאותה האסטרטגיה. לכאורה יש אפשור שבשתיקה למשוך לכמה כיוונים שונים, בו זמנית, בפיזור מאמץ “by design”. יותר גרוע: כל stakeholder לעצמו עלול “לפזר סיכונים” ולהשקיע בכמה יוזמות – כדי שלפחות יזמה אחת “שלו!” – תצליח. המנגנון בעצם מאפשר להשקיע בעשרות יוזמות במקביל, בלי תיאום, ועם סיכוי הולך וקטן להשיג ערך משמעותי. פנדורה כבר בדעיכה, ולא נחשבת דוגמה ללמוד ממנה. אין לי ידיעה אם זה מה שהוביל לנפילתה – אבל זו בהחלט נראית לי דרך מעולה לאבד פוקוס!

כך פלשו לנורמנדי: כוחות אדירים הפולשים בו זמנית לחמישה חופים צמודים – כי Failure is not an option. לא טפטוף של כוחות קטנים לאורך עשרות ומאות החופים של צרפת. Beachheading (“הפעלת ראש חץ”) הוא Guideline ברור לחברות סטארט-אפ: לרכז מאמצים בודדים לאימפקט גבוה – ולא לפזר אותם.

מה אפשר לעשות?

“טוב. אולי יש לנו בעיית פוקוס. אז בואו נתפקס יותר טוב, לא?”

זה נשמע קל, אבל זה לא – במיוחד שהארגון גדל:

  • כדי להתמקד ב 10 יוזמות, הארגון דחה כבר 40 יוזמות אחרות. קשה להפנים שלא התמקדנו מספיק, במיוחד כאשר:
    • הארגון הצליח וגדל – “והגיע הזמן קצת ‘לשחרר’ ולעשות יותר דברים”.
    • מצטרפים לארגון עוד ועוד אנשי-מפתח שמעלים נקודות נבונות – היכן לארגון יש חוסרים, ו”חשוב” להשקיע ועכשיו. בשביל זה גייסנו אותם – לא?

המפתח לפוקוס בארגון גָּדֵל הוא:

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

המלצה היא לתת למשימות הארגוניות החשובות שם גדול כמו “Wildly Important Goals” (בקיצור: WIG). שם גדול שלא ניתן להתעלם ממנו. הארגון צריך להתמקד בכמה משימות סופר-חשובות שכאלו בצורה עמוקה. השם גם יגרום לביקורת פנימית – אם המשימה אינה באמת חשובה ומשמעותית עד כדי-כך.

כ WIG, יש לבחור את המשימות שמוכנים ללכת בהם “עד הסוף” מבחינת משאבים והשקעה, מתוך אמונה שכל יום שמושקע בהן – ייתן תמורה משמעותית לחברה.

אמורים להיות מעט מאוד WIG – בהם אנחנו מתמקדים. (תזכורת למתודולוגית ה OKR, בה יש לקבוע 3-5 יעדים של החברה – ולא יותר. חברות המתחילות לנהל רשימות ארוכות של יעדים, נחשבות כחוטאות למתודולוגיה). מכאן:

  • האם ל WIG יש את כל המשאבים (האנשים) כדי לעבוד ביעילות מרבית? אם לא – שקלו לצמצם / לדחות יעדים אחרים, בכדי לאפשר לו להתקדם מהר יותר. אנחנו רוצים לשים על כל WIG כמה שיותר משאבים, כל עוד זה יעיל – ולהתקדם בו כמה שיותר מהר.
  • אם יעדים מתעכבים – אל תקבלו את המציאות הזו! אל תלחיצו אנשים לעבוד שעות נוספות! העדיפו:
    • לצמצם את ה scope של היעד – כך שתשיגו את היעד המעודכן – מוקדם/מהר יותר.
    • לצמצם יעדים אחרים – אם ניתן להציב עליו עוד כוח עבודה.
      • פחות יעדים = דבר טוב. פחות תלויות והפרעות הדדיות (שלא תמיד אנו מודעים להן).
    • לפצל את היעד לשני יעדים: שלב א’ משמעותי, ואז שלב ב’ משמעותי.
      • בלי קשר לעמידה ביעדים: אם ניתן לעשות זאת – עשו זאת בהקדם. כל “loop” שסגרתם מוקדם יותר ייתן לכם פידבק עד כמה הוא באמת מצליח / משמעותי – ואתם רוצים ללמוד את הדברים האלו, בעיקר ב WIGs – כמה שיותר מוקדם!
      • כלל מומלץ הוא “כלל 90 היום” – לא יהיה WIG ארגוני שזמן העבודה שלו יותר משלושה חודשים. אם יש – פצלו אותו / הפחיתו scope. לא ניתן לתוצאות קריטיות לחברה להתעכב ולא נסכים שזמן גדול מדי אנו לא יודעים אם ההשפעה שצפויה מהן הושגה.
  • הרשו לעצמכם, ביתר קלות, לסרב ליוזמות של אנשים חרוצים, טובים, ואהובים. אנחנו רוצים לתגמל, לחבר (to engage), ולהוקיר את דעתם של האנשים שעובדים למען הארגון – אך חשוב להבהיר שקידום יוזמות “nice-to-have” ברמה הארגונית – היא לא דרך לעשות זאת. הרבה חזיתות יכולות להיפתח בכדי לרצות אנשים טובים. האנשים טובים – אך הנזק אותו הנזק.
  • הערה: אנשים שעובדים על יעד משמעותי וברור, שהם מבינים שהוא כזה – יהיו לרוב יותר פרודוקטיביים ומחויבים מאנשים שביקשו מהם “להשקיע מאמץ” – ולעבוד שעות נוספות / קשה יותר.
יהלום אדום = נקודת אימפקט / למידה.

איזו גישה מרגישה יותר נכונה?

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

מצד שני, גישת ה Parallelize אומרת שנשיג את היעדים שלנו מאוחר יותר. וכנ”ל לגבי למידה מכל יעד – יגיע מאוחר יותר. אם מרגיש שגישת ה Parallelize היא ניהול סיכונים נבון יותר (“לא לשים את כל הביצים בסל אחד”), דווקא כאשר מדובר ב WIGs – גישת ה Maximize Focus היא מסוכנת פחות: אם יש WIG שלא עובד – נגלה את זה מוקדם יותר, וזה יותר חשוב: ללמוד ולהתכוונן מחדש – איך בדרך אחרת, להשיג את היעד הכל-כך חשוב הזה.

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

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

עוד נקודות:

  • ליצור תרבות של דיון מתמיד ב WIGs שלנו: האם הם נכונים? מספיק משמעותיים? אנחנו משקיעים בהם את כל מה שאפשר?
    • תרבות כזו מייצרים ע”י דוגמה אישית של מנהלים, וע”פ פרגון אמיתי למי שיוצר דיון איכותי בנושא (חשוב לבדוק, גם אם מסקנת הדיון היא: “בעצם הכל בסדר”).
  • מה עושים עם פרויקטים שאינם WIG? איך לא נפגע המורל של מי שלא עובד על WIG – אך עובד על דברים חשובים אחרים? נסו להפוך כל מאמץ ל WIG, או לפחות ל WIG-like: צמצום ה scope להכרחי ביותר הניתן ופוקוס להצלחה. למשל: אם יש בעיה מסוימת – אל תקימו יוזמה לפתור אותה לגמרי: הקימו יוזמה להביא את המצב ל “good enough” – ואז להמשיך ליוזמה הבאה. יהיה קל יותר לחבר את האנשים על היוזמה שהם עושים משהו משמעותי, ולא מבזבזים רגע מיותר. כמו ב WIG.
  • יוזמה שראיתי פעם הייתה לצבוע פרויקטים בצבעים:
    • כחול = WIG. “חשוב בטירוף!”. לשם הולך כוח האש העיקרי. כמטאפורה: “כיבוש האי XYZ”.
    • צהוב = Sustainability – “תיקון דליפה בספינה” כדי שנוכל להגיע ליעד (“האי XYZ”). אפילו אם זה לא הפרויקט העיקרי – מובן שזה חשוב ונדרש בכדי להצליח ב WIG.
    • לבן = למידה / POC – פרויקטי גישוש שנחיצות כל אחד מהם אכן בספק – אך מהם יצמח ה WIG הבא “איסוף מודיעין” או “מחקר מדעי לקראת הדור הבא”, לצורך העניין.
    • הצבעים עוזרים להעביר את המקום האסטרטגי של כל פרויקט בבהירות – ולעזור לארגון לכוונן את עצמו נכון יותר לכל פרויקט. למשל: מובן יותר לנסות להימנע שאיש בפרויקט כחול ישקיע זמן בעזרה לפרויקט צהוב – מבלי שזה ייחשב חוסר-קולגיאליות. פרויקט לבן יכול להימנע / לדלג על נהלים – וכך להיות יעיל יותר.
  • celebrate scope reduction – כפי שמחיקת קוד הוא דבר שחוגגים (למרות שמישהו השקיע וכתב את הקוד הזה באהבה, פעם) – גם צמצום של Scope הוא דבר לחגוג ולשמוח איתו.
  • אחריות ברורה בהחלט – לכל WIG חשוב שיהיה Owner ברור. קפטן שחייב לספק את המשימה. ניסיון (לפזר אחריות) – לרוב נגמר באסון.
    • חשוב שיהיה גם Executive Owner מחויב, בעל יכולת לקבל החלטות משמעותיות. Executive Attention הוא משאב חשוב – שגם אותו צריך לספק ל WIG.
  • אם צוות משקיע ביותר מ 2 WIGs בו-זמנית, כנראה משהו לא בסדר. Context Switch הוא “מס” לא רק על תהליכים במערכות הפעלה.

סיכום

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

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

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

שיהיה בהצלחה!

קישורים רלוונטיים: