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

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

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

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

כמה מחשבות על Hypergrowth

״צמיחה-חריגה״ (HyperGrowth) הוא מצב בו חברה צומחת בקצב לא שגרתי. הצמיחה יכולה להיות במכירות, שווי, מספר עובדים, מספר לקוחות וכו׳.

על איזה מדד אנחנו מדברים?

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

מתי צמיחה נחשבת ל״חריגה״?

אין הגדרה חד-משמעית, אך מקובל להתייחס לצמיחה של 40-50% בשנה ומעלה, לאחר שהחברה התבססה – כצמיחה-חריגה.

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

(בואו נתעלם לרגע מ Bootstraps – שקיימים, וחברות שמגייסות הון – עוד לפני שהוכיחו Product Market-fit – שגם אלו קיימות).

האם צמיחה של 40% בשנה היא צמיחה-חריגה להייטק הישראלי? כלומר ארגון של 40 עובדים המגייס במהלך השנה עוד 16 עובדים?

זה אכן נשמע לא כל-כך חריג בשוק של היום.

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

אם בשנת 2010 היו כ 20 חדי-קרן בעולם (חברות פרטיות בשווי של מעל מיליארד דולר), ב 2015 כבר היו כ 100 חדי-קרן, ובעת כתיבת הפוסט יש כ 500 (ע״פ CBInsights). יותר כסף זורם לחברות סטארט-אפ => צמיחה מהירה יותר.

המונח ״חד-קרן״ נבחר בכדי לתאר ייצור נדיר וייחודי – והיום כבר מתחילים לדבר על Decacorn (חברה פרטית בשווי 10 מיליארד או יותר) ואפילו Hectocorn (אשאיר לכם לבדוק…) – על מנת לבדל את הייחודי ויוצא-דופן.

זווית נוספת:

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

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

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

לקבל פי 2 Traffic בשנה – זה לרוב לא אתגר כל-כך גדול.

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

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

חשבו על עיירה ההופכת למטרופולין (״גוש דן״) תוך 6-7 שנים: יש כאן אתגר ארגוני-ניהולי-חברתי-טכנולוגי ממשי ומשמעותי!

מה ״הבעיה״ בצמיחה-חריגה?

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

אז מה הבעיה בצמיחה-חריגה? למה לא רק לחגוג אותה?

