מי מקבל את ההחלטות הטכנולוגיות בארגון? [דיון]

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

  • מי נכון שיקבל את ההחלטות הטכנולוגיות בארגון?
  • איך זהות מקבל ההחלטות משפיעה על היחס בין ריסון לאפשור?
  • ב Code Review – מה מעמדו של ה Reviewer? האם הוא יכול לחייב את כותב הפיצ׳ר לשנות דברים או שהוא רק ממליץ? האם נכון לאפשר לו לחסום הכנסה של קוד ל master?
 
הנה צץ לו נושא אמיתי, שהטריד כמה מקוראי הבלוג – והחלטתי להרים את הכפפה.
 
תייגתי את הפוסט כ [דיון] כי בניגוד לרוב הפוסטים, אין לי מתודולוגיה סדורה שאני מתבסס עליה. זה גם אינו נושא שהפכתי וחשבתי עליו רבות (אם אני כותב פוסט על כזה נושא, לרוב התחבטתי בו כבר שנים). אני כותב את הפוסט כי הנושא נראה לי מעניין, חשוב, ורלוונטי – ובעיקר בעקבות בקשות קוראים. אז בואו ניקח אותו בפרספקטיבה הנכונה.
 
 

טראומות

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

"נושא כאוב נוסף שניתן להתייחס אליו זה code review – מה מעמדו של ה reviewer?…" – עוד תגובה לפוסט

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

אשתף בשתי "טראומות" שלי:

שעבדתי ב SAP עבדנו על מוצר וובי (Web) כלשהו, יום אחד הגיע ארכיטקט בכיר מאוד בארגון ודרש שנשכתב את כל המוצר משפת ג'אווה ל PL/QSL – על גבי בסיס הנתונים החדש ש SAP בנתה, HANA. הוא טען שהביצועים ישתפרו בצורה דרמטית, וזה יועיל למוצר – וגם כדרך אגב SAP תוכל להתנסות יותר בפיתוח משמעותי על גבי HANA, כמו שנאמר: Eat your own dog food.

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

ההתנגדות למהלך בקרב מובילי המוצר הייתה מקיר-לקיר, אבל הארכיטקט הבכיר מאוד (ומי שהוא ייצג) הכריעו – והדבר נעשה. אחרי שישה חודשים של שכתוב קוד ג'אווה ל PL/SQL (שפה גמישה הרבה פחות) שרשרת הכישלונות הייתה כל-כך ברורה וכואבת – שההחלטה התהפכה. לקח לנו עוד כחודשיים להפוך את ההחלטה (לסרוק שינויים ב PL/SQL – ולהכניס אותם חזרה לג'אווה), אבדנו 8 חודשי עבודה (של כ 50 מפתחים), והתשנו מאוד את הצוות ואת האמונה שלו בדרך. המוצר נכשל – אבל גם כנראה היה נכשל בלי קשר להחלטה הזו (לא היה לו מספיק ערך עסקי).

המקרה השני התרחש דווקא בחברת סאטראט-אפ בה רצינו, לראשונה, לבנות אפליקציית Desktop למשתמשים חצי-טכניים. ה VP R&D של הארגון דחף באגרסיביות כלי בשם Eclipse-RCP, פלטפורמת ה UI בה משתמשת Eclipse (ומיועדת לכתיבת IDEs או כלים דומים) – על סמך היכרות על הפלטפורמה מפרויקט שניהל בארגון קודם.

בחנו את הטכנולוגיות מול אלטרנטיבות יותר מקובלות (בזמנו): ממשק וובי, Java Swing, ו FORMS.NET.

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

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

המקרה השני יותר מוזר / חזק בעיני: בעוד במקרה הראשון נראה שההחלטה שירתה צורך עסקי אמיתי של החברה (HANA היא מוצר דגל של SAP, שהכניס לחברה מאות מיליונים) – גם במחיר "הקרבה" של קבוצת פיתוח / מוצר זניח אחר, במקרה השני לא היה אינטרס אחר או "גדול יותר" לחברה. ההחלטה להשתמש ב Eclipse RCP הייתה פשוט לא טובה, ולא שירתה שום צורך אמיתי נראה לעין. היא התנהלה בצורה רעה – שגרמה למעורבים (ביניהם אני) לאבד אמון בהנהלה. נכון שהנזק (האבסולוטי) היה קטן יותר: כמה אנשים שאיבדו מידה של אמון במנהל, ואולי עבודה של 2-3 מפתחים לאורך כחודשיים – התבררה כבזבוז.

