A Peep into DevOps Dysfunctions, Liat Ashkenazi, SVP Engineering and GM Israel, OwnBackup

בפרק המיוחד הזה, בשיתוף עם כנס DevOpsDays Tel Aviv, 
אנו שמחים לארח את ליאת אשכנזי, SVP Engineering ב OwnBackup - שתיתן הצצה להרצאת ה keynote שלה בכנס וגם קצת על איך לחשוב על developer efficiency ו experience כדי להימנע בכאלה dysfunctions.

In this special episode, in partnership with DevOpsDays Tel Aviv, we are excited to host Liat Ashkenazi, SVP Engineering at OwnBackup, who will give us a sneak peek into her Keynote talk at DevOpsDays Tel Aviv, and some tips for how to prioritize developer efficiency and experience, to prevent DevOps dysfunctions.

Transcript

ישי: בפרק הזה אני שמח לארח את ליאת אשכנזי SVP Engineering and GM Israel, ב-OwnBackup, היי ליאת,

ליאת: אהלן.

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

ליאת: איזה כיף לי גם.

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

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

ישי: הצבא לא היה כזה כבר הייטק? 8200?

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

ישי: את אומרת עבודה, תוך כדי כבר התחלת לעבוד במקצוע?

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

ישי: איפה היה המקום הראשון?

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

ישי: כמה יוצא לך, SVP Engineering להתעסק עוד בצד הטכני? בצד ה-, אהבת מתמטיקה, 

ליאת: כן.

ישי: היום זה הכול אנשים לא? 

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

ישי: לא לפרודקשן.

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

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

ליאת: אני הולכת לדבר על, קראנו לזה Four Dysfunctions of DevOps Teams,

ישי: רק 4?

ליאת: רק 4, אבל בעצם מאחורי זו עומד האיך בעצם ה-devops תומך בארגוני פיתוח וכמה זה חשוב לאימפקט על כמה זה חשוב וכמה, איזה אימפקט גדול זה עושה לביזנס בסופו של דבר, אוקי? וזה מתבטא ב-development efficiency, כמה הפיתוח, בעזרת ה-devops יכול להגיע למצב שהוא מאוד מאוד יעיל, מבחינת execution וגם satisfied. זאת אומרת זה מאוד מאוד חשוב היכולת הזאת של מפתחים לרוץ קדימה ובלי תשתיות devops אי אפשר לעשות את זה. 

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

ישי: אז טיפה למה בחרת דווקא את הנושא הזה? יש לך המון ניסיון, בוודאי מאוד מגוון, למה דווקא האזור הזה של developer efficiency ואיך devops זו תומך בזה ו-developer experience?

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

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

ליאת: כן, בדיוק אצלי זה עובד. וכל המסביב הזה פשוט גרם לי להיות פחות יעילה בתפקיד שלי. וככל שהתקדמתי במסלול הניהולי הבנתי שבעצם התפקיד שלי זה לעזור לצוותים שלי, שיהיה להם דילוור מה שנקרא חלק, עד כמה שאפשר. אף פעם אין את האידיאלי, בסדר? וגם אני אגיד עוד משהו, עברתי הרבה חברות, לא ציינתי את זה, "Avaya", אחרי זה מרקורי שנהפכה לימים HP  ואז CWT ואז "Harmon" ואז "Imperva" ועכשיו אני ב-OwnBackup וכל חברה זה משהו שונה, גם המוצר הוא שונה לגמרי, אם הוא on-prem או SaaS, גם המבנה הוא שונה לגמרי, גם ה-stage, זאת אומרת איפה נמצאת החברה זה שונה לגמרי. זאת אומרת, אי אפשר להגיד אוקיי, אני רוצה צוות יעיל, אז אני עושה קופי פייסט ככה עושה, מעתיק ממה שהיה לי מקודם. לא. צריך להבין את החברה, צריך להבין מה צריך בפיתוח, ולכן הנושא הזה של development efficiency הוא נושא מרתק בעיני. זאת אומרת לקחת צוותי פיתוח ולהביא אותם ל-execution טוב ושהם גם יהיו מרוצים ולא מתוסכלים, בסדר? כמו שאני הרגשתי אז, אני חושבת שזה  נושא מאוד מאוד מעניין ולכן בחרתי לדבר על זה. 

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

ליאת: אחרת לגמרי.

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

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

ישי: פלייקי.

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

ישי: אז זה שילוב של מה? מדידות ממערכות אבל גם לשאול את המפתחים?

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

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

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

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

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

ישי: טוב, אם יש developer experience טוב אז הם יישארו, לא?

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

ישי: אבל זה עוד תכונה, עוד יכולת ש-VP Engineering טוב צריך שיהיה לו,

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

ישי: אבל זה לא standalone.

ליאת: לא חושבת שזה standalone, כן. 

ישי: אוקיי, ודיברת על ה-devops אז את רומזת שלפחות אצלך, ואולי זה ההמלצה שלך, devops רואה את עצמו אחראי לשאלות האלה של developer experience,  של ה-flow, של לא רק איך הדברים מגיעים לפרודקשן, כי הרבה פעמים devops חושב על אוקיי, איך אני מביא את זה בצורה reliable לפרודקשן, איך זה ירוץ שם בלי בעיות, אבל לאו דווקא על איך החיים של המפתח או המפתחת שרוצים לדלוור ולעבור הלאה.

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

