עמיתי היקר שי משעלי, אותו אני מכיר ומוקיר מתקופת עבודתו בגט, כתב לאחרונה מאמר על כך שבעצם ניהול אינו אופן ההתפתחות הבלעדי כיום בתעשיה שלנו.
הסאב טקסט במאמר היה - "ניהול - זה כנראה לא בשבילי, וגם אתם הקוראים תחשבו טוב טוב לפני שאתם פונים לניהול, וודאו שאתם עושים זאת מהסיבות הנכונות".
למעשה, שי בחר להציג דעה רווחת כיום בקרב מהנדסים - הדוגלת בכך שחיים בתעשיה כ-IC והמשך התפתחות מקצועית - כ Tech Leads, Principal/Staff Engineer וכד' - הינה מסלול המתאים לרבים, לעומת ניהול - אשר נתפס בעבר כקידום היחיד האפשרי וכיום הוא רק אחד ממסלולי ההתפתחות, ולא בהכרח מתאים לכולם.
המאמר של שי הדליק אצלי נורה. זה זמן מה שאני מוצא את עצמי מהרהר בסוגיה הרת הגורל - למה יש מועמדים מעטים כל כך כיום לניהול מבין המהנדסים.
והאמת? בוא נודה באמת. מנהל בהייטק כיום נתפש במקרה הטוב כמנהיג (אשריהם של אלו המוכשרים
שהצליחו להתפש כאלה על ידי סביבתם) ובמקרה הנפוץ - כעסקן לא מקצועי הבוחש בקלחת, נושא במשרה שאין מנוס מלאייש אותה.
יש גם מילה מאוד מפחידה שמתקשרת למנהל, שהס מלהזכיר אותה ברבים - "פ-ו-ל-י-ט-י-ק-ה" !!!
הניהול - נראה שאינו אטרקטיבי כבעבר.
אם נחזור שני עשורים אחורה - אפשר להבין איך הגענו עד הלום. חברות מובילות בשנות ה-90 כמו מיקרוסופט ו IBM נתקעו עם מודל התפתחות מקצועי עתיק, קלטו שגוגל עוקפת אותן בסיבוב והן מאבדות כוח אדם איכותי ומרכזי, ושאלו את עצמן את השאלה - מה שונה במה שגוגל עושה.
אחת התשובות - בניית מסלול התפתחות מקצועי למהנדסים.
מאז כל התעשיה מחקה את גוגל בצורה זו אחרת, מסלולי התפתחות מקצועיים הפכו לסטנדרט, מפתחים רבים מעדיפים להישאר IC - Individual Contributor והשאר היסטוריה.
בהזדמנות זו, אני רוצה לדבר בזכות ההתפתחות לניהול והאתגר המדהים שמזדמן לכל מי שפונה למסלול הזה.
השאלות אותן בעיני צריך לשאול כל מפתח שמתלבט האם לפנות לניהול או לא, היא כמה אתם רוצים להשפיע על הארגון שלכם? כמה אתם רוצים שהמוצר שאתם מפתחים יצליח, ולהשפיע על עתידו והכיוון אליו הוא יתפתח? כמה חשוב לכם להשפיע על התרבות ההנדסית בארגון שלכם?
וכמה תהנו מהצלחה והתפתחות של עובדים אחרים?
כל מנהל צעיר בהייטק מכיר את המשולש הקדוש:
בואו ננסה לפרק לגורמים את האתגרים שמציע כל אחד מאזורי ההשפעה הללו בארגון, ומה תוכלו אתם לעשות כמנהלים, ברמות ניהול שונות בארגון.
People
מנהל צריך לבנות ולשמר את האנשים שלו, כל הזמן, ולבנות מוטיבציה.
מעבר ליחס האישי שצריכים לקבל כל העובדים, כי כל אינדיבידואל הוא עולם ומלואו, יש לחשוב יחד איתם על ההתפתחות שלהם, לתכנן אותה, לעקוב ולוודא שהתוכנית מתקיימת. יש לשקף לעובדים את ההתפתחות שהתרחשה בעבר - לא כל אחד יכול לתרגם את השינויים שקורים ביכולות שלו להכרה בהם.
על המנהל להעניק פידבק בונה - בכל סיטואציה בה יש הצלחה פחותה, בין אם מדובר ב soft skills או ב hard skills של העובד. כמו כן, יש לבצע סבבי משוב שגרתיים, לא בהכרח מבוססי משוב ארגוני (רבעוני למשל) על מנת לשקף לעובד את האופן בו הוא נתפס בארגון, מה נעשה טוב ומה ניתן לשפר
שגרה של מנהל כוללת גם קשב לקשיים אישיים של העובדים, וסיוע, ככל שניתן, על מנת לאפשר המשך תרומה לארגון.
ברמה האישית, קשה לתאר את הסיפוק שאני חש כאשר אחד החברים אותם אני זוכה לנהל מכיר בכברת הדרך וההתפתחות שהוא עשה, למשל במשוב שנתי - ולדעת שהתרומה שלי לכך הינה משמעותית, שיצרתי עבורו את ההזדמנויות הנכונות, כמו גם לראות את רמת המחויבות של הקבוצה שלי למקום העבודה בסקרים השונים.
Technology
מנהל צריך להיות מקצועי בתחומו. עליו להיות סקרן ולומד, להיות בעניינים ולהכיר היטב את הארכיטקטורה של המוצר, את ההחלטות הטכניות שעל הפרק, ללמוד את האלטרנטיבות - גם בתוך המערכת וגם מחוץ לה. עליו לגבש דעה - ולחתור לביצועה.
על המנהל לחפש ולמצוא למצוא פתרונות מאפשרים ומיטיגציה - שמצד אחד לא יחסמו את ההתפתחות העתידית של המוצר, לא יפגעו באיכות המערכת - ומצד שני יאפשרו התקדמות יעילה של היוזמות המוצריות.
מנהל צריך לדעת מה הוא רוצה, ולבנות מסלול חכם, מדויק, ומדורג להשגת היעד - ולקדם את המסלול הזה עקב בצד אגודל (לא לשכוח, רצוי לתכנן באופן שבו כל שלב בפרויקט נכנס לפרודקשן מיד עם פיתוחו, ולא בסוף הפרויקט).
אין זבנג וגמרנו. כשמנהל מעוניין לקדם בחברה פרויקט תשתית משמעותי שלדעתו ישפר את מצב החברה משמעותית, עליו לשכנע stake holders שונים בארגון, לעשות buy in, לערב את האנשים הנכונים, לבנות תוכנית - שוב לשכנע, שוב לעשות buy in... תהליך סיזיפי ומייגע שצריך לדחוף ולדחוף לאורך זמן.
אין נכון הוא הדבר שכ-IC אין ביכולתו של המהנדס להשפיע וליזום, לשיפור הטכנולוגיה והמוצר - נהפוך הוא, הציפייה ממהנדסים בכירים, ארכיטקטים היא לגמרי כזו. עם זאת, יכולות ההשפעה שלהם בדרך כלל מוגבלות יותר מהמנהלים, וכמו כן, מנסיוני, לרוב אין המהנדסים (לצערי) זוכים להכשרה או/ו התנסויות מספקות באזורי ה soft skills אשר יאפשרו להם השפעה משמעותית בארגון (על הנדבך הזה במקצועיות של כל אחד מהמהנדסים אני שם דגש משמעותי בהתפתחות האישית שלהם).
Process
כמה פעמים חשבתם על כך שאתם מבזבזים זמן יקר על משהו שיכול היה, וצריך היה להתנהל אחרת?
בין אם מדובר על תהליך העבודה (מישהו אמר דיילי / פלנינג / רטרו) ובין אם על התהליך הטכנולוגי - ניצול משאבי מערכת, יעילות ביצועי הקוד - בכל אלו מצופה שתשפיעו ותעירו כ- IC.
ה-CI/CD לא מספיק יציב? מושקע זמן יקר בייצוב תשתיות?
כמנהלים, תוכלו ותרצו לנתח את העבודה של גוף הפיתוח אותו אתם מנהלים, ללמוד מגופים אחרים ולחשוב באופן מתמיד מה צריך לשנות וליעל.
אתם גם תשפיעו על האופן בו פועל הארגון שלכם, על תהליכי התכנון ועל הבחירות האסטרטגיות של החברה.
ככל שתתקדמו בהיררכיה הניהולית בארגון, יעברו אט אט האתגרים מרמת המיקרו למאקרו, כמו גם יכולת ההשפעה שלכם. תוכלו לאתגר פרדיגמות מחשבתיות ישנות, להציע ולקדם פתרונות טכנולוגיים חדשים, לדחוף פיתוח של אזורים אותם אתם רואים קריטיים במוצר שלכם, ולשנות סדרי עולם באופן בו פועל הארגון שלכם.
עבורי זה פשוט מרתק.
מה אתכם?
------------------
יבגני מומבלט הוא Head of R&D בחברת gett ומנהל נלהב מהטכנולוגיה שאנשים יכולים ליצור, בבלוג תשובה לבלוג של שי משעלי ״למה קידום לא חייב לעבוד בניהול״
צפייה בוידאו 
האזנה לפרק 
קריאת הבלוג 
תשאלו אותנו הכל