בכל פעם שאני שומע על צמיחה-חריגה אני נזכר במשפט ״Success Killed The Punk״ (נדמה לי שהוא מהסרט The Filth and the Fury): הפאנק, הזרם החתרני כל-כך הצליח – שהוא הפך למיינסטרים, וכבר לא היה מקום לחתרנים אמיתיים.

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

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

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

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

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

  • רוב מהעובדים בחברה הם עובדים חדשים, עד הודעה חדשה!
    • בהנחה שעובד הוא ״חדש״ בשנה-שנה וחצי הראשונה שלו בחברה, עד שהוא מכיר היטב את הארגון והמערכת – אנו הולכים לחוות תקופה בה רוב העובדים הם חדשים, וזה לא עתיד להשתנות עד קצת אחרי שקצב הצמיחה יתמתן.
    • עובדים חדשים = פחות היכרות עם המערכת, הארגון, וההיסטוריה.
      • עובד חדש מכיר פחות, ולכן הוא צריך יותר עזרה ויותר זמן בכדי להגיע לתוצאות דומות.
      • לעובד חדש יש אינטואיציה פחות מפותחת מה מסוכן ו/או מה הגיוני, הוא מועד יותר לטעויות ופספוסים.
    • כאשר הארגון מלא בעובדים חדשים, במי יתייעץ העובד שהגיע לפני שבוע? בעובד שהגיע לפני חודשיים, או בעובד שכבר נמצא ארבע חודשים?
      • בסופו של דברים, עובדים חדשים יתייעצו עם עובדים חדשים אחרים – שהרבה פעמים לא יספקו תשובות מספיק טובות.
      • הידע הממוצע במערכת / ביזנס / ארגון – ימשיך ויפחת ככל שהצמיחה החריגה ממשיכה. פחות ידע = הנדסה פחות טובה.
  • טשטוש התרבות הארגונית (ו/או Engineering Culture)
    • תרבות ארגונית היא נרכשת – ויכולה להתקיים בלי מייסדיה (כפי שניסוי חמשת הקופים מדגים).
    • כאשר קצב ההצטרפות גדל – ההקניה נפגעת:
      • כאשר עובד חדש מצטרף – הוא מגיע עם ״שק של הרגלים״. למשל, אם הוא ״לא מאמין בבדיקות יחידה״ – אך התרבות היא להקפיד על בדיקות יחידה – הוא יתיישר מהר מאוד. אם כולם עושים זאת – גם הוא יעשה.
      • כאשר הרבה עובדים חדשים מצטרפים בזמן קצר – היישור הוא כבר פחות אוטומטי. אם קבוצה של עובדים הגיעה עם הרגל שנוגד את התרבות – גדלים הסיכויים שהם יצליחו לערער את העיקרון התרבותי.
      • עכשיו: שינוי בתרבות הוא לא בהכרח רע. ייתכן והתרבות כוללת כמה הרגלים מזיקים. למשל: ארגון שלא עבד עם בדיקות יחידה – ועובדים חדשים שמגיעים עם ״שק הרגלים״ ומשנים את התרבות – הם כנראה דבר טוב. אבל:
        • הנטייה של עובד חדש היא להיצמד ל״שק ההרגלים״ שלו כפי שהוא, ללא הבנת הצרכים הייחודים של הארגון שאליו הוא יצטרף. הסיכוי שההתנגדויות יהיו במקומות הנכונים – קטנים ככל שהארגון עובד היטב.
        • יש יתרון גדול לתרבות ארגונית משותפת/אחידה. האחידות בטכנולוגיות / שיטות הרבה פעמים עדיפה על חצי-מעבר לטכנולוגיה / שיטה טובה יותר.
  • האצת וריבוי תהליכי-שינוי
    • אנחנו יודעים שמה ש״עובד״ עבור 10 עובדים עלול כבר לא לעבוד עבור 20-30 עובדים, ואז לא להתאים כבר ל 50-60 עובדים וכן הלאה: בעקבות צמיחה מספר העובדים – יש לשנות תהליכים והרגלים.
    • כאשר הארגון גדל מהר – גם השינויים צריכים להעשות מהר יותר.
    • שינוי כולל מאמץ וסיכון, אך צמיחה-חריגה לא מספקת הנחות*: את השינויים יש לעשות, וכל טעות – תהיה כואבת ומזיקה באותה המידה לו לא הייתה צמיחה-חריגה.
    • * לעיתים ארגונים בצמיחה-חריגה מדלגים על שלבים: במקום להיערך למצב של 100 עובדים – מתכוננים כבר מיד למצב של 300 עובדים.
      • ה Tradeoff: חוסכים איטרציה של שינוי – אך מתפקדים זמן מה במודל ״גדול/כבד״ יותר מהנדרש. הרבה פעמים ה Tradeoff הזה משתלם.
    • אפשר לחשוב על צמיחה-חריגה כ״מגבר״ לשינויים ארגוניים:
      • כאשר/היכן שהתרבות הארגונית / קבלת ההחלטות שלכם היא טובה – היא תשרת אתכם היטב בצמיחה-חריגה.
      • כאשר/היכן שהתרבות הארגונית / קבלת ההחלטות שלכם לקויה – היא תזיק לכם שוב ושוב בצמיחה-חריגה.
      • יצא לי באופן אישי, לחוות כניסה לצמיחה-חריגה בארגון פיתוח אחד עם יסודות הנדסיים רעועים (אין בדיקות אוטומטיות, אין לוגים, אין תרבות של שיפור קוד תמידי) ואחד עם יסודות יציבים (בדיקות אוטומטיות הן דבר מובן מאליו, יש כלי ניטור טובים, יש תרבות של שיפור קוד) – וההבדלים בתוצאות בין שני המצבים היה דרמטי. אני מתאפק שלא לומר: ״הבדלים של שמייים וארץ״.
  • מעט סובלנות לקושי ב Scalability ארגוני
    • כאשר שוררים תנאים עסקיים (מודל עסקי/שוק/הזדמנויות) לצמחה מהירה – המשקיעים => ה Board => המנכ״ל => המנהלים הבכירים => המנהלים הזוטרים ילחצו לאפשר אותה. זו הדרך להצליח – וזה תפקידם.
    • הסובלנות לדחיית הצמיחה תהיה נמוכה, ומה שצריך לזוז בכדי לאפשר את המשך הצמיחה המהירה – יזוז:
      • מנהלים יאלצו להאציל ולפזר סמכויות – גם כאשר הקצב מהיר מדי לטעמם.
      • אם מחלקת הפיתוח מתקשה לגייס עובדים בקצב של מחלקת המכירות – היא תאלץ לגייס מהר יותר, ולעשות את הפשרות הנחוצות.
      • תהליכים ידניים – יאלצו לעבור אוטומציה, גם אם כרוכות בכך פשרות באיכות.
    • כל ״ניצחון״ (איכותי, צודק, נכון) שיגביל את הצמיחה – יצור לחץ הולך וגובר לאפשר חזרה את הצמיחה בחזרה. לא סביר שקבוצה קטנה של אנשים בארגון תחסום את הארגון מצמיחה-חריגה: הלחץ לצמיחה מהירה בסוף ינצח כל שיקול/טיעון. אם הצלחתם לעכב את הצמיחה – דעו שזה רק עניין של זמן, עד שתאלצו לסור מהדרך (לא משנה כמה הוגנת וטובה התרבות הארגונית).
    • ארגון תוכנה – הוא מורכב יותר לצמיחה מארגון מכירות (אני מאמין). מערכת תוכנה – הולכת ומסתבכת עם הזמן – ולכן צריכה יותר עבודה על כל שינוי ככל שהזמן עובר. כל זה לא משנה – כל עוד ארגון התוכנה הוא צוואר בקבוק לצמיחת החברה (וכנראה שפעמים רבות זה יהיה המצב) -יהיה עליו לצמוח. אם הגדילה לא תעשה אורגנית – היא יכולה להיעשות ברכישה של ארגון תוכנה נוסף (ולא בהכרח הכי טובה). ארגון התוכנה הוא לא זה שיעצור את הצמיחה-החריגה של החברה.

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

מקור: https://lethain.com/productivity-in-the-age-of-hypergrowth

מה הדרכים להתמודד עם צמיחה-חריגה?

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

אני זוכר שעברתי לעבוד ב SAP בשנת 2005, אחת מנקודות המכירה של הארגון הייתה ״פה תעבוד ב Scale מטורף. יש לנו לקוחות עם עד 120 אלף משתמשים (!!!) למערכות שלנו. לא תמצא כזה Scale בשום מקום אחר״.