ישי: אז זה אזור שמתחיל היום קצת, buzzword שמתחיל לעלות של Platform Engineering, איך את רואה את זה מתחבר עם ה-dev ops? אותו דבר? זה extension?

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

ישי: אוקיי, אז את שמה את זה בקובייה ככה, במגירה של ה-CI? אבל הם מדברים פה לפעמים על דברים כמו איך אני בכלל יודע מי אחראי על service, איפה התיעוד, מי יעשה לי review, זה דברים שעוד לפני ה-CI, הם ממש, אני כותב קוד ואני צריך למצוא אנשים למצוא ידע, זה גם חלק מ-platform, לא?

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

ישי: הכול תחת אנשי ה-devops, לפחות ארגונית זה אחריות שלהם.

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

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

ליאת: מה ה-communication, בדיוק, מה, איך אנחנו, איך תהליכי עבודה בן אנשי ה-devops למפתחים, מהמפתחים עושים, מה ה-devops עושים, עוד פעם, לא אחד לאחד כתוב, אבל ככה באופן כללי אחריות, אז זה סוגיה ככה בפני עצמה אבל אני יכולה לספר לך מה עשיתי ב-OwnBackup. מה שהיה ב-OwnBackup זה שהיה devops שהיו אחראים על הכול, גם על ה-CI, גם על ה-CD, גם על ה-platform engineering, לא משנה איך לא תקרא לזה, כל המושגים היו אחראים על הכול.  בפועל, הם היו אחראים על פרודקשן, בסדר? כי הם היו אחראים גם על ה- CD וגם על ה-CI, אז מה קרה בפועל? כשהם אחראים על הפרודקשן מה מושך את רוב תשומת ליבם? הפרודקשן, 

ישי: אז הם עשו גם סוג של SRE?

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

ישי: והם היו צבועים? כאילו הזמן שלהם צבוע,

ליאת: צבועים, צבועים לגמרי, צוות נפרד שם,

ישי: שלא דיווח לצוות ההוא.

ליאת: שלא דיווח לצוות ההוא, שהם אחראים על ה-CI, מתרכזים ב-CI, מתרכזים בלהרים סביבות אוטומטיות למפתחים, מתרכזים בזה. עכשיו, עוד פעם אני חוזרת לקופי פייסט שדיברנו. האם זה נכון לכל ארגון? לא. זה היה נכון ל-OwnBackup בתקופה שנכנסתי, וגם עכשיו זה נכון, האם זה יהיה נכון ל-OwnBackup עוד שנה? יכול להיות שלא, יכול להיות שנעשה שינוי, אני אומרת אבל באותו רגע, זאת אומרת זה היה מקום לתת לזה את ה-attention כי OwnBackup זאת חברה שגדלה מאוד מאוד מהר, גדילה מהירה, הכפילה את עצמה כל שנה, אבל התשתיות עדיין היו כאילו סטארט אפ של 10 אנשים, בסדר? שאנחנו סטארט אפ היום של 800 איש, 150 איש בפיתוח בקבוצה שלי. זה, אי אפשר להמשיך לעבוד באותה צורה. ולכן הייתי חייבת לתת לזה את הפוקוס, אני עדיין חושבת שצריך לתת לזה את הפוקוס, על ה-platform engineering, CI, איך שלא נקרא לזה, כדי שבאמת התשתיות, נשים את התשתיות הנכונות, ובאמת הראינו הצלחה מאוד מאוד גדולה. 

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

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

ישי: נטוורק זה חלק מה-assets שלנו, לא?

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

ישי: אז כל pull request,  כל שינוי בקוד שאני עושה, 3 שעות כדי לבדוק אותו בסביבה שהיא לא local,

ליאת: בסביבה שהיא local, כן, לא, שהיא לא local אבל שהבילד רץ וסביבה, כן, 

ישי: 3 שעות, אוקיי, הרבה קפה. 

ליאת: הרבה קפה והרבה תסכול, למה? כי גם הבילד לא סטבילי, אוקיי? היה לו,

ישי: הוא ייכשל אחרי שעתיים וחצי.

ליאת: בדיוק, בדיוק דקה לפני שהוא יסתיים.  אז כן, אז, ואז היו בסביבות 50% כישלונות ושלוש שעות ריצה. וזה עוד בנוסף לזה שהסביבה של הטסטים לא נבנתה מסקרץ' באופן אוטומטי, זאת אומרת יש פה עוד איזה מימד. והגענו לחצי שעה של בילד עם פלייקי טסט שקרובים לאפס. ולא, חשוב להגיד, לא פשוט עשינו disable טסטים, שזה אז הם לא פלייקי, לא, תיקנו אותם, והיום, מפתחים מרימים סביבת פיתוח בצורה אוטומטית מאוד מאוד מהר, מה שהיה לוקח פעם הרבה זמן ולא רק סביבות פיתוח, גם סביבות סטייג'ינג שזה סביבות שיותר מורכבות וגדולות. אז אנחנו משתפרים ותמיד אני מאוד מאמינה, הפילוסופיה הניהולית שלי היא continuous improvement אי אפשר לעשות את הכול בבת אחת, משתפרים בצעדים, תמיד צריך לחשוב רגע, מה השיפור הבא? כאילו השיפור הבא שאולי חשבתי לפני 3 חודשים הוא שונה היום, אולי צריך לעשות משהו אחר אז צריך כל הזמן לעשות חשיבה במה אני רוצה להשתפר הפעם. 

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

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

