Is the VP Engineering Just a Glorified Project Manager?, Adi Shacham-Shavit

בפרק הראשון של פיתוח בהפרעה ישי בארי, CTO ב LinearB מארח את עדי שחם-שביט. היא  תדבר על המגמות, הטכנולוגיות, התרבות והכילים אשר שינו את פני התעשיה במהלך ה 20 שנה שהיא מנהלת פיתוח בחברות מובילות מ Liveperson ל AppsFlyer, Lemonade, והיום SVP Engineering ב Transmit Security, ו co-founder ב Leap המכשיר מנהלי.ות פיתוח לאתגרים של scale-up בצמיחה מהירה.

In our first Hebrew episode of Dev Interrupted, Yishai Beeri, CTO at LinearB hosts Adi Shacham-Shavit.  She will talk about the different trends, technologies, culture, and tools that changed the face of the industry over the course of the past 20 years, where she served as an engineering leader at some of the hottest Israeli companies from Liveperson to AppsFlyer, Lemonade and today is SVP Engineering at Transmit Security and co-founder of Leap--the program to help engineering leaders in scale-ups handle the challenges of rapid growth.

Transcript

Episode Transcript תמליל הפרק

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

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

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

אני ישי בארי, CTO בליניאר בי.

(מוזיקה)

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

בפרק הראשון אני שמח לארח את עדי שחם שביט, אחת המנהיגות המנוסות בתעשייה, קו-פאונדר של "LEAP", תוכנית למנהלי פיתוח ו- SVP R&D בTransmit Security.           ועכשיו נעבוד לראיון המלא.

(מוזיקה)

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

עדי: אז אני מאוד מתרגשת להיות אורחת ראשונה, אני הרבה שנים בתעשייה, עשיתי כל מיני תפקידי פיתוח ואחרי זה הגעתי לLiveperson בשלב שהיא הייתה חברה קטנה של 60 איש ועשיתי שם לא מעט תפקידים, עד שעזבתי כשהיו 900 ואחרי זה עשיתי סוויץ' מאוד דרמטי ועברתי לAppsflyer בתור הבן אדם העשירי בחברה, באתי להקים ולנהל את הצוות פיתוח אבל בעצם היינו ארבעה אנשים בכל הצוות, במהלך שלוש וחצי שנים שהייתי בחברה הצוות גדל ל-70 איש, המערכת גדלה מלטפל ב-200,000,000 איוונטים ביום ל -20 מיליארד, ידענו לתת עוד ועוד value מעל אותו דאטה שאספנו והחברה מאוד מאוד גדלה והתפתחה, זה היה גם התפקיד ניהול פיתוח הראשון שלי, נחזור לזה אחרי זה ואני אספר קצת יותר למה בכלל הלכתי לעשות את זה, חזרתי לנהל את הפיתוח בLemonade, הגעתי בשלב יותר מתקדם אחרי Round B לקחתי גם את התפקיד של הפיתוח וגם את התפקיד של הacting CISO, דאטה, Privacy, רגולציה, יציאה אחרי זה לאירופה, חזרתי לנהל את הפיתוח בסטארט-אפ בשם Clear שעושה מערכות של Settlement ו- Reconciliation בין ארגוני אנטרפרייז גדולים ע"י יצירה של רשת של בלוקצ'יין פרטית ביניהם ולפני שנה וחצי הקמתי פורום של מנהלות פיתוח בכירות בארגון שנקרא "באות" ולפני שנה הקמתי ביחד עם מירי קוריאל שהיא השותפה שלי תוכנית למנהלי פיתוח בסטארט-אפים בשלבים של סקייל-אפ בשם "LEAP" ולפני ארבעה חודשים הצטרפתי לטרנסמיט סקיוריטי.

ישי: וואו! ובטרנסמיט את ?SVP R&D 

עדי: נכון 

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

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

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

עדי: וואי היה מלא.

ישי: אנחנו אוהבים כישלונות מפוארים.

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

ישי: וזה משהו שאפשר ללמד? את ההבנה, את התחושה הזו שאני לא רק מייצר פיצ'רים אלא אני צריך להיות יותר מחובר להנהלה זה משהו שאתם מצליחים להעביר אותו בLEAP?

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

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

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

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

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

״כשמנהל פיתוח אומר לכם לא זה לא כי הוא בא לבאס אתכם.״

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

(מוזיקה)

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

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

עדי: אז אני אולי כאילו אספר קצת על החוויה שלי הייתה לאורך הרבה שנים בתעשייה, פעם מישהו אמר לי ש-VP R&D הוא לא יותר מ- Glorified Project Manager שכל התפקיד שלו זה לוודא שהפרויקטים נכנסים בזמן ויוצאים בזמן והגרסה המדולוורת כמו שצריך ללקוחות בלי באגים ואני היום מסתכלת על זה ואומרת כאילו אין דבר שהוא יותר גרוע אם אתה עדיין רק יודע לעשות Project management בתור מנהל פיתוח אז אתה לא עושה את התפקיד שלך בצורה מספיק טובה.

"פעם מישהו אמר לי ש-VP R&D הוא לא יותר מ- Glorified Project Manager"

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

ישי: זה תלוי על הקיר.

עדי: זה תלוי על הקיר, בדיוק (צוחקת).

ישי:  אז מה בטכנולוגיה שינה את זה? הקיצור זמנים של התהליך Build ו- Deploy שמאפשרים לי להיות הרבה יותר קרוב ללמוד משהו מהשוק? מהלקוחות שלי או היוזרים?

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

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

ישי: אז בעצם אם אני לוקח את מה שאת אומרת, מי שעדיין היום מפתח בעולמות של on prem או שקשורים מאוד לחומרה, יש לו סייקלים ארוכים של Validation הוא נשאר מאחור, מועמד שיבוא להצטרף לLEAP אבל הוא בעולם שאין לו CI/CD והוא לא שם, והוא מורחק מהפרודקשן כמעט By definition, מה הוא אבוד?

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

