Deciphering the R&D Operations Manager Role, Nofar Ben Kereth

בפרק זה, נופר בן קרת, מנהלת R&D Operations בחברת Cloudinary מספרת מה זה בכלל התפקיד הזה?! למי זה מתאים ואיזה כישורים צריך...ולמה בסוף בכל ארגוני הפיתוח יהיו תפקידים כאלה. 

In this episode, Nofar Ben Kereth R&D Operations Manager at Cloudinary helps us demystify this emerging role...what it even means, who it's suited for, and why every engineering organization will need such a function eventually.

Transcript

Copy Transcript Copied

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

פיתוח בהפרעה עם ישי  ונופר בן קרת

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

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

בפרק הזה אנחנו שמחים לארח את נופר בן קרת, מנהלת אופרציה בפיתוח, ב-Cloudinary . הי נופר, איזה כיף שאת פה.

נופר: הי ישי, כיף להיות פה.

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

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

ישי: התפקיד הזה של PMO, וניהול PMOs כבר נגע בצוותים שמפתחים תוכנה או שזה יותר באזורים שהם Low Tech?

 ״ניהול אופרציה - זה בעיקר עניין של אופי!״

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

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

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

ישי: כמה אנשים היו אז ב-Cloudinary?

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

ישי: זה רק הגודל של הR&D?

נופר: כן רק R&D. החברה הכפילה את עצמה היינו 200 וקצת. היום אנחנו 500. 

ישי: וואו. אז את מגיעה לחברה עם 50 מפתחים או ארגון R&D של 50 אנשים. ולמי את מדווחת? מי הכניס אותך לתפקיד? עם מי עבדת?

נופר: אז אורי הוא VP R&D, הוא המנהל שלי מההתחלה.

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

נופר: בדרך כלל כששואלים אותי מה התפקיד אומר אז אני אומרת שאני אחראית לכל התהליכים שהם לא production. כל תהליכי התכנון הקצר טווח, ארוכי טווח, תכנון רבעוני, ספרינטים, מתודולוגיות, עבודה. איך אנחנו מיישמים את זה בתוך Cloudinary? יש הרבה מתודות. מתודולוגיות מעולות, אבל אנחנו לא יכולים לקחת את זה as is ולהשתית את זה על ארגון. אז באמת לראות מה ה-flavor שלנו בתוך Cloudinary. מה מתאים לנו בתוך התרבות? אני מנהלת את כל הכלים והטמעה של כלים חדשים, כל מה שקשור במדדים דאשבורדים, כל מה שיוצא בזה המעקב של הדאשבורדים ובעצם גם להסיק מזה מסקנות ולהבין מה אנחנו צריכים לעשות כדי לשפר, בעצם זה שהם איזה פרויקטים נגזרים מכל המדדים האלה. ואם כבר אמרתי פרויקטים אז גם ניהול לכל הפרוייקטים. יש לנו פרוייקטים נרחבים חוצי קבוצות, גם המתודולוגיות וניהול פרויקטים, מה זה ניהול פרויקטים ב-R&D של Cloudinary, כלומר, באיזה כלים אנחנו משתמשים? איך אנחנו מנהלים את הפרויקט עצמו? מבחינת תקשורת, stake holders, כל מה שקשור לזה ובאופן כללי ייעול התהליכים והאפקטיביות של הפיתוח. זה קצת באוויר, אבל זה באמת כולל הרבה דברים, ושוב זה החל מניהול ידע ו-Jira והמתודולוגיות עבודה ועד גם לקורס on boarding לעובדים חדשים. שזה באמת ורסטיליות מאוד מאוד גדולה בתפקיד.

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

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

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

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

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

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

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

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

ישי: אוקיי מבחינת הצוות שלך? איך זה מתנהל? מתאר לעצמי שיש לך את המנהל שלך VP R&D,  מי עוד בצוות שלך? ב-first team שלך? איך זה נראה?

נופר: אז יש תחתי עובדת אחת כרגע שהיא בעצם משחקת על שני כובעים. אחד, יש לה את הצוותים שלה, צוותים שהיא הגיעה ספציפית לעזור להם ביום יום שלהם, ממש בספרינטים לראות שהם לוקחים את המתודולוגיה בתצורה הנכונה, שהם אפקטיביים שהם מבינים איך איך הם נכנסים לתוך הR&D אז זה בעצם איזשהו כובע שהוא יותר ככה נקודתי לצוותים, וגם יש לה את הכובע הרוחבי יותר, שזה פרויקטים רחבי עם הטמעות של דברים. ניהול הכלים בפיתוח. אז כרגע לי יש עובדת אחת, אנחנו נתרחב בקרוב ואנחנו הולכים לכיוון של גילדות יותר. כלומר, אנחנו מאוד מנסים לעשות את הקבוצות והצוותים עצמאיים. כלומר, end to end מבחינת התפקידים, devops  נכנסים לתוך הצוותים ממש, אוטומציה וכולם באמת end to end. אז גם מנהלי פרויקטים. בקרוב יהיו מנהלי פרויקטים PMO ו-program יהיו בתוך הקבוצות עצמן ותהיה איזושהי גילדה רוחבית שתדבר. 

ישי: אז הPMO, יהיו בצוותים ואת תהיי סוג של ראש הגילדה

נופר: כן היה גם צוות…

ישי: אז את עוזרת להם.

נופר: בדיוק יהיה גם גרעין וגם גילדה. 

ישי: הבנתי. אבל מבחינת הצוות שלך, זאת אומרת הצוות שאת מדווחת בו אז זה את, VP R&D, וראשי הקבוצות זה הפורום?

נופר: כן

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

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

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

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

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

נופר: נכון

ישי: אז מה הכי קשה מה הכי מעצבן?

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

ישי: אז צריך טיפ-טיפה לפחד מנופר….

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

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

נופר: כן בדיוק

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

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

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

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

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

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

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

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

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

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

ישי: ספרי לי קצת לגבי הנושא של managing up - של ניהול כלפי מעלה. בסוף יש לך בוס, VP R&D. איך בתפקיד הזה מתנהלים ומנהלים כלפי כלפי הבוס או הבוסית?

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

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

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

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

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

ישי: כי חסכת להם זמן והקלת להם את החיים?

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

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

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

ישי: אז קצת אוהבים וקצת מפחדים.

נופר: כן כן כן. אולי היינו צריכים להביא אותם לדבר.

ישי: נעשה עוד פרק…

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

נופר: כן אז בעצם אני מנהלת עם עוד 4 נשים מדהימות. קהילה של מנהלות פרויקטים. היום אנחנו כבר 2000 מנהלות פרויקטים בקהילה שזה מדהים. 2000 בארץ - עוד לא התרחבנו לחו"ל, אנחנו נגיע לשם. כן, זה רק אומר כמה התחום הזה הוא הוא מטורף, אז אני אני כבר שם שנה בניהול של הקהילה. הקהילה קמה לפני 3 שנים. אני הצטרפתי, הייתי מאוד פעילה בקהילה ופנו אליי לשאול אם אני רוצה להצטרף. קהילה מדהימה באמת יש שם הרבה תמיכה ועזרה ושיתוף, וזה ככה תחום בגלל שהוא עוד חדש. הוא חדש … לא חדש, הוא עוד מתהווה. אז יש באמת הרבה חשיבה משותפת ואנחנו עושות הרבה מפגשים ומיטאפים והרבה תכנים, ומאוד עוזרות אחת לשנייה.

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

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

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

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