ישי: הזמן המבוזבז זה ה-ROI שלי.

ליאת: לגמרי, לגמרי.

ישי: ויש לך גם דרך להראות הנה, הנה התפוקה עלתה?

ליאת: ברור.

ישי: ככה שהסטתי את כל הדולרים האלה לעבודה,

ליאת: לא, תראה, זה תפוקה, זה,

ישי: זה קשה.

ליאת: כמו שאמרתי זה מאוד קשה למדוד בדיוק בדיוק בדיוק כמה המפתחים, מה ה-velocity  של מפתחים, סתם, ביום או בשבוע או בחודש, כן? אבל כן אתה רואה idle time או waiting time של מפתח או waste time או איך שלא תקרא לזה. ואתה יכול למדוד את זה בערך, אתה אומר טוב, תקשיב, מתוך ה-3 שעות האלה, הסדר, זה לא שהוא לא עבד 3 שעות, אבל בוא נגיד שככה שעה היה לו idle ו-contact switching,

ישי: היה לו contact switch, בטח.

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

ישי: הרבה.

ליאת: בדיוק.

ישי: ויש הרבה מפתחים.

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

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

ליאת: כן. אז ניתן, 

ישי: או שהכול מצליח.

ליאת: אין דבר כזה שהכול מצליח, מי שעושה טועה (צוחקת) 

ישי: אז בוא נשמע. 

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

ישי: וכל האנשים אוהבים מאוד שינוי.

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

ישי: הם לא רצו להתעסק בדברים שהם מחוץ לקופסה של הקוד?

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

ישי: מרד.

ליאת: לא של מרד, אלא פשוט לא רוצים, 

ישי: לא זז.

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

ישי: וואלה. 

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

ישי: להתאים את הפתרון לאנשים.

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

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

ישי: אז דיברנו על הצלחות, דיברנו קצת על איך נכשלים. תספרי לי משהו שחשבת על הנושא הזה של engineering efficiency, של  developer experience, משהו שהאמנת בו לפני 5 שנים והפסקת להאמין בו היום.

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

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

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

ישי: שזה מקצוע, שזה חשוב, 

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

ישי: וההבנה הזאת את רואה שהיא מתרגמת ליותר פתיחות לטוב, צריך לעשות השקעות non-functional,

ליאת: נכון.

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

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

ישי: את חושבת שזה משהו, איזשהו תהליך שעבר על חברות ישראליות דווקא? או שאת רואה,

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

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

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

ישי: וזה שפות שונות, התרגום מ-,

ליאת: אז צריך לדעת לתרגם. 

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

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

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

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

ליאת: בדיוק.

ישי: יש תהליך וצריך להסתכל מלמעלה. 

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

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

ישי: לקראת סיום השאלה שאי אפשר להימנע ממנה, AI, LLMs, GenerativeAI, איך בעינייך זה משפיע, אם את רואה את זה כבר  משפיע או איך זה ישפיע בשנים הקרובות על השאלות האלה של developer experience, איך אני מדלוור, efficiency של צוותים. 

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

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

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

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

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

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

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

ישי: אז להסתכל וקצת סבלנות. 

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

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

ליאת: בבקשה. היה לי כיף.

ישי: כנ"ל, אנחנו מחכים ל-keynote שלך ב-devopsdays Israel ואולי גם נפטפט טיפה אחר כך. אז שיהיה המון בהצלחה. 

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

ישי: נתראה בקרוב. 

ליאת: תודה. 

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

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

 (opening music)

Welcome to the second season of Dev Interrupted, the Hebrew version of Dev Interrupted, LinearB's podcast for engineering managers. Where we will host leaders in the industry and talk with them about everything that interests engineering managers, those who work with them and those who might want to manage an engineering organization some day. This season we will place a special emphasis on developer experience. I'm Yishai Beeri, CTO at LinearB, let’s get started.

(transitional music)

Yishai: In this episode I am happy to host Liat Ashkenazi SVP Engineering and GM Israel, at OwnBackup, Hi Liat,

Liat: Hello.

Yishai: What a pleasure you came.

Liat: What fun I have too.

Yishai: So we're talking about the keynote you're giving in a few weeks at DevOpsDays Tel Aviv, a big and impressive event. And we'll give a little glimpse, a little taste of what you're talking about and also a little bit of how you prepared for it, but as usual I want to start by hearing about you, about your journey, where you started and how you got to where you are today.

Liat: The beginning of my journey, back in my high school days, even let's go back a little more, because that'll tell my story even better, I didn't think about computer science at all. I wasn't the kind of geek who messes with computers and tries to find all kinds of ways to hack, and at some point I said well, I I will be a lawyer, which was at a time when hi-tech was not yet that modern, modern is not a modern word either (laughs). I said I would be a lawyer, and even at a graduation party, it was elementary and high school then, there was no middle school, a graduation party in elementary I presented, there was such a presentation and I presented that I was going to be a lawyer, etc. And at some point the situation changed in high school, when I realized that I really, really liked math and was good at it and there was an option for matriculation in computer science, I won't say in which language it would indicate how old I am, and I said 'come on, let me try it'. It was something that really was esoteric at the time, it wasn't that everyone was doing it, and I really tried it and liked it, and then after the army I said well, what do I want to study? I was very confused because once again, I was not one of those people who are always in front of the computer, etc.

Yishai: Wasn't the army already pretty high-tech? 8200 unit?