ישי: גם כשיש בעצם ריבוי של סביבות פרודקשן? גם on prem זה הקצה של זה כשיש כמעט מספר אין סופי של סביבות פרודקשן. 

עדי: נכון, לגמרי, לגמרי.

(מוזיקה)

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

עדי: אז בוא נתחיל הפוך בסדר? הרבה פעמים יוצא לי לשמוע פאונדרים או מנכ"לים אומרים למנהלי פיתוח שלהם 'הפיתוח לא מדלוור', או 'פעם היינו עושים את הדברים הרבה יותר מהר', או 'אני לא יכול לעבוד בסייקלים האלה בצורה הזאתי וצריך לעשות את זה אחרת', עכשיו אם אני מנהלת פיתוח והפאונדר שלי אמר לי את זה ואין לי דאטה אני יכולה לחשוב שהוא... אני יכולה לנחש כל מיני דברים אבל אני לא יכולה לבוא עם הפתרון בעצם לאמירה הזאתי, הרבה פעמים האמירות האלה מגיעות כשסטארט-אפ פתאום עובר שלב של סקייל-אפ מאוד משמעותי ומה שעבד לי כשהיה לי צוות של עשרה אנשים לא עובד לי כשיש לי צוות של שלושים או של חמישים, אתה יודע סטארט-אפים היום עוברים לסקיילים מאוד מאוד קשוחים ובשביל להבין באמת איפה יש לי בעיה אני חייבת להשתמש בדאטה ודאטה זה לא כמה Story points עשיתי ב JIRA כי זה בעיני לא מטריקה שאני חושבת... שאני מציעה לאנשים למדוד אותה, אני חושבת שזה מטריקה שקל נורא למדוד אותה אבל זה לא אומר שזה המטריקה שאנחנו רוצים למדוד אותה.     מה שמעניין בעיני וזה אולי... נכון דיברנו על זה, זה ה"הולי גרייל" זה להבין איך אני מדלוורת את הווליו הנכון שלי בעצם ללקוחות או איך אני מעלה את הוויליו שאני מדלוורת ללקוחות ואם יהיה לי דאטה בפנים אני אוכל להבין אז דאטה זה יעזור לי להגדיל את ה- Velocity ולהבין איפה יש לי צווארי בקבוק בתהליך של הפיתוח ולהבין איזה חלק הוא אולי עובד טוב אבל אין לא מספיק capacity ואיזה חלק אולי הוא לא עובד טוב, ואיפה צריך להכניס איזה שהוא תהליך מסודר שפעם היו יושבים שני אנשים שעשו את הכל ביחד מקצה לקצה והיום יש לי כמה צוותים שכל צוות עובד על מערכת אחרת ולייצר של איזה שהוא תהליך של קולבורציה נכון ואם אין לי דאטה אני יכולה לנחש ואולי לקלוע ואולי לא.

ישי: אני שמעתי כאן,עוד לפני הדאטה ככלי לפתור בעיות,  דאטה כdefense, אם הפאונדר בא אלי אם טענה שאולי נכונה ואולי לא קודם כל יש לי דאטה להגיד 'זה לא בדיוק מה שאתה חושב', ' זה לא בדיוק מה שאתה אומר', 'יש לי דאטה שמראה שאנחנו מדלוורים כן במהירות הנכונה או לפחות לא כזה גרוע כמו שאתה לרוב תצייר את זה', אבל אחרי ה- First line of defense יש את אומרת את השימוש בדאטה כדי לפתוr בעיות, כדי למצוא את ה...

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

עדי: יש אני חושבת חוץ מ... יש שני מדדים שאני לא אוהבת, אחד זה Story points ב- JIRAכי זה נורא קל למדוד את זה וזה נורא קל להסתכל ולהגיד רגע בספרינט אמור להיות 20 Story points והיום עשיתם רק 18 אז אתם צוות מדרדר אולי, אבל אולי עשינו את ה-18 הקשות ולא את ה-20 הקלות ונורא קל כאילו להשתפר בזה ולהרגיש כאילו נורא טוב עם עצמנו ובעצם לא לשפר שום דבר ומטריקה נוספת שאני ממש ממש ממש לא אוהבת זה אחוז  Test coverage של Unit testing על המערכת, זה בעיני עוד מדד למשהו שגורם לי אולי להרגיש נורא נורא טוב אבל לא בטוח שבדקתי את הדברים הנכונים והחשובים וזה... כן נכוויתי מזה אבל עבדתי פעם בארגון שמדדו את זה ובאו להגיד לנו רגע, למה אחוז  Test coverage הוא לא מעל אחוז כזה ומתחת לאחוז כזה ואף אחד לא ניהל את השיחה האמתית של הquality של הטסטים שלנו, שאם אנחנו מייצרים את הטסטים הנכונים בכלל או אם אנחנו מודדים באמת הסיכון נמצא בהם אלא בכמות, בכמה טסטים יש לי וזה יצר לי איזה שהוא אנטי אני חושבת לממד הזה, אולי לא בצדק.

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

עדי:  כן, אני חושבת, אולי (צוחקת).

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

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

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

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

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

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

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

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

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

(מוזיקה)

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

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

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

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

ישי: אז זה בעצם שילוב...

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

ישי: בעולם הזה שהמפתח הוא מלך או מלכה, ביקוש מטורף למפתחים זה האתגר אחד הגדולים בלגדל חברות, זה הגישה לטאלנט, הגישה לכשרון ומהצד השני יש פה אתגר של איך בונים ביחד כקבוצה, בונים value דרך שינויים ב-Code base, מעניין אותי מה את חושבת על הצדדים של ה- Developer Experience על מה אני או את כמנהלת פיתוח צריכה לחשוב עליו כשאת מסתכלת על ה- experience של המפתחים, איך אני מייצרת להם את ה- Experience הנכון שיוביל גם ל- Well-being וגם לתפוקה, גם להצלחה במדדים השונים ובסופו של דבר לדלוור value?