ישי: זה נכון אבל לומר שהתפקיד הזה יש לו איזשהו הטיה או משיכה יותר לנשים יש בו יותר נשים מאשר שאר תפקידים דומים בהייטק ?

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

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

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

ישי: אני חושב שההגדרות כאלה עוזרות מאוד להבשלה של תחום כתחום עיסוק. בסופו של דבר יושבת ההנהלה של איזה סטארט אפ אומרת ״אנחנו מרגישים שאנחנו צריכים *משהו* בתפקיד הזה״. רגע, זה release manager, זה project manager?. זה developer experience?. מה, מה בכלל צריך להביא? ובארץ לא מעט מנהלים או מנהלות בתחומים האלה זה פעם ראשונה בתפקיד, אז זה לא גייסו אף פעם ולא ניהלו אף פעם מישהו מהדיסיפלינה הזאת אז לדעתי מאוד יעזור. 

נופר: לגמרי

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

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

ישי: אז זה גם מאפשר לדבר על התפתחות של קריירה, מה זה אומר קריירה בעולם של של R&D Operations או של כל אחד מהשמות השונים לתפקידים.

נופר: לגמרי… יש כל כך הרבה שמות...

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

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

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

נופר: אז. גם אנשים שהם מתוך הפיתוח הרבה פעמים עושים את המעבר הזה. זה לא סופר נפוץ, אבל גם עושים את זה אני חושבת…

ישי : ממש developers וראשי צוותים?

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

ישי: ספרי קצת על האינטראקציה עם אנשים מחוץ לארגון הפיתוח או מחלקות שונות: sales, marketing, customer success ואחרות. איפה התפקיד הזה פוגש אותם?

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

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

נופר: כן לגמרי לגמרי אז למשל, בספרינטים. אז בספרינטים אני אשים יותר דגש על על מתודולוגיות העבודה ואיך הצוות צריך ליישם ואיך נהיה יותר אפקטיביים והפרודקט אופרשיינס היא תשים יותר דגש על איך לאפות את הסטוריז בצורה יותר טובה. ואיך כותבים requirements ואיך  עושים acceptance criteria בצורה יותר נכונה ואיך אנחנו גם דואגים שהפיתוח יעבוד על הדברים הנכונים ולא רק להביא פיצ'רים שמגניבים, אלא איך זה מתחבר לתמונה הכללית. ואיך אנחנו נותנים את הערך הכי גדול ללקוח שלנו ואיך זה באמת, איך לכתוב objective בצורה נכונה. אם אנחנו מסתכלים בתמונה של הרבעון. אז כן יש אזורים, שחופפים, ושם אנחנו נעבוד מאוד מאוד בצמוד ובשאר אנחנו נתקשר יותר. וכמובן product operations זה גם על האזור של הביטאות, ומה זה alpha ומה זה beta ומה זה early access ואיך אנחנו משחררים דברים החוצה ואיך אנחנו עושים הכשרות לשאר החברה. כן.

ישי: אז, עם כמה דוגמאות שאני מכיר מהעולם של צרכים, של R&D, מול פרודקט באזורים שהזכרת -  אם R&D רוצה יותר זמן לnon functional ורוצה להשקיע בnon functional. את המייצגת שלו מול פרודקט אופרשיינס? להגיד "חבר'ה בואו, בספרינט הזה צריך לייצר עוד capacity ל-nonfunctional".  או שזה R&D ישירות מול פרויקט?

נופר: אז החלום, והאמת שזה קורה אצלנו ברוב הצוותים זה שהpair הזה של R&D של מנהל פיתוח ופרודקט יידעו לעבוד כל כך טוב לתקשר כל כך טוב שהם יודעים מתי צריך את הR&D אג'נדה ומתי פרודקט. אז רוב הצוותים באמת יודעים לעשות את זה, אנחנו יותר נגדיר. האם יש capacity קבוע שאנחנו רוצים בתור ארגון להשאיר לזה? האם יש איזשהו רבעון ספציפי שעכשיו אנחנו אומרים אנחנו מתמקדים בהפרדה לmicro services, לא יודעת, סתם, אני ממציאה - אז באמת זה של הצוותים הownership. אנחנו הenablers לדבר הזה.

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

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

ישי: ו-product operations זה משהו שגם נופל תחת המטרייה של Women in Project Management? זה מבחינתך חלק מהסל הזה של תפקידים ומשרות שהקהילה שלך מדברת עליה?

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

ישי: נכון יש גם ארגונים שבהם product ו-R&D הם ביחד.

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

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

נופר: כן. לי אישית, מאוד חשוב שנעבוד אותו עם מחלקות אחרות. support, CS'  CSMs זה מאוד חשוב, החל מעצם זה שאנחנו עובדים ביחד,  ואנחנו עובדים די צמוד וגם למשל קריאות on call ,שהמפתחים שלנו צריכים לפתור, והsupport צריכים את המפתחים, ומאוד חשוב לעבוד טוב ביחד ומאוד חשוב להכיר אחד את השני ולהכיר את השפה. אז אנחנו עושים הרבה בתחום הזה. יכולה לספר על משהו מאוד מעניין שאנחנו עושים כל מישהו חדש שמפתח שמגיע ל-Cloudinary הוא מצטרף יומיים לSupport שלנו, פותר איתם טיקטים. והם תמיד נורא סקפטים בהתחלה, אבל בסופו של דבר הם יוצאים משם באמת על גבול המסנוורים, גם מהרמה של הSupport. וגם זה עוזר להם מאוד להתקרב ללקוחות ולהבין שמבקשים אחרי זה משהו on call. או שאיזשהו support מבקש איזשהו פתרון אז זה מאוד מבינים אחד את השני וגם ברמה החברית הם יוצרים שם קשרים שהם באמת טובים אח"כ לעבודה.

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

נופר: מי שרוצה יכול לעשות את זה. אז כן הם חוזרים… וזה באמת איזשהו תהליך הכי קטנטן שעשינו והוא יצר קשר מאוד טוב בין שתי המחלקות, אז לי באופן אישי חשוב גם כמובן גם באזור התהליכים שאנחנו עושים כל מיני triage של באגים חשובים ללקוחות בדברים כאלה, אבל יותר חשוב לי לקרב בין המחלקות ברמה התקשורתית. עשינו כל מיני דברים, למשל גם הבאנו, עשינו איזשהו תהליך עם CSM שהם כל רבעון עושים לנו real life customer use cases הם באים שלושה csmים ומספרים לנו על איך הלקוחות משתמשים בפיצ'רים חדשים שיצאו ובאיזה use case מעניין וזה באמת מחבר גם את הפיתוח לביזנס ומה הלקוחות רוצים. ומה איפה הבעיות של הלקוחות וזה יוצר ערך אדיר במה שהם עושים אחר כך בפועל. אבל גם ברמת התקשורת בין המחלקות ואיך אנחנו מעורבים עם כולם.

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

נופר: בדיוק