120 אלף משתמשים? היום לחצי מהסטארט-אפים הקיקיוניים – יש מספר דומה של מתשמשים (במיוחד בתחום הפרסום). ב Next-Insurance אנחנו מגדירים את עצמנו כ״חברה ש Scale הוא לא עניין שלה״ – ולא מזמן עברנו את 120 אלף הלקוחות.

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

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

רשימה לא מלאה:

מיקרו-שירותים

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

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

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

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

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

Companies

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

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

וריאציה שראיתי פעם היא Companies בעלי בסיס קוד קדמון משותף. בחברת Nice שבה עבדתי מזמן, לקחו מוצר שעליו עבדו כ 50-60 מהנדסים (מערכת להקלטה של תכנים) ופיצלו אותה ל2 חטיבות עצמאיות: הקלטת וידאו והקלטת אודיו. עשו פשוט Fork לקוד, ושכפלו את המחלה ל-2 מחלקות שעבדו על בסיס אותו קוד שהיה עד כה.

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

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

Lean Startup

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

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

שמירה על מיקוד / WIP

עוד עיקרון מדובר הוא שמירה על מיקוד-חד, והגבלת ה Work In Process (בקיצר: WIP).

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

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

טעות נפוצה, היא להתרשם ממספר האנשים (Head Count) ולהשתמש בהם להתחיל יוזמות נוספות / חדשות. תמיד יש רעיונות לכל מיני דברים ״חיוביים״.

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

התוצאה של ההתפזרות הזו היא: ״סתם״. יוזמות רבות, הגוזלות תשומת-לב מיוזמות חשובות יותר, מייצרות תחושה משמחת של ״עשייה״ אך ללא משמעות אמיתית, ללא Impact.

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

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

עדיף להציב עובדים חדשים ביוזמות חשובות, גם כאשר אינם יעילים – מאשר לשלוח אותם לנסות יוזמות שוליות / יוזמות חשובית שהסיכוי שלהם לעשות Impact אמיתי הוא שולי.

זו גם דרך – להגדיל את מאגר האנשים שיכולים להוביל בהבנה מאמצים שיגרמו ל Impact – שזה הנתיב הקריטי.

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

וריאציה נוספת: ״The key to scaling – is to say no״.

ערכים ומדיניות

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

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

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

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

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

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

  • Dare to Simplify (ערך של Next-Insurance) – הוא ערך שאני מאוד אוהב. המילה החזקה היא ״Dare״: ״קח סיכון על מנת לפשט, זה מספיק חשוב!״. עצם הצבת הערך הזה ברמת החברה – עזר למקד דיונים ולשכנע את המשתתפים לחתור לפשוטת, גם כאשר זה לא היה קל.
  • Don't just identify a problem – fix it (מתוך מאמר על AirBnb) – במיוחד בארגון בצמיחה-חריגה – דברים יתקלקלו כל הזמן. חשוב לנצל את מאגר הכוחות/מוחות/תשומת-הלב כדי לשפר ולתקן כל הזמן תקלות. לתקן בעיות שלא אני גרמתי (כמובן) ולתקן בעיות שמפריעות לאחרים יותר מאשר לי (גם זה).
  • Everything changes all the time. Get over it – זו יותר מדיניות מאשר ערך. אם לאנשים משתבשות שוב ושוב תוכניות, והם מתרכזים בדיוק על ״אסור להזיז לנו דברים – זה הורס את התוכניות״, התמודדות נגד היא להגדיר את המדיניות הזו. לחדד לאנשים שיהיה עליהם להמשיך ולהתמודד עם שינוי מהיר-תמידי. זה מה שמצופה מהעובדים, למרות שזה לא קל.
    • הערה אישית: אני מקווה שזה בא עם הכרה כנה בקשיים. מנהלת HR שמצהירה ״אלו כאבי גדילה – זה טבעי״, מניסיוני, לא מספיק עזר. אני רוצה להאמין שמסר כמו – ״שמע, זה מזופת. זה יכול פעמים לשגע אותך – אבל זו המציאות שלנו. נסה לקחת את זה כאתגר – ולא להתייאש, כולנו עוברים את זה״ – היה עובד טוב יותר.