עדי: אז זו שאלה מעולה כי זה כאילו דבר שאנחנו נורא מבינים פנימה למה זה דבר חשוב והחוצה זה לא באמת ממש אכפת למישהו ה- Experience של המפתחים שלי.

ישי: ושיהיה ברור אני לא מדבר על גודל המסך או על מספר טעמי הגלידה.

עדי: כן, כן, ברור (צוחקת).

ישי: ממש Developer Experience ברמת העבודה.

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

ישי:  אז ה- Developer Experience נוצר ממה? מהחלטות של Priority? במה אני משקיע? אני משקיע ב- Non functional כדי לקצר Build? או נוצר מ... קניתי את הטכנולוגיות הנכונות? השקעתי    ב- Tool set?

עדי: זה מתחיל בכלל להגיד אני רוצה שה- Developer experience שלי יהיה טוב וחשוב בסדר? כי כשאני בוחרת כלים והנה יש לנו היום בארגון דוגמה על כלים ל-Static code analysis שלי יצא לעבוד עם כמה כלים בהיסטוריה היותר רחוקה שלי שנורא נורא בחרו אותם מישהו שלא מבין בפיתוח ורק הסתכל בעצם על איכות האנליזה ובכלל לא נכנס לתוך שיקול איזה חוויה תהיה למפתחים ואם זה יהיה אפקטיבי או לא יהיה אפקטיבי להם לעבוד וכמה מהר הם יוכלו בעצם לתת ווליו מתוך הכלי הזה והיום כשאנחנו בוחרים כלי כזה בתוך הארגון שלנו זה אחד השיקולים, זה אם נוכל לעשות לו אינטגרציה בתוך התהליך CI או לא, אם לא אז הוא לא נכנס בכלל, אם מפתח יוכל לקבל את הפידבק-לופ ישר כשהוא כותב את הקוד מצוין, לא אז אנחנו צריכים לחשוב אם זה כלי שאנחנו יכולים להסתדר איתו.   אז זה מתחיל בלחשוב אם אתה רוצה לשים את זה כאיזה שהוא שיקול וזה גם שילוב של לבחור את הכלים הנכונים וגם לתעדף משימות, זה שילוב של שני הדברים האלה.

ישי: מי ה-Owner של ה Developer experience-בעינייך? זה מנהל הפיתוח? הוא ה-Owner של זה שצריך לא לישון בלילה אם ה- Developer experience שלו לא מספיק טוב או שיש מישהו אחר?

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

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

עדי: כן אבל למנוע טעויות זה הצדקה מצוינת, זה מעלה את הquality, זה למנוע טעויות אנוש, יש לזה הצדקה מסוימת.

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

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

ישי: את מוצאת או רואה מפתחים מפתחות שמראיינים את החברה על Developer experience כחלק מהבחירה שלהם לאן ללכת? שיקול האם אני הולך לעבוד אצלך או בחברה אחרת? כי פעם לפני הרבה שנים היה את ה12 נקודות של ג'ואל ספולסקי שהוא ממש פרסם, אני חושב שזה ההתחלה של ה- Developer experience כ-Mind set  שאנשים בדקו האם החברה שאני הולך לעבוד בה, כמה נקודות היא מקבלת ולפי זה האם אני מחליט לעבוד בה או לא.

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

ישי: חלק, בהחלט, העובדה שיש CD או קרוב לזה.

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

ישי: גרסת אביב 2022.

עדי: אביב 2022 נכון (צוחקת), כן אני רואה כאלה.

ישי:  זה שעון סטופר את אומרת.

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

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

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

ישי: אני לא dev , אני מטפל בבעיות כל היום.

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

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

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

ישי: אז מי הטופ 3 שלך?

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

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

בארגונים שאת ניהלת, מנהלת, את מצליחה להגיע למצב שמפתחים מדברים עם לקוחות?

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

ישי: וזה את רואה שמצליחים לעשות את זה גם בסקייל? שיש לי כבר 100-200 מפתחים עדיין אפשר לייצר אפילו אם בחלק מהמקרים את המגע הישיר הזה?

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

(מוזיקה)

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

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

ישי: אנשים שהם בעצמם מנהלי פיתוח? מן buddy system כאלה או שלאו דווקא?

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

ישי: ומה לגבי עצה אחת לאנשים שעובדים עם מנהלי פיתוח, מי שמדווח למנהל פיתוח או למי שמנהל, בין אם זה CTO או CEO או אנשים שיושבים ליד מנהלי הפיתוח בשולחן ההנהלה, משהו אחד שהם צריכים לזכור כדי לעבוד יותר טוב עם מנהלי הפיתוח?

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

(מוזיקה)

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

עדי: תודה רבה, תודה שהזמנת אותי.

ישי:  להתראות.

(מוזיקה)

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

 (מוזיקת סיום)

(Opening music)

Yishai: Welcome to the Israeli version of Dev Interrupted, LinearB’s hit podcast for engineering managers. On our show we will talk about everything that “interrupts” engineering managers from their flow. I'm Yishai Beeri, CTO at LinearB.

(Music)

Yishai: With the announcement of our big Round B, we are excited to bring you this newly minted podcast in Hebrew. On the show we will host industry leaders who will talk about everything that disrupts engineering managers, along with those who work with them, and those who want to one day manage an engineering organization themselves. In the first episode, I am happy to host Adi Shacham-Shavit, one of the most seasoned leaders in the industry,  co-founder of "LEAP", a program for training the next generation of engineering leaders, and the SVP Engineering at Transmit Security. And now we'll dive into the full interview.

(Music)

Yishai: I would be happy if you could tell me a little about your journey, how you started, how your career unfolded and where you are today.

