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

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

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

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

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

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

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

חחח.. 😄😄

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• כשהאדם מעביר ידע, הוא לא מעביר אותו בדיוק כפי שקיבל אותו – אלא מוסיף לו ערך ע״י תימצות, המחשה, דוגמאות משופרות, וכו׳.
  • היכולת של 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 נוסף… 😬

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

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