Individual Contributors: The Art of Leading Without Managing, Orit Wasserman & Shlomi Noach

בפרק הזה, ישי בארי, CTO ב LinearB מארח את אורית ואסרמן Distinguished Engineer ב Red Hat, ושלומי נח Engineer & Database Geek ב PlanetScale על איך נראה מסלול ה Individual Contributor כהחלטת קריירה, משני ICs ותיקים ומנוסים, ואיפה זה פוגש את ה engineering management בארגון.

In this episode, Yishai Beeri, CTO at LinearB, hosts Orit Wasserman, Distinguished Engineer at Red Hat, and Shlomi Noach, Engineer & Database Geek at Planetscale, who talk about their journey as individual contributors, the path of ICs as a career choice, and where this meets and impacts engineering managers.

Transcript

Episode Transcript תמליל הפרק

Hebrew, then English בעברית ואז אנגלית:

(מוסיקת פתיח)

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

ישי: בפרק הזה אני שמח לארח את שלומי נוח, מפתח ב PlanetScale ואת אורית וסרמן, Distinguished Engineer ב Red Hat, אהלן.

אורית: היי.

שלומי: אהלן.

ישי: איזה כיף שבאתם. 

שלומי: תודה שהזדמנת אותנו.

ישי: השקעתם, באתם מרחוק.

שלומי: כן, הגענו מהגליל, ברכבת. 

ישי: איזה כיף, תחבורה ציבורית עובדת. 

שלומי: במקרה זה הצליח.

אורית: כן, היום היה טוב.

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

שלומי: שמי שלומי נוח, אני מפתח, 24 שנים בתחום, )עשיתי הרגע את החשבון), עובד היום בחברת PlanetScale כמפתח, לפני זה ב GitHub כ-Principal Engineer ולפני זה בעוד חברות booking.com, Outbrain וכו', אני נשאבתי לעולם של דאטאבייסים. אני מפתח במקור אבל נשאבתי לעולם של דאטאבייסים ככה כי הייתי צריך לעשות משהו עם דאטאבייסים ונכנסתי מאוד חזק לתחום ובעצם ב-10-15 שנה האחרונות אני ממש סובב את העולם הזה, כותב גם אופן סורסים, פתרונות לעולם דאטאבייסים וגם עובד או על תשתיות או כמו שהיום, בחברה שלי, אני עובד על דאטאבייס כמוצר ממש. אז אני ממש סובב את העולם הזה. 

ישי: ממש עד רמת ה-DBA? או,

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

ישי: זו הנישה שלך.

שלומי: זו ממש נישה, כן. 

ישי: וואלה, תודה. אורית? ספרי לי קצת על ההתגלגלות שלך.

אורית: אז אני גם בתחום המון שנים, מעל 20, לא רוצה לספור. התחלתי כעתודאית, לא הכי ממליצה על המסלול אבל, ושירתתי ביחידה שהיום נקראת אופק, בחיל האוויר, אז זה היה ממד"ס, בפלמחים. ואני בתחום דומה לשלומי, אני גם אוהבת תשתיות אבל אפילו יותר נמוך ממה ששלומי עושה, זה נחשב מבחינתי, אני קוראת לזה middleware קצת יותר גבוה. הגעתי לזה במקרה, פשוט זה תמיד משהו שנמשכתי (אליו), רציתי לראות איך הדברים עובדים למטה, קרוב לברזלים, לחומרה, ולכן ככה לסטוראג' הגעתי במקרה. הייתי באיזשהו סטארטאפ סקיוריטי, הגיע המשבר של אלפיים ו-, מה זה היה? 2001? קוצצתי, וחיפשתי עבודה–ואהבתי C++ אז לינוקס, רציתי. אז מצאתי סטארטאפ בסטוראג' וככה הגעתי לתחום. כן היה לי הפסקה שעברתי לתחום יותר של ווירטואליזציה, עבדתי על KVM. אבל חזרתי לסטוראג' וזה מה שאני עושה בשנים האחרונות, מאוד אוהבת open source גם. גם לזה הגעתי במקרה, עם KVM, ומאז אני מאוד אוהבת open source וכל הלינוקס קרנל...כל הפרויקטים של ה-open source והקהילה, זה מאוד מדבר אליי גם. ואני חושבת שבסופו של דבר אני פשוט אוהבת את התפר הזה בין התוכנה לחומרה. 

ישי: מעולה, אז הנושא שלנו היום יהיה העולם של ה-individual contributor, שניכם בכירים שהתקדמתם במסלול כזה ואני רוצה קצת לחפור על איך זה עובד, איך זה נראה, איך בוחרים או נבחרים לדברים כאלה. אבל אולי נתחיל בלדבר על הפיל שבחדר, אתם שני בני זוג, שניכם individual contributors בכירים, איך זה להיות באותו עולם תוכן, מאוד קרוב ביום יום, 24/7, זה משנה משהו? זה בכלל לא קשור? העבודה נשארת בעבודה?

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

ישי: הדאטאבייס יכול להאשים את הסטוראג'...איזה שטויות את עושה עם הסטוראג' והדאטה.

שלומי: נכון, ממש, ממש ככה,

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

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

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

ישי: מצליחים לנצל את זה ללא יודע, כנסים משותפים ולנסוע ביחד?

אורית: כן, כן, כן, היינו עכשיו ברברסים.

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

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

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

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