ישי: שזה עוד הרחבה של תפקיד הproject manager וזה זולג לנושא של on boarding של עובדים חדשים בR&D. את קצת הזכרת את זה שזה גם אזור שאת נוגעת בו. אז באמת מה? מה את עושה באזור הזה, של בניין הכוח? בסוף מנהלים מגייסים עושים עבודה, מגייסים מישהו נהוג שהאחריות לon boarding זה של המנהלים. איפה זה פוגש אותך?

נופר: אנחנו קורים לזה NHC - זה New Hires Community וזה בעצם, הצורך הזה קם בקורונה. כלומר, זה משהו כבר לא חדש. הקורונה לא חדשה. זה שנתיים, זה קם בקורונה. גייסנו הרבה, המשכנו לגייס בקורונה גם בסגרים והיה מאוד קשה לעשות on boarding לאנשים חדשים. לא ברמה הטכנית, ברמה של הecosystem, ואיך אני fit in  בתוך הR&D ומה התרבות פה? ואיך אני מכיר אנשים ואיפה אני גם נמצא אפילו בארגון מבחינה היררכית. איזה קבוצות יש סביבי והחלטנו להקים איזה שהיא קראנו לזה קהילה כי מאוד רצינו שזה יהיה משהו שהם גם איך יוכלו אחרי זה לחזור לשם ולהכיר אנשים, וזה בעצם און בורדינג שהוא לא טכני. מן הסתם, המנהל הוא האחריות אצלו לעשות און בורדינג טכני ולהכניס את הבנאדם לאזורים ולכלים ולאיך צוות עובד, ופה אנחנו נותנים איזשהו פתרון שהוא יותר כלל R&D וזמין - קורס או תוכנית נקרא לזה שנותנת טעימות מכל הR&D, אנחנו מתחילים. קודם כל זה 4 ימים. כל יום אנחנו מתחילים ב peer discussion. יש לנו את הHRBP שמגיעה לכל peer discussion כזה ומעלה איזושהי שאלה קצת יותר אישית כזאת, ואז אנחנו נותנים טעימות, כל ראש קבוצה בא עם אנשי הצוותים שלו ומכיר את כל הקבוצה ומה הם עושים על מה הם אחראים. שמים שם הרבה דגש על הפן האישי. אנחנו כבר הרבה אנשים, אבל כשהתחלנו את הNHC הזה היינו 10 צוותים, היום אנחנו 20, התחלנו את הנסיעה. אז כל ראש צוות בא ודיבר ממש על האנשים שלו ועל התחביבים שלהם וזה ממש מגניב. היום אנחנו כבר לא מסוגלים לעשות את זה, אז קצת הורדנו לצערי את הפן האישי הזה או מזערנו אותו. אז ראשי קבוצות, ואיזה שהוא סשן שהוא ארכיטקטוני שנותן, חולש על כל המערכת ועל כל הקבוצות, ולא רק על האזור והVP פרודקט באה לספר קצת את הצד שלה ואיך היא רואה את היחסים עם הפרודקט. יש סשן שהוא external function שהוא  סיפרתי על ה CS והsupport וdocumentation באים אז באמת איזשהי טעימה מכל האקוסיסטם שלנו. ואיך אנחנו עובדים וגם ליצור איזושהי קהילה אתה אתה רואה את האנשים האלה אחרי זה חברים, כלומר זה כל פעם. תכנית של בין 8 לעשרה אנשים, באמת חברים אח"כ ומכירים אנשים מצוותים אחרים. והם יודעים לפנות אליהם, וזה לא רק עוד מישהו עם תמונה בסלאק.

ישי: אז אנשים זוכרים את הcohort שהם באו איתו? וכאילו זה החבר'ה שלי, מהמחזור שלי?

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

ישי: ובצד שכן קשור לטכני ולdelivery הנושא הזה של הנושא, של מעקב אחרי on boarding, יעילות שלנו בramp up time - זה תחת האחריות שלך, לעזור למנהלים ולראשי הקבוצות לדעת שיש לנו תהליך יעיל, של און בורדינג שאנחנו מצליחים להביא אנשים להיות לתפקד בצורה יעילה בצוות, לעשות reviews לאחרים, להשתתף בכל התהליכים?

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

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

אני רוצה לדבר איתך טיפה על על, זה שהוא buzz word שהולך וקצת עולה ומאוד מתחבר לתפקיד שאנחנו מדברים עליו. הנושא של developer experience עם דגש על developer experience פנימי, כלומר לא המפתחים שעובדים עם נגיד ה API של קלאודינרי, אלא המפתחים והמפתחות שעובדים בקלאודינרי, ומה החוויה שלהם ביום יום? איפה זה פוגש אותך? איך את רואה את זה בתוך התפקיד? גם שלך וגם בקהילה.

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

ישי: המפתחים שלך מאוד אוהבים את Jira, נכון?

נופר: הם חולים על  Jira, אין ספק…

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

ישי: את מדברת על הבנה של הbusiness context ועל ההבנה של הWHY. למה אנחנו מפתחים את הפיצ'ר הזה? איפה זה עוזר לחברה וללקוחות?

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

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

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

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

נופר: כן

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

נופר: אני לא חושבת שיש איזשהו pattern כי זה מאוד משתנה בין צוות לצוות זה ומה הצוות עושה, אבל זה תמיד…

ישי: זה עניין של productivity?  כלי פרודוקטיביות?

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

ישי: אה ממש ספריות לקוד בייס

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

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

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

ישי: ואת הרגשת, זאת אומרת, התרבות הזאת ניכרה כבר בשלבי הinterview שלך?

נופר: כן לגמרי לגמרי.

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

נופר בן קרת: תודה רבה לך ישי.

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

אני ישי בארי. נשתמע בפרק הבא!

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

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

(Opening music)

Dev Interrupted with Yishai Beeri and Nofar Ben Kereth

Yishai: Welcome to Dev Interrupted, the Hebrew version of Dev Interrupted, LinearB's successful podcast for engineering managers. Here we will talk about everything that hinders engineering managers. I am Yishai Beeri, CTO at LinearB.

With the announcement of our big fundraising round, we are excited to bring you the podcast in Hebrew. We will host leaders from the industry to talk about everything that hinders engineering managers, those who work with them and those who want to one day manage an engineering organization.

In this episode we are happy to host Nofer Ben Kereth, R&D Operations Manager, at Cloudinary. Hi Nofar, nice to have you here.

Nofar: Hi Yishai, nice to be here.

Yishai: Great. So as usual, we'll start by asking you how did you even get here? Tell me a little about your journey throughout your career, which led you to become an engineering operations manager.

Nofar: So this is how - I started industrial and management studies at Shenkar, I studied there for 4 years, and actually I started working in the field of operations and project management there. That is, not yet in the high-tech industry. During my studies I managed the operation of the student union, which actually included working with external suppliers. I managed the position, the union’s budget, I produced the union’s job fairs. I continued this at the same time as working a regular day job, later I continued in the union. I held a significant role, albeit for a short time, but I really learned a lot there. And from there I continued to a consulting company called Simple - where I held two positions, I started as PMO for one of the clients - where I really got educated on the job. Both at Simple in general and at this client specifically, I also learned a lot about how the organization actually works. What does the organization need? How do you identify the challenges of an organization? And after two years, I was promoted to be a team leader, managing PMOs and clients in all kinds of fields, which was very, very interesting. From small start-up companies to very, very large organizations. But I was also in the areas of hospitals and health funds (edit for clarity: Israeli health services). So I really saw a lot and it was very, very interesting to see and also to compare the organizations and to understand that we actually didn't invent problems, we all have the same problems, even in Low Tech, in a hospital, and in high-tech companies.