Adi: First off, I'm very excited to be the show’s first guest, I've been in the industry for many years, having held all kinds of engineering roles––I came to LivePerson, where at the time it was a small company of 60 people and held quite a few roles, until I left when there were 900 people, and after that I made a very dramatic switch and moved To Appsflyer as the tenth person in the company. I came to set up and manage the entire engineering team, but basically we were four people in the whole team, for the three and a half years I was in the company the team grew to 70 people, the system grew from 200,000,000 events per day to 20 billion, we learned how to provide more and more value from the same data we collected and the company grew very much and developed. This was also my first VP Engineering role, we will go back to this after that and I will tell a little more why I even went to do it, I went back to engineering management at Lemonade.  I arrived at Lemonade at a more advanced stage after their Round B. There I took both the role of VP Engineering as well as the role of acting CISO for Data, Privacy, and Regulation, entering the European market and more.  After that I went on to lead the engineering as EVP Engineering at a start-up called Clear that builds settlement and reconciliation systems between large enterprise organizations through the creation of a private blockchain network between them. A year and a half ago I set up a forum of senior engineering managers in an organization called "Baot", and a year ago I set up together with Miri Couriel who is my partner, a program for the engineering of engineering managers in start-ups in the scale-up phase called "LEAP" and four months ago I joined Transmit Security.

Yishai: Wow! And at Transmit you’re the SVP R&D

Adi: That's right

Yishai: So we'll be back to ask you, as someone who has been involved in developing and managing teams, why you have repeatedly returned to roles of VP Engineering, and the establishment of engineering organizations from scratch. I think there are some interesting questions there, but first I want to hear a little more about LEAP, tell me a little about the program, what are you doing there, what did you learn?

Adi: Sure, we already had two cohorts and now we are in the middle of the third cohort. In each cohort there are between 12-14 VPs of Engineering from start-ups usually at a stage when the start-up suddenly succeeds and starts to grow rapidly, and then you suddenly have to not just manage the engineering properly but also to understand how to help the company grow and evolve and how to work differently with the Founders and the rest of the management team. I think it was born right from the heart, from the place of ... Honestly, I wish someone would help me save some of the things I learned the hard way, and helped me skip over some of the bumps I fell into, and provided some structure and order in the methodology and thinking about these things because there is a lot of complexity in actually doing it right.

Yishai: If you are talking about difficulties or failures you have experienced and if having a LEAP in your time would have helped you, would you like to tell us about one of these?

Adi: Wow there were many.

Yishai: We love glorious failure stories.

Adi: (laughs) I think it took me a while to understand that as an engineering manager in a start-up you not only manage the engineering, but you are also part of the company management and you have to communicate the needs of the engineering teams to the founders and other management stakeholders, and how to understand what the business needs from the engineering organization, and bring  this to the forefront of the engineering team’s strategy, and make the right decisions. I think it was not a specific failure, and there was a time it took me to figure it out, as well as to figure out what was the right course of action and how to execute it well and correctly.

Yishai: And is that something that can be taught? The understanding, this feeling that I not only produce features but I need to be more connected to the management––is this something you manage to convey in LEAP?

Adi: I think that ... First, I hope so. That might be a better question for the graduates. I think actually establishing what the VP R&D role in a startup actually is,  and providing the right framing maybe already in this session it very very opens the mind to people to understand what they need to do, because a lot of times you work in a startup and founders don't know how to tell you ‘that's what I need from you”, they need a lot of things from the engineering team  and the engineering  manager and they do not know how to state it clearly. I need this and I need you to give me that, and I need you to talk to me this way, because they have many other things they need to take them forward. The fact that you start to become aware of the fact that there is actually a business part within your role, and one part is understanding the business, and the other half is understanding how it translates into technology, I think this is one of the things that perhaps drives the greatest change of thinking.

Yishai: So it sounds like not only engineering managers need to learn this framing and understand it, but also those who employ them, and who work alongside them. What shifts have you witnessed from the many years you spent in such roles? Any change in how the managers, the founders, or how the stakeholders who sit at the same table perceive this role and know how to conduct themselves in front of it? Maybe they need a course too?

Adi: Yes (laughs), the truth that a lot of times people in the course tell us maybe next time I will bring X that works with me in this and that position to the course next time, or the next course. I think there is some kind of dissonance between the perception that ... engineering managers are ultimately programmers, engineers, and we always have a certain way of communicating and a certain way of phrasing things, and a certain way of looking at the world through the eyes of an engineer who is very structured in thinking and it is very ... for example we will not talk about something that happens if we are not sure know exactly how it works, when it happens and when it comes into play, and this is a big dissonance between people who are entrepreneurs or people who are in places of say marketing and sales who often run forward and fly ahead with their ideas, and when we say no to them or not yet it turns them off and it is tough for them.   And when we say to engineering managers there are words that are more correct to communicate in this or that context, or you have to come up with a variety of solutions instead of just saying no, but to say this can be done instead and can be put into this project and done in this way.

I think maybe if I wanted to say one thing to someone who works with engineering managers: When an engineering manager tells you no it's not because they want to turn you down, it's maybe because they can’t think how they doe this task in addition to all the other sixty things they’re juggling and if you tell them, hang on a sec, maybe you can do it and prioritize something else instead it can open up their thinking and help them be creative in the solution they come up with.

"When an engineering manager tells you no it's not because they want to turn you down."

(Music)

Yishai: So let's talk a little bit about technology. If we look at the changes in  the role of the manager and today's engineering day has changed in the last 20 years, I have no doubt that technology and the changes we are all familiar with, beyond cloud and others, come into play here. Can you put your finger on what are the main ways that technology has impacted and changed the engineering management role or enabled changes?