שלומי: לגמרי מסכים, זאת אומרת הדבר הראשון שאני אוהב לפתח, זה משהו שמסב לי אושר, אם הכל מצליח אז זה מסב לי אושר, יש ימים טובים יותר וטובים פחות, אבל זה מה שאני אוהב לעשות ודרך הפיתוח אני מצליח להשפיע השפעה משמעותית על החברה, על הקהילה, על עולם ה-open source. זאת אומרת אפשר להגיע למרחקים מאוד גדולים. אני עובד כמפתח כבר שנים רבות, אם שואלים את השאלה הזאת של מה אתה רוצה לעשות עוד 5 שנים, השאלה הקלאסית כשאתה מצטרף לכל חברה, כן? התשובה נכון להיום ולאורך כבר 15 שנים זה אני רוצה להמשיך להיות individual contributor. פחות נמשך לניהול, בעברי הקמתי חברה, הייתי שותף לחברה וכל ההתעסקות הזאת בדברים שהם מעבר למוצר, לפיתוח, הדברים שהם, ניהול כוח אדם, בלשמר כוח אדם וכל הבעיות האלה של ניהול הן לא מדברות אליי. אני גם לא חושב שאני מאוד טוב בזה, אז אני מעדיף להישאר בחוזקות שלי ולעשות דברים שאני נהנה מהם. 

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

אורית: טוב, אני אוכל לענות, כי מאז שבאמת התקדמתי והפכתי להיות ארכיטקטית וכו' אז באמת הזמן לפתח קוד מאוד ירד, אפילו יותר מידי ירד. אני מאוד מתגעגעת לזה, זה משהו שאני מתלבטת איך אפשר להחזיר את הכמות שתהיה יותר טכנית, זה נכון שזה people, זה בהחלט להניע אנשים ולשכנע אותם בלי הסמכות של מנהל. כי אני לא יכולה להגיד למישהו תעשה את זה, אני צריכה שהוא ירצה לעשות את זה. ובהחלט זה מה ש-, זה יותר soft skill מאשר לא רק טכני, אבל זה קצת שונה כי עדיין אתה לא מנהל את האנשים מבחינת היום. אתה לא עושה, כאילו יש חברות ויש מחלקות אז יש people manager ויש tech lead, אז אנחנו עדיין נשארים ב-tech lead, כלומר אנחנו לא מנהלים את האנשים בקטע היותר של אנשים. כן יש דברים מאוד חופפים, אני מסכימה, אני בהחלט, אני אפילו מעודדת, כאילו עוזרת לאנשים להתקדם כאילו במובן שאני מדברת עם מנהלים בנושא מסלול קידום וזה משהו שגם מנהל אמור לעשות. אז אני עושה את זה למי שנראה לי שהוא צריך עזרה או שהוא ממש טוב. אני גם קובעת אסטרטגיה, אפילו לפעמים עושה החלטה על מה אנשים יעבדו, כך שיש בזה חפיפה. 

ישי: וכל ההתעסקות הזאת בעולם של ה-soft skill וה-people שנכנס לעבודה של מוביל טכני, זה necessary evil? או שזה חלק מה-, 

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

״יש דרכים שונות לייצר השראה ולהניע אנשים מאשר להיות בדרג ניהול״

ישי: ואומר עשיתם לא טוב, תשנו.

שלומי: לא, חס וחלילה. 

אורית: לא, זה אף פעם לא אומרים עשית לא טוב. זה למשל משהו שלומדים מאוד בהתחלה, אלא שואלים שאלות, אומרים אוקיי, מה עושים במקרה הזה ומה קורה אם ככה ומה אם נרצה להשתמש בזה למשהו אחר, ואז התשובה היא לא עשינו טוב, צריך לעשות אחרת. אבל כל ה-, נגיד ה-soft skill, אז, כללית ב-open source, בשביל להצליח, למרות שיש את הדימוי של Linus...שהוא לא בא עם soft skill חזק, כן צריך את ה-soft skill. אתה בד"כ לא יכול לבוא לקהילה של אנשים, במיוחד שגם התקשורת מאוד מאוד אסינכרונית, ולהודיע להם מה לעשות. אתה צריך ללמוד לשכנע, לדעת להסביר את עצמך, להסביר ארכיטקטורה, להסביר למה, להבין גם את המשתמשים. זה מאוד חשוב ואני לא חושבת שזה necessary evil, אני לפחות תמיד מאוד אהבתי שכשאני עושה משהו, שאני כותבת תוכנה, שמישהו בסוף ישתמש בה ויגיד וואלה, זה ממש עזר לי.

״אף פעם לא אומרים עשית לא טוב. זה למשל משהו שלומדים מאוד בהתחלה, אלא שואלים שאלות.״

(מוסיקת מעבר)

ישי: אז לאור זה שיש בכל זאת לא מעט מהזמן וה-attention הולך על מה שאני קורא לו people stuff, להניע אנשים בכל מיני שיטות, וברור שצריך להתמקצע בזה, אבל אלה לא מהלכים טכניים, זה לא כתיבה של קוד או ספריה או שיפור בארכיטקטורה אלא בוא נשכנע אנשים שזה נכון. בוא נניע אותם לעשות פריוריטי ואולי איכשהו להתמודד עם, יש להם לחץ לדלוור אבל אני מעיר להם על העובדה שאפשר לעשות את זה יותר טוב ואולי נקבל בחזרה benefits, אבל יש פה עבודת שכנוע, עבודה של people. לאור כל זה, אני חוזר לשלב של מישהו בקריירה שאומר רגע, אני חושב איך אני מתקדם, איך אני צובר ניסיון, credentials, מעמד, ואני מתלבט או מתלבטת בין ללכת לנהל אנשים לבין ללכת להשפיע כ-tech lead. בשתי האופציות אני נאלץ או צריך למנף people skills ולעשות דברים שהם לא קוד וממש טכני, אני חייב להישאר בקופסה הזאת של אני רק כותב קוד, אני מעיף output מעולה אבל אין לי שום השפעה, זה כנראה לא מחזיק מים. אז כיוון שבכל מקרה אני צריך להתעסק עם people skills, איך הייתם ממליצים למישהו לבחור? או להגיד זה מתאים לי? מתאים לי להשפיע ככה על אנשים ולא להשפיע ככה על אנשים?