Liat: No, there wasn't that then, there wasn't that. And I said well, I want something mathematical, I don't want to start reading legal cases and to that, I said I want to change and I said I will go to the computer science track at Tel Aviv University. Then there wasn't one class, I did computer science and economics, and from here my romance with the world of software began. After that I also continued, of course at the same time as work I also continued on to a master's degree in computer science. I liked it so much I did a thesis, and the day that I finished the thesis and gave a lecture to the professors at the university there about the thesis.––I went and bought a kit, once upon a time you bought kits for an MBA degree, so I also have a long romance with Tel Aviv University, I did 3 degrees there.

Yishai: You say work, while you have already started working in the profession?

Liat: Yes, I started working professionally as a developer, it was at first C, C++, then Java and I really loved, I loved this world of software.

Yishai: Where was the first place?

Liat: Avaya, yes, that was the first company and after that I joined Mercure, later became HP, excellent place. It was also my first management school, where I actually progressed to management and it was amazing because there was really a training system for managers in all levels and there was mentorship and I really learned. I learned what it means to manage a team, after that what it means to manage a group, what it means, how It's to establish teams not only locally to establish teams abroad and really it was my amazing school for management. It gave me that boost forward, and yes, after that I advanced to different management positions in different companies. It was very interesting, each company with its own challenges. I really, really love this role, both the technological hat and the culture hat, I really like the combination of things.

Yishai: How much do you, as an SVP Engineering, get to deal with the technical side? You said you love math,

Liat: Yes.

Yishai: Today everything is just people isn't it?

Liat: Yes, it's a lot of people, but there are, there are technical aspects. Architectural decisions need to be made, I'm not in the code review stage, I'm not entering, not at the stage, not in the depth of code review, but I do make architectural decisions. Today for example there are three architects who report to me, me, we have to make decisions, and even a lot of decisions. And DevOps reports to me, and of course all the development managers that report to me, so I say that there is the technological integration here as well, not at the level of the low level, which I also miss, when I miss it I just write with my boy Python. so yes,

Yishai: Not for production.

Liat: Not for production, but I do, I also have the technical touches because I love it. Yes, but a lot of people management, mostly people.

Yishai: Ok, so that is quite a journey, starting with realizing that this is what you love, degrees, work and progress up the entire ladder, we will come back to your journey a bit later and I remind you that we are talking today in preparation for your keynote at DevOpsDays. So you, maybe tell us in a word, like the title of the keynote, what are you going to talk about? What topics?

Liat: I'm going to talk about, we called it Four Dysfunctions of DevOps Teams,

Yishai: only 4?

Liat: Only 4, but actually behind this is how devops actually supports development organizations and how important it is to the impact, on how important it is and how big of an impact it makes to the business in the end, ok? And this is expressed in development efficiency, how much engineering, with the help of devops, can reach a status that is very, very efficient, in terms of execution and also satisfied. I mean it is very, very important this ability of developers to run forward and without devops infrastructures it is impossible to do that.

(transitional music)

Yishai: So why did you choose this topic? You have a lot of experience, certainly very diverse, why specifically this area of ​​developer efficiency and how does devops support this and developer experience?

Liat: So I'll tell you a story. As a developer, let's go back 15 years or so. It frustrated me that I was wasting a lot of time on things that could have been automated or could have taken me 5 minutes instead of 2 hours. And it just hurt my productivity. And I wanted to write code, now I wanted to not only write code, I also wanted to talk to customers and I also wanted to test my code and I wanted everything but I didn't want to waste time on things like spinning up a machine, how long does it take to spin up a machine? 3 hours, okay? I have been waiting for 3 hours to have a machine. Or I'm running a build, the build is broken, okay, now go figure out why the build is broken, someone put something in there. Okay, I failed a test, now go figure out who put in what and all this adjacent work.

Yishai: It works for me.

Liat: Yes, it works exactly for me. And this whole environment just made me less effective in my role. And as I progressed in the management track, I realized that basically my job is to help my teams, to have them deliver frictionlessly, as much as possible. There is never the ideal, okay? And I'll say something else, I went through many companies, I didn't mention it, Avaya, after that Mercure which later became HP then CWT then Harmon then Imperva and now I'm at OwnBackup and each company is something different. The product is also different, completely, if it is on-prem or SaaS, the team structure is also completely different, also the stage, I mean where the company is in terms of maturity is completely different. I mean, you can't say okay, I want an efficient team, so I make a copy paste like this, copying from what I had before. No. You have to understand the company, you have to understand what is needed in development, so this topic of development efficiency is a fascinating topic for me. This means taking development teams and bringing them to a good execution and that they will also be satisfied and not frustrated, okay? The way I felt at the time, I think it's a very, very interesting topic and that's why I chose to talk about it.

Yishai: And you say that in every company it looks different.

Liat: Completely different.

Yishai: I mean, it's not a school-learned solution, but there is a different structure, there are differing needs, but I want to start at the beginning, you come to a company or you are in the company, okay? There are all the things that are soft skills, but when developers say that they are stuck, there are all kinds of problems, but as you said, there is no perfect. How do I even know what my current status is? How do I measure it? How am I, do I have any way of knowing wait, where do we stand? Are we 7? Are we a 3? Are we 17?

Liat: Yes, there are ways. And in every company, you have to find the right ways according to the problems that exist at the time in the company or in the engineering teams that actually cause them to malfunction, okay? So just for example let's measure how long a build takes, let's measure how many tests we fail out of all the tests it was, false, yes?