״R&D operations management is first and foremost a matter of character."

Yishai: This role of PMO, and the management of PMOs – did this already involve teams that develop software or is it more in areas that are Low Tech?

Nofar: Both, engineering teams and entire engineering organizations, and also an area of ​​project managers in the field of implementations, of new tools in health insurance funds, this has always been in the software area. I've also done things that are less technical, it was really very interesting to see some sort of spectrum of areas, and that everyone ends up encountering the same problems whether it's software or not. After almost 4 years I decided to move to the next level. I started working at Cloudinary, where I became the R&D Operations Manager. I ended up in one position and it developed and changed completely and my responsibility increased. Over time I started doing more and more things and touching more areas. And today the role really dominates many areas within R&D.

Yishai: Yes, we will talk more about this in depth, about both how this role evolved and how such roles develop in the industry, but tell me about when you came to Cloudinary, how did you make this transition from a consulting company? I mean what did you see, what were Cloudinary looking for? And how did it suit you? How was that transition?

Nofar: So first of all I was looking to be in one place. A consulting company - this means that I am on the road all day, physically, but also all the time among clients and I wanted one place that is mine, where I grow, in a specific area. That doesn't actually change, every second. This dynamism, I really liked my time consulting, but at some point it was already a bit too much and I was looking for one place. I specifically wanted a product company and I came to Cloudinary to really manage the operation. It started from managing the tools, managing some processes like Agile, Scrum all kinds of buzzwords like that.

Yishai: How many people were at Cloudinary then?

Nofar: So when I arrived there were almost 50, today we are 130 which is our growth over two and a half years. It is a very, very big leap and we continue to grow and this is really one of the challenges of the position.

Yishai: Is it just the size of the R&D?

Nofar: Yes, that is just in the R&D. The company itself has doubled, we were 200 or so, and today we are 500.

Yishai: Wow. So you come to a company with 50 developers or an R&D organization of 50 people. And who do you report to? Who put you in the position? Who did you work with?

Nofar: So Uri is the VP R&D, he has been my manager from the beginning.

Yishai: Great, so tell us a little about what the role is. What is operations management in R&D. What was it like when you arrived and how has it changed - then we will be asked a little about what it means today.

Nofar: Usually when I am asked what the position means, I say that I am responsible for all processes that are not production. All short-term, long-term planning processes, quarterly planning, sprints, methodologies, work. How do we implement this within Cloudinary? There are many methods. Excellent methodologies, but we cannot take it as is, and apply to our organization. So really see what our flavor is at Cloudinary. 

What suits us within our culture? I manage all the tools and the implementation of new tools, everything related to dashboard indicators, everything that comes out of the monitoring of the dashboards and basically also drawing conclusions from these metrics, and understanding what we need to do to improve. Basically a lot of different projects are derived from all these indicators. And if I already said projects, then also management of all projects. We have extensive cross-team projects, both the methodologies and project management, what is project management in Cloudinary R&D, i.e. what tools do we use? How do we manage the project itself? In terms of communication, stakeholders, everything related to this and in general the optimization of the processes and the effectiveness of the engineering. It's a bit up in the air, but it really includes a lot of things, and again it starts from knowledge management and Jira, and work methodologies through  on-boarding courses for new employees. which is really very, very great versatility in the role.

Yishai: So you also say "how do we conduct ourselves on a daily basis"? But also how do we train new employees to be productive in Cloudinary?.

Nofar: Completely. Not only productive, but also how to become familiar with our culture and how we do things and not just what tool I use and what work environment.

Yishai: Okay, so you're talking about how we learn, how we improve, and where they meet. I don't know, people like Scrum Masters or similar positions that are actually accepted today to think that an engineering team learns on its own, that's part of its essence, they do retros. It's learning to improve.

Nofar: It's teams - of course they learn on their own, and this is also our guideline. They need to learn, they need to improve, they need to understand on their own where they need to learn, to improve. But my job includes two things, first of all to enable them to do these things. How to direct them, how to do a retro correctly, and with what tool to do the retro, how to draw conclusions from it and how to make sure that things happen and at the same time also connect them to some uniform line across the entire R&D. I mean, we are indeed 20 teams. We really want them to run autonomously and for them to be independent, but we do need some kind of line that connects us, we still have dependencies. We are still one organization. We are still, everyone still works at Cloudinary and it is important to have some kind of connecting line, which everyone understands and connects, and from this line any team can do anything. I don't want to say everything they want, but everything they want that is within the framework.  I work well and I deliver well and I also deliver the right thing. And not only not only effective.

Yishai: So what, how do you choose, or how did you choose? What goes into the uniform line, versus where do I have freedom? For example Kanban iterations or each team works in the format that suits them.

Nofar: Yes, so I don't have black and white here. To me, it is very important that we speak the same language. Let's understand together where we are going, that this quarter will not be completely disconnected from other quarters. We have the joint Cloudinary story that stems from the product. We work on this a lot together, but what objective do we have in general for these two organizations of product and R&D? And how does the team fit into this thing? So it is from this point of view in terms of the processes. So again this common language of the same rhythm and the same tools and the same methodologies, for me personally it is very important. That is, for example, it is important that sprints are the same length so that we all finish and start at the same time, and we can also adjust the organizational processes to this objective. That is, if we are now planning a quarter so that we know when everyone can deliver. It could be that it is a dependency that everyone has to delve into at the same time, so that it will be at the same rhythm, they are working at the same rhythm.

Yishai: So what example is there of something where each team chooses and has some independence in the area of ​​the processes?

Nofar: So I will give a very small example that is significant for teams, for example with our daily (edit for clarity: daily standup). We put emphasis on the content of the daily, but everyone will do it as much as they want and in whatever constellation works for them. There are teams that do it every day because it's important to them. Some teams do it 3 times a week and some teams do it as needed every week. So there is a lot of room to play around in what we define, but there's still that uniform line of what we want to come out of that meeting or from that process.

Yishai: Ok as far as your team is concerned? How does it work? I imagine you have your VP R&D, who else is on your team? In your first team? How does it look?

Nofar: So there is one employee under me right now who is basically wearing two hats. One, she has her teams, teams that she specifically came to help in their day-to-day, right in the sprints to see that they take the methodology in the right configuration, that they are effective, that they understand how they enter into R&D work. So it's actually some kind of hat that is more specific to the teams, and also it has the wider hat, which is wide projects with implementations of things. Management of engineering tools. So right now I have one employee, we will expand soon and we are going in the direction of more guilds. I mean, we really try to make the groups and teams independent. That is, end to end in terms of the roles, DevOps go into the actual teams, automation and all of it is really end to end. So are project managers. Soon there will be PMO and program project managers within the groups themselves and there will be some sort of horizontal guild that will help communicate.

Yishai: So the PMO, will be in teams and you will be a kind of head of the guild

Nofar: Yes there is also a team…

Yishai: So you help them.

Nofar: Exactly there will be both a core and a guild.