שלומי: אני חושב שנכון שבשניהם צריכים people skills אבל people skills מנותבים למקומות מאוד שונים. בתור tech lead ובתור מנהל או מנהלת, אני חושב שכמנהל אתה צריך לענות לאנשים על שלל בעיות אישיות או התלבטויות מקצועיות שיש להם או, בכלל בעיות אינטראקציה בין חברי צוות או בין צוותים. ואלה דברים שאני כ- individual contributor לא מתעסק בהם ולא רוצה. כלומר אני לא, זה גם לשים את הפוליטיקה בצד וגם לשים את המרות בצד ולי זה לא עושה טוב ולכן לי זה די ברור שאני לא אהנה ולא אהיה מספיק טוב כמנהל של אנשים, לפחות בזמן הקרוב. מי יודע מה יהיה עוד 5 או 10 שנים? 

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

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

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

אורית: אני בלופ.

ישי: את בלופ, אוקיי, את תספרי לי קצת איך את פוגשת את ההחלטות העסקיות?

אורית: טוב, דבר ראשון האסטרטגיה והפריוריטיז העסקיות, זה גופים גדולים גם, אבל יש את כל ה-product manager, מה שקוראים ביזנס יוניט (business units), שהם מרקטינג וסיילס, שבהחלט יש להם גם נתונים. אבל אני בקשר עם ה-product manager, בקשר גם עם לקוחות מאוד גדולים, שומעת מה הם רוצים, עוקבת גם מבחינת התעשייה לאן היא הולכת ונותנת את האינפוטים שלנו ושלי וזה כן יכול לעשות שיפט בפריוריטי. חוץ מזה לפעמים אני שמה לב שאולי נגיד ה-product יותר מידי עסוקים במידי, יש משהו שצריך אולי לעשות קדימה כי זה מה שהתעשייה הולכת אליה, אז אני בהחלט עושה כזה מעין, בצד, או יש פרויקט או משהו שאפשר לקרב אותנו לזה כשנצטרך עוד שנתיים או משהו כזה. 

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

אורית: כן. 

שלומי: ואצלי הסיטואציה היא קצת מעניינת כי אני איש של פיתוח ודאטאבייסים ואני עובד בחברה שמייצרת Database as a Service שקהל הלקוחות שלנו הם מפתחים. כלומר אני ממש, אני בלופ של למי אני מייצר את המוצר ומה הם צריכים מהמוצר. אבל אני חושב שזה נכון באופן כללי גם בגלל שזאת חברה קטנה יחסית, יש 90 איש אם אני לא טועה נכון להיום. ופחות או יותר כולם מדברים עם כולם. וגם בגלל שאנחנו בעצם מצפים מהמפתחים והמפתחות שיהיו קצת יותר אוריינטד למה יהיה ה-user experience או מה באמת היוזר או הלקוח רוצה או רוצה לקבל, אז אני חושב שזה קצת מוטמע בתהליכי הפיתוח שלנו או בבחירה של על מה נעבוד. ולצד כל זה, וזה עוד דבר שאני מאוד אוהב לפנות אליו למנהל שלי, למנהל הישיר שלי, שיעזור לי בתיעדופים, כלומר יש לי רעיונות, יש לי הצעות, יש לי דברים שאני חושב שכדאי לשפר, צריך לשפר, והוא יבוא ויגיד לי מה נראה לו must ללקוחות הקיימים או must לצרכים שיש לחברה היום, מה יותר ידחוף את החברה קדימה בזמן הזה. 

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

שלומי: אז גם בחברה שלי היום, ב PlanetScale, גם בGitHub , זכיתי למנהלים שהם באו מהשטח, engineers שהפכו להיות מנהלים. וקודם כל יש להם את הראייה הטכנית והם מבינים את הצד הטכני של העניינים, וזה מאוד מאוד עוזר ומקל, לפחות עליי. אבל הם גם מאוד מאוד product oriented וגם customer oriented, אני חושב שמה שאני הכי אהבתי שהצטרפתי ל GitHub, המנהל שלי, ראש הצוות שלי בא ואמר לי נעים מאוד, אני סם, תחשוב עליי בתור הקונסיארז' שלך, אתה צריך משהו? תפנה אליי, חוץ מזה אני אפנה לך את הדרך ורוץ קדימה. 

ישי: הוא היה מנהל שהאחריות שלו הייתה באותו סוג? כאילו היררכיה של  individual contributor? או שהוא כבר ניהל קבוצה והיה לו...

שלומי: הוא כבר ניהל קבוצה, כמו גם המנהל שלי היום שהוא, בעצם אני reporting to the VP R&D של החברה, לא משנה הטייטלים. זאת חברה קטנה, אבל המנהל שלי הוא בעצם VP והוא מתעסק בכל דבר שהוא בחברה, אז אפשר להגיד שהוא גם בא מהעולם הזה של ה-IC אבל הוא בהחלט היום מתעסק יותר ב-product ולקוחות.

(מוסיקת מעבר)

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

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

ישי: איך IC מודד את עצמו? בסוף הוא מול המנהלים שלו, יאללה עבר רבעון, מה ה-goals, ה-OKRs, מה, איך ניגשים לזה בכלל?

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

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

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

(מוסיקת מעבר)

ישי: אני רוצה לשאול אתכם איך זה, בעיניים שלכם, מה צריך מנהל שעובד עם IC's, אתם תיארתם מצב של מנהל של יחידה או קבוצה, מנהל engineers, מנהל אולי אנשי product, ויש לו IC's בכירים שעוזרים לו בעצם להוביל את הצד הטכנולוגי. מה חשוב למנהל כשהוא עובד עם מישהו בכיר בעמדה כזאת של IC, מה חשוב לו לעשות ולא לעשות.

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

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

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

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

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

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

ישי: אוקיי, אז זה לא נגמר כשאתה נהיה IC בכיר, לאותם אלה שקשה להם, זה ממשיך להיות קשה. 

שלומי: כן (צוחק)

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

