בפוסט הזה אני רוצה לדון בעניין של מובילות הנדסית, מה שבאנגלית ייקרא בוודאי 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 נוסף… 😬

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

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

• סמכותי (במקור: Directing) – המנהל מספק הנחיות מפורשות, ומפקח על השגת המטרות. הוא אומר מה לעשות, איך לעשות, מתי לעשות, וכשדברים אינם לטעמו – הוא אומר זאת במקום.
• מעורב (מלשון “מעורבות”, במקור: Coaching) – המנהל מנחה מה לעשות ומפקח מקרוב על העשייה, תוך כדי שהוא מסביר את הרציונל וההחלטות, מפגין דוגמה אישית, יורד לפרטים, ועוזר היכן שצריך.
• תומך (במקור: Supporting) – המנהל קשוב לעובדים, מספק תמיכה ועידוד, המנהל מפגין התחשבות, אכפתיות לעובדים, ומפרגן להצלחות.
• סומך (במקור: Delegating) – המנהל מאציל את הסמכויות לעובדים: מספק להם עצמאות, אך גם את מלוא האחריות. המנהל עשוי להיות אדיש או מנותק מהפרטים.

ובכן, הנה תוצאות ההדגמה:

• הסגנון הסמכותי הוא ג, ד, א – בהתאמה.
• הסגנון המעורב הוא ב, ב, ד – בהתאמה.
• הסגנון התומך הוא א, ג, ג – בהתאמה.
• הסגנון הסומך הוא ד, א, ב – בהתאמה.

איזה סגנון ניהולי הוא המוצלח ביותר?

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

השאלה שעולה מיד לראש היא: “האם הסגנון שלי מוצלח, או לא?”
״האם סגנון הניהול הדומיננטי אצלי – הוא הסגנון הטוב ביותר?״

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

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

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

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

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

ע”פ “מודל הצרכים” (לא לבלבל עם פרמידת הצרכים של מאסלו) על המנהל:

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

“Nothing is so unequal – as the equal treatment of unequals”

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

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

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

צרכי העובדים

את מודל הצרכים ניתן לתאר באופן הפשטני הבא:

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

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

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

ע”פ המודל, מחלקים את העובדים ל-4 רמות של התפתחות בסיטואציה הנתונה (פרויקט, צוות, משימה, וכו’):

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

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

בהינתן התאמה של עובד לקטגוריה D1 – D4, סגנון הניהול המומלץ הוא:

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

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

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

ההשפעות השונות של סגנונות הניהול השונים

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

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

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

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

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

סיכום

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

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

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

מה שנדרש ממני הוא גישה מעורבת במשימות 2,1 ו 3, וגישה סומכת במשימות 5,4, ו 6.
לפעמים קל לשכוח את זה.

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