On-Boarding and Education
בחברת Gett (לשעבר GetTaxi) חוויתי לראשונה צמיחה-חריגה אמיתית.
בסאפ פעם הוספו לנו לפרויקט מהיום-למחר כמה עשרות עובדים, אבל הכרנו חלק מהם, והם הכירו היטב את הארגון. היו לנו כבר הרגלים משותפים. זה, יחסית, היה ״בקטנה״.
קליטה לארגון ב Gett היה תהליך קשה:
עובדים חדשים היו צריכים להכיר ביזנס חדש (מוניות, On-Demand Transportation), טכנולוגיה חדש (רובי, Go), שוק חדש (Consumer), רבים היו חדשים ל SaaS, טיפול בפרוקדשיין ו AWS ואפילו רבים היו חדשים למק. כל זה עוד לפני שהגענו למערכת חדשה ומורכבת, שעברה הרבה שינויים מהירים וגם היה בה הרבה Legacy להיזהר ממנו, ארגון שפועל ב – 4 מדינות, כל אחת עם כללים וצרכים משלה. ארגון וצוותים, בעלי תפקידים שונים ומשונים.
פלא שזו לא הסתגלות קלה?
מה עשינו לעזור לעובדים?
בהתחלה – את הדברים הרגילים: הצמדנו לכל עובד חדש Buddy (עובד אחר) שילווה אותו בכמה שבועות הראשונים (freestyle), ועשינו כמה סשנים להכרת המערכת.
הייתה תקופה שהזמנו קורס חיצוני של שבוע לשפת רובי, שלמרות ניסיונות שיפור, לא השיג שביעות רצון גבוהה – ולא הרגשנו שלאחריו אנשים יודעים ממש את השפה.
זה לא היה מספיק טוב. ההרגשה הכללית הייתה שעובדים שנמצאים כמה חודשים בחברה עדיין חסרים המון – ואינם עצמאים כמעט בשום משימה משמעותית. הם הרבו לתקן באגים קטנים או לכתוב שירותים צדדים – שלא נוגעים בליבת המערכת.
בהמשך לקחנו את היוזמה, והשקענו פנימית בהכנת בתכנים ממוקדים יותר לגבי רובי, ו Go אך גם AWS ו SQL. יותר מזה – סשנים יותר מבוקרים ומוקפדים על הכרת המערכת.
זה היה תהליך: בהתחלה זה צלע – אך אם הזמן היה יותר ויותר טוב.
עצם היותו תהליך פנימי – יכולנו להתאים תכנים בדיוק לארגון. למשל: לדבר על הספריות המשותפות הפנימיות של הקוד. על הבעיות הנפוצות שצצו אצלנו.
בסופו של דבר, הצלחנו לעשות את המעבר, ולחבר עובדים חדשים לטכנולוגיה והסביבה שלנו בצורה יעילה – כך שלאחר כמה חודשים, גם העובדים החדשים, וגם המנהלים בארגון – הרגישו הרבה יותר טוב לגבי היכולת של עובדים חדשים להתמצא במערכת. תהליך ה On-Boarding היה אחד הצעדים היותר פוריים שעשינו להשתלט על הבלאגן בקליטת כמות משמעותית של עובדים.
היום ב Next-Insurance יש לנו תהליך On-Boarding של הימים הראשונים, של השבועות הראשונים, ושל החודשים הראשונים. משם והלאה יש מבחר של סשנים (מוקלטים) במגוון נושאים רלוונטים – זמינים לרגע שבו העובד יזדקק להם. יש גם StackOverflow פנימי ווויקי – מהם אפשר להמשיך ללמוד.
תהליך ה On-Boarding מתחבר באופן טבעי לתיעוד וחומר לימודי להמשך תקופת העבודה. לפעמים עובד לא נתקל בנושא במערכת גם במשך שנתיים-שלוש. טוב שכאשר הוא נתקל בנושא – יש לו מקור יעיל להשלים לגביו ידע.
עוד גישה שיש לגבי קליטת עובדים במצב של צמיחה-חריגה היא לעשות ״תורנות״ בין הצוותים בגיוס העובדים. במקום לגייס לכל הצוותים כל הזמן, יש כל פרק זמן (נניח: רבעון) צוותים שמגייסים – וצוותים ש״מתאוששים״ מגיוס.
ההנחה היא שבניגוד למרתון (או התמודדות שוודית עם קורונה) בו שומרים על קצב קבוע כל הזמן, בקליטת עובדים יש הרבה הפרעה לצוות בביצוע ראיונות וקליטת עובדים חדשים.
לכן עדיף שתקופה הצוות יעסוק בגיוס, ותקופה הצוות יעסוק בקליטה ו״גידול״ העובדים החדשים – ולא לנסות למקד צוות בשני המאמצים בו-זמנית.
צמיחה-חריגה, בה רוב העובדים הם עובדים חדשים.

גיוס רק אנשים מצוינים

אחת הגישות שהתנסתי בהן היא התמודדות עם צמיחה-חריגה ע״י גיוס של אנשים מצוינים בלבד (על בסיס הספר Scaling Up).
המחשבה הייתה שעובדים ״סבירים״ – רק יעכבו אותנו, וידרשו המון תשומת לב. זו בעיה קשה, כאשר צומחים מאוד מהר (להזכיר: +100% בשנה) ורוב העובדים הם חדשים. במקום זאת, ניסינו להתמקד רק בעובדים ״מעולים״ שהם אלו שיהיו עצמאים הרבה יותר, ידרשו פחות תמיכה, וישפרו כל הזמן תהליכים – במקום רק לצרוך אותם (או להתלונן שהם חסרים).
לצורך העניין נעזרנו בחברת ייעוץ מלונדון (שהתבססה על הספר Who. חלק מאיתנו גם טסו לשם להדרכה) – ולקחנו את העניין בסופר-רצינות. מהמנכ״ל – עד אחרון המראיינים.
ההחלטה הייתה לגייס פחות, לשלם יותר – אבל להביא רק אנשים מצוינים ״A players״. היו חודשים רבים שהקדשנו לנושא הגיוס יותר זמן מכל נושא אחר.
איך זיהינו אנשים מצוינים? אנשים שיצאנו מהראיון איתם ללא ספקות. שהרשימו את כל המראיינים מאוד. לא חששנו לפסול אנשים שיש לגביהם ספקות, והרבה כאלה.
זוכרים את העיקרון של אי-עצירת הצמיחה? היוזמה לגיוס אנשים מצוינים בלבד הגיעה מהמנכ״ל – וכדי לעמוד ביעדי הגיוס היינו צריכים לראיין בלי סוף. 3-5 ראיונות בשבוע היה קצב שגרתי למראיין, ואני זוכר מקרה של מנהל הפיתוח שסיפר שקיים 15 ראיונות בשבוע בודד.
את התוצאה ראינו רק לאחר חודשים – היא לא הייתה טובה. למרות מאמץ אדיר, פשוט אדיר – זה לא עבד כפי שציפינו.
בהבנה לאחור, הייתה תפיסה בארגון (שקדמה לכל התהליך) שחשוב לנו מאוד לגייס אנשים עם ״אש בעיניים״ עם מוטיבציית-שיא. בכדי להשיג מוטיבציית שיא גייסנו אנשים שהתפקיד שהוצע להם – היה עבורם קפיצת מדרגה משמעותית (כלל האצבע היה: ״30% יותר ממה שעשו בתפקיד הקודם״). למשל: מנהל בחברת פרויקטים, שבא לנהל קבוצת פיתוח Consumer/SasS בחברת סאטראט-אפ מבוקשת. בחור מאוד מוכשר – עם טונה של מוטיבציה להצליח. החיסרון שהבנו בדיעבד: לרבים מאלו שגייסנו לא היה ניסיון קודם במה שהם עומדים להתמודד איתו. הם עברו טבילת-אש ראשונה אצלנו, בתנאים לא אופטימליים, בלשון המעטה.
בסיבוב השני (לאחר חודשים), התמקדנו באנשים עם ניסיון ברור במה שהם עומדים לעשות. אנשים שכבר עשו את זה, ועשו את זה טוב. למשל: מפתחים – העדפנו שכבר עבדו בסביבת SaaS ופרודקשיין. ה״אש בעיניים״ כבר הייתה פחות שכיחה.
לאחר חודשים הבנו את התוצאות – והן היו טובות יותר, אבל לא עמדו בציפייה. יחסית למאמץ האדיר שהשקענו – עדיין קיבלנו עובדים שלרבים מהם לקח זמן להסתגל – והם היו זקוקים לכמות נכבדת של תמיכה לאורך זמן.
תאוריה (מרשימה), וניסיון – לחוד. זה הניסיון שלי.
הייתי ממליץ להתמקד באנשים שכבר התמודדו עם סוג האתגרים שעומדים בפניהם, ואולי קצת הלאה – ונמנע מלנסות ו״להצמיח אנשים מוכשרים ומלאי מוטיבציה״ לתפקיד. עדיין – הגיוס נראה לי כשלב הכרחי, אך לא מספיק על מנת להתמודד עם צמיחה-חריגה.