ישי: אני רוצה רגע לדרוך בשדה מוקשים, בעולם של פיתוח כלל ואולי גם, תגידו לי אתם, בעולם של הסניורז וה-IC's, מידת הנוכחות של גברים, נשים, וגם איפה אתם, אם אתם רואים שזה משפיע על יכולת ההשפעה, יותר קל לגברים אולי להשפיע כי הם נתפסים באופן ראשוני כבעלי יותר סמכות, אני לא יודע, אני יודע שהעולם הזה הוא זז, אבל הוא עדיין בבעיה, אני רואה את זה בארגוני פיתוח, הם לא מאוזנים והקידום הוא לא תמיד מאוזן, אז איפה זה פוגש את העולם של ה-IC's?

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

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

שלומי: נכון.

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

שלומי: אז האמת שאופי העבודה שלנו מאוד שונה, אורית עובדת יותר בזום, אני כמעט ולא, למעשה לפני שבועיים-שלושה המנכ"ל שלנו הוציא איזה ממו בבלוג הפנימי של החברה שהוא שם לב שאנחנו יותר מידי, שיש יותר מידי ישיבות ונא לצמצם. אצלנו פחות מאמינים בישיבות, אני חושב שזה מאוד מאוד תלוי באמת כמה אינטראקציה חייבת להיות לך עם עוד בני אדם ועד כמה האנשים שאתה עובד איתם פתוחים לרעיון הזה שאתה עובד remote, שאתה נמצא ב-time zone אחר וכו'. אני זכיתי לעבוד גם ב GitHub, גם ב PlanetScale בחברות שבהן זה first class citizen remote, first class, כלומר אין הנחה שאתה תהיה זמין בשעה מסוימת, אני עכשיו פה מקליט באולפן, זאת גם שעת עבודה. יכול להיות שמישהו כרגע נותן לי פינג, אבל אף אחד לא מצפה ממני שאני אענה בדיוק ברגע הזה. אצלי באמת העבודה היא כמעט לגמרי אסינכרונית, כלומר רוב הזמן אני עובד solitaire, מידי פעם מצ'וטט או בסלאק או לפעמים במפגש זום, אבל רוב הזמן אני באמת לבד ולא זקוק לתקשורת בינאישית בשביל להניע אותי קדימה. מידי פעם יש מקומות שנתקעים ואז מנסים להסתנכרן. 

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

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

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

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

שלומי: נכון.

ישי: אתה בחיסרון, אם אתה בזום וכולם ב-, ליד איזה שולחן,

שלומי: אני מסכים.

ישי: אז איך פותרים את זה או איך ניגשים לזה?

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

ישי: ועם הידיים.

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

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

אורית: קשה (צוחקת)

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

אורית: זה לא משנה נראה לי המסלול, soft skills, צריך לעבוד על soft skills, לא להזניח את זה,

ישי: אי אפשר לברוח מזה, אה?

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

ישי: שלומי ואורית תודה רבה.

שלומי: תודה רבה.

ישי: היה מצוין, תודה שבאתם.

שלומי: כיף שהיית כאן.

אורית: תודה רבה, היה נורא כיף.

(מוסיקת מעבר)

היכנסו ל-devinterrupted.com להירשם, תוכלו למצוא שם גם את כל הפרקים שלנו באנגלית. אני מזכיר לכם שאנחנו ב-LinearB. בצמיחה מהירה מגייסים למגוון של תפקידים בכל התחומים. בואו ל-linearb.io/careers למצוא את האתגר הבא שלכם. אני ישי בארי, נשתמע בפרק הבא.

(מוסיקת מעבר)

** לינקים לקהילות שהוזכרו בפרק - כאן.**

Yishai:         Welcome to “Dev Interrupted", LinearB's podcast which discusses everything that hinders the daily work of engineering managers. I'm Yishai Beeri, CTO at LinearB. We are happy to bring you the podcast in Hebrew where we host leaders in the industry to talk about everything that interests engineering managers, those who work with them, and those who want to one day manage an engineering organization.

Yishai: In this episode I am happy to host Shlomi Noah, developer at PlanetScale and Orit Wasserman, Distinguished Engineer at Red Hat, hello.

Orit: Hi.

Shlomi: Hello.

Yishai: What a pleasure to have you.

Shlomi: Thank you for giving us the opportunity.

Yishai: You invested in us, you came from afar.

Shlomi: Yes, we came from the Galilee, by train.

Yishai: What fun, public transport works.

Shlomi: In this case we succeeded.

Orit: Yes, today was good.

Yishai: Nice. So as always, I like to ask my guests to tell me in a few words how you got to this point, Shlomi, let's start with you.

Shlomi: My name is Shlomi Noach, I am a developer, 24 years in the field, (I just did the math), I work today at PlanetScale as a developer, before that at GitHub as a Principal Engineer and before that at other companies, booking.com, Outbrain, etc. I was attracted to the world of databases, I'm originally a developer but I was drawn to the world of databases because I had to do something with databases and I entered the field very strongly and in fact in the last 10-15 years I've been really involved in this world, writing also how to deliver solutions to the world of databases and also working either on infrastructures or as today, in my company, I work on a database as a real product. So I literally focus on this world.

Yishai: Right up to the DBA level? or,

Shlomi: Yes, yes, I mean for several years I was actually the DBA of my company, because there was no DBA and that's how I was exposed, but because I'm also a developer in orientation, so actually how these two worlds connected and the things I deal with today is precisely this connection between the world of development for the database, because there is a big black hole that needs to be filled. The interfaces and integrations are filled with friction, the whole way of operating and integrating with databases is usually unpleasant and there is a lot to be done in this area.

Yishai: This is your niche.

Shlomi: It's really a niche, yes.

Yishai: Well, thank you. Orit? Tell me a little about your evolution.

Orit: So I've also been in the field for many years, over 20, I don't want to count. I started as an Atuda soldier, I don't highly recommend the path, though, and I served in the unit that today is called Ofek, in the Air Force, so it was from M”MDS, in Palmahim. And I am in a similar field to Shlomi, I also like infrastructure, but even at a lower level than what Shlomi does, it’s considered as far as I am concerned, middleware a little higher. I came to this world by accident, it's just always something I was drawn (to), I wanted to see how things work down below, close to the irons, to the hardware, and that's how I came to storage by accident. I was at some security startup, the crisis of Y2K came and , what was it? 2001? I was cut, and I was looking for a job–I liked C++... so Linux. So I found a startup in storage and that's how I got into the field. Yes, I had a break where I moved into more of a virtualization field, I worked on KVM. But I came back to storage and that's what I’ve been doing in recent years. I really like open source as well. I came to this too by chance, with KVM, and since then I really like open source and the whole Linux kernel...all the open source projects and the community, it really speaks to me too. And I think that in the end I just love this intersection between the software and the hardware.

