קודמתי לדרגת סיניור במיקרוסופט - מה למדתי בדרך

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

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

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

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

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

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

שלושת מעגלי ההשפעה

במיקרוסופט קידום מגיע אך ורק על בסיס אימפקט - האימפקט שעשית ימדד באמצעות:

- איך השפעתי על המוצר באופן ישיר באמצעות העבודה שלי

- איך השפעתי על מפתחים אחרים באמצעות העבודה שלי

- איך השתמשתי במה שמפתחים אחרים עשו כדי לייצר השפעה

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

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

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

הרחבת אחריות

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

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

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

הצד השני הוא נושא הניטור והאיכות של המוצר - התמקצעתי מאוד בנושא בשנים האחרונות ובתחילת הקריירה שלי ויש לי passion טבעי לשם. נוכחתי לדעת שהחשיבות שההנהלה רואה בניטור אקטיבי של המוצר ובהבטחת איכות של executable שיורד עם המערכת הפעלה (במיוחד אחרי מה שקרה עם crowdstrike) גרם לי להיות נקודה משמעותית בצוות ובקבוצה בתחום הזה.

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

מנטורינג

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

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

מע׳ יחסים עם המנהל הישיר

בחברה הקודמת בה עבדתי הייתה לי שיחה פתוחה עם ה VP R&D שאמר לי משהו שאני זוכר טוב עד היום - ״מנהלים תמיד יעדיפו עובד שהוא עזר ולא עובד שהוא נטל״. בהתחלה ישר עבר לי בראש ״thank you captain obvious", אבל אז התחלתי לשים לב לכמות עבודת הסרק שאני מייצר למנהל שלי, בין אם זה בתלונות על מפתחים אחרים בסיטואציות איתן יש לי את הכלים להתמודד בעצמי, בין אם זה בשיקולים טכניים נישתיים עליהם אני יכול להתייעץ עם אנשים אחרים וגם פשוט על ידי דיווחים שוטפים בציר לא מנוהל כמו slack או teams.

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

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

לסיכום

במיקרוסופט לפחות, הקידום מ mid-level ל senior, לא מצריך לרוב הברקות טכניות ולא נמדד בכמות שורות קוד, אלא בדגש על הרחבת scope האחריות ויצירת clarity למנהל שלי ולמנהלים שלו על ההישגים והאימפקט שאני עושה.