מה אפשר ללמוד מהמקרים הללו?

(אני מתייחס רק לשני המקרים שתיארתי – שאני מכיר אותם היטב)

  • לעתים ה"אנשים הפשוטים בשטח" מבינים טוב יותר, ויכולים לקבל החלטות טובות יותר ממנהלים בכירים.
  • בכל זאת, קולם של האנשים הבכירים רם יותר – והשפעתם גדולה יותר.
    • במאמר מוסגר אוסיף שזו אחת המוטיבציות של אנשים להתקדם בארגון: להתקדם בעיקר בכדי להיות מסוגלים להשפיע יותר.
  • כשהטיעונים להחלטה לא נראים הגיוניים / מציאותיים – מתרחש תהליך של איבוד אמון, תהליך המלווה בתסכול וכאב, בקרב אלו שלא יכולים להשפיע עליו.
  • בחדרי הישיבות ובדיונים ניתן לומר הכל – אבל מציאות-ברורה היא חזקה יותר.
    • למשל: למרות כוחו הרב של מנהל הפיתוח לקבוע שימוש ב Eclipse RCP בניגוד לכל הדעות האחרות, עבודה קצרה (יחסית) בשטח – הפכה לחלוטין את ההחלטה.
    • כלומר: המנהל יכול היה להכריע שננסה את השימוש ב Eclipse RCP, אבל לא באמת היה לו מספיק כח להכריח את השימוש בו לאורך זמן / ניסיון לא טוב.
 