Yishai: Excellent, so our topic today will be the world of the individual contributor, you are both seniors who have progressed on such a path and I want to dig a little deeper into how it works, what it looks like, how you choose or are chosen for such a journey. But maybe we'll start by talking about the elephant in the room, you are spouses, both of you are senior individual contributors, how is it to be in the same content world, very close every day, 24/7, does it make a difference? It's not related at all? Does work stay at work?

Shlomi: It matters a lot, we have a lot of conversations about work, a lot in common, luckily we are somewhat in similar fields because really sometimes it's like that,

Yishai: The database can blame the storage...what nonsense are you doing with the storage and the data.

Shlomi: Right, really, really like that,

Orit: Yes, so the girls sometimes laugh on car trips, they hear our conversations and they don't understand what we are talking about. There are advantages to this because the world is, like when I have a bad day at work and I come to Shlomi to vent, he can totally understand what I mean. Yes, of course, you have to keep boundaries, not get into technical conversations too much, and also save time for other things.

Shlomi: There are sometimes conversations in the evening that really don't go in the right direction, it's (laughing) when we get into Kubernetes and hypervisors. I tell Orit–– stop, I can't continue (laughing).

Orit: But for us, it works. My brother-in-law once said why not open a startup together, but that seems to me like it would be a bit too much.

Yishai: Do you manage to take advantage of it for joint conferences and travel together?

Orit: Yes, yes, yes, we were at Reversim now.

Shlomi: Yes, exactly, two weeks ago we were at the Reversim conference together, we went to FOSDEM together, but most of the conferences are not together, there are conferences specific to storage and there are conferences specific to databases, and we also keep our distance.

Orit: Yes, also, today they are older, but when they were little one parent had to stay and then we wouldn't travel together.

Yishai: Excellent. So, individual contributors, I now want to touch a little on the question first of all both from your experience and for those who might be listening to us and thinking what is my path, how do I want to move forward? So there is always this choice for someone who already deserves a promotion or is gaining some experience, am I going to be a manager, am I going to manage people or am I going to advance and influence and gain experience as a developer, as a senior developer, as an architect––this whole world of individual contributor? So tell me a little bit about the point you had and maybe a dilemma or how you chose or how you were led in these directions.

Orit: Well, in the army I was at first a developer, then I was a team leader, and after that, after I was discharged, I said I didn't want to be a team leader again. Especially in the army it seems to me that it was a position with a lot of bureaucracy and not easy, and I don't think that throughout my career I really made the decision. It's just always been - I've always been more attracted to the technical field, it's also a field that challenges me more, I'm also good at it. I think as a manager I'll be fine, but as an IC I'm really, really good and really enjoy it, which is the most important.

Shlomi: I completely agree, I mean the first thing I like to develop is something that brings me happiness, if everything works out then it brings me happiness, there are better days and less good days, but this is what I like to do and through development I manage to have a significant impact, on the community, on the open source world. This means that you can reach very large distances. I have been working as a developer for many years. If you ask this question of what do you want to do in 5 years, the classic question when you join any company, yes? The answer is as of today and for 15 years now, I want to continue being an individual contributor. I am less attracted to management. In the past I founded a company, I was a partner in a company and all this dealing with things that are beyond the product, development, the things that are, personnel management, retaining personnel and all these problems of management do not speak to me. I don't think I'm very good at it either, so I prefer to stick to my strengths and do things I enjoy.

Yishai: I want to challenge a bit what you said, you actually said we like to focus on the technical content, on the umbrella, but when an individual contributor becomes a senior, the form of their influence in the end is not in lines of code but in, well, let's talk about architecture. Let's talk about how to do things, in what order we will roll out this capability or the infrastructure, so that the work will be both effective and in the end we will deliver the product, and a significant part of everything I talked about goes back to the people. Because you can talk until tomorrow about architecture––but you have to motivate people to do the right thing, you have to give them feedback that they did the wrong thing, it's just like managing people at the HR level, so where, how do you manage to do it without spending,  quote / unquote , time on the people stuff.

Orit: Well, I can answer, because since I really progressed and became an architect, etc., then really the time to develop code has decreased a lot, even too much. I miss it very much, it's something I'm debating how to bring back, to an amount that would be more technical. It's true that it's people, it's definitely motivating people and convincing them without the authority of a manager. Because I can't tell someone to do it, I need them to want to do it. And that's definitely what -, it's more of a soft skill and not only technical, but it's a little different because you still don't manage the people in terms of today, you don't. Like there are companies, and there are departments so there is a people manager and there is a tech lead, so we still remain in tech lead(ership), meaning we don't manage the people. Yes, there are highly overlapping things, I agree, I definitely do, I even encourage, and help people to advance, in the sense that I talk to managers about a promotion track and this is something a manager is also supposed to do. So I do it for whoever I think needs help or is really good. I also set strategy, even sometimes decide what people will work on, so there is an overlap.

Yishai: And all this messing around in the world of soft skills and the people who go into the work of a technical leader, is this a necessary evil? or is it part of the