Yishai: Flaky.

Liat: Flaky, exactly. It can be measured. Now let's analyze the metrics before we start improving so we can see our improvement. And let's see, are we good with the number Flaky? Maybe we only have two tests that fail each time, ok, no need to improve that, let's improve something else. So first of all it's observation, which means that when I enter an organization, I first look, understand, what's not good, what affects, what will significantly impact the life of a developer who wants to write code and deliver with peace of mind (laughs). So I say, I mean it's about the key experience, we'll even call it that. And this is where observation actually comes in first, it's impossible to run ahead and say I did this before, so come on, let's do it here too. No, you have to do some kind of observation and see, okay, what is true for, what is true now.

Yishai: So it's a combination of what? Measurements from systems but also ask the developers?

Liat: Also asking the developers, it's even a kind of interview like this, like having conversations like this with people even in the corridor, I mean, it doesn't have to be formal. And to hear also to measure, because many times there are feelings that they are not, now it is impossible to measure everything, okay? The question of the questions, how to measure the velocity of development. I have been asked this question so many times, it is very difficult, there is something about it, I could write a book about it. So not everything can be measured very, very precisely, but yes, you can measure how long the build takes, how long it takes the developer to spin up a machine, you can measure that, yes? He starts, he finishes, you can enter it, or you can see it in some kind of log or you can, I mean there are ways to measure. You have to try as much as possible to make decisions based on data, this is also something I'm going to talk about because it's also, it's not only what needs to be solved, it's also how we solve, data is also very, very helpful in making decisions in which direction to go.

Yishai: Yes, you talk to developers and you don't always get it, I mean sometimes the picture is where there are the most complaints, it may depend on who is complaining, depending on the character and not necessarily on

Liat: Exactly, I think it should be a combination of both, I mean not just data, not just talk, it's both. And here also comes a lot of experience, I mean there is also a dimension of experience here because I have already seen so many problems and so many cases so it helps me to understand the problems faster and focus on the areas that will probably cause a big improvement.

Yishai: Do you feel that this is a kind of professional specialization? I mean I can bring in VP Engineering to manage my department? Or I can bring a fixer to take a department or an organization that has delivery problems and fix it, which is a slightly different specialty, it's a bit,

Liat: Yeah, look, that's just one dimension of the job. And I don't think so, I mean I don't know if you can reach a situation where there is such a fixer, I think that simply part of his job to lead a large development group is to get to know it, but part of it is also to know how to keep the people and what to say to the people.

Yishai: Well, if there is a good developer experience then they will stay, right?

Liat: Not only that, how to mentor people, how to manage managers who are directors and have their independence and their opinion and you need to know how to empower the team, I mean there are so many dimensions here that I don't think that -, I mean I don't think that there is such a position that is only a fixer that comes has devops, and today I have an amazing team that knows how to suggest and propose the tools and they do see what is broken and they are of course part of, part of what I succeed in is, how I succeed is that I have the right people as well, it's not just like that . So I say there is this here, but I wouldn't call it fixer but,

Yishai: But this is another feature, another ability that a good VP Engineering should have,

Liat: They should have.

Yishai: But it's not standalone.

Liat: I don't think it's standalone, yes.

Yishai: Okay, and you talked about devops, so you are implying that at least in your case, and maybe this is your recommendation, devops sees itself as responsible for these questions of developer experience, of the flow, of not only how things get to production. Because many times devops thinks about okay, how do I bring it to production in a reliable way, how will it run there without problems, but not necessarily about how the life of the developer who wants to deliver and move on.

Liat: Right, so you touched on an important point here, it's also very important to think about the CI and not just the CD. Because the CI has a very, very significant influence on our ability to deliver and deliver well, with high quality. Because if we only think about the CD then where will we catch all the bugs? In production. And our delivery will be slower of course, yes? So it's an impact of velocity and quality. So yes, you really need to think about the CI as well and not just the CD, so devops yes, from its role, I will soon tell if we have time to touch on it what I did in OwnBackup, and in every company it is a little different, but yes, it is very It is very important to also look at the development process and not just the production.

Yishai: So an area that is starting a bit today, a buzzword that is starting to gain momentum is Platform Engineering, how do you see it connecting with the devops? Is it the same? Is it an extension?

Liat: Totally related, very connected, platform engineering connects exactly to the CI that I was talking about, how as a development organization do we make sure that we have the right infrastructures so that we can deliver smoothly, okay?

Yishai: Okay, so you put it in the box like that, in the CI drawer? But they sometimes talk here about things like how do I even know who is responsible for service, where is the documentation, who will do a review for me, these are things that are even before the CI, they really are, I write code and I need to find people to find knowledge, this is also part of -platform, no?

Liat: Yes, for me it's the whole process of the SDLC, I mean I call it CI but it's possible, I mean everyone with their own terminology, for me it's from the first moment we have some kind of requirement to develop a feature, how do we make it go through smoothly or efficiently, until production. And it's not only efficient, it's also high quality, okay? So for me it's one to one, we need,

Yishai: Everything is under the devops people, at least organizationally it is their responsibility.

Liat: Or, but here it is also an issue, it depends on the organization. Not necessarily, I think that developers should have a lot of knowledge of devops today, and not only today, yes? But a developer shouldn't have to just have OK, I write code, someone else will check for me, someone else will take care of the infrastructure, someone else... no. I strongly believe that these capabilities are also needed within the development, but yes, the devops people, I do think that an organization needs devops people and once again, it depends on which organization and how we build it, also this, I'm going to talk about this in the session , at DevOpsDays, it really matters, it really matters where you put the devops people, how many devops people, what the developers are,