אני אוסיף כמה תובנות נוספות, מכלל הניסיון שלי:
  • אנשים שונים מבינים את המציאות באופנים שונים, לעתים במידה שכמעט ואינה ניתנת לגישור.
    • לפעמים, התכתשויות על החלטות טכנולוגיות – נעשות באמונה שלמה, של שני הצדדים, שזה הדבר נכון לארגון. זה המקרה הטוב יותר.
    • יש מקרים, לא נדירים, בהם השיקול שמנחה אנשים הוא לא באמת טובת הארגון, אלא טובתם שלהם: חשק, עניין, תחושת ביטחון ("זו הטכנולוגיה שאני מכיר", "נוח לי יותר לעבוד עם הקבוצה הזו", או "זה יקנה לי שקט מול מישהו קולני בארגון"). הרבה פעמים אלו צרכים אישיים ולא "רשעות טהורה" – אבל הגישה הזו לרוב תוביל לתוצאה (וגם אווירה) – טובה פחות. זה המקרה הפחות טוב.
      • אני אתוודה, שאני לא פעם "דחפתי" החלטות טכנולוגיות על בסיס היכרות אישית שלי. רציתי שנעבוד עם כלים שאני בקיא בהם, ויהיה לי יותר מה לתרום, ויותר יכולת השפעה. רק במעט הפעמים – זה היה השיקול הנכון לארגון (כלומר: זה שאני אכיר / ארגיש בנוח עם הטכנולוגיה), ואני מנסה מאוד להימנע ולחזור על הטעות הזו.
  • החלטות טכנולוגיות, על אף המאמץ להפוך אותן "למדע מדויק" – לעולם לא יהיו לגמרי כאלו. תמיד יש בהן אלמנטים של טעם אישי וניסיונות עבר סובייקטיביים, הן יוכרעו במידה על סמך יחסי-הכוחות בארגון, ובלתי-נמנע שחלק מהאנשים לא יהיו מרוצים.
    • אני לא מאמין בניסיון לרצות את כולם – ואני מאמין שהן צריכות להתקבל ולהעשות, גם כשיש חוסר שביעות-רצון. כמובן שככל שחוסר שביעות הרצון גדול יותר, ומאנשים רלוונטיים יותר – נכונות ההחלטה נחלשת.
    • חשוב, לתת משקל משמעותי למי שעומד "לחיות" עם ההחלטה, ולשלם בפועל על טעויות בהחלטה. למשל: אם בניתוח הטכני אופציה א' מקבלת ציון 90 ואופציה ב' ציון 70, אבל הצוות שאמור לממש את הקוד ולחיות איתו מאמין יותר באופציה ב' – סיכוי טוב שנכון יותר לאמץ את אופציה ב', משני טיעונים מאוד ענייניים:
      • א. סיכוי טוב שמישהו בשטח מבין משהו שאתם לא, אפילו אם הוא לא יודע להסביר את זה בצורה טובה. (אם היה מתקשר מעולה, אולי היו מקדמים אותו והוא כבר לא היה בשטח?).
      • ב. מוטיבציה היא הדלק של תעשיית התוכנה. מי שכואב את הבחירה באופציה א', יוכל בלי משים, לממש אותה בדירוג 60, בעוד את אופציה ב' שהוא מאוד מאמין בה, להביא למימוש לדירוג 80.
        זו נשמעת כמו סחטנות או כוחנות, אבל זו המציאות האנושית ככל שאני מצליח להבין אותה: כך הדברים מתגלגלים בשטח ולא חכם "לטבוע בצדקנות". אנשים טובים יעשו עבודה פחות טובה שהם לא מרגישים חלק ממנה, ועבודה יותר טובה כאשר הם כן מרגישים חלק ממנה. לכן זה צריך להיות פאקטור גדול בשיקול.
  • המציאות חזקה יותר מכל טיעון – ולכן לעתים עדיף להתכתש בשטח מאשר באולם הדיונים. כאשר זה אפשרי, יש טעם בפשוט לנסות בשטח, ולשמור אופציות לשינוי כיוון.
    • לא פעם נופתע, שבעצם אופציה שפחות האמנו בה עובדת "טוב מספיק".
    • לא פעם, המציאות בשטח תשנה את דעת המתנגדים – ברוח טובה, ונוכל לפנות לדרך טובה יותר, כקבוצה מגובשת.
    • הכרעה בשטח היא בשום אופן לא הסתמכות על הגורל או "הרמת ידיים". כדי להצליח בה טוב חשוב:
      • לחתור בשטח למגע מוקדם וחד-משמעי, ככל האפשר, עם נקודות המחלקות.
      • תיאום ציפיות לשינוי כיוון, במידה ומדדי הצלחה מסוימים לא יוכרעו.
      • אפשור האופציות הטכנולוגיות (ארכיטקטורה), והפרויקטליות (לוחות זמנים) לשינוי הכיוון. אם יצאנו לניסיון בלי יכולת אמיתית לבצע שינוי כיוון אמיתי מאוחר יותר – יצאנו פשוט טיפשים. סליחה.
  • ניתן אולי להסיק מכאן שעדיף "להפוך את הפירמידה" ולתת למפתחים את מירב שיקול הדעת וההחלטות בנושאים טכנולוגיים – וכך גם להשיג את מירב המוטיבציה וההיכרות עם השטח. זו שאיפה יפה, אבל אני חושב שהיא לא מתרחשת מהסיבות הבאות:
    • לעתים מפתחים בשטח מבינים טוב יותר – אבל גם לפעמים לא.
    • מפתחים נוטים לגלות אהבה רבה לטכנולוגיות חדשות ומדוברות – באופן שמטה יותר מדי החלטות לכיוונים פחות טובים.
    • גם מפתחים לא חפים מאלמנט של קידום האינטרס האישי: "שימוש ב ישפר את מעמדי מול חברי / קו"ח / בטחון עצמי".
    • למפתחים לרוב יש הבנה פחות טובה של הביזנס, אלמנט קריטי בנכונות של ההחלטה.
    • מפתחים לא פעם מפגינים חשיבה קצרת טווח / נאיבית – לגבי החלטות.
    • בקיצור: הבכירים לרוב קונים את מעמדם (וקולם העדיף) בזכות האמון בהם, שהם מסוגלים לקחת החלטות טובות יותר. כמובן שיש כשלים במינויים, ולא פעם הבכיר הוא אדם שמקבל החלטות טכנולוגיות רעות באופן סדרתי.
  • ניסיון וידע הם דבר להתבסס עליו בקבלת החלטות טכנולוגיות – אבל כיצד?
    • אני רואה משקל משמעותי למישהו שכבר היה בסיטואציה דומה. זהו ניסיון קונקרטי.
    • "שנות-ניסיון" הוא לטעמי מדד מטעה: זה חבל, אבל יש אנשים עם 10 ו 20 שנות ניסיון שהידע שלהם פחות יסודי ו/או הם מקבלים החלטות טכנולוגיות פחות טוב מאנשים אחרים עם 5 או אפילו פחות שנות ניסיון. הם עברו הרבה מערכות וחברות – אבל ספגו מזה רק מעט. מאוד הייתי רוצה לאפיין מהי קבלת החלטות טובה וכיצד רוכשים את המיומנות הזו. ניסיתי בכמה הזדמנויות – אבל זה נושא גדול.
    • ברור שהמעמדות (מונח מציק באוזן) בארגון משנים גם הם. לארכיטקט או ראש צוות יהיה משקל גדול יותר – על אף שייתכן שהם לא "יספקו את הסחורה".
      • ראשי צוותים, למשל, הם ה Backbone של הארגון. זה תפקיד קשה, שוחק, ולעתים – כפוי טובה. הארגון "חייב" משהו לאנשים הללו בתמורה, ולעתים זה מתבטא בסלחנות להחלטות פחות טובות שלהם. דינאמיקת ה"קח ותן" הזו נוגעת בכל מי שנותן ערך נוסף לארגון והארגון "חייב" לו. זו דינמיקה חיונית, כנראה – שיש לה צדדים פחות יפים, אך היא חשובה.
 
 