Shlomi: No, not with me, I mean I think there are simply different ways to inspire and motivate people than being in management. That is, for me, in my opinion of what an individual contributor in a senior position in an organization is, knowing how to identify problems and knowing how to offer solutions. And these solutions are good for everyone. That is, everyone is happy when these solutions arrive and everyone is happy to commit to them, and when you see that something is successful, it generates very, very high engagement. When you release something to open source, when you talk about it at a conference, it generates engagement. People like it, enjoy working with it, of course you have to be a pleasant person, and know how to talk to people and respect people and appreciate people as every manager must know. Every person who talks to another person should know how to give feedback and give a kind word, but it doesn't have to come from a place of management, I think that if there is something that I usually need help with or ask my manager to give me, it's actually the validation and backing to come and talk to another team. And basically it should be clear that I'm coming and I'm taking up a bit of their time, that if I'm going to talk to them then it's not like they're going to feel like I fell on them out of nowhere, who is this developer who now wants us to do something for him - but it's going to be good. That is, to help me to prepare the ground so that I will not be portrayed as this Principal who comes and assigns tasks to me.

Yishai: And says you did not do this well, change it.

Shlomi: No, God forbid.

Orit: No, we never say you did not do well. This is, for example, something that you learn a lot at early on, that you ask questions, you say okay, what do we do in this case and what happens if this is the case and what if we want to use it for something else, then the answer is we didn't do this well, we need to do it differently. But all the, let's say the soft skills, then, generally in open source, in order to be successful, even though there is the image of Linus... that he doesn't come with strong soft skills, you do need soft skills. You usually can't come to a community of people, especially since the communication is also very, very asynchronous, and tell them what to do. You have to learn to convince, know how to explain yourself, explain architecture, explain why, understand the users as well. This is very important and I don't think it is a necessary evil, at least I've always really liked that when I do something, that I write software, that someone will use it in the end and say voila, it really helped me.

(transitional music)

Yishai: So in light of the fact that still quite a bit of time and attention go to what I call “people stuff”, motivating people through all kinds of methods, and it is clear that you need to specialize in this, but these are not technical capabilities, it is not writing code or a library or improving the architecture, but rather let's convince people that it's right. Let's motivate them to make it a priority and maybe somehow deal with the pressure they have to deliver, but I remind them of the fact that it can be done better and maybe we will get back benefits, but there is work of persuasion here, work with people. In light of all this, I return to the stage of someone's career who says wait, I think about how I progress, how I gain experience, credentials, status, and I am debating or debating between managing people and going to influence as a tech lead. In both options I am forced or have to leverage people skills and do things that are not code and really technical, I have to stay in this box of I just write code, I throw out excellent output but I have no effect, it probably doesn't hold water. So since I have to deal with people skills in any case, how would you recommend for someone to choose? Or say this suits me? Is it appropriate for me to influence people like this and not influence people like this?

Shlomi: I think it is true that both need people skills, but people skills are directed to very different places. As a tech lead and as a manager, I think that as a manager you have to support people with a lot of personal problems or professional doubts they have or, in general, interaction problems and conflicts between team members or between teams. And these are things that I, as an individual contributor, do not deal with and do not want to deal with. I mean I don't.  For me, it's both putting politics aside and putting authority aside, and it doesn't do me any good. So it's pretty clear to me that I won't enjoy it and I won't be good enough as a manager of people, at least in the near future. Who knows what will happen in another 5 or 10 years?

Yishai: Okay, so at the end of the day the point is whether I want or enjoy dealing with solving people's problems such as promotion paths, such as conflicts, if not then I should probably aim in the direction of tech lead, if I'm trying to summarize.

Shlomi: I think so if you don't want to, if you're not looking to be someone who solves people's problems, then you shouldn't at this point, because these problems will come and they need, they need a solution.

Yishai: Okay. There is another area where managers are involved, and maybe this makes the role of a manager a little different from a tech lead, and it is precisely on the sides of the so-called business priorities. At the end of the day, a manager of an engineering organization, in addition to handling people, also handles products and priorities, it will work this way, it will enable a this business move or business progress in one way or another, and sometimes the tech lead is less in this loop or, you tell me.

Orit: I'm in the loop.

Yishai: You're in the loop, okay, will you tell me a little about how you are involved with the business decisions?

Orit: Well, the first thing is the strategy and the business priorities, these are large entities as well, but there are all the product managers, that are called business units, which include marketing and sales, that definitely also have data points. But I am in contact with the product manager, in contact with very large customers as well, I hear what they want, I also follow the industry where the trends are going and provide input and this can influence a shift in priority. Apart from that, sometimes I notice that maybe the product is too busy, there is something that maybe needs to be done going forward because that's where the industry is going to, so I definitely do stuff like that, on the side, or there's a project or something that can bring us closer to a certain goal that we’ll need in another two years or something like that.

Yishai: So you say, for you, it’s definitely in the scope to work on business priority and how I will build infrastructure that will allow me to seize business in the future.

Orit: Yes.

Shlomi: And for me the situation is a bit interesting because I am a developer and database person and I work for a company that produces a Database as a Service where our customers are developers. I mean I'm really, I'm in the loop of who I'm making the product for and what they need from the product. But I think it's true in general also because it's a relatively small company, there are 90 people if I'm not mistaken as of today. And more or less everyone talks to everyone. And also because we actually expect the developers to be a little more oriented to what the user experience will be or what the user or the customer really wants or wants to receive, so I think it is somewhat embedded in our development processes or in the choice of what we will work on. And besides all this, and this is another thing that I really like to turn to my manager, my direct manager, to help me with priorities, that is, I have ideas, I have suggestions, I have things that I think should be improved, need to be improved, and he will come and tell me what he thinks is a must for the existing customers or a must for the needs the company has today, that will push the company forward at this time.

Yishai: This really raises an interesting point, and maybe we will talk about the differences between how IC influences a startup or a small company, versus a very large company. You talked about your manager. I'd like to  ask whether your managers are people from the same discipline, that is, a technical leader. Let's say a chief architect who manages architects, or maybe in a small company, the manager is already a business manager, who has the IC who works with him, who helps him move things.

Shlomi: So even in my company today, at PlanetScale, also at GitHub, I had managers who came from the field, engineers who became managers. And first of all they have the technical vision and they understand the technical side of things, which is very, very helpful and easy, at least for me. But they are also very very product oriented and customer oriented, I think what I liked the most when I joined GitHub, my manager, my team leader came and said “nice to meet you, I'm Sam, think of me as your concierge, do you need anything? Turn to me, otherwise I will clear the way for you and you run ahead.”