Adi: So I might as well now talk a bit about my experience over my many years in the industry. Someone once told me that the VP R&D is nothing more than a glorified project manager whose whole job is to make sure projects get in and out on time and the versions are released properly and bugless for customers. And today I look at it and say like there is nothing that is worse than still only knowing how to do Project Management as a Engineering Manager, if so - then you are not doing your job well enough. I think if I reflect a moment about technology and the changes the entire DevOps movement has taken us to, it also allows us to manage engineering in a very very different way and be very close to the business and be very close to delivery, and not do what I'm sure you also once did. Complete in advance a very fancy Gantt and what will delivered from engineering in what month, and then by the first week of January it is no longer aligned with reality but still in the tenth week of the year someone will come back to you with a slide and tell me but you wrote in the Gantt that you would deliver this feature, what about it? You can’t explain to them ...

"Someone once told me that the VP R&D is nothing more than a glorified project manager."

Yishai: It hangs on the wall.

Adi: It's hanging on the wall, exactly (laughs).

Yishai: So what in technology has changed all this? The shortening times of the Build and Deploy process that allow us to be much quicker to learn from the market? From customers or users?

Adi: So I think it's really a combination of the CI / CD that seems to be no less than a revolution to me in this world for how we work and how we manage engineering. It allows us to actually move from this demanding need for planning a version half a year in advance down to the last details and what will be included and what will not. We’ll test it for months and go through design cycles of debugging and QA, and if there is anyone who is young and is not familiar with this, I am happy for them.  And CI/CD allows us to actually concentrate on understanding what the right value is at all and not how I push as much content as possible into this half year.

I think the second thing is the democratization of System and Network into the engineering, of monitoring systems that are today much more accessible to developers with observability - that they basically allow developers to also understand what happens to my system in production, and what is really being used, and where the traffic suddenly went up, and not have to guess where the next Bottleneck will be, or guess how many users I will have at the moment, but truly understand what's happening to my systems.  This was also the second game changer for me. I personally saw this, saw it and experienced it myself, saw what happens to developers when they do not touch production and they are not familiar with the production, and the systems they know how to produce and on the other hand when you bring them closer to production systems, how much better the engineering and product put out is.

Yishai: So basically if I take what you say, whoever is still developing in the worlds of on-prem or very related to hardware, that has long validation cycles is left behind, a candidate who will come to join LEAP but is in a world that has no CICD and is removed from production almost by definition, are they a lost cause?

Adi: God forbid, so for hardware it's a little hard for me to relate because I did not do it myself, but on-prem even today I have a system that is deployed on-prem, and I also managed to produce a blockchain system that is partially on-prem ... but some customers it was installed On-prem and at some other places, beyond what I have done in my distant past in recent years and probably among LEAP  participants are from all walks of life including those who come from a combination of hardware and software. I think it does not bother you to better understand what happens in business and why we do things a certain way and how can it be done more correctly, and also understand how you are from the world of the on-prem, ok it will not be a CD because customers sitting in the on-prem you do not touch them in production and make them a CD, but you can produce excellent observability in these places, which helps us understand what is happening and how to debug it and how to get there for a deep understanding of the system.

Yishai: Also that there is actually a multitude of production environments? Even points where on-perm is the edge - where there are almost an infinite number of production environments.

Adi: True, absolutely, completely.

(Music)

Yishai: So the next topic I want to talk to you about is data, we talked about the challenges of engineering managers and how an engineering manager in the modern world should hope that they has access to CI/CD and and observability, and hopefully maybe one production system, but where does data come into the picture here? How does data help me as an engineering manager do a better job?

Adi: So let's start from the flipside okay? Many times I hear founders or CEOs say to their engineering managers 'engineering is not delivering', or 'we used to do things much faster', or 'I can not work on these cycles this way and we have to do it differently', now If I'm a engineering manager and my founder told me this and there is no data ... I can guess all sorts of things but I basically can not come up with a solution for this statement. Many times these statements come when a startup suddenly goes through a significant phase of scale and what worked for them when they had a team of ten people does not work when they have a team of thirty or fifty. You know start-ups today move to very rapid and large scale and to really understand where I have a problem I have to use data, and data it is not some story points in Jira. This is not a metric I like to tell  people to measure. I think it's a metric that is terribly easy to measure but that does not mean it's the metric we want to measure. Honestly, we talked about it. The "Holy Grail" it's figuring out how I deliver true value to clients, or how to raise the value delivered to customers. If I have data I can understand then this data will help me increase velocity and understand where I have bottlenecks in the engineering process and understand which part may work well, but there is not enough capacity, and which maybe don’t work so well, and where to put some sort of order and process where there used to be two people who did everything together from end to end, and today there are several teams where each team works on a different system. So this will help produce some sort of process for correct collaboration and if I have no data I can only guess and maybe it’s related and maybe not.

Yishai: I heard here even before data as a tool to solve problems, data as a defense. If the founder comes to me with a claim that may be true and maybe not. First of all I have data to say 'it's not exactly what you think', 'it's not exactly what you say', 'there I have data that shows that we are delivery at the right speed or at least not as bad as you would conclude ', but after the first line of defense you say use the data to open up problems, to find the ... So you mentioned here what worth measuring and what not to measure, do you have a story or case where you got burned by a wrong metric or an organization that measured the wrong things?

Adi: There I think except ... there are two metrics I do not like, one is story points in Jira, because it is very easy to measure it and it is very easy to look and say - hang on in the sprint there should be 20 story points and today you did only 18 so your team is deteriorating maybe, but maybe we did the 18 hard ones and not the 20 easy ones, and it's very easy to falsely feel as if we’re getting better  and feel really good with ourselves and actually not improve anything. Another metric that I really don’t like is the percentage of unit test coverage on the system. I think this is another metric of something that makes me feel awfully good but not sure I checked the right and important things and it ... yes I was burned by it but I once worked in an organization that measured it and came to tell us with questions like why is the percentage of test coverage not above such a threshold, and below such a percentage. And eventually no one has conducted the real conversation of the quality of our tests, if we are producing the right tests at all, or if we really measure the risk through them. But just in quantity, how many tests I have run, and it created in me a kind of distaste I think to this metric, maybe not rightly so.