Yishai: Got it. But in terms of your team, I mean the team you report to is then you, VP R&D, and the heads of the groups is the forum?

Nofar: Yes

Yishai: Got it. Tell me a little about what. What do you think in your experience is needed to be successful in such a position?

Nofar: All operations and project management roles, to me, require a lot of  strength of character. I mean we - yes you have to study, and yes, you have to have the technical knowledge and the tools and the methodologies, but you will see in this field people who know how to close things, get things moving, take something and do it from start to finish. Even if you don't fully understand the field. I mean, you have to learn a lot of things, but not be in the details of everything, and apply this with people where this affects their day to day. 

So I think that first of all it requires a lot of character and how you approach things and how open you are, and how well you know how to push things. Of course. A lot of patience. But some kind of adaptability and dynamism which is very, very important and of course there will be the right foundation in terms of what I know, and what I bring to the position. Industry and management in my opinion can be very suitable. But what is anything…that is, of course, we are talking in the field of the high-tech area, so everything is a little more tech oriented. This is important, because you have to actually understand the other side. During the last few years it was very important for me to understand the programmers, so I went and studied a little SheCodes, it really helped me understand how they think. Although I will not sit down now and code something, absolutely not, but it really helped me to understand how they think and what problems they encounter on a daily basis, and not just in theory.

Yishai: And do you see that this understanding enabled you to do something differently in the conversation with the developers and the team leaders?

Nofar: Absolutely absolutely it allows me to understand what they say completely, and what  they mean, and sometimes what it is based upon. Of course, experience is also evident, you see more and more, and every team leader works a little differently and every team leader manages a little differently. But yes, it really helped me understand.

Yishai: If you had to think - what is the hardest part of the job? In the end, there are things you do and are used to and it flows, and there are things that are more difficult. Does it feel like this, "fighting uphill"?

Nofar: Right

Yishai: So what is the most difficult, what is the most annoying?

Nofar: So I think that matrix management is like that, because it's a loaded title, that’s the hardest thing. In the end, you are not really the manager of these people and you have to drive an organization of - I have 130 people, in another place it will be 500 people. And all…

Yishai: So you need to be a little bit afraid of Nofar...

Nofar: It's true, it's true. Some say they are afraid. So yes, it is motivating so many people, each one has an area that is important to them. The way they know how to work and sometimes there is a little bit of flexibility in what I want, in how they are willing to change the way they work. So I think that this matrixonian management draws people after you. It's a difficulty and it kind of connects me to what I said about character. You have to know very well how to connect with people and understand where their pains are and where you can help them. You can help them and that's ultimately what I do. But yes, in my opinion, this is the biggest challenge, in all positions, project management, operation. A thousand titles…

Yishai: How do I move people who are not my reports, while needing to make an impact and change.

Nofar: Yes exactly

Yishai: Tell me a little more about how you see, even within Cloudinary, this role. When you arrived and how it has evolved, but also in the industry - people you know from different companies, this world of operation management, sometimes it's called project management? Sometimes the truth is - it has a lot of names, but they are all in the same area of ​​how I, on the one hand, direct the executives to deal with strategy and there is someone here who takes care of delivery and moves the entire organization in the direction of delivery. This role has been changing in recent years. Has it evolved at the industry level, what do you see, both at Cloudinary and in general, of how this position has grown?

Nofar: So first of all it's a relatively new position. I think that today most organizations already understand that it is needed no matter what the title. Although maybe we need to put some order in what each title does. But yes, it is a role that has become quite, I don't know if to say it is required more and more, but more people understand over time that it is needed. 10 years ago you would not have seen this in any organization. 

Today, most engineering organizations have at least one such person, and in my eyes it is also starting, there is also starting to be a trend of this happening earlier. I mean, even small startups, bring someone who has control over the entire organization, and sees some kind of overall picture, and not just the picture of the code and the technical parts, and the production, something that is more holistic. And this position also gets more and more responsibility over time, if we used to look only at project management and maybe someone who looks at all projects, then now we also look at processes and how to make the organization more effective, and how we measure this, and then also to do something with these measurements. Not only measure, but also have someone who is actually a kind of go-to person who knows a little about the whole organization, or knows a lot about the whole organization and has answers, or at least he knows how to direct the questions to the right places. 

Yes, I'm very happy that there are organizations that understand the need for this position because it's really witnessing a change in the field. You really see how the organization changes, and how the organization is helped by this function and little by little it is required more and more, and people build teams. And this is us. I also see it in the community of project managers that I manage, that really is growing. The community also talks about it, but the community is growing and you can really see that this position is becoming very, very necessary.

Yishai: And in Cloudinary you describe a process where, on the one hand, this role grows, becoming a team. On the other hand, there is some process of decentralization, of putting branches of this role into groups or teams. So what? How do you decide if it is something centralized or something decentralized? Or what do you decentralize?

Nofar: So first of all it depends a lot on the stage of the organization. If the organization is from the get-go designed as separate groups that can run ahead and is at a stage where it is able to do so. I do believe that all the functions should be decentralized, but as I said before, connect it to the general line of the organization. The very fact that a group can, in fact, have all the functions and run ahead, is something that it is, it really allows for a very, very high delivery ability. To put it into the proper framing, but on the other hand, yes, there needs to be a team at the core that sees the whole picture, because when we decentralize then everyone actually sees their own area. So yes, you need someone to see the big picture. So yes, I think this is the right direction, with the asterisk that we should always see how we connect to the core.

Yishai: And you mentioned a bit about the community that you are helping to create. Soon we will dive into the story of the community itself. But what do you hear from the people there about how this position has evolved? How is it, what do they see or do they see in the industry in terms of challenges, say, do you see a lot of decentralization, like what happened in Cloudinary? Or do you see that it is still centralized?

Nofar: So I think the majority right now is centralized, from what I see. In general this role looks very different in each organization. Myself included, when I arrived at Cloudinary, I came to position A, and it expanded over time and really changed, and I was given more and more responsibility, so every organization sees it differently and every organization has its own needs. It really depends on the culture, it really depends on what the managers are capable of doing, or what the organization has defined for managers to do or not do. How tolerant the organization is to accepting change and implementing them as well. So right now I don't think the trend is necessarily decentralization. I hope it goes there. I also believe that the teams and all work methodologies will move in that direction. And I believe that the same will go for us.

Yishai: So this situation, where this role is very different between organizations - is this part of the definition of the role in your eyes, or is it a symptom of the fact that this is a new role, there are still no mature and orderly definitions of what I should expect in the role?

Nofar: I think this is somewhat the essence of the job, because really every organization has different needs, and every organization works differently, and every organization has a different culture. And what I said about the managers, I mean really every organization has a different management culture and everyone knows how to do things in a different way and there are organizations whose teams will find it very easy to implement work methodologies like scrum or kanban and there are organizations that will need the help. Precisely in this area I can say, for example, that when I arrived there were no cross-departmental projects. That is, there was no need for proper project management, and today we have this need. So I think that this versatility, and among companies it is very much the essence of the job, but you will hear that in the end the job comes down to helping engineering teams by assisting them and being more effective and paving the way for them to do the work they know how to do.

Yishai: Got it. Then the question arises of someone who specializes in such a position in company X and then moves to a new company, and in fact the position is completely different. How do you take experience and knowledge and methods gained when it is different at every company? So how do we progress or how do we transfer this knowledge from one position to another position?