Guidelines and Standardization

הנה משהו מפחיד. רואים את המילים הללו למעלה? אלו מילים של Enterprise, של Coroporate.

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

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

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

אני רוצה להמליץ בחום על כמה עקרונות בניסוח Guidelines שכאלו, בכדי לא לקחת מה "Corporate״ גם את הצדדים השליליים שלו:

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

סיכום

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

אלו פרקטיקות ותהליכים המגמה הזו תפתח?

האם ימשיכו לצמוך בקצבים יותר ויותר מהירים?

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

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

תאוריה ארגונית: מתן משוב

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

הפעם אני רוצה לדבר קצת על תיאוריה ניהולית, וספציפית על מתן משוב (feedback).

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

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

למשל: רבים מאיתנו רגילים לשיחות הערכה שנתיות בהן אנו מדורגים למדד ביצועים בטווח בין 1-5 (כאשר רוב האנשים נופלים לערך 3 שאומר ״אתה בסדר״). ובכן, המודל המאוד-נפוץ (ולא אהוד?) הזה, שהיה קיים בכל חברה שעבדתי בה ב 17-18 שנות הקריירה שלי – כבר נחשב, ב cutting edge של התאוריה ניהולית, כשנוי-במחלוקת במקרה הטוב – או ממש מזיק במקרה הרע.

למה? – על זה ארצה לספר בפוסט.

התאוריה המקובלת למתן משוב

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

מדוע לתת משוב?

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

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

אלו הם רעיונות ניהוליים בסיסיים ומקובלים.

מהו משוב ״טוב״?

קשה לי להאמין שיש מנהלים שעברו הכשרה בשנים האחרונות ולא מכירים את מודל ה SMART למתן משוב (ו/או יעדים):

  • Specific – דרשו תוצאה ברורה. תנו משוב על אירועים ספציפיים, עם דוגמאות.
  • Measurable – התמקדו במדדים אובייקטיבים ככל-הניתן. לא ״לא הרגשתי שעשית עבודה טובה״ אלא יותר ״איחרת כך וכך פעמים בלוחות הזמנים ברבעון האחרון״.
  • Achievable – העובד צריך להסכים ליעד, ולהאמין שהוא מסוגל להשיג אותו (גם אם לא בקלות). לגבי משוב – עליו להאמין שמה שמתבקש ממנו הוא אפשרי.
  • Relevant – התמקדו במה שמשמעותי להצלחת העובד בתפקיד (אפשר לנסות ״לדרוש יותר״ ו/או ״להוציא אותו מאזור הנוחות״ שלו).
  • Time-based – קבעו לוחות זמנים לשיפור הרצוי. ברור ששינוי לא קורה ברגע – אבל יש גם סכנה שללא מסגרת זמנים ברורה – השינוי הרצוי ״יתמסמס״.