Yishai: Was he a manager whose responsibilities were of the same type? Like a hierarchy of individual contributors? Or he already managed a team and had...

Shlomi: He already managed a group, as well as my manager today, who is actually reporting to the VP R&D of the company, regardless of the titles. It's a small company, but my manager is actually a VP and he deals with everything in the company, so you can say that he also comes from this world of the IC, but he definitely deals more with product and customers these days.

(transitional music)

Yishai: So let's talk a little about how, what are the tools of an individual contributor to influence. They don't have a rank in most cases of “I decide and that's it” and I tell you what to do, they also don't control the resources in most cases, the people or the developers, let's now put three people on a project. So what are the main tools for influence? How do I end up making things happen?

Orit: Communication first. There are all kinds of levels, if it's higher levels, then really show, many times the research before, to find proof, not to come empty-handed and say “just because”. And show, sometimes, even do a demo or POC, and demonstrate how this will work. If it's someone outside of our product, another product, then it's either contact the engineering and work together with them and that's how a relationship is created. It's a lot about relationships in the end, like above also downwards. I mean if one day I come to some group of developers and I tell them this is what needs to be done, it won't work, you need to be a known person. So I also introduce (the solution) to the whole group, give enrichment lectures in all kinds of fields, update on what is being done strategically, in which directions the industry is going. I do code reviews, I also try to sometimes join engineering meetings and give my opinion, and most importantly help and create a relationship.

Yishai: How does IC measure itself? At the end, when they are  in front of their managers, come on, it's been a quarter, what are the goals, the OKRs, what, how do you even approach it?

Orit: I sometimes look, especially now, that I don't get to write much code, so it was very difficult for me to measure my contribution. So I just look at things that I was involved in and what happened in the end, and things that I decided I didn't have time for, so I didn’t get involved or I let them go. Which by the way is a difficult topic, deciding to let go, when there are many things to do. And I see that somehow the things I'm involved in are successes. First of all, many times the projects are completed, they end successfully, the client is satisfied, everyone is satisfied, on time, which is something very rare, so this is probably the proof actually.

Shlomi: And I think this is also the role of my manager, I mean I'm ultimately a human being and I need someone to give me positive feedback. There are good times when I feel I really delivered something that improved the product, solved a problem, I don't know what, improved the service, improved the product, and it's clear to me that it’s visible. Something new came out and we're all happy, and there are times I don't know, I worked a little on infrastructure here, infrastructure there, I solved some kind of bug here, I didn't feel like I was riding some kind of wave anymore. And I talk to my manager, telling him listen, lately, in the last few months, I’m feeling my delivery was weak. He tells me what are you talking about? Look, people like to work with you, you solved a problem with a client, right, it seems like a small problem to you, but this client is a big client and within 3 days the problem was solved, so the client is satisfied, they could have left us. And this feedback that comes from external sources is very important and really helps me to evaluate myself.

"Feedback that comes from external sources is very important and really helps me to evaluate myself."

Orit: Yes, especially in open source, which is another nice thing, it's not just your manager, you see what the community thinks of you and how they react, so you also have another source of feedback - which is cool.

(transitional music)

Yishai: I want to ask you what it is like, in your eyes, what does a manager who works with ICs need, you described a situation of a manager of a unit or group, a manager of engineers, maybe a manager of product people, and they have senior I's who actually help them lead the technological side. What is important for the manager when they work with someone senior in such an IC position, what is important for them to do and not do?

Orit: Well, I'll say what's important to me, so what really characterizes me throughout my career, I need them to give me a lot of freedom. A few years ago a manager micromanaged me, it turns me off, drives me crazy, I can't. I need them to give me autonomy, to trust me, and then the results are amazing. And I think this is true for all ICs, I think especially ICs, if you manage them too closely, you will actually lose all their advantages. Because their advantage is their ability to lead things, grow things and see things that you as a manager probably don't see, so it's important to give them the freedom to decide what's important. That’s all.

Yishai: It's true to say that senior ICs because of their strengths, may have a blind spot to questions of politics or what they’re stuck on, their ability to flag stuff for their manager and say free me up because this is what I'm stuck on.

Shlomi: There are those who do it great, naturally, I personally don’t.

Orit: I do it naturally, me, if I need help I just ask. I don't wait for the manager to help me, but I usually either solve it or ask, even go to the product, ask them to move things I'm stuck on, it's a matter of character. There are ICs that will just come, either they will manage to do so on their own, or they know how to ask, there are those who -, this is generally true, there are those who need help. In terms of organizational politics, sometimes the manager can't help, or the manager, and specifically the ICs, as if we say it's a large organization, so you can suddenly talk to another product, another business, precisely that the two ICs of these groups can solve the problem better than if they go through an administrative way, that is precisely because it is engineering to engineering, it is solved, and the relationships actually improve some kind of political problem. So it doesn't always have to be the other way...

Yishai: I understand, but at least the manager should be aware that not all ICs know how to communicate in the most effective way what they are stuck on and sometimes you have to be proactive.

Orit: That is true for every developer, there are those who don't know how to say they are stuck and there are those who will manage on their own and even notify before and...

Yishai: Okay, so it doesn't end when you become a senior IC, for those who find it difficult, it continues to be difficult.

Shlomi: Yes (laughs)

Orit: I think with experience you learn what works for you, what doesn't, what are your strong points, what are the less strong points, and a good manager knows how to work with them and actually improves your skills, strengthens you in your weaknesses and channels your strengths.

Yishai: I want to tread a minefield for a moment, in the world of development in general and maybe also, you tell me, in the world of seniors and ICs, the extent of the presence of men, women, and also where you are, if you see that it affects the ability to influence, it is easier for men to maybe have an impact because they are primarily seen as having more authority, I don't know, I know that this world is evolving, but there is still trouble. I see it in engineering organizations, they are unbalanced and promotions are not always balanced, so where does it meet the world of the ICs?