Nofar: So first of all I see it as an interesting challenge. And there is no one thing here, that is, what you did. If you did apply scrum methodology, so you go and learn kanban and you read and you understand, you try, and you change. There is no, there is no answer for how to do that. And that's how you'll succeed, I think it also has a lot to do with character and dynamism and the ability to adapt and the ability to learn new things, and also go and assimilate them. An interesting challenge for me.

Yishai: Tell me a little about the topic of managing up. At the end you have a boss, VP R&D. How do you conduct yourself and manage towards the boss in this position?

Nofar: So I think the first thing is to demonstrate where the organization can be helped, and where are the areas that the organization needs to improve and can be better. And why should it get better? I mean, it's not only here that needs to be improved, and here and there, why? What will this give us? And how will it help us and how will it help the VP R&D personally? And it also depends a lot on the other side. I mean, it's clear that the job is also one of the responsibilities, it's to be able to show these things and to be able to sway the management after you. But on the other hand, organizations that bring this role, these roles need to really understand that they need to be open to change, that they need to be open to see where we are wrong and where we can be better. So it lies on both sides. I think it's mostly, show where the engineering organization could be better and why.

Yishai: So this means that part of the requirements of the job is to look for what else I can or should do, and not necessarily what they defined for me because the issues that were defined for me have gaps in them and are not always known or very transparent to the management.

Nofar: Right. Sometimes, these positions also don't come with any kind, for the most part. Sometimes there are the problems that the organization knows it needs to address, and they don't come with some kind of grocery list of where the organization needs to improve or what needs to be done to improve it, but really it's the ability to see the places those hidden ones, the places no one gets to and they can really move the needle.

Yishai: You have, on the one hand, a place close to the ear of the big boss or whoever runs the engineering organization, and a lot of power that also comes from this definition of the role of let's find out how to improve, as well as a lot of initiative. On the other hand, you need the trust, the trust of the developers and the team leaders. How do you do it without being perceived as the "long arm of the management", and it always creates or can create some kind of situation of someone else from above and imposing things on us?

Nofar: Right. This very much connects to the matrix management I said earlier. But I think it's a role where you have to be a people person. It's a bit cliche to say, but you have to get along with people. And again the role is not only top down, at least with us. I strongly believe that at Cloudinary, in general the culture is very much to share with everyone. So, yes, there will be things that in the end we will decide and do, but it is very much in cooperation and very much in explaining to the teams why we are doing them, and giving them the space to express their opinion and what works less for them and what works better for them, and let's change, and let's adapt to a specific team. And it's a lot to show where it helps them. One of the first things I did at Cloudinary was to automate all of the work in Jira withGithub and Jenkins and this also “bought me” personally the open door to the developers.

Yishai: Because you saved them time and made their lives easier?

Nofar: Yes, but this is an example that shows them very much where it helps them, but as soon as you show why they do it and what the reason is, then I think you sweep the people after you. Sometimes neither. Yes, there is nothing to be done, not everything will be accepted and certainly not by programmers.

Yishai: There is also a situation where you know how to represent the needs of a team or a certain group, if something hurts and there is some need, that through you they manage to raise it upwards or get more resources to make a change in some area because there is a conversation with you, there is actually a way to promote their needs ?

Nofar: Totally, totally. And also - over time I became that persona, and this is something that is very, very important to me.

Yishai: So a little love and a little fear.

Nofar: Yes Yes Yes. Maybe we should have gotten them to talk.

Yishai: We will do another episode...

We mentioned a little about your activity in the community. Tell us a little more about how you started doing it? How did you get to that? What does it give you?

Nofar: Yes, so actually I manage with 4 other amazing women, a community of project managers. Today we are already 2000 project managers in the community which is amazing. 2000 in Israel - we haven't expanded abroad yet, we'll get there. Yes, that just shows how crazy this field is, so I've been there for a year managing the community. The community was established 3 years ago. I joined, I was very active in the community and they contacted me to ask if I wanted to join. Really amazing community, there is a lot of support and help and sharing, and it's like this field because it's still new. It is new... not new, it is still emerging. So there is really a lot of common thinking and we do a lot of meetings and meetups and a lot of content, and really help each other.

Yishai: If this is a 3-year-old community, then most of the metups have been remote until now.

Nofar: It's true that they were remote. We also try to meet now in this period and a little before COVID. So, yes, a lot remotely, but connections were made there that are really hard to explain. We also have all kinds of mentoring programs that have created a lot of connections. We also have meetings that are just over coffee in the morning, and then we get to know the women in the community as well and very, very interesting connections are made there. So yes, it's a truly net community. A kind of house for project managers.

Yishai: And can you put your finger on what kind of content or questions or sharing happens that are technical questions about how to do something in Jira or how to deal with a boss who doesn't understand the role? What, what, do you see drawing them...?

Nofar: That's it... that's it. It ranges from how I do this in Jira to how you implemented this process, or how you manage quarterly planning, to fundamental questions about the role itself, and how I build a role from scratch. Many women build this role from scratch. I say women because this is a women's community.

Yishai: This is true, but to say that this position has some kind of bias or attraction to women, that there are more women in it than other similar positions in high-tech?

Nofar: The truth is that I have also seen many men in the field, because I am in the community, so I mostly see women, but also many men in the field. Also in my previous position at Simple, so I saw a lot of men in the space. So I don't know if it is unambiguous.

Yishai: Okay. So you say, the community also talks about the technical aspects but also about the process aspects?

Nofar: Yes, we also try to have our meetups - where there are also talks but also a lot of debates, yes, there is always the content and also there is always someone who will come to lecture. But for example our previous physical meetup, we started in circles, we brought essential questions about the day-to-day life of the position, starting with what are the challenges in your day-to-day and all kinds of questions like that and we started with half an hour, each circle discussing these questions and it was a resounding success. And we also try to do things that are fundamental to our region. In this area, for example, we are going to map all the roles and what they do, and make some kind of definition of each role. It's very, very hard work. We really want to lead this field and change it and be part of how it shapes and changes.

Yishai: I think that such definitions help a lot in the maturation of a field as a field of occupation. In the end, the management of some start-up sits down and says "We feel we need *something* in this position." Wait, is it a release manager, is it a project manager? Is it developer experience? What, what do you even need to bring? And in Israel, quite a few managers in these fields are doing this for the first time, so they have never recruited or managed someone from this discipline, so I think it will be very helpful.

Nofar: Completely

Yishai: Setting expectations, what skills are needed for everything, when do you need it? When do you need it–yes, so you really intend to publish some kind of guide of what this job looks like?

Nofar: Yes. Yes. completely completely. It is a very difficult job because it has to be both very precise and a lot of information has to be collected. I mean that's what we know. It's not necessarily what it should be, we should really do some research and something else that is an example of the "essence of the job" area we'll call it. What we are doing now is dealing a bit with salaries, and we did a very large salary survey. According to positions, according to years of experience, according to the size of the company, which will really help people and people in this position, to understand what they should demand in which position. Something that is not yet established enough for anyone to know what to ask for or what. What is right for the field.

Yishai: So it also makes it possible to talk about the engineering of a career, what does a career mean in the world of R&D Operations or any of the different names for the positions.

Nofar: Totally… there are so many names…