Yishai: Is it even a separate department or are they scattered in development.

Liat: What is the communication, exactly, what, how are we, how are the work processes from the devops people to the developers, from the developers, what do the devops do, once again, not one to one written, but that's how responsibility is in general, so it's an issue like that for me itself but I can tell you what I did in OwnBackup. What was in OwnBackup was that there was devops who were responsible for everything, also for the CI, also for the CD, also for the platform engineering, no matter what you call it, all the concepts were responsible for everything. Actually, they were in charge of production, okay? Because they were responsible for both the CD and the CI, so what actually happened? When they are in charge of the production what attracts most of their attention? the production,

Yishai: So they also did some kind of SRE?

Liat: Yes, and what is left for CI? Nothing, there is no time left, not because they are not good people, just because they have no time left because there is no way around it, there are fires burning, customers. Production is more important than anything and the CI is, it wasn't good, I mean it wasn't, as I said at the beginning the frustration of the, that I felt when I was developing, was the same with the developers at OwnBackup because really the build took a long time, things broke. The infrastructure of the CI was not good. So what I did was I recruited devops people to give their attention to CI because at the time that was what was required.

Yishai: And were they were earmarked for this? as if their time is wasted,

Liat: Hypocrites, total hypocrites, separate team there,

Yishai: who did not report to that team.

Liat: That he didn't report to that team, that they're in charge of CI, concentrating on CI, concentrating on raising automated environments for developers, concentrating on that. Now, once again I return to the coffee feast we talked about. Is this true for every organization? No. This was true for OwnBackup at the time I joined, and it is also true now, will it be true for OwnBackup in another year? Maybe not, maybe we'll make a change, I say but at that moment, I mean it was a place to give it the attention because OwnBackup is a company that grew very, very fast, fast growth, doubled itself every year, but the infrastructure was still like a startup Up of 10 people, okay? That we are a start-up today of 800 people, 150 people in development in my group. It is impossible to continue working in the same way. And so I had to give it the focus, I still think it should be given the focus, on the platform engineering, CI, whatever we call it, so that we really have the infrastructure, we put in the right infrastructure, and we really showed a very, very great success.

Yishai: How long does it take? Did you recruit a team and say voila, I see success?

Liat: Well, so first of all I recruited people I already knew were good because I knew them before. (laughing) And I really succeeded,

Yishai: Our network is part of our assets, isn't it?

Liat: So they brought value very, very quickly. And let's say let's take a given example, did we talk about data? So when I joined I started measuring how long the build takes, okay? Not me personally, but my people started measuring, and it took 3 hours. Today we are on half an hour,

Yishai: So every pull request, every change in the code I make, 3 hours to test it in an environment that is not local,

Liat: In an environment that is local, yes, no, that is not local but that the build is running and environment, yes,

Yishai: 3 hours, ok, a lot of coffee.

Liat: A lot of coffee and a lot of frustration, why? Because the build isn't stable either, okay? He had,

Yishai: It will fail after two and a half hours.

Liat: Exactly, exactly a minute before it ends. So yeah, so, and then there were around 50% failures and three hours of running time. And this is in addition to the fact that the environment of the tests was not automatically built from scratch, so there is another dimension here. And we reached half an hour of Bild with a flaky test that is close to zero. And no, it's important to say, we didn't just disable tests, that's when they're not flaky, no, we fixed them, and today, developers automatically set up a development environment very, very quickly, which used to take a lot of time and not only development environments, staging environments as well which is more complex and large environments. So we improve and I always strongly believe, my management philosophy is continuous improvement, you can't do everything at once, you improve in steps, you always have to think for a moment, what is the next improvement? As if the next improvement I might have thought of 3 months ago is different today, maybe I need to do something different so I need to constantly think about what I want to improve this time.

Yishai: So I want to challenge you for a moment, there is a success story here that you have greatly shortened the build process, I have no doubt that the developers are more than disappointed, but in the end you are serving the business, right? And you want the engineering to be aligned with what the business needs and for the CEO, in such a placeholder, someone who is not in engineering does not care about the continuation of the build, so how do you show that there is an improvement here that contributes to the business? As if it allows you to give more to the business?

Liat: So first of all, it was very easy to measure it. Because if you calculate, and by the way I have a slide like this - it's beautiful - that I showed to the CEO, then you touched on the point, because it's easy to calculate, you see 3 hours for a build versus half an hour for a build, you see 50% success versus 99% success, and then you Calculate how much does a developer cost per month? How much time did the developer spend in his month, how many dollars, translating to dollars is very, very simple, really, because,

Yishai: The wasted time is my ROI.

Liat: Totally, totally.

Yishai: And do you also have a way to show here, here the output has increased?

Liat: Obviously.

Yishai: So I diverted all those dollars to work,

Liat: No, look, it's output, it's,

Yishai: It is difficult.

Liat: As I said, it is very difficult to measure exactly exactly how many developers, what is the velocity of developers, simply, per day or week or month, yes? But yes you see idle time or waiting time of a developer or waste time or whatever you call it. And you can measure it approximately, you say well, listen, out of those 3 hours, the order, it's not that he didn't work for 3 hours, but let's say that he had idle and context switching for about an hour,

Yishai: They had a context switch, sure.