אפשר להקביל את ה SMART לעקרונות של Gamification: אנו ״משחקים״ במשחק השגי, אך נוכל להשיג את המעורבות של העובד רק אם המשחק יהיה צפוי (specific, measurable), הוגן (relevant achievable, specific), שלא משנים את החוקים באמצע, ועם מסגרת כלשהי (time, rewards).
עוד רעיונות מקובלים:
  • אדם (העובד) לא יכול לספוג כמות גבוהה של משוב שלילי ברצף – וחשוב מאוד לאזן בין משוב חיובי ושלילי. מדדים מוכרים ומקובלים הם:
    • אתם יכולים לתת משוב שלילי אחד על כל 5-6 משובים חיוביים שנתתם.
    • מנהל נדרש לתת לכל עובד משוב חיובי לפחות אחת לשבוע. ואם הוא לא מסוגל – יש לשקול את הדרך מחדש: שינוי משמעותי או פרידה.
  • לבני-אדם יש Blind Spots (כמו כתם על החולצה שהם לא שמים אליו לב). אם לא נעיר את דעתם לעניין – הם פשוט לא ידעו.
  • נותן המשוב צריך להיות מקובל (Creditable) בעיני מקבל המשוב. ללא אמון – המשוב לא יתקבל ברצינות.
    • יש יתרון למתן משוב דומה מכמה מקורות שונים – מה שמקשה על מקבל המשוב לפטור את המשוב כ״טעות אקראית בהבנה״.
    • לעתים מנסים ליצר סימטריה ולעודד משוב מהעובדים, במידה רבה בכדי לבנות אמון, ולא רק בכדי להשתפר בעצמם.
  • שימוש בחיוביות: מתן דגש על שימוש בשפה חיובית ולהימנע ממילות-שלילה / מילים המעוררות התנגדות.
    • יש זרם כללי של ״ניהול חיובי״, שנראה לי שהוא דיי פופולרי בארה״ב.
    • גרסה מתונה יותר: לא להיות שיפוטיים. לציין את האירוע וההשלכות המזיקות, אבל לא לשפוט ״זה חמור״, ״נכשלת״, וכו׳. בכל מקרה ותמיד: להתמקד בהתנהגות ולא באדם.
  • משוב, אסור שיהיה אירוע תקופתי. שיחת הערכה שנתית – היא רחוקה מדי. משוב צריך להיות על בסיס יום-יומי, קרוב במידת האפשר להתנהגות אליה אנו רוצים להתייחס. הרעיון הזה נקרא כך לעתים ״משוב מתמשך״ (קצת באזז).
    • שיחת משוב תקופתית אמורה רק לסכם משובים ממהלך התקופה ולוודא ששום דבר לא התפספס.
באופן אישי: הרעיונות הללו מקובלים והגיוניים בעיני.
מתן משוב שלילי הוא אירוע טעון רגשית, שבקלות יכול להביא לתחושות לא נעימות ולא רצויות – ולכן שני הצדדים (נותן, ומקבל) נוטים לנסות ולהימנע ממנו. יש מנהלים שלעולם לא יתנו משובים מסוימים – מהחשש כיצד הם יתקבלו וכיצד ישפיעו על העובד / מערכת היחסים איתו.
ישנו רעיון בשם Feedback Sandwich, בו עוטפים את המסר השלילי בדברי הערכה לפני ואחרי, שפעם נחשב כמו פתרון אפשרי לבעיה – אבל היום נחשב בעיקר כדרך טובה להעביר מסר עמום שפשוט לא עובר ו/או משדר חוסר-כנות.

מגמות חדשות במתן משוב

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

Feedback or Feedforward?

ארצה להתחיל במונח בשם Feed Forward: אולי כמנהלים, במקום להתמקד בהיסטוריה, במה העובד עשה, נתמקד דווקא בעתיד – מה העובד יעשה הלאה?
מתן משוב לפעמים מכניס את המנהל לסגנון של ״דיווח חשבונאי״. למנהל יש בראש רשימה של מקרים טובים ולא טובים שהעובד שלו היה מעורב בהם – והוא עומד לערוך איתו ״דוח רווח והפסד תקופתי״ בו חשוב לתת תמונה מדויקת ומלאה של ה״מאזן הפיננסי״ של העובד.
הסגנון הזה לא נעים לא למנהל ולא לעובד – אבל לעתים הוא מרגיש כמו ״עבודה מסודרת ושיטתית״ (דבר חיובי, בעיקרון) – מה שעשוי לעיתים לחזק את התחושה בקרב המנהל שמדובר בדבר ״נכון״.
האם סגנון ה״משוב החשבונאי״ באמת אפקטיבי? האם המטרה של ״חיזוק התנהגויות חיוביות וצמצום שליליות״ באמת מושגת ביעילות?
עם הזמן מצטברים עוד ועוד מחקרים שמעידים שלא. שהעומס הרגשי של מתן משוב מרוכז (במיוחד אם תקופתי) הוא רב – והעובד ינסה ״להיפטר״ ממנו בהקדם. אולי בעזרת שינוי קוסמטי שימנע דיון נוסף בנושא בתקופה הבאה, אולי ע״י הדחקה כזו או אחרת.
הרעיון של FeedForward הוא להיות ״חבר״ לעובד – ולא ״מבקר״. לא להתמקד בעבר (הלא נעים), אלא בעתיד החיובי. מרכז השיחה הוא איך אנחנו עושים טוב בהמשך – מבלי לשים דגש על הבעיות שהביאו אותנו למסקנה שיש מה לשפר.
למשל:
״נראה לי שתוכל להצליח יותר בתפקיד שלך אם תיגש לאנשים ברגישות גבוהה יותר. זה עשוי לגרום לך לקבל שיתוף פעולה עמוק יותר – מה שיעזור לך להצליח״. (במקום: ״גם משה וגם יפעת העלו את זה שהם לא נהנים לעבוד איתך. זה עלה כבר מספר פעמים.״)
או:
״אני מתרשם שאתה עסוק כולך ב Delivery – אבל בסוף אתה עובד קשה יותר בגלל תיקון באגים. נראה לי שגם לך יהיה טוב יותר אם תשקיע את הזמן הנדרש בכתיבת כל הבדיקות הנדרשות, ובדיקה שנייה של הקוד. יעריכו אותך יותר – וגם זה יהיה שוחק פחות עבורך״. (במקום: ״אתה חייב לייצר פחות באגים. התקלה האחרונה שיצרת בפרודקשיין הייתה חמורה, וזו לא הפעם הראשונה שזה קורה…״).
זה רעיון יפה, ורב עצמה בעיני – וגם אני מתרשם שגם די יעיל (מהמעט שיצא לי לחוות אותו). מי שבקי בתאוריה של השפעה / שינוי (aka Change Management) יודע שיצירת ״חוויה חזקה״ או ״מטלטלת״ היא דרך לא יעילה בעליל לגרום לשינוי. דווקא פילוס הדרך להתנהגות ה״רצויה״ והפיכתה לקלה יותר – היא גישה יעילה הרבה יותר.
כמובן FeedForward מתאים כאשר העובד בסה״כ מביא ערך ומוערך. קשה לי לומר כיצד להשתמש בו כאשר אתם נותנים לעובד הזדמנות אחרונה לפני פרידה.