אפשור מול ריסון בהיבט של קבלת החלטות

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

חקר-מקרה: נקסט אינשורנס

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

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

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

* אנשי-המפתח במקרה הזה הם בעלי מעמד/סמכות אחרים (ראשי צוותים אחרים) ו/או בעלי מומחיות (מי שכתב רכיב רלוונטי, אולי איש Operations או Data Engineer שיש לו פרספקטיבה נוספת).

 
הפילוסופיה של הארגון היא:
  • קבלת החלטות היא העצמה ופיתוח של העובד – ויש רצון לתת למפתחים לקבל החלטות בעצמם, ככל שזה יעבוד טוב.
  • האחריות מוטלת בסופו של דבר על ראשי הצוותים, ראשי הקבוצות, ואף הארכיטקטים – ואחריות באה עם יכולת השפעה.
אלו שני עקרונות סותרים, אבל משרטטים גבול מטושטש כלשהו של קבלת ההחלטות: החלטה מקומית – ברמת המפתח. ככל שההשפעה של ההחלטה גדולה יותר – תתקבל בדרגים גבוהים יותר. הדרגים הגבוהים יכולים וצריכים להשפיע ואפילו במקרים חמורים – להפוך החלטות לא טובות (בהנחה שהם זיהו נכון את המצב, ורוב הפעמים הפיכת ההחלטה תעשה טוב – ולא נזק).
 
החופש של המפתח לקבל החלטות תלויה מאוד בראש הצוות שלו, והאמון שיש למפתח עם ראש הצוות. ראשי צוותים מסוימים יותר נוטים לסמוך על מפתחים ולתת להם את החופש בקבלת החלטות מאשר אחרים. ראשי צוותים נוטים לסמוך ולתת לחברי צוות אחדים יותר חופש על פני אחרים – זה מאוד אינדוודואלי ומקומי. באופן לא לגמרי טריוויאלי, לא תמיד המפתחים מרגישים תרומה אישית יותר אצל ראשי צוותים שנותנים יותר חופש. יש הטוענים שדווקא ראשי הצוותים שמעורבים בפרטים – הם סביבת עבודה עדיפה וטובה יותר (שוב: הסתכלות אישית).
 