Liat: True, and from the fact that they waited for the machine, they waited or tried to spin up a machine for 3 hours because they spin them up manually and not automatically, how long did it take them, two hours, okay. So you are calculating some kind of calculation here, so wait, is it possible, and we do commits all the time, I mean this is a company that we constantly have frequent deployments. So is it possible that we saved an hour of developer time a day here? Let's calculate how much an hour of a developer costs per day?

Yishai: Much.

Liat: exactly.

Yishai: And there are many developers.

Liat: So it is possible to make such a calculation and when I showed it to people in the business, even to our CRO, I mean they understood what it was about, because once you translate it into dollars it is easy to understand.

Yishai: So for them it is an investment that has paid for itself and it is possible to perhaps put another investment in the same area, to continue investing in improvements in this area. So from a success story, I want you to choose for me a story of a change that didn't work out and it doesn't matter which company, but a change where you identified a problem and tried to change it and something there didn't work.

Liat: Yes. then we can

Yishai: Or everything works out.

Liat: There is no such thing as everything succeeding, whoever does makes mistakes (laughing)

Yishai: So let's hear.

Liat: Okay, I'll give an example of something that didn't work. Basically, those who come to make a change think about the change, think about its shortcomings, what its advantages are, and every change is also related to people. And that should be remembered and I forgot. it was in

Yishai: And all people love change very much.

Liat: exactly. And organizational structure also influences, very much influences the way of working and the ability to reach results that suit the organization at that moment. And I decided to make an organizational change in which I put more people into the teams, that there will be more heterogeneous teams and that the developers will also do things that are not just writing code. Say writing tests, devops, all that. And there was a very, very big opposition from the developers, it wasn't in OwnBackup, from the developers for this change, and I didn't take that into account.

Yishai: They didn't want to mess with things that were outside the box of the code?

Liat: No, they didn't want to. And as much as I tried to make them buy-in for it, maybe not enough, maybe I didn't try enough, maybe I should have tried more, it was very difficult to assimilate, this change because there was a very, very big resistance to change. It's not a resistance now, is it? A demonstration is a resistance of…

Yishai: Rebellion.

Liat: Not of rebellion, but simply not wanting,

Yishai: Not moving.

Liat: Like yes? It's not not shouting, it just doesn't move. And for me it was a failure because I was trying to bring about a change that actually the people were not yet so ripe for it. So, I mean, in this whole aspect of changes, you also have to take into account that there are people here (laughs).

Yishai: Walla.

Liat: And you need to think and give them more buy-in, or say okay, right now the organization is not ready for that, let's do something a little different, okay?

Yishai: Adapt the solution to the people.

Liat: Adapt the solution to the people. I adapted the solution to the organization, I adapted it less to the people, and have learned from mistakes.

(transitional music)

Yishai: So we talked about successes, we talked a little about how we fail. Tell me something you thought about this topic of engineering efficiency, of developer experience, something you believed in 5 years ago and stopped believing in today.

Liat: I didn't think it was interesting to the business. And I couldn't believe how interesting it was for the business. And we talked about how the CEO, there is absolutely an interest of the business in this matter because the business today understands more, and I'm not talking only about the business in OwnBackup, I think that the business in OwnBackup is amazing, because there really is an understanding of the matter, but not only in OwnBackup, they are beginning to understand how much this actually ultimately affects the company's ability to deliver what it needs to its customers and to the field. So today there is much more understanding of how important development infrastructures are, compared to the past when it was less, there was less of this understanding. And What surprised me, I mean, as much as I am in my current position, it really surprised me that there is an understanding of the business to,

Yishai: Has your understanding changed? Or is business in general really moving a little more to look at these questions, to be interested in it, to understand that it is significant?

Liat: Look, I think it's both. My ability today to talk about the business and explain things is also better, there's nothing to be done, it comes with experience. But I think that also, as time goes by, we realize how important automation is, how important it is tech-, like if we talk about AI then it's like this, I'll get into that too, I mean there's more of a deep understanding of business, yes, it's important how you do the the things And not only come on, come on, come on, come on, come on, come on, okay? I mean there is a need, and there is also more understanding, of how important it is to bring in a development manager who knows how to do these things, to bring development organizations to excellence. Which is something I really like to do, how important it is to bring in such a development manager and not just a development manager who knows how to do a code review. I mean you understand, I think there is more understanding in business, once again, in the industry in general, which is important.

Yishai: that it's a profession, that it's important,

Liat: That it is important, that automation is an important thing, that it is important to invest in it. There was less of this understanding in the past. Come on, write code, do manual tests, whatever the process is, deliver it quickly, and I think that-,

Yishai: And this understanding you see translates into more openness to the good, you need to make non-functional investments,

Liat: Right.

Yishai: We have to wait a moment with deliveries because I'm building something here that will later produce a higher velocity, but do we need to take a hit sooner?

Liat: Completely. I really feel that there is more and more understanding of the business, how to invest in a more correct architecture, invest in infrastructure, really. It's noticeable and it's something that surprised me because 5 years ago it was a little different.

Yishai: Do you think this is something, some kind of process that Israeli companies have gone through? or you see,

Liat: No, I don't think it's specifically about Israeli companies. I think that in general in the software world there is a deeper understanding of development processes. Up to the level of CEOs, they understand that automation is needed for things, they understand that in order to run regressions, you can't run regressions manually because then you put the whole development on running regressions, as if just for example, okay? It's an understanding that more and more this is how software enters the business world And not only in development managers.