המשוב שלא מתיישב

את החלק הזה אני כותב על בסיס מאמר בשם The Feedback Fallacy שפורסם ב Harvard Business Review לפני כשנה. אחד הכותבים שלו הוא מרקוס בקינגהם, שאולי מוכר לכם בעקבות הרעיון שהוא מקדם לאורך שנים: ״התמקדו בשיפור החוזקות של העובדים, ולא בהתכתשות בחולשותיהם״.

כפי שציינתי, מגמה שהולכת ומתחזקת היא מתן ״משוב מתמשך״, בתכיפות, ולא כפעולה תקופתית.

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

האם משוב תכוף, גם כאשר מתקבל באופן חיובי – באמת משנה התנהגות?

ע״פ המאמר, מחקרים[א] מראים שדווקא לא כל-כך.

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

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

האם המידע הזה הוא באמת נכון? – גם כאן מוטלים ספקות גדולים:

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

לסיכום, אם אני כמנהל:

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

מצוינות

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

המודל המועדף על כן הוא משוב בנוסח: ״התוצאה טובה מאוד בעיני בגלל סיבה 1 סיבה 2 סיבה 3; מה בעצם גרם להצלחה הזו? אתה יודע להסביר?״

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

סיכום

העברת משוב לעובדים (או מעובד למנהל – גם הכיוון הזה חשוב!) הוא נושא חשוב בבסיס העבודה בארגון. זה לא נושא קל, לא נושא פשוט, וכנראה שלרובנו יש ״צלקות״ מהתהליך הזה – משני הצדדים. לפחות לי יש.
האם מצאנו את הנוסחה להצלחה? – אין לי מושג. הרעיונות הפופולארים ״החדשים״ (לשנת 2020) נשמעים נבונים ועניינים. רק ניסיון והזמן – יוכלו לומר עד כמה הם טובים. מה מהם יש לשכוח – ומה יש להמשיך ולפתח.
האם אני אנסה לאמץ את הרעיונות הללו – כן.
האם אני שלם שהגישה הזו לא יכולה להוביל לטיפוח בינוניות? – לא לגמרי. מלווה אותי עדיין מידה מסוימת של חשש.
אתם יותר ממוזמנים להגיב ולשתף מניסיונכם בנושא.
שיהיה בהצלחה!
——-
[א] ציון ״מחקרים״ הוא גם סוג של באזז. מחקרים יש לכל הכיוונים, בעיקר במדעי ההתנהגות. רק ריבוי מחקרים המחזקים זה את זה – הוא מקור מספיק משמעותי להסתמך עליו. המאמר לא ציין את המחקרים – מה שמשאיר את האמירות כהצהרה כללית בלבד / כלי לשכנוע הקורא.

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

על 4 סגנונות ניהול

הפוסט נכתב בשיתוף עם יהודה גרנות – CTO & CO-Founder at Fincheck.

 

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

יש לו מספר וריאציות.

בווריאציה הפשוטה ביותר (מקור: Rensselaer Polytechnic Institute. Retrieved 24 May 2012) מגדירים שני סגנונות בלבד:

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

 

איננו מסכימים איתו! אולי לאחר קריאת הפוסט – גם אתם לא.

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

 

האם אתם יכולים לחשוב על מנהלים שאתם מכירים / עבדתם איתם – ולהבין לאיזו אסכולה הם שייכים?

מקור: Cinetropolis
 

להכיר את סגנונות הניהול

הוריאציה הקצת-יותר-מורכבת (מקור: Leadership & the One Minute Manager) מדברת על 4 סגנונות ניהול:

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

 

במידה ואתם בעצמכם מנהלים – איזה סגנון מאפיין אתכם?

 

 

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

 

אם תתקלו בהן, אז הנה שמות נרדפים לסגנונות: הגישה המעורבת נקראת גם Consultative, הגישה התומכת נקראת גם Democratic, והגישה הסומכת נקראת גם לסה-פר (Laissez-faire, שמשמעו "תנו לעשות, תנו לעבור").

מודל סגנונות הניהול, וריאציית חמשת הסגנונות.
 

בחן את עצמך (למנהלים): סגנונות הניהול השונים

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

מקרה #1 – אתה רוצה לבצע שינוי ארגוני משמעותי. ביצועי הארגון / צוות טובים – אך השינוי נחוץ. מה תעשה?

א. אתן לצוות להשתתף ולהשפיע על דרך הכנסת השינוי.

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

 

מקרה #2 – הצוות מפגין לאחרונה ירידה בביצועים: איחור ביום משימות, והאיכות ״לא משהו״. מה תעשה?

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