Orit: Well, this one’s for me (laughing). So this exists, it's very noticeable, like especially largely because of the like the percentage of women beforehand, even already at the entry into the industry is lower and of course over time. So, yes, there are differences. For example, I will talk about, of course, the fact that I say that I am a distinguished engineer so I have to give my title up front. I think if I were a man I could just say I'm something, I'm just a developer, but when it comes to someone who doesn't know me, it helps me a lot to say my title, which is a very senior technical one, and that already gives me a bit of a better starting point in the conversation . But I definitely start conversations many times today with people I don't know by self-introduction, which men don't need to do, so that they understand who they are talking to and that I am technical and I know, this means that this also happens to me with clients, unfortunately. Clients who know me listen to me straight away, but in the beginning there is a period when they have to be convinced so that they understand who is speaking, I just had a client from Turkey, which is probably culturally related, where it was very difficult with them and they didn't listen to me, but in the end they realized their mistake after they suffered and realized, I was right and now everything is fine, but it took a lot more effort and I'm pretty sure the gender issue was related.

Yishai: So maybe in the end we'll go back home a bit, two spouses who work in the same field, and besides in similar positions of technological leadership that work fully remote, long before COVID, you told me that you actually work in this remote mode with international teams.

Shlomi: True.

Yishai: A little about the mechanics of it, where does it work better, less well, what is life like for someone who lives in the Galilee and works in technology in depth, all day on Zoom? I don't know, tell me a little about how it is, two in the same house.

Shlomi: So the truth is that the nature of our work is very different, Orit works more on Zoom, I hardly ever do. In fact two or three weeks ago our CEO put out a memo on the company's internal blog that he noticed that we are doing that too much, that there are too many meetings and we want to cut back. They believe less in meetings. I think it really depends on how much interaction you require with other people and how open the people you work with are to this idea that you work remotely, that you are in a different time zone, etc. I also had the privilege of working at GitHub, also at PlanetScale in companies where remote work is a first class citizen, first class, meaning there's no assumption that you'll be available at a certain time. I'm here right now recording in the studio, that's also work time. Maybe someone is pinging me right now, but no one expects me to answer exactly at this moment. For me, the work is almost completely asynchronous, that is, most of the time I work in solitary mode, occasionally chatting or in Slack or sometimes in a Zoom meeting, but most of the time I am really alone and do not need interpersonal communication to move me forward. From time to time there are places that I get stuck and then try to sync.

Orit: Yes, so unfortunately I'm not like that anymore, I have many meetings as Shlomi said, so we used to be in the same office, but now he is no longer willing to be with me. (laughs) He says that I have too many meetings and it bothers him, so I got the office, it's mine (laughs). No, it's not really mine, we have two desks, but we don't work at the same time because I have a lot of meetings, plus that's why we have another excellent setup and workstation in the bedroom, where the desk is fully stocked.

Shlomi: But it is abandoned, I usually sit on the balcony with a cup of coffee and program in front of the view.

Orit: Yes, Shlomi likes to sit on the balcony, I envy him, but somehow I like working at the table, I like a framework more.

Yishai: And there is the, you said there is no expectation that I will be available at any moment, but sometimes there is a situation where okay, the other people are not that remote and then the one who is remote is at a disadvantage, okay, everyone is in, I don't know what, an office , and someone joins the meeting remotely.

Shlomi: True.

Yishai: You're at a disadvantage, if you're in Zoom and everyone else is at, at some table,

Shlomi: I agree.

Yishai: So how do we solve it or how do we approach it?

Shlomi: It's very difficult, when you're the exception to the group, it's very difficult, especially if it's an Israeli company or an Israeli group where it's natural, in our nature, in our culture, to talk and to chatter in the hallway, in the kitchen, etc.

Yishai: And with our hands.

Shlomi: With our hands, right (laughs) and then you lose something, that's right. There must be a commitment from the rest of the team, ok, it's impossible for them not to talk, but things need to be written down or things need to be formalized, and if that doesn't exist, then in my opinion there won't be symmetry and it will really be very difficult. You'll be some kind of outsider, half guest. It's still workable but you won't be in the same position as other people. If everyone agrees to this commitment to formalize things, write things down, share issues, pull requests, internal memos, no matter what, then the integration is much more authentic and you yourself can respond in the same language, write things, etc. and share your knowledge with them and reach a little more symmetry.

Yishai: To wrap up, do you have one tip, one thought, for an IC at the start of their journey? What they should pay attention to, how, what to do, what not to do, one thing that you would like to contribute as a tip to someone who is starting their career and thinking about how I become a leading IC?

Orit: Hard (laughing)

Shlomi: Promotion is not necessarily a managerial track, it is possible to make an impact in development, it is possible to make an impact in sharing knowledge, it is possible, there are many ways to make a significant impact on a company, one that is valued, one that receives good feedback, without reaching the managerial stage, and perhaps this is the basic thing to start with .

Orit: It doesn't matter, I think the track you choose, SOFT SKILLS are key, you should work on soft skills, not neglect them.

"It doesn't matter, I think the track you choose, SOFT SKILLS are key, you should work on soft skills, not neglect them."

Yishai: You can't run away from it, eh?

Orit: You can't run away, especially we also have to remember that in the end we are writing software that should be sold, so remember the user who pays us in the end and also look at their needs.

Yishai: Shlomi and Orit, thank you very much.

Shlomi: Thank you very much.

Yishai: It was excellent, thank you for coming.

Shlomi: I'm glad you were here.

Orit: Thank you very much, it was a lot of fun.

(transitional music)

Go to devinterrupted.com to subscribe, you can also find all our episodes in English there. I remind you that we at LinearB are in rapid growth and are recruiting for a variety of positions in all fields. Visit linearb.io/careers to find your next challenge. I'm Yishai Beeri, we'll hear from you in the next episode.

(Closing music)

Links to the nifty tools and resources mentioned in the episode:

• Red Hat
• PlanetScale
• Reversim
• FOSDEM