Yishai: It sounds like the things that are easy to measure are probably the things that are less successful to measure.

Adi: Yeah, I think, maybe (laughs).

Yishai: So if we want to measure what is important, what is useful for an engineering manager to make decisions, to improve the organization, then what do you think are the critical things to measure or how are the really important things measured?

Adi: That's a good question, look it's a question that I think is divided into several things, one is the areas of the system itself and measuring the scale that my system knows how to withstand and its stability and its uptime, that are eventually completely business metrics. And at first we think it doesn’t Interest the business, but of course it interests the business, because if my system is not stable then the organization is in trouble and if I want to improve it I need to measure it and understand where I am improving it and where in the system I have a problem. A metric that I really like in systems is to measure the Time to Resolution. I mean not to assume that I will arrive with zero production bugs, with zero production bugs, but how fast I discovered an issue and how fast I fixed something I discovered. It's an excellent measure because It shows how fast I can actually put patches in production.

Yishai: It also reduces cost, my ability to resolve an issue quickly increases my confidence in coming out with something new that may have glitches but I can overcome the glitches quickly.

Adi: Then if I actually have a very strong observability into the software on the one hand and on the other hand I can fix bugs quickly, then even if my QA is not perfect and I do not think any of us have perfect QA, I can ... Exactly, I can feel good about things because I can go out with them and I know that I ... be sure that I have other tools that help me solve the problems. And that by the way is a very significant change in thinking, because we used to think we should not go out with bugs for production or that a bug in production is like a disaster and today I think that if I have these two tools then yes I do not want to come out with bugs for production, I want to come out with a perfect system, but I recognize the fact that my system is not perfect and I can fix it as soon as possible.

Yishai: It's around the quality, what about around the very process of engineering or the ability to deliver? At the end the boss wants to deliver faster.

Adi: So here are some metrics that I like to look at and measure, such as how long from the stage I decided I was going to do something to the stage that I actually get it into production, that's a metric maybe ... the automation metric is that right? Because maybe I can manually upload it pretty fast, but it does not really matter to me as the manual process is intended to provide the baseline for how fast the automated process can or should be -  from the stage I decided to do something, uploading it, until it is deployed to production and in front of first customers. On the other hand, see also where I have a bottlenecks in the process, where this is a bit more complicated because sometimes the bottlenecks are actually in the lack of knowledge of the developers, that, they inherited something and then they do not understand at all what to do with what they got, and they start looking for that knowledge and there it actually gets stuck. Sometimes the bottlenecks are in systems that haven’t been tested, and I understand that I need test systems, and understand how to produce them for myself even very simple test systems that I can simulate things on. I think this understanding is something that is very critical, and many times I think when engineering managers are told their team is not delivering, many times it means suddenly there are bottlenecks in a process that used to work great. Or suddenly we have  bottlenecks and our ability to identify those bottlenecks in the very broad sense of the word, can be and figuring this out from just understanding that the team is not delivering, which doesn’t mean that if I bring in 30 more people now it will help because I might bring in 30 people and it will be worse not better.

Yishai: You talk about a situation where you can reach the understanding that once we delivered fast, and today you do not say you can go back to the same velocity even if you know how to identify the bottlenecks, and you know how to solve them, investigate them. While it’s not a lost cause, because we grew in the process and scaled, but on the other hand it will not be the same - it will be a little different.

Adi: It will not be the same but for good reasons okay? Let's get to a place where it's not the same thing because I used to build a system from a POC. Obviously it will not be the same to build a POC patch to show the customer and see if they like it, versus  a robust system that supports millions of users at once. Let's stay in this place and not in such a place, I also once wrote the same code in two days and today it takes two weeks because this developer does not know how to test and should be taught basic testing first.

(Music)

Yishai: We talked about metrics, about things that are worth measuring or should be measured, and things that may not be worth measuring. I want to ask you a philosophical question about metrics in an engineering organization, and what does it look like on the part of the developers, are we being measured? Are we mice on the wheel? What did you encounter when you have tried or when you introduced metrics to an engineering organization? How do developers react to this? How do developers react to the fact that engineering even needs to be measured?

Adi: I think here we get into what you are actually measuring, if I measure them in lines of code then it really does feel like mice on the wheel, and it is also not a good metric to measure, but if you measure the value that they deliver, and they also understand why they do it, I think it's a great experience for developers, it helps them improve, it helps them understand. Developers  love metrics, love to improve something and see it in numbers, it's our bread and butter.  And it should not be about why you personally wrote only 3 lines of code today and not 20.

Yishai: What about the ownership of the measurement process, the decision of what to measure? It can come from above: let's measure it, everyone please align with the metrics, or it can come bottom up, where each team will decide what is right for them to measure, how do you see this -  between democracy and chaos? Top-down vs. bottom-up perspective.

Adi: I think it very much depends on the situation of the start-up and work style. I will explain, today we very much work in teams that are basically oriented by product from end to end teams responsible for a product and its delivery and its measurements and then these metrics are actually relevant to the specific team. How many more users can be onboarded to the system, how fast can  your system integrate with another system, such measurements. Then it is specific to each team.  Then there are things that are more horizontal. They are derived from having created a uniform CI process and we want to make sure that our build times really are within a certain scope of time, and if it took more than that then let's understand how we improve it all the time.

Yishai: So it's actually a combination ...

Adi: I'm talking about a combination, yes. I'm talking about a combination of metrics, and I'm also talking about the state of a company. If you build everything from scratch from the first day of the company then that’s one thing, if you go into a company and you make a change it's a different situation, I think each start-up  really is a standalone case unto itself.

