קיימת ספרות ענפה בתעשייה בנושא ניהול צוותים. אלפי בלוגים, רבבות מאמרים, אינספור ציוצים על ניהול.
אבל שמתי לב שיש מעט מאוד תוכן על ניהול מנהלים.
כשהתחלתי לראשונה לנהל מנהלים (ובעצם לבנות ארגון פיתוח, שזה לא בהכרח אותו הדבר), חיפשתי המון חומרים לקרוא, והמחסור הורגש.
יש אחלה בלוג של דניאל קורן, שסיכם שיחות עם מנהלים מגניבים בתעשייה. יש שם טיפים מעולים לראש הקבוצה או ה-VP R&D המתחיל - ממליץ מאוד לקרוא.
אבל אני חושב שיש צד משמעותי שלא מדברים עליו, והייתי שמח לנצל את הפוסט הזה לטובתו, וזה הפרקטיקה של המעבר מראש צוות למנהל של מנהלים.
מה כלכך שונה בין צוות לקבוצה?
הנקודה הראשונה ששמתי לב אליה היא שדברים שבאו לי אינטואיטיבית בתור מנהל של מפתחים פתאום לא עובדים לי בתור מנהל של מנהלים.
הדבר המשמעותי ביותר הוא - חופש.
כראש צוות הייתי נותן המון חופש. סמכתי על המהנדסים שלי שהם יודעים טוב ממני מה לעשות. היו לי דרכים לעשות מוניטורינג על העבודה שלהם, הייתה לי אינטואיציה טובה מתי להתערב ומתי לא, וידעתי ליצור ממשקים שאפשרו לי להיות בבקרה על ההתקדמות של הצוות בהתאם ליעדים שהצבתי לו.
כשעובדים בצוותי מוצר יש משימות שראש הצוות מייצר (נקרא להן משימות אינפרה), ויש משימות שמגיעות מהביזנס (נקרא להן משימות פרודקט).
התפקיד של ראש הצוות הוא לעשות באלאנס מסוים בין המשימות האלה, לדאוג שעומדים ביעדים הביזנסיים שהתחייבנו אליהם ושומרים על איכות גבוהה מבחינת התשתית ואיכות הקוד.
מלבד זאת, יש לך אחריות HRית על האנשים (לדאוג שטוב להם, לדאוג שהם מתקדמים ומתפתחים, לדאוג שהם עובדים כמו שצריך, ולוודא שהגלידה וואסבי במקרר לא פג תוקף כי מתיאס חולה על זה).
כשהגעת לרמת craftsmanship גבוהה בתור ראש צוות, אתה יכול בעיניים עצומות לדעת אילו משימות לתת לאיזה מפתח, אתה יודע על מי לסמוך כשהוא מרים לך דגלים ואת מי לדגום יותר.
אתה יודע מה מניע כל אחד מהעובדים שלך, אתה יודע מי מבריק ומי מפשל, את מי צריך לקדם ואת מי צריך לפטר, אתה יודע מי נותן אסטימציה לא רעה על משימות שהוא מקבל ועל מי צריך לקחת ספיירים.
יש סוגים שונים של מנהלים - כאלה שהם טכניים יותר וטכניים פחות, כאלה שיוצרים קשר חברי-עמוק עם העובדים שלהם וכאלה מרוחקים יותר. יש כאלה שמפקחים על המשימות מקרוב וכאלה שמעדיפים לעשות את זה מרחוק.
לכל אחת מהדרכים יתרונות וחסרונות, והן מתאימות לכל מיני שלבים של ארגון ותלויות מאוד בכם, באנשים שאתם מנהלים ובסוג המשימות.
מנסיוני למדתי שאין דבר כזה שיטת ניהול טובה אחת, מנהלים שונים יכולים להגיע לתוצאות והישגים דומים בדרכים אחרות.
אכלת ת׳ראס, חשבתי שבאנו לדבר על ניהול מנהלים
אז אוקיי, עשינו יישור קו על ניהול צוותים 101. כעת, בואו נעבור לשלב הבא.
עליתם לכיתה ב׳. אתם ראשי צוותים מדהימים, אני יודע.
אבל עכשיו אתם מנהלים מנהלים (חיחי), וחשוב לי לחדד נקודה קטנה שתעזור לנו להבין את שורש המורכבות בסוג הניהול הזה.
הנקודה היא כזאת:
אם היית ראש צוות מבריק/ה, זה לא בהכרח אומר שהיית מהנדס/ת מבריק/ה (לעיתים זה אומר את ההפך).
כלומר, עד עכשיו ניהלת אנשים (נו טוב, מהנדסים) שיתכן והיו טובים יותר ממך במה שהם עושים.
הסיבה שקודמת לתפקיד ראש צוות היא לא כי את המהנדסת הכי טובה בצוות, אלא כי את המתאימה ביותר לתפקיד הניהול.
מהצד השני, בפוזיציה החדשה שלך בתור מנהלת של מנהלים, את מנהלת אנשים שלפני רגע עשית את העבודה שלהם והיית פאקינג טובה בה. כנראה שהרבה יותר מהם. בגלל זה קידמו אותך.
חשוב לחדד את הנקודה הזאת.
ראש צוות טוב הוא לא בהכרח המהנדס הכי טוב.
אבל ראש קבוצה טוב הוא כנראה מישהו שהיה לפני כן ראש צוות מדהים.
נחזור לנושא החופש.
כמעט כל הבלוגים שאני נתקלתי בהם על ניהול מנהלים מכוונים למנהל הצעיר.
בהשאלה מהצבא, מדובר בבחור חולה סגמ״ת שנפל עכשיו מבה״ד 1 ומנסה להוכיח לכולם שהוא הבוס.
אותו עלם חמודות, כך מסבירים כל הבלוגרים, צריך להבין שיש תחתיו מנהלים אמיתיים, בשר ודם, חכמים לא פחות ממנו.
כמובן שהאינסטינקט הראשוני של אותו מנהל שמנסה לבסס את מעמדו הוא להתנפל עליהם עם משימות, להתערב להם באיך הם עושים דיילי, לדגום את ה-jira שלהם, לעשות over ruling דרך קוד ריוויו למהנדס הכי ג׳וניור בחברה, ולעשות פגישה יומית עם כל ראשי הצוותים ולשאול מה קורה עם הפיצ׳רים?
״אל תעשה את זה״ הם צועקים עליו.
״אתה עכשיו מנהל של מנהלים!״. ״תן להם כמה שיותר חופש ותראה ישועות״.
משמע כל המנהלים תחתיך הם נפוליאון בונפרטה - חירות, שיוויון ואחווה הם צועקים. תן להם חופש, והם יביאו אותך לגאולה.
אני הולך קצת לנפץ את הבועה הזאת, ולהגדיר את הצעדים האקטיביים שמנהל של מנהלים צריך לעשות כדי לוודא שהארגון מתפקד.
הסורים על הגדרות
הגדרות הן דבר חשוב.
הן עוזרות לנו לחדד ציפיות עם העובדים שלנו, וכשמדובר במנהלים שפועלים בתוך מסגרת רחבה מאוד by definition, זה חשוב כפליים.
חשוב מאוד להגיד לראשי הצוותים שלך מה אתה מצפה מהם, ולפעמים גם לעזור להם ב״איך״, תלוי כמה הם לא בכיוון.
אני רוצה לפרוט כמה נקודות שיכולות להוות טמפלייט לצורה שבה אפשר לתאם ציפיות עם ראשי צוותים ולכוון אותם להצלחה. כמו שאומרים - הצלחתם הצלחתכם, וכישולנם פיטוריכם.
בפוסט נפרד אנחנו נדבר על KPIים ומטריקות, ונספר על תהליך שעשינו (ואנחנו עדיין עושים בארגון) וגם סתם כדי שלא תוכלו להגיד לי ״חחח למה אין מטריקות יא ליצן״. אבל בגדול אני חושב שחשוב להתחיל דווקא מתיאום ציפיות שהוא יותר אבסטרקטי לפני שצוללים לאזורים הטכניים של המדידה.
אז מה הם הדברים העיקריים שעליהם נמדד ראש הצוות בארגון שלכם?
או כמו הכותרת ש-GPT המליץ לנו לתת לפוסט הזה: ״4 דברים שלא ידעתם שצריך לדרוש מהמנהלים שלכם, לא תאמינו לנקודה 3!״
1. עמידה ביעדים עסקיים
ראש צוות נדרשת לעמוד ביעדים העסקיים שהחברה מציבה לה. אם הצוות מתחייב לדלוור roadmap ברמת הרבעון ולא עומד בו, זו נורה אדומה. אם הצוות אמור לדלוור פיצ׳רים ברמת הספרינט ולא עומד בהם, נורה אדומה.
כמו שבתור ראש צוות נורא קל לדעת מתי מפתח לא מדלוור, בתור ראש קבוצה דיי קל לדעת מתי צוות לא מדלוור. התפקיד שלך כאן הוא מאוד משמעותי אבל יחסית מובנה - לעשות מוניטורינג על ההתחייבויות של הצוות, to call bullshit על מילים יפות ללא כיסוי, והבטחות ללא גיבוי. אם ראש הצוות שלכם מתחייבת לדלוור פרויקט דיי משמעותי עד סוף הרבעון ואתם מאמינים שהיא לא תוכל לעמוד בו, עליכם לאתגר אותה.
וזה עובד גם לכיוון השני - אם המשימות שהיא מציבה לעצמה לא מספיק שאפתניות, אחריותך כמנהל שלה להתערב.
דרך אפשרית לעשות מוניטורינג לעמידה ביעדים היא פגישת סטטוס דו-שבועית / חודשית / בכל שנה מעוברת שבה עוברים על המשימות של הצוות ב-high level.
מנהל המוצר של הצוות יכול להיות ally טוב בפגישות האלה, וחשוב שהוא ינכח בפורומים האלה וירים לך דגלים כשהוא מריח משהו רקוב.
2. ניהול אנשים
מה קורה עם החבר׳ה שלך? הם מרוצים? מה אפיק הגדילה שלהם? את מי צריך לקדם? את מי צריך לפטר?
התפקיד שלך לדאוג שהמנהלים תחתיך מתעסקים בשאלות האלה כל יום.
איך עושים את זה? טיפה יותר מורכב ותלוי במנהלים שתחתיך.
חלקם יעשו את זה באופן טבעי, חלקם יברחו מזה כמו מאש. חלק ישמחו להכוונה, וחלק ירצו שתעזוב אותם לנפשם כי הם יודעים יותר טוב ממך.
החוכמה היא לעשות מוניטורינג בצורה הנכונה, לוודא שהכל על השולחן (זה אומר לפעמים לדגום את ה״איך״), לתת להם לחנוך לנער על פי דרכו, אבל גם להזכיר להם מהי דרך המלך (או המלכה, הכוונה היא אליכם כמובן).
טמפלייט אפשרי לשיחה דו שבועית עם כל אחד מראשי הצוותים שלך יכול להיות משהו בסגנון הזה:
עוברים על האקסל עם האנשים שהוא או היא מנהלים
על כל אחד מהעובדים:
איך הלך לו בספרינט האחרון?
האם הוא מודע לזה? (לטוב ולרע, וזו נקודה מאוד חשובה)
מה המשימות לספרינט הבא? איך זה מתכתב עם תוכנית הגדילה של אותו עובד? (אם אין תוכנית כזו, כדאי שתהיה)
אגב, ב"לדגום את האיך" התכוונתי בדיוק לנקודות כמו 2.b. לגיטימי שתבקשו לשמוע איך בדיוק עבר הפידבק ולוודא שהעובדים מודעים למצבם החיובי / שלילי.
3. אחריות על ה-Infra
כאן זה כבר מתחיל להסתבך.
בתור מנהל פיתוח של קבוצה אתה אחראי לדאוג שהמוצר יציב, מנוטר כהלכה, שה-velocity גבוה ושכשיש תקלה בפרודקשן היא נפתרת הכי מהר שאפשר (אנחנו מתכננים לעשות פוסט נפרד על מטריקות של ארגון הפיתוח, אבל בגדול זה זה).
הדברים האלה מצריכים עבודה קבועה של הצוותים על משימות אינפרה.
לפיכך, הם מצריכים מהצוותים לייצר infra roadmap.
ובאחריותכם לדגום את זה.
עכשיו, זה כנראה כבר לא משנה כמה אתם טכניים כמנהלים - ככל שאתה עולה בהיררכיית הניהול, הסנסורים הטכניים שלך הולכים ונעלמים.
כבר אין לנו תמונה מאוד טובה של כל הקוד, כל הטסטים, וכל המוניטורינג שאנחנו עושים במערכת שלנו, וזה בסדר.
באזור הזה אתם צריכים לייצר סנסורים חיצוניים חזקים יותר, ויש פונקציות רוחביות שאמורות לעזור לכם. אם בצוות הבודד היה לכם טק ליד או סניור חזק שעוזר לכם לקבל ויזאביליות על האיזורים הבעיתיים ולהרים לכם דגלים על tech debts, איזורים שקשה לפתח בהם, או איזורים שהtest coverage בהם נמוך - כאן אתם צריכים לעשות את זה בסקייל.
לצורך כך, נדרשים פתרון מבני, ופתרון תהליכי:
פתרון מבני - פונקציות כמו staff engineer או principal engineer יכולים להיות הowners של הדומיין הזה. פונקציות שנמדדות על ה-overall code quality או על הביצועים של המערכת ויכולות להרים לכם דגלים כשיש בעיות קשות בצוותים שמצריכות את טיפולכם.
פתרון תהליכי - לדרוש מראשי הצוותים שלך בנייה והצגה של Infra roadmap אחת לרבעון, לבצע מעקב אחרי ההתקדמות, ולראות שהמטריקות שהגדרת באמת משתפרות (למשל, כמות הבאגים בפרודקשן).
4. משימות רוחביות
ללידרים בארגון יש בדרך כלל משימות רוחביות שהן מעבר לתפקיד הרשמי שלהם.
יכול להיות שאחת המנהלות אחראית על כל הנושא של ה-onboarding, אחד אחר אחראי על הגיוסים, ויש את זאת שמובילה שינוי רוחבי בחברה שנעבור להשתמש ב-tiktok במקום סלאק כאמצעי להעברת מסרים מידיים (אגב, מומלץ מאוד, שיפר לנו את ה-velocity).
לא אכנס לזה בפוסט הנוכחי, אבל הציפייה מלידר בארגון היא שהוא יוביל שינוי מעבר ל-scope שהוגדר לו, וצריך לוודא שמנהלים מבינים את זה.
אז מה היה לנו פה?
דיברנו על ניהול צוותים ועל המעבר לניהול מנהלים, על גדילה לתפקיד מתוך מקום של הצלחה בתפקיד הקודם ועל כמה שזה שונה מהקפיצה הקודמת שעשינו לתפקיד הניהולי הראשון.
ודיברנו גם על הגדרות שאפשר לייצר עם המנהלים שתחתינו כדי לבסס צורת תקשורת שתעזור לנו לעקוב אחרי ההתקדמות של הצוותים שאנחנו מנהלים בלי לתת חופש בלתי מוגבל מצד אחד ובלי לעשות מיקרו מנג'מנט מהצד השני.
וכשאני אומר דיברנו, זה בעיקר אני דיברתי, קצת הלך לי הקול.
הפוסט הזה היה מעין בליל מחשבות התחלתי על ניהול מנהלים, ובעיקר התמקד בתפקיד ה״שוטף״ של המנהל. נקרא לזה היום-יום, או הטקטיקה.
אני ארצה לכתוב בהמשך על מהלכים קצת יותר אסטרטגיים שמנהל קבוצה צריך לעסוק בהם, ועל נושאים אחרים ורבים בפוסטים הבאים.