.
מקרה #3 – אתה מתוודע לשני חברי צוות שלא מסתדרים ביניהם במידה מזיקה. מה תעשה?

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

 

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

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

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

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

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

למנהלים – העניין הזה תופס מקום חשוב ורגיש במיוחד: "אולי אני צריך לשנות סגנון מ-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.
לפעמים קל לשכוח את זה.

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

"האם הבחור הזה מתאים לנו?" (על מודל החשילות)

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

מקור (https://www.fastcompany.com/27454/dee-hock-management). Dee Hock הוא המייסד והמנכ"ל האגדי של חברת ויזה, והוגה דעות חשוב בתחום הניהול.

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

"ניסיון קל לרכוש וליישם בצורה נכונה – כאשר התכונות האחרות נתונות". ההיפך – לא בהכרח נכון.
או כמו שאומרים בעגה הצבאית: "קשור חמור לעמוד כמה שנים – והוא יהפוך לרב-סרן" [א].

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

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

האם שינוי הוא קשה?

חברת הייעוץ ghSmart, המתמחה בתהליכי גיוס, פיתחה מודל בשם מודל החשילות (Malleability).
המודל הזה בא לעזור ולנבא אלו תכונות סביר יותר שמועמד יוכל לשנות / להתאים לתפקיד החדש – ואלו פחות.

מודל החשילות בא לסייע בדילמה: "הבחור הזה נראה לי ממש מתאים חוץ מא' וב' – כמה סביר שהוא יתאים את עצמו לתפקיד?"

כמטאפורה:

  • הענפים והעלים הם החלק הכי פשוט לשינוי בעץ: לדוגמה – העץ משיר את עליו ע"פ עונות השנה המשתנות.
  • הגזע הוא קצת יותר קשה לעיצוב: אבל אור שמש ורוחות, יכולים לגרום לגזע להתעקל עם הזמן – לצורה שתטיב עם העץ.
  • השורשים מחופרים היטב באדמה, וכמעט כמעט שלא משתנים לאחר שצמחו. במקרים קיצוניים בלבד – ייתכן בהם שינוי.
התכונות הבאות, נחשבות כ"עלים":
  • הכרת המוצר
  • הכרות עם החברה, והבנת הדינמיקה הארגונית שלה
  • הכרות עם טכנולוגיות / סביבת פיתוח
  • אחריות אישית
  • מיומנות תכנון / ארגון אישי
  • מיומנות להנחות אנשים אחרים
  • התמקדות ביעדים הנכונים לחברה
כל אלו הן תכונות שאם הן חסרות למועמד – לא כדאי לפסול אותו בגללן. קל יחסית להשלים אותן.
התכונות הבאות, נחשבות כ"ענפים":
  • הכרת השוק / התחום
  • יכולת הקשבה
  • יכולת הסבר טובה
  • יכולת האצלת סמכויות (למנהלים)
  • יכולת לגייס ולקדם עובדים טובים (למנהלים)
  • פיתוח מודעות עצמית גבוהה יותר
אלו הן תכונות שרק מעט יותר קשה לשנות – ועדיין לא כדאי לוותר עד מועמד שחסר אותן.
התכונות הבאות, נחשבות כ"גזע":
  • יכולת לחשיבה אסטרטגית
  • יכולת להיכנס ולהתעמק בפרטים
  • יכולת מיקוד – במספר מצומצם של נושאים.
  • פתיחות לקבלת פידבק או רעיונות אחרים
  • שיקול דעת
  • החלטיות
  • גמישות
  • יוזמה / פרואקטיביות
  • ביטחון עצמי
  • בניית קשרים טובים עם אנשים
  • עבודת צוות / שיתוף פעולה / עבודה למען מטרות משותפות
  • השפעה / השפעה ללא סמכות
  • התמודדות עם "פוליטיקה" / דינאמיקה ארגונית
  • גילוי אמפתיה לאחרים
  • היכולת לעורר השארה באחרים / ליטוע בהם מוטיבציה ואנרגיה
  • מצוינות / raise the bar
  • טיפול בעובדים חלשים (למנהלים)
  • לדעת ליחצן את העבודה של הצוות (למנהלים)
אלו הן תכונות שאינן קלות לשינוי. אם אתם מתלבטים לגבי מועמד בשל תכונות מהרשימה – קחו בחשבון את האפשרות שעל אף הבעת רצון, התכונות הללו לא ישתנו.
התכונות הבאות, נחשבות כ"שורשים":
  • אינטליגנציה / חדות
  • שיטתיות / יכולות אנליטיות
  • יצירתיות
  • Drive – החשק לעשות דברים
  • הרצון להשפיע וחולל שינוי
  • קבלת אתגרים גדולים / לקיחת סיכונים
  • התמדה
  • כמות ההשקעה במקום העבודה
  • שליטה עצמית
  • כנות / יושרה
  • אסרטיביות
  • כבוד לזולת / קבלת האחר
אל תבנו על כך התכונות הללו שישתנו, באמת שלא…
אם היה לכם מועמד שהצליח לשנות אחת מהתכונות הללו – זכיתם! אנא ספרו על כך בהערה לפוסט 🙂
שיהיה בהצלחה!

נ.ב. – הפוסט נכתב בלשון זכר, רק מכיוון שזה מפשט את הכתיבה / קריאה.

—-
[א] – גילוי נאות: אני בעל 15 שנות ניסיון בתעשייה, ובאמת שאין לי תמריץ "לזלזל" בחשיבות הניסיון.