Yishai: In this world where the developer is king or queen, insane demand for developers is one of the biggest challenges in growing companies, such as access to talent. On the other hand there is a challenge here of how to build together as a team, build value through code base changes. I wonder what you think about the aspects of the developer experience. What I or you, as an engineering manager, should think about when you look at the developers' experience. How do I create the right experience for them that will lead to both well-being and productivity, as well as success in the various metrics and ultimately a thing that delivers value?

Adi: So this is a great question because it's like something we deeply understand inside why this is an important thing, but externally this  does not really really matter to anyone––the experience of my developers.

Yishai: And to be clear, I'm not talking about the screen size or the number of ice cream flavors.

Adi: Yes, yes, obviously (laughs).

Yishai: Real developer experience at the work level.

Adi: Of course, obviously. Let's start with the fact that I think the good developers like a good work environment, and like that they have the ability to check their code all the time, and the ability to work with tools that are the right tools for the job, and integrate security into the engineering process, and run smoothly ahead with everything at once.  Which actually helps me understand how to connect it to their effectiveness, because in the end if I have a very very effective and very good experience it's a lot of fun for the good developers and it's very right for the organization too, it actually helps ... I'll give an example: If my developers build takes an hour and a half for example, and I will invest time and we will shorten it even to a quarter of an hour okay? Let's not talk about two minutes, even less than an hour, I have made my developers very happy, and on the other hand I saved a lot of time that is worth a lot of money to the organization. It's a win-win for both of these sides.

Yishai: So the developer experience was created from what? By priority decisions? What do I invest in? I invest in the non-functional to shorten build times? Or is this something that is created from ... I bought the right technologies? I invested in the right tool set?

Adi: It starts by saying - I want my developer experience to be good, and it’s important to me. Because when I choose tools. I  have a great example from today, in my organization for example we have tools for static code analysis. I had the opportunity to use such tools in my more distant history.  These were always chosen by someone who really does not understand engineering and just actually looked at the quality of analysis, and did not even consider what experience the developers will have with them, and whether it will be effective or not effective for them to work, and how fast they can actually derive value out of this tool. Today when we choose such a tool within our organization this is one of the considerations, it is whether we can integrate it within the CI process or not, if not then it does not enter In general. If a developer has a feedback loop directly when they write the code, if not then we need to think if it's a tool we can reconcile. So it starts with thinking if you want to give developer experience priority of consideration and it's both a combination of choosing the right tools and also prioritizing tasks, it's a combination of these two things.

Yishai: Who do you think is the owner of the developer experience? Is it the engineering manager? Are they the owner and the one who will lose sleep at night if the developer experience is not good enough or there is someone else?

Adi: So it's clear that in the end––the organization does not really care about dev experience, I can’t really tell the VP Marketing why don’t you care about the developer experience? Obviously it's my responsibility, but to me, it's also my place to give legitimacy to each of my developers on a daily basis. Because if you come across something that you do over and over and over again and it takes half an hour each time, and we can spend two days and shorten its time. It is not only legitimate It's your responsibility to take and escalate it, because I do not know all the tasks you do every day and there is not the ability to do it, but if you raise the flag and say it 'I must put in the next sprint or as an upcoming task because …’ To come up with this justification that says I will invest two days and I will save after that, what ... half an hour time X how many developers, and that is a conversation that is easy for us to have with product and understand where it comes in as a priority, it is the job of each developer to raise the flag.

Yishai: So looking at the developer experience in a very similar way to Waste, I see something that is ineffective so I will raise it, and ask to invest in solving it and resolving it. Are there places where the developer experience goes beyond Waste? I mean not only did I save X times Y developers but it touches things I can not immediately justify through time or efficiency? Because what is easy to sell to executives––yes, it will save us a lot of time and we will achieve more, what is harder to sell to executives is that it will make my life easier, it may prevent mistakes.

Adi: Yes, but to prevent mistakes is a great justification, it raises the quality, it is to prevent human errors, it has a certain justification.

Yishai: or "It’s killing my sanity to do it every day, save me from it somehow, find me a tool that will do it for me" ... Not all things translate straight into a waste that is easy for you to justify.

Adi: Right, here I think this is often the place where programmers are less empowered with explaining "killing my sanity" is an argument that we do not know how to prioritize over waste or business value or security right? It's like a conversation we can’t really handle, and it's often the role of engineering managers who need to specialize in how you "normalize" the sentence that a developer says, sometimes says "it’s killing me". Sometimes they will tell me it is not a best practice but they say it's for some reason, they will always say it’s for some other reason. They never come and say something like "this is what I want". I feel great, let's have a hackathon.  I want to write in Haskell in production now, so I will have a hackathon and write something in Haskell  and it will be cool. But If there's a good reason, a best practice often what sits behind the good reason or "it’s killing my sanity" is many times I just do it all day, the same monotonous work and I can do more things instead. And if I automate it now, then I can do even more stuff instead. It's a reason and it's our job to help normalize it.

Yishai: Do you find or see developers who interview the company about developer experience as part of their choice of where to go? As a major consideration whether they are going to work for you or another company? Because once many years ago there were the 12 points of Joel Spolsky that he actually published. I think this is the beginning of the developer experience as a mindset that people check if the company they are going to work for, how many points it got from the 12-point system, and according to that decide whether to work there or not.

Adi: I see senior developers who say if I tell them that now that they’ll work in three-week sprints instead of continuous deployment, then they will say no thank you very much, this is not the company for. I do not know if you include that as a developer experience.

Yishai: Partly, certainly, is the fact that there is a CD or close to it.

Adi: Or that we’re getting there, okay even if we’re not quite there today, but we’re getting there and not that it is fine and dandy to roll out versions 

Yishai: Spring Version 2022.

Adi: Spring 2022 is true (laughs), yes I’ve see such.

Yishai: It's a stopwatch you say.