Yishai: Yeah, so it sounds like a need. It sounds like people are looking for this knowledge to know where it's going.

Nofar: Absolutely, these needs arise in the community in a genuine way, not needs we invented - it arises.

Yishai: Okay, and if you need to know more about your position, also as your experience in general in Cloudinary in the role and in the community. Anyone who wants to enter this field? Wants to build a career for herself. What, what should they think about, what should they emphasize, how would it be best to prepare for it? By the way, where do you come from for such a position other than, as you described a course of studies and consulting, where do you see entrances or transitions to such a position?

Nofar: So. Even people who are from engineering often make this transition. It's not super common, but they do it too I think...

Yishai: Really developers and team leaders?

Nofar: Yes Yes Yes. The team leaders usually don't, usually not because they already have some kind of path that they have paved for themselves, but with us recently someone from QA became a project manager right here in our company, so I also see such changes, and I think that again this story of character connects to me . A person who likes to lead, likes to change. They like to look at the challenges and solve them and not only in the technical area but very much in the personal area, and the effectiveness of the organization. So I don't think it's strange to come, with a technological degree for this field - it will be a more difficult job. So anyone who is project management oriented we’ll call it, they can totally do it.

Yishai: Tell us a little about the interaction with people outside the engineering organization or different departments: sales, marketing, customer success and others. Where does this role meet them?

Nofar: So the strongest relationship I have is probably with the product team. I talked a little about the fact that we do the quarterly planning and the sprints, so the work is very, very close, I personally work closely with the VP Product and now a product operations function joined us, so these are such roles. We work closely to define things together. I mean it's very nice that I will define how quarterly planning is done in engineering, but where does the product come in and what emphasis should they give and what preparations should they make. And us too of course. After we plan, we do some kind of transition on the plan and challenges. So my work is very, very close to the project.

Yishai: Can you give us examples of what falls in your place versus what falls in product operations? Sounds like close areas to the point of overlapping.

Nofar: Yes completely completely. Then for example, in sprints. So in the sprints I will put more emphasis on the work methodologies and how the team should implement and how we can be more effective and the product operations will put more emphasis on how to bake the stories in a better way. How do we write requirements and how do we create acceptance criteria more correctly, and how do we also make sure that the engineering works on the right things and not just writes cool features, but how it connects to the overall picture. And how do we give the greatest value to our clients, and how to really, how to write an objective correctly. If we look at the picture of the quarter. So yes there are areas that overlap, and there we will work very, very closely and in the rest we will communicate more. And of course product operations is also responsible for the entire area of ​​betas, and what is alpha and what is beta, and what is early access, and how we release things and how we do training for the rest of the company. Yes.

Yishai: So, with some examples I understand the world of needs, of R&D, versus a product in the areas you mentioned - if R&D wants more time for non-functional and wants to invest in non-functional. Are you their representative in front of Product Operations? To say "come on guys, in this sprint we need to produce more non-functional capacity". Or is it R&D directly in front of a project?

Nofar: So the dream, and the truth that happens with us in most teams, is that this R&D pair of an engineer and product manager will know how to work together so well and communicate so well that they know when the R&D agenda is needed and when a product is needed. So most teams really know how to do it, we'll be more specific. Is there a fixed capacity that we want to leave for this as an organization? Is there any specific quarter that we now say we are focusing on separating into microservices. I don't know, I'm just making it up - so really it's the ownership of the teams. We are the enablers of this thing.

Yishai: Got it. And with some attraction to the bigger or generic things. They are now making some significant change - let's create capacity for it. And you describe that in fact product operations is a new world in Cloudinary, it is not something with a similar seniority to yours. So what? Were you involved in the construction of this, or even in the understanding that product operations should be produced?

Nofar: Yes yes I was first of all involved in the entire construction of the position itself and how we are, as well as in recruitment, and also probably in on boarding. So it is absolutely something I would be a part of. And it also made me and our project operations function to work... It hasn’t been a long time, yes, but already we work very closely and well. And even before I worked with them, I still worked with our VP Product, this gave the best example of how to work properly together. So I see that this is also our connection and how we will work together in which we will present things, it will greatly benefit you that the teams will work in the same way and learn the ways of communication.

Yishai: And is product operations something that also falls under the umbrella of Women in Project Management? Is this to you part of this basket of roles and jobs that your community is talking about?

Nofar: Yes - some of the roles, yes? The rest probably, they may not receive sufficient value. Although there are people who do both roles at the same time, meaning it can be one role.

Yishai: True, there are also organizations where product and R&D are together.

Nofar: So yes, there’s a lot of people like that––that will be in our community. They just won't get the full support. It could be from other women who do, but it's not something we're putting emphasis on right now, maybe more so later.

Yishai: Okay, so we talked about the strong relationship with a product. What about other parts of the organization, even more distant?

Nofar: Yes. For me personally, it is very important that we work with other departments. Support, CS' CSMs is very important, starting with the fact that we work together, and we work quite closely and also for example on call, which our developers need to solve, and support needs the developers, and it is very important to work well together and it is very important to get to know each other and know the language . So we do a lot in this area. I can tell you about something very interesting that we do with every new developer who comes to Cloudinary, they join our Support for two days, solve tickets with them. And they are always terribly skeptical at first, but in the end they really go out of there borderline dazzled, also from the level of the Support. And this also helps them a lot to get closer to the customers and to understand when they ask for something on a call after that. Or when support asks for some kind of solution, so they really understand each other, and also on a social level, they create relationships there that are really good later for work.

Yishai: Do they occasionally return to "reserves" in this matter?

Nofar: Anyone who wants to can do it. So yes they come back... and this is really some kind of the smallest process we have done and it created a very good relationship between the two departments, so it is important to me personally, also of course, also in the process area that we do all kinds of triage of important bugs for customers in such things, but it is more important to me to bring the departments closer together on the communication level. We did all kinds of things, for example we also brought in, we did some kind of process with CSM who every quarter do real life customer use cases for us. Three CSMs come and tell us about how the customers use the new features that have been released, and which use case is interesting, and this really connects the engineering to the business as well, and what the customers want, and where the customers' problems are. And that creates tremendous value in what they do next in practice. But also at the level of communication between the departments and how we are involved with everyone.

Yishai: So this sewing - of how you build relationships between the departments, and how you time both the visits or reserve duty or on-boarding service in support, and the use cases,is this your job? I mean, that's what you're saying here, I recognize a gap and offer a solution that's how it's done. We will strengthen the relationship.

Nofar: Exactly

Yishai: Which is another extension of the role of the project manager and it spills over into the issue of onboarding new employees in R&D. You mentioned a bit that this is also an area that you touch. So really what? What are you doing in this area, of  strength building? In the end, hiring managers do this work, recruit someone who is usually responsible for the on-boarding of the managers. Where does this meet you?

Nofar: We call it NHC - it's New Hires Community and actually, this need arose during COVID. I mean, it's not something new anymore. COVID is not new. It's been two years, it started with COVID. We recruited a lot, we continued to recruit during COVID, even during lockdowns and it was very difficult to onboard new people. Not at the technical level, at the ecosystem level, and how do I fit in within R&D and what is the culture here? And how do I know people and where I am even in the organization hierarchically. What groups are there around me, and we decided to establish some kind of we called it a community because we really wanted it to be something that they would also be able to go back to after that and get to know people, and it's actually on-boarding which is not technical. 