צוותים אחראים על מיקרו-שירותים – ולכן ניתן להם חופש בעיצוב המיקרו-שירות. לחופש הזה יש גבולות, ולרוב אני (או הארכיטקטים שאיתי) הם אלו שמגבילים אותו:
  • חשוב לנו ניהול Stack מינימלי של טכנולוגיות – בכדי לפשט את המערכת ולשמר את היכולת של מפתח מצוות X להבין ולשנות קוד של צוות Y. אנחנו נקשה/נאתגר בכל פעם שיהיה רצון להרחיב ולשנות את ה Stack הטכונולוגי, ונגדיר סדרת מבחנים – שיש לעבור בכדי להוסיף טכנולוגיה ל Stacks (יש לנו כמה Stacks שכאלו: Backend, Frontend, ו Data).
  • כנ"ל לגבי מבנים וסגנונות עבודה. יש לנו קווים מנחים / Patterns למבנה של מיקרו-שירות (שכבות, אינטרקציה, דרך לכתוב בדיקות, איך מתבצעת תקשורת בין שירותים, דפוסים לעבודה עם בסיס הנתונים) – ואני והצוות שלי נאתגר את מי שירצה לחרוג או לשנות אותם. צריך להראות ערך / צורך ברור ומעל ספק סביר – בכדי לעשות שינוי. העיקרון המנחה הוא שמערכת אחידה יותר – תהיה מובנה וצפויה יותר לשאר הארגון.
  • יש לנו תהליך של "ניסוי" בו כל אחד, בתיאום ראש הצוות, יכול לנסות טכנולוגיה חדשה / סגנון חדש באזור מוגדר. לאחר כמה חודשים של ניסיון אמור להיות שלב Go/no Go. אם קבוצת ה Reveiw השתכנה שזה שיפור ברור – מאמצים כחלק מהסטנדרט (או לעתים: סטנדרט רק למקרים ספיציפיים ומגודרים היטב.). אם צוות ה Reviewer לא השתכנע שזה מספיק טוב – הניסוי יימחק והקוד יומר לסנטדרט.
    • תהליך יפה, שלא כ"כ מתנהל בפועל. יש שני מקרים ברורים בהם נכנסו כך טכנולוגיות חדשות לרוחב החברה – וגם מספר דחיות, אבל עדיין ממתינים כ 10 ניסיויים באוויר, בלי שאנחנו עושים להם תהליך רביו. כשל אישי שלי.
  • לא מזמן הקמנו קבוצת עבודה להגדרת Guidelines לעבודה: אני מוביל את הקבוצה בעזרת נציג מכל מחלקת פיתוח. אנו מציעים ביחד טיוטה לסטנדרטים (שהוסכם שכארגון אנו רוצים בהם): כיצד להגדיר API, כיצד לעשות Code Review, כיצד להשתמש ב Exceptions. הטיוטה עוברת Community Review – סשנים בהם כל מפתח יכול להצטרף ולהציע שינויים, אבל הוא צריך לבוא עם "שיעורי בית" מוכנים: טיעונים ודוגמאות משכנעים. על השינויים מסכימים ברמת ה Community. לפעמים זה קל, לפעמים בהצבעה – ואחרת אני מכריע (מקרים נדירים שזה נדרש. נדרש כדי לא למרוח החלטות). מאותו שלב אנחנו מפרסמים את ה Guideline ועובדים לפיו.
    • עד כמה ה Guideline תואם למציאות בפועל? לפעמים יותר, ולפעמים פחות. כשיש ויכוח בין שני צדדים – הוא כן מסמך מכריע בהחלטה. כלומר: צוות שיחליט לעבוד אחרת יכול לעשות זאת "מתחת לראדאר" עד אשר יהיה ויכוח פומבי בנושא. גם אז – ננסה להבין אם הבעיה היא חוסר-הגמישות של הצוות, או בעיה ב Guideline שנקבע.
ספציפית Code Review הוא חוזה חשוב במארג היחסים והדינמיקה של החלטות טכניות בארגון. אסכם שוב את הרקע: אנו עובדים במיקרו-שירותים בהם לכל שירות אחראי צוות מוגדר. אנחנו מאפשרים ומעודדים אנשים לשנות קוד בשירותים אחרים – אבל רק בהסכמה של הצוות שאחראי על השירות. אלו עיקרי העקרונות שלפיהם אנחנו עובדים:
  • חייב להיות לפחות Reviewer אחד שמאשר את הקוד. אם מדובר בקוד של צוות אחר – חייב להיות אישור של מישהו מהצוות.
  • Reviewer שלא מרגיש שיש לו משהו משמעותי לתרום ב Review יסיר את עצמו, ויוסיף Reviewer אחר במידת הצורך.
  • ברוב המקרים, ה Reviewer רק מספק הצעות לכותב הקוד. הצעות יכולות להתקבל או להדחות. אנו מעודדים אנשים להיות רגישים אחד לשני, וגם לפרגן על קוד טוב – בכדי לבנות את האמון.
    • Code Review בהגדרה הוא לא כלי להכתיב סגנון מועדף לאנשים אחרים. ה Reviwer נותן עצות, ורצוי שיצליח לתת אותן ממקום חברי ותומך (ולא ממקום נוזף ומתנגד).
  • במידה וה Reviwer מזהה בעיה משמעותית: באג, תכנון (Design) בעייתי, או חריגה משמעותית מה Guidelines הוא מסמן את ה PR כ "Changes Required". מהשלב הזה ה PR לא יוכל להתמזג (merge) ללא הסכמה של אותו Reviewer. כלומר: אנו נותנים ל Reviewer דגל אדום להרים, שיש מאחורי סמכות – אבל הציפיה היא להשתמש בו בזהירות ובאחריות.
    • מי שישתמש בזכות הזו במידה רבה מדי – יזכה להכוונה מחדש מהמנהל שלו.
  • יש לנו גם שורה של עצות מה לבדוק בקוד Review, ועל מה להעיר. זה בעיקר Checklist לבודק.
 
 