Yishai: It's interesting from our side, at LinearB we really see a significant shift in how companies, managements think about this world of efficiency. looking for tooling, it is starting to be something that has a budget, that has attention from the CEO level and below. So we experience it a little more as the maturity of the market we are in, but I very much agree with you that once upon a time the CEO mainly looked at the numbers of sales and it was important for him to understand the mechanics inside. Now it is important for the CEO to understand the mechanics of the development process as well. Because in the end this is the biggest result of the company and most companies are software companies, so if you don't understand this, you will be left behind.

Liat: exactly. And you need a development manager who also knew how to explain it to him well, really, because it's very difficult to understand in a field you don't know that much about.

Yishai: And it's different languages, the translation from,

Liat: So you need to know how to translate.

(transitional music)

Yishai: So if we go back to your talk, which is coming soon at devopsdays, and we talked about successes, we talked about failures, we talked a little about changes in the perception of developments. Give us one more interesting point, like a sneak peek into something you're going to talk about, that we may not have thought about until today or that may be a little surprising to those who are not in this field every day.

Liat: I think the surprise is how to think about all the parameters together. I mean, sometimes we only look at the good, the pipeline is broken, let's fix it. Sometimes you only look well, let's recruit more people here and there. I think that the combination of the more holistic or more high level view is something that I will touch on in the lecture of which people I need to recruit, where do I put the people, what is the structure, how is the communication, what is the communication between the development and devops people, how do I identify, how Do I make data driven decisions? How do I identify what I need, how do I actually build my CI? Or whatever we call it correctly, I mean the combination between these things, I think that's what brings the more overall success, and not one point success.

Yishai: You say it's not some swag and we ended up in one place,

Liat: exactly.

Yishai: There is a process and you have to look from above.

Liat: You have to look at things holistically and make a decision first of all at a high level and then break it down into details, once again, I don't think everything should be done, it is possible or should or should be done at once, but yes to look at the totality of things. And yes, I think this is something I will talk about that will be interesting.

(transitional music)

Yishai: Towards the end of the question that cannot be avoided, AI, LLMs, GenerativeAI, how do you think it affects, if you see it already affecting or how it will affect in the coming years these questions of developer experience, how I delve, efficiency of teams.

Liat: As we already understood before, I like to make the developer's life easy and efficient. And so I am very excited about what is going to happen and what is already starting to happen around this world of AI automation, I think it will bring us to a much better place. Because the developer, the development people, in general, the developer, the QA, the devops will deal with innovation and everything else will be done automatically by itself. The things that don't need to be done manually or automatically but that need to be planned in advance. I think it will bring us to a better situation, more efficient, truer to us and we will really have the things we are left with, which requires a lot of thinking around them, not everything is possible.

Yishai: So do you see a future where the developers mainly give instructions to the machines that write the code and connect the things and test?

Liat: Completely. Not long ago we had the hackathon, we did the hackathon at OwnBackup, it was a week or two ago and they brought amazing ideas there. This also means how to make the lives of the developers better, also how to make the lives of our customers better through all kinds of tools that through the UI access all kinds of AI options that help them to navigate. So I really think that, I am very excited about this field.

Yishai: What does this mean for the Juniors World Governor? If now the developer only or mainly needs to do the activation of the tools, but not to write most of the lines of code, then what, does this change the career path of a developer? Or what does it mean to be a junior developer who is not polished enough yet?

Liat: So a junior developer still has to design a feature how we want to do it, the junior developer designs a smaller feature than someone who designs a larger feature or a whole system, yes? And there will still be room here to think about innovations, how do we insert code here that is a little more complicated. I mean, not everything is black work we call it, right? There are many things that juniors can do even without much experience, that's fine, we still have small features, we still have things that need thought behind them and yes, and configuring the tools to do it for us, okay? And if it's even just for configuring a tool in such a way that it will pick up an environment for us or run a certain set of tests for us according to exactly where we touched, in my opinion it will make our lives easier and more efficient.

Yishai: Excellent, so in conclusion, one piece of advice if you want to give a manager, a development manager who wants to start touching this world of how to improve the process, the productivity, the joy of the developers. Surely we all feel that something is broken, something is stuttering, how to start, how to take the first step for those who have not touched it in an orderly manner.

Liat: The first step is really observation. That means looking, collecting data, interviewing, kind of interviewing people, the developers themselves. And that's the first piece of advice. Don't run, say wait, I've done this before, come on come on, let's do it here too. This is not true, as I said from the failure story I told to also see what people are ready for, what kind of change people are ready for, so really this whole thing is observation, this is the first step.

Yishai: So look and have some patience.

Liat: A little patience, to look, and after doing some kind of analysis, once again, it shouldn't take months, yes? But some kind of observation, to collect data and then make the decision what is the first step? It's impossible to do everything, this is true in general for improvement, it's not only related to devops, in general, in all the changes I've made, think for a moment, what's the first step? After that, what's the next step, okay? Don't go and build a plan for the year ahead, we are agile, the world changes all the time, okay? What is the first thing I want, what is the second thing I want to do and move forward from here.

Yishai: Excellent. Liat, thank you very much for coming.

Liat: you are welcome. I had fun.

Yishai: As above, we are waiting for your keynote at devopsdays Israel and maybe we will also chat a bit afterwards. So good luck.

Liat: Thank you.

Yishai: See you soon.

Liat: Thanks.

(transitional music)

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