Obviously, the manager has the responsibility to do technical on-boarding and introduce the person to the areas and tools and how the team works, and here we provide some kind of solution that is more R&D inclusive and available - we'll call it a course or program that gives a taste of all the R&D, we're starting. First of all, it's 4 days. Every day we start with a peer discussion. We have the HRBP who comes to every peer discussion like this and raises some kind of a little more personal question like this, then we give a taster, each group head comes with their team members and gets to know the whole group and what they do and what they are responsible for. They put a lot of emphasis on the personal aspect. We are already a lot of people, but when we started this NHC we were 10 teams, today we are 20, we started the journey. So every team leader came and really talked about their people and their hobbies and that's really cool. Today we are no longer able to do that, so unfortunately we have somewhat reduced this personal aspect or minimized it. So group leaders, and any session that is architectural that gives, dominates the entire system and all the groups, and not just the region, and the VP Product came to tell a little about her side and how she sees the relationship with the product. There is a session that is an external function that I told you about, the CS and the support and documentation come, so really some kind of taste of our entire ecosystem. And how we work and also create some kind of community. You see these people after this, where they are each other's friends, nearly every time. A program of between 8 and ten people, they really become friends later and know people from other teams. And they know how to contact them, and it's not just another person with a picture on Slack.

Yishai: So people remember the cohort they came with? And like it's my guys, from my cycle?

Nofar: Totally, “class of…”. So yes, it creates something very, very good and also really gives them the knowledge of how to take part in the R&D, and not just the technical knowledge, which is part of when you do onboarding, it is not something that is easy to learn on your own. You need to be spoon fed it usually...

Yishai: And on the side of this topic that is related to the technical and the delivery, of following up on boarding, our efficiency in ramp up time - it is under your responsibility to help managers and group leaders know that we have an effective onboarding process that we manage to get people to function effectively in the team, Do reviews for others, participate in all the processes?

Nofar: So it's not currently under my umbrella. I say right now - because it's the responsibility of the team managers, obviously, but it's always the area where they will come to consult me ​​if necessary. That is, I am not always…it’s not something that is not under my responsibility. This means that you can come to consult and get help. And by the way, a lot of my everyday life. People who make appointments and ask to consult about some new process they are trying to do.

Yishai: But it's not a process that you measure directly and are measured on, okay.

I want to talk to you a little bit about a buzzword that is gaining popularity and is very connected to the position we are talking about. The issue of developer experience with an emphasis on internal developer experience. That is, not the developers who work with, say, Cloudinary's API, but the developers who work in Cloudinary, and what is their experience on a daily basis? Where does it connect with you? How do you see it within the role? Both yours and the community.

Nofar: So I think that I wouldn't say "the essence of the role", but it is something that is very, very important in the role because in the end I come to optimize the engineering. If we say it in one word. And that is to help the teams work better, so that means making room for them to work and making processes that will support them, and creating processes that will save them time later on, as well as working on the right things and giving them the right tools. What I said, for example, with Jira, is something that I really connect with the developer experience. I mean, it really frees up their time. It creates order for them, for their tasks, and what they need to do, and also brings the team together around an orderly process, but on the other hand it also frees up their time.

Yishai: Your developers really love Jira, don't they?

Nofar: They are sick of Jira, no doubt…

ֿ But again the place, the area of ​​clearing the obstacles, the challenges and helping them solve them. To me, it's part of the developer experience and also helping them understand where they are in the big picture. I mean, although it's not something they will necessarily see as developer experience, but once they see the big picture and they understand where they belong, in my opinion, it greatly improves their work and helps them to be better and more accurate.

Yishai: You are talking about understanding the business context and understanding the WHY. Why are we developing this feature? Where does it help the company and customers?

Nofar: So yes, so really helping them to be better at what they are doing, not with the help of technical things but talking about the peripheral aspects, the surrounding ecosystem.

Yishai: If you have to put your finger on I don't know what it is, the one or two that you think are the most annoying or the most disturbing to the developers, obstacles that you see, that repeat themselves. What is the number one?

Nofar: So I think that many times planning is something that is difficult for developers to do a lot, and little by little they realize that in a large organization that without it they don't work on things that are meaningful. So those who learn to understand it - then they don't see it as an obstacle. Those who see it as a challenge that needs to be helped and solved, so I think that planning and tools - tools are always an issue. Also tools like Jira, Confluence and such, but I, too, feel like using this little plugin or this work environment, and that we are big enough to have to say no. So it starts to become an issue. We don't say no to say no. Obviously we say no because there is some kind of set of tools and there is already a matter of security and we are big enough not to pay for 1000 small tools but rather for something uniform. I think these are two areas.

Yishai: So the developers have found some tool or want to shorten some process for themselves with the help of a tool, and then they may encounter an obstacle or the need for uniformity.

Nofar: Yes

Yishai: I see. And you see some kind of pattern in general, the types of tools people are looking for. What do they come to solve with tools?

Nofar: I don't think there is any pattern because it varies a lot from team to team and what the team does, but it's always...

Yishai: Is it a matter of productivity? Productivity tool?

Nofar: No, it's more in the technical area of ​​I need something that will close the loop for me on the specific code now that I'm doing something that will solve it.

Yishai: Oh really libraries for the code base

Nofar: Yes, no not libraries, but. All kinds, I don't have any specific example.

Yishai: Okay. My last question will be about Cloudinary's special story in the famous bootstrap story. This is an unusual company that managed to grow quickly. At least in the first years, without external funding. Where did you encounter in your role, in the evolution of your role? Where do you see it affecting you or how you behave today?

Nofar: So first of all we didn't raise capital even at a late stage. Cloudinary is a truly amazing company. There is an extraordinary culture in the levels of transparency as well, but also in the levels of mutual help and appreciation, and we are very close-knit, and communicate well with each other. And that's also what fascinated me about the process. I mean, when I interviewed for Cloudinary, I interviewed for other places at the same time, and it's probably also the position, but this is the company that did it the most for me. I mean, they really see that this is something that is ours and that we built it and that no external help was needed and that it is really some very strong need in the market and we know how to fulfill it. It meets me mainly in the culture, in the everyday culture to say it is a role, as I said it is very necessary to sway people. And to influence people, I think the culture of Cloudinary which is... I don't know if it came from bootstrapping, but it was created from this story of this being something that is ours. It really helps me to motivate the people because there is really an openness to changes and there is some kind of transparency that we all know, at least, and for me it was very, very helpful in my job.

Yishai: And you felt, I mean, this culture was already evident during your interview stages?

Nofar: Yes completely completely.

Yishai: Nofar, thank you very much for being with us, it was great.

Nofar: Thank you very much Yishai.

Yishai: Go to 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 https://linearb.io/careers to find your next challenge.

I am Yishai Beeri, until the next episode

Visit https://devinterrupted.com to register - you can also find all our episodes in English there. I remind you that we are rapidly growing at LinearB, recruiting for a variety of positions. Come find your next challenge at https://linearb.io/careers.
I am Yishai Beeri. We'll meet in the next episode.

(Closing music)

Links to the awesome resources mentioned in the episode:

• SheCodes;
• Women in Project Management