Adi: Especially with the more seniors, because senior developers in the end also have a preference for how they like to work and with which tools, now this love to work with certain tools or in a specific way, we sometimes paint it in a bad color. But the good developers know what helps them to be effective, it's what helps them get into the flow of their work because it what they are familiar with.  In the same way that  I know to explain why developing in concepts based on Dov Hobbes' worldviews produce a better product, I know to explain it because I saw it in practice, and I saw when it doesn’t work that way, and the difference between them.

Yishai: Have you seen organizations that somehow manage to measure the developer experience directly? Say I was here and now I'm in a better place? Or does it end up translating only into waste or efficiency of work?

Adi: So there are two primary things I managed to see as measurable, where one of them is attrition. If you see attrition of people, it can be either when you understand this is someone who just wrapped up their tenure, and wanted to move on to something new, and had nowhere to progress within the organization. Or whether it is things like burnout. Burnout is completely due to recurring production problems, where you get up every day at 2AM to fix something manually instead of taking care of it, which is also in my eyes in the extreme of I have no experience.

Yishai: I don’t want to admit it, but I dealt with problems all day.

Adi: And I also get up every day at 2AM to take care of something that I can spend a week on now and fix, instead of getting up every day at 2AM. That leads to crazy burnout. Secondly is performing surveys, where you survey once every six months or so, or once a quarter or once a year, your engineering organizations and see the trend of improvement. Invest in surveys and you’ll see the trend of improvement, it's not something you can see on such a day-to-day level changing, it does not ...

Yishai: Do you see value in producing any gold standard? Here are the things you should strive for in the worlds of Dev Experience? Part of what you spoke about with regards to CD,  or what my cycle looks like, and how to get things into production. Is there any logic to distilling it into ’this is the golden list’ and if you are sticking close to it you are in the right direction? Or it's really every organization on its own and every case ... there is no such thing as that ... there is nowhere to aim.

Adi: That's a good question, I'm like I have my list that works for me... either where I aspire or where I want to aspire.

Yishai: So what’s your top 3?

Adi: Okay wait (laughs), I think my top 3 is getting to the place of being able to do CI/CD automation, where I have tests and everything sits in the right system, where basically my engineering process protects me, helping me actually get to a place of actual autonomy and independence for developers by exposing them to professional business knowledge related to the company as much as possible, that are also related to other teams that help them make the right decisions every day. Likewise the ability to be effective, the ability to actually know at any given time what my team's goal is and how things I do affect the entire organization, and in my eyes it produces a very, very important value and meaning for people.

Yishai: Push the context as close to the developers as possible. In the organizations you manage, do you manage  to reach a situation where developers talk to customers?

Adi: It depends (laughs), I'll tell you why I say it depends, because there are situations where it's a bit sensitive that developers will talk to customers, but totally that developers should hear conversations with customers, sometimes put developers in conversations with customers in a situation that the customer really wants someone to say yes about something, or that a customer comes to come down on the company and then putting the developer there is not always fair. In the end we do not grow up in a world that knows how to deal with customers, in the form of managing complex situations, so there is something unfair. But totally listening to customer conversations, participating In customer conversations, supporting customers directly, yes it sure is a good idea.

Yishai: And do you see that you can do that at scale as well? I already have 100-200 developers - can I still create this direct contact for some cases?

Adi: Yeah, yeah, totally, I think it's priceless because in the end when I'm developing something I do not know who uses it, what it looks like for the end user. Sometimes something that seems to me not bad at all, it shocks a person to see who uses my system, and after I see how someone really uses it or really talks about what they’re doing with my system, it becomes a game-changer in my mind for how to develop things.

(Music)

Yishai: So before we wrap up, I would love to hear from you maybe one or two tips––if you have a hard time choosing––the same developer who dreams of being a engineering manager or a team manager who just landed their engineering management position, one tip on what to focus on, how to swim in this deep water.

Adi: So I think I will split this into those who are not yet in the position and to those who are not in the position, to those who are not yet in the position and want to go to such a position I would recommend they always try to ask for the next task that can advance them to their next role. The task that will help you get there. And for whoever is in such a position, whether you chose it or there was no choice– this also happens sometimes. And even though you chose to go into this position, I think it's an amazing role. I think the fact is I chose to do it for the fourth time. Create a personal advisory board for yourself, such a group of people you can consult with who are from outside of your work, who are friends, who will tell you the truth about things, who you can consult with on issues related to your personal conduct or things in the industry, and so from time to time get help from them.

Yishai: People who are themselves engineering managers? From such a buddy-system (members of the system) or not necessarily?

Adi: So it does not have to, it can, it is preferable to have such but there should be a group of few people who will be people who can give you greater context, because sometimes I’m so deep in my own world and sometimes other people help to give me context, wait - it works this way for me too, and that way is okay , and it will work out soon, because it's such a phase, and it'll be resolved any moment. So it's great but also to have people to talk to are those that are peripheral to our job, from product or marketing or senior developers who can thus complement my knowledge and help give me a different context.

Yishai: What about one piece of advice for people who work with engineering managers, those who report to an engineering manager, whether it's CTO or CEO or people sitting next to engineering managers at the executive table, one thing they need to remember to work better with engineering managers?

Adi: I think maybe one, always give the engineering manager the business context of the things you ask for, I mean do not come and say do it for me 'like this' or the engineering will give me a system that only “does this” but also the business context, what customers want , what market do we want to penetrate, as much context as possible is very very helpful.

(Music)

Yishai: Thank you very much Adi, it was wonderful to host you in the first episode of Pituach BeHafraa - Dev Interrupted, the LinearB podcast, was wonderful.

Adi: Thank you very much, thank you for inviting me.

Yishai: Goodbye.

(Music)

Yishai: Thank you very much for joining us for the first podcast, more episodes coming up real soon, go to devInterrupted.com to sign up, you will also find all our episodes in English there. I remind you that we at LinearB are growing rapidly, recruiting for a variety of roles in all areas, visit linearb.io/careers to find your next challenge. I'm Yishai Beeri, until the next episode.

(Closing music)