סיכום

 
ההחלטות בארגון מתקבלות מתוך שיקולים טכניים (לא מדויקים, למרות שהיינו רוצים שיהיו כאלו) בשילוב של שיקולים ודינאמיקה ארגונית. ההכרה ב Tradeoffs המעורבים, ובכוחות הפועלים – עוזרת להבין טוב יותר את הדינאמיקה, ולקחת החלטות טובות יותר.
 
מה הדבר המשמעותי ביותר שאפשר לעשות בכדי לקחת החלטות טכנולוגיות טובות יותר?
 
כלל חשוב, לדעתי, הוא לקדש את הנוסחה: Org > Group > I.
 
לנסות כל הזמן לקחת החלטות שטובות לארגון, ולנסות ו"לנער" החוצה שיקולים מקומיים. זה עניין של תרבות ארגונית. בכל פעם שמישהו ייקח החלטה מקומית בוטה יותר, ויצליח בכך – כך נתרחק מהיעד.
 
מבחינתי, זהו שיקול מרכזי בבחירת ארגון. אני מנסה להימנע מלבחור מקומות-עבודה בהם אנשי המפתח הם צבעונים (הרבה פעמים יש בזה משהו כריזמטי), קולניים, ו"קצת משוגעים". אני נוטה לחשוב שאלו האנשים שיעשו יותר שיקולים אישיים / אמוציונליים – וירחיקו את הארגון מתרבות שמרוכזת בהסתכלות על טובת-הכלל.
 
אני מנסה גם לבחור ארגונים בהם סט האמונות הטכנולוגי של אנשי המפתח – דומה לשלי. עבדתי במקומות שהיה פער גדול, זו הייתה חוויה מלמדת – אבל עם פוטנציאל לתסכולים גדולים. בסופו של דבר אני מאמין שבארגון חשוב קונצנזוס על ערכי הליבה – וטוב להיות שותף לקונצנזוס.
 
 
 
שיהיה בהצלחה!
 
 
 

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

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

כיצד לצמצם פוליטיקה ארגונית? (מבלי לעבוד לבד)

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

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

האם ניתן להימנע מפוליטיקה ארגונית?

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

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

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

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

כיצד לתמרץ פוליטיקה ארגונית

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

אין משמרות

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

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

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

הנזק מהחלטה נקודתית ותמימה לכאורה – היה עמוק ומתמשך.

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

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

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

The Chosen

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

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

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

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

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

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

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

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

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

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

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

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

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

לקדם את טוראי ראיין

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

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

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

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

נשמע win-win, לא?

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

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

דוגמאות קצרות אחרות ששווה להזכיר:

  • מנהל שלא מספק קרדיט לעובדיו. שמו מתנוסס על פרויקטים, עליהם בקושי השפיע.
    • גם ההתנהגות (הרעה) הזו – היא מודל לחיקוי.
  • מנהל שלא "מרגיע" עובדים סופר-תחרותיים, המתייחסים לעובדים אחרים בזילזול, או עובדים מרירים שלא מפסיקים להתלונן ולעקוץ עובדים אחרים.
    • לפעמים העובד ה"קשה" יהיה ביצועיסט מצויין – ויהיה קשה לאמוד את מידת הנזק הסביבתי שההתנהגות שלו, ובעיקר: קבלת ההתנהגות שלו – גורמת.
    • התפרסמו בשנים האחרונות תוצאות מחקרים שהראו שקיום יריבות מתמשכת בצוות, ותחושת אי-ביטחון לעשות שגיאות ולטעות – היא מנבא מוצלח למדי לאי-הצלחה של ארגון.
      למשל: Google on Psychological Safety
  • וריאציה נוספת: קליקות מזיקות
    חברויות עמוקות בצוות הן דבר מבורך, אך לעתים נוצרות "קליקות" שלא מקבלות אחרים: חבורת מפתחים ותיקים שעבדו ביחד בחברה קודמת, מפתחים מול QA, צוות דוברי רוסית שמשתמשים ברוסית גם מול חבר צוות שאינו יודע את השפה, וכו'.

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

ואם רוצים בכל זאת, דווקא – לצמצם את הפוליטיקה?

שורשי צמיחת הפוליטיקה בארגון, אם כן, הם ב:

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

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

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

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

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

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

Self < Team < Organization

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

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

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

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

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

סיכום

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

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

כמו בסיפור של עוץ לי גוץ לי – החוב סופו להיפרע.  [1]

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

—-

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

על היוגי והקומיסר

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

\"כבר עשינו עבודת הכנה מקיפה לגבי המעבר ל MDA (קרי: Model-Driven Architecture):\", פתח הארכיטקט הבכיר (להלן א׳, שמו שמור במערכת). \"הגדרנו Meta-Model לכל המערכת שלנו, וביססנו אותו על Meta-Meta Model (או super model). יש לנו רשימה של נקודות שצריך עוד לסגור – אבל אנחנו כבר יכולים להתחיל. הצוות של יוסי החל ליישם Repository למודלים, ועוד חודשיים נוכל כבר לתת לכל שאר הצוותים בארגון להמיר את הקוד שלהם למבנה ה MDA.\"

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

\"אבל מה היתרון בלעבור ל MDA??\" – הזעיף פנים ראש צוות אחד, בחור קצת מחומם.

\"זו פרקטיקה בצמיחה, יש כבר \'body of knowledge\' שהולך ונבנה בתחום, ויש גם כמה יישומים מוצלחים (במיוחד בעולם ה Databases)\" – ענה א׳ בלי למצמץ, בלי לשדר אי-נוחות, בלי בושה.

\"אבל מה היתרון בשבילנו, למוצר שלנו??\" – נשאל שוב. \"עכשיו אני אמור להשקיע חצי שנה עם הצוות בשינוי ארכיטקטורה – בשביל מה??\"

\"אה… אתה צודק מאוד.\" – נראה שלא׳ נפל סוף-סוף האסימון.
\"אנחנו נכתוב רשימה של היתרונות של MDA ונראה אילו הכי משמעותיים עבורנו, נתמקד במה ששימושי עבורנו, כמובן. נקודה טובה!\".

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

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

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

מה קורה פה בעצם?

(בעקבות שאלה: לא, זה לא אירוע שקרה בגטט… אלא שנים רבות לפני כן)

מקור: https://vidyow.com/video/the-main-differences-between-t/vcbaDoo8guL

ציר טראמפ-אובמה

למזלנו, ההיסטוריה העכשווית מספקת לנו מטאפורה רלוונטית שקל להתייחס אליה*.

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

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

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

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

האם ייתכן שאובמה לא הצליח לעשות הרבה ב-2 הכהונות שלו?
האם ייתכן שטראמפ לא יחריב את ארצות הברית, ואולי יעשה כמה דברים טובים?

על טראמפ קל לצחוק. אני אישית נהנה – אני מודה!

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

מקור: הפוסט http://getindata.com/blog/post/lean-big-data-how-to-avoid-wasting-money-with-big-data-technologies-and-get-some-roi
כשנתקלתי לראשונה בתיאור הזה החוויה שלי הייתה: הנאה. איזה סיפור מצוין. (\"כל-כך נכון!\")
שמרתי את התמונה בצד – ואמרתי לעצמי שאכלול אותה באיזה פוסט. לא חשבתי שזה יהיה הפוסט.

יש משהו ציני וקוטבי בתיאור המקרה הזה (ובדומים לו):

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

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

מה הסיפור שלכם?

חשבו. האם יש סיפור דומה שאתם נתקלתם בו?

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

It\'s all about tradeoffs

בסופו של דבר אפשר לומר שיש סקאלה של שני סגנונות הפוכים:

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

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

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

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

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

סיכום

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

אני בהחלט יותר יוגי מקומיסר. זה כנראה משתקף בפוסט, אך הנחתי שגם רוב הקוראים של הבלוג הם כאלו.

הייתי מנסה לנסח את נקודות המחשבה הבאות (ניסוח ראשוני):

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

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

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

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

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