בפרק סיום עונה 2 של פיתוח בהפרעה, ישי בארי מארח את אביב בן יוסף, שמייעץ למנהלי פיתוח ב day job שלו, והוא משתף כל כך הרבה ידע ומיומנות בניהול פיתוח בפרק אחד - שזה לא מפתיע שהוא הספיק לכתוב כבר שני ספרים - אחד יצא ממש לא מזמן. הוא יעזור לנו להבין איך לפרק אתגרים נפוצים ואפילו איך לכמת הצלחה של ארגוני פיתוח - וגם האם יש מתכון סודי להצלחה בניהול פיתוח? האזינו לגלות.
In our season 2 finale episode, Yishai Beeri is joined by Aviv Ben Yosef, Tech Executive Consultant in his day job, who drops so much wisdom and expertise in a single episode - it's not surprising he's already managed to write two books, one that was released very recently. He'll help us unpack common engineering leadership challenges and how to quantify success of engineering organizations - and whether there is a secret recipe to success. Join us to find out.
Episode Transcript תמליל הפרק
Hebrew, then English* בעברית ואז אנגלית:
(*Translated with Google Translate - so there may be some errors.
Please also bear in mind that Hebrew is a gendered language and therefore anything that is noted in a specific gender is intended as neutral and not gender-specific.)
(מוסיקת פתיח)
ברוכים הבאים לעונה השנייה של פיתוח בהפרעה, הגרסה העברית ל Dev Interrupted הפודקאסט המצליח של LinearB למנהלי ומנהלות פיתוח. נארח פה מובילים ומובילות בתעשייה ונדבר איתם על כל מה שמעניין מנהלי פיתוח, מי שעובד איתם ומי שרוצה יום אחד לנהל ארגון פיתוח. בעונה הזו נשים דגש מיוחד על חווית המפתח, developer experience. אני ישי בארי, CTO ב- LinearB, כבר מתחילים.
(מוסיקת פתיח)
ישי: בפרק הזה אני שמח לארח את אביב בן יוסף, מלווה ומייעץ למנהלי פיתוח וסופר שכתב שני ספרים חשובים בתחום, אהלן אביב,
אביב: אהלן.
ישי: טוב שבאת.
אביב: טוב להיות פה.
ישי: אז כרגיל אני אשאל אותך על הדרך שעברת עד היום, תספר לנו קצת איפה התחלת? איך התגלגלת ואיך הגעת לאן שאתה נמצא בו היום.
אביב: אוקיי, התחלתי כמו הרבה נראה לי בגילי, שזה כזה לא היה עדיין איך ללמוד להיות מתכנת, כזה חיפשנו דברים באינטרנט לבד, למדתי לתכנת בגיל 9 בערך, משהו כזה. והתגלגלתי בזמנו לעולם הזה של ההאקינג כי זה נראה לי הכי מגניב בתור ילד כזה, אם אני באמת רוצה להבין איך מחשבים עובדים אני חייב לדעת עד העומק איך דברים מתפקדים, ואז השלב הבא ליד תמיד נראה אני חייב להבין בדיוק איך זה עובד, אם אני יודע לפרוץ לתוך זה, משמע אני באמת יודע איך זה עובד. ושם התגלגלתי, זה היה כזה תקופה של פרצתי לשרתי ממשלה איראניים כי הראש שלי היה כזה, אוקיי, אני ילד, אני לא רוצה להיכנס לכלא, מה אני אעשה? אף אחד לא יסגיר אותי לאירן בחיים כנראה, אז זה כנראה הדבר הנכון לעשות, וזה, זה קצת איך שהעברתי את שנות התיכון שלי בתור הובי. באופן לא מפתיע מתברר שזה גם משהו שעוזר לך להיכנס למודיעין בסוף אז שם שירתי כמה שנים והיה באמת כיף ולמדתי המון. אח"כ הייתי שנה ב-IBM, הגעתי שם בדיוק אחרי רכישה וכולם אמרו לי לא, לא, זה עדיין סטארט אפ, אתה תראה, לא, זה לא היה סטארט אפ, זה היה IBM. ברחתי אחרי שנה בערך, הייתי עובד ראשון בסטארט אפ, שזה גם בית ספר מטורף ומשהו כמו אוטוטו 11 שנים שאני עצמאי, בהתחלה הייתי כזה סוג של פרילנסר, עבדתי עם עוד חבר טוב ורצנו על מלא סטארטאפים פה בארץ ועזרנו להם להרים דברים מאוד מאוד מהר ולאט לאט זה,
ישי: כתבת קוד for hire ?
אביב: כן, והמון חברות שנרכשו סלאש עשו IPOs סלאש כל מיני דברים טובים כאלה, ומאז לאורך השנים זה קצת התגלגל יותר לכיוונים של, רציתי פשוט יותר אימפקט, כמה שאני אוהב לתכנת וזה משהו שקסם לי מאז שאני ילד קטן. אני הרגשתי שיש גבול לכמה אימפקט אני יכול לתת לחברה מלתקתק על המקלדת, ולאט לאט התחלתי לעזור בעוד דרכים, זה היה כזה פעם הייתי סוג של, היום קוראים "Fractional CT או Fractional Chief Architect וכל מיני דברים כאלה, עשיתי את זה כמה שנים ומשהו כמו 3, 4 שנים כבר שאני בעיקר מלווה חברות כי הרגשתי שלא בא לי להיות הפלסטר הזה מבחוץ של אין לנו CTO, אין לנו VP Engineering, אנחנו רוצים שמישהו יעזור לנו תקופה מסוימת, אלא אמרתי לא, אני רוצה לעבוד עם חברות שיש להם את האנשים האלה ופשוט לעזור להם להשתפר. וזה די מה שאני עושה קצת מלפני הקורונה.
ישי: אז זה סוג של מה? מנטורינג וליווי ל-executives בתחום ומובילים של ארגוני פיתוח?
אביב: כן, זה פחות או יותר אם אני עובד עם CTO או VPs of Engineering זה ממש עבודה one on one כי אני חושב שכל אחד מאיתנו תמיד יכול ללמוד מלא, גם אני עם coach כבר שנים ואני מרגיש איך זה תמיד עוזר לי להתפתח, גם העבודה one on one וגם ה-organization development של איך צריך להיראות הארגון ומה ה-next step ואיך אנחנו תמיד שואפים להשתפר ולא להישאר תקועים. ולפעמים אני גם עובד עם CEO-ים או CPO-ים לגבי בכלל איך להסתכל על ה-product engineering machine של החברה. איך זה צריך להראות, לאן אנחנו צריכים לשאוף, דברים כאלה.
ישי: וזה פה בארץ? אתה עובד גם בחוץ לארץ?
אביב: היום חצי מהלקוחות שלי הם לא בארץ.
ישי: וואלה?
אביב: כן, הקורונה מאוד עזרה מהבחינה הזאתי.
ישי: באיזה, כאילו גיאוגרפיות ספציפיות? או סטארטאפים בכל מקום?
אביב: סטארטאפים ממש בכל מקום. אבל אתה יודע, באופן טבעי יש את ה-, רואים יותר באזורי מערב אירופה וכמובן ארה"ב. אני בעיקר נהנה לעבוד יותר עם חברות באירופה, פשוט מבחינת ה-time zone כי אני עצלן ואני לא אוהב לעשות שיחות בלילה. אבל מעבר לזה, ל-wherever it takes me, באחד הספרים שהוצאתי אתה רואה שם פתאום, זה מדהים שפתאום מישהו מסינגפור ואנשים מאוסטרליה וניו זילנד וכל מיני מקומות בעולם פונים אליך ואתה רואה שהדברים האלה נפוצים בעולם שאנשים יש להם את אותם בעיות ורוצים לשמוע את הדברים האלה אז wherever it's needed I'm there.
ישי: יש איזה גודל חברה או שלב טיפוסי שאתה לרוב עובד איתו?
אביב: אני אגיד את האמת, יש פה משהו שהוא קצת איך שאני המצאתי לעצמי את העבודה שלי, כאילו זה די התפתח. שאני פשוט נהנה מהכול, כמו שנהניתי בעולם ההאקינג להיכנס לכל level של ה-operating system ולהבין אותו, יש חברות, ליטרלי חברות שהרגע גייסו כסף והם מביאים אותי הפאונדרים ביום הראשון שיש להם את השני מתכנתים הראשונים כי הם רוצים לעבוד איתי, ואני עובד עם חברות ציבוריות וכל מה שבאמצע, כן אני אגיד שעכשיו עם הבלגן שאנחנו רואים ב-tech industry אז אני יוצא לי פחות לעבוד עם חברות קטנות כי הם נראה לי הכי strapped for cash וזה חבל לי כי אני מאוד נהנה לעבוד גם איתם אבל מה שיוצא ומי שצריך עזרה ואני נהנה, כל עוד זה mutual benefit אני שם.
ישי: כמה זמן פחות או יותר ה-engagement שלך? כמה זמן אתה מעורב בחיים של חברה כזאת?
אביב: הממוצע הוא משהו בין חצי שנה לשנה הייתי אומר. שיש כאלה שזה כזה סוג של מתחילים מפסיקים, מתחילים מפסיקים, אני נותן להם מלא מלא שיעורי בית סלאש כיוונים. ומשהו כמו חצי שנה, שנה אחר כך, כשהם כבר גדלו, הגיעו לשלב הבא, הם עוד פעם רוצים לעשות כזה עוד סשנים. אבל זה באמת תלוי, יש את האנשים שמגיעים, לאחרונה עבדתי עם מישהו שאתה ראית שהוא פשוט, אני תמיד הייתי אומר שהוא הספוג האנושי. כל דבר שאמרתי לו הרגשתי שבשיחה הבאה זהו, זה כבר מומש, זה לא כזה אה, כן, לא היה לי זמן, לא, הבנאדם על הכול וזה היה מישהו ש-3 חודשים אחרי שהבאתי לו כל כך הרבה דברים וכל כך הרבה התקדמות. זה היה כזה סע, לך, כאילו עזוב, אתה לא צריך את הגלגלי עזר, לך לבד ותעוף על זה, ומנגד יש לי,
ישי: צריך להיזהר לא להצליח מדי ב-consulting
אביב: (צוחק) תראה, אני באמת מאמין שבדברים האלה אין to do too much good, אם הוא יכול לעוף על זה, גם אם זה אומר שאתה, סיימנו רק אחרי 3 חודשים ומבחינתי אני יודע שזה פשוט סימן טוב למה אפשר להגיע ואני מבסוט על זה בטירוף. ואני גם יודע שתמיד בסופו של דבר דברים מתפתחים ואנחנו, אנשים רוצים לקבל עוד פידבק או הדברים משתנים וזה נהדר לראות את ההתפתחות הזאתי. אז הוא נגיד לדוגמא מישהו 3 חודשים, באמת אחד האנשים, היה לי הכי כיף לעבוד איתם בכל השנים שאני עצמאי. ומנגד יש לי לקוחות שעובדים איתי כבר שנתיים ברצף פשוט כי הם כל הזמן רואים את זה שהם רוצים את ה-ongoing extra pair of eyes שיכולים לבוא ולהגיד להם האם זה הגיוני, האם זה לא הגיוני, עם מישהו מבחוץ להתייעץ איתו, זה ממש תלוי בבן אדם, בחברה, ושוב, יש חברות שאני אומר להם, לדעתי כדאי להפסיק. ויש חברות שאני זורם עם זה כי אני רואה שזה באמת הם מקבלים value, וזה לא, הם לא צריכים את זה כי,
ישי: כי שהמטפל שלך אומר שצריך להפסיק.
אביב: בדיוק, זה בקטע של אם אתה רואה שהם יכולים לעשות את זה לבד, זה נחמד תמיד לקבל עוד כסף בבנק, נכון, אבל אם אתה רוצה ליצור מצב שבו הם משתמשים בזה כי הם צריכים ומקבלים value ולא כי הם רגילים, ואתה לא רוצה לייצר כזה תלות, נכון? זה כמו שלא יודע, יהיה לי מאוד כיף לשחק עם הילדים שלי שנים אבל מתישהו אני רוצה שהן ישחקו עם עוד ילדים, או אני רוצה שהם ינסו רגע ללכת ברחוב קצת לבד, עם הגדולה נכון? אנחנו מנסים לעשות את זה, סבבה, מתישהו צריך לעשות את זה כי זה מה שטוב להם, גם אם לך זה נחמד, אז זה קצת ההסתכלות.
ישי: הזכרת את הספרים שלך, תספר לי קצת איך נכנסת לתחום הזה של לא רק כלי עזר, גם לכתוב ספרים בתחום.
אביב: כן, לכתוב אני אוהב, זה משהו שתמיד בא לי בקלות, יש לי, אני מתחזק בלוגים קיימים, לא יודע, בערך מאז שאני בן 16. ותמיד הייתי כותב יחסית הרבה, פחות או יותר כשהתחילה הקורונה והפסקתי לנסוע לתל אביב כמה פעמים בשבוע ופתאום התפנו לי יחסית הרבה שעות - אמרתי אוקיי, אני יכול פשוט ללכת ולתת לזה להיזרק לטוויטר או שאני יכול למצוא משהו יותר הגיוני לעשות בזמן הזה. והחלטתי לנסות לכתוב ספר וגם החלטתי שאני רוצה לעשות את זה כזה נכון airquotes אני רוצה לא לכתוב כזה self-publish book, אני רוצה ממש למצוא מוציא לאור בחו"ל שירצה ולעשות את כל התהליך הזה כי רציתי לחוות את זה וזה היה תהליך שעשיתי במשך איזה חצי שנה בערך של אתה כותב book proposal של מה אתה רוצה לעשות, למי אתה רוצה לעזור, איך אתה הולך לשווק את זה, ולמזלי מצאתי publisher שממש היה לי כיף לעבוד איתם וכתבתי את הספר יחסית מהר, נראה לי באיזה 3 חודשים.
ישי: באיזה נושא? מה בחרת?
אביב: זה היה ספר, הראשון שלי The Tech Executive Operating System הוא היה פחות או יותר אוסף של לקחים, מערכות וסוג של personal algorithms למנהלי פיתוח, בין אם זה first timers או אנשים שהם בתהליך של לצמוח מהר והם רוצים לוודא שהם ממשיכים להתקדם יותר מהר מכמה מהר שהצוות שלהם גדל וזה היה כזה אוסף של לקחים מכל הלקוחות שלי, בין אם זה על איך השבוע שלך צריך להיראות איך, איך צריך לעשות one on one's בדרג של VP of Engineering, איך זה,
ישי: זה מה? ספר בישול כזה? מתכונים?
אביב: כן, פחות או יותר, כי יש שם כזה ממש, נגיד יש שם, עשיתי דיאגרמה מאוד מאוד גדולה של איך אנחנו מכבים שריפות בארגון, כל מיני דברים כאלה, וזה היה הספר הראשון שכתבתי, שוב, היה לי זמן ואמרתי נראה לי זה לי יהיה תרגיל מעניין בתור מישהו שאף פעם אל עשה את זה. וגם פייר, היה פה משהו מאוד מגניב מבחינתי כי בתור מישהו שמגיע מהרשת הברוכה של 8200 רוב הלקוחות שלי היו פחות או יותר משם, ורציתי מאוד לטעום גם מה קורה מעבר, מחוץ לבועה המאוד קסומה הזאת. כי ידעתי שלא כולם מתנהלים בצורה הזאתי של אה, כל אחד מכיר את כולם או בהופ של אחד פחות או יותר, ואתה תמיד יש לך את הרקע על כל אחד ויש, אתה יודע מאיפה אנשים הגיעו ואיזה סוגי culture קיימים. רציתי מאוד מאוד לראות מה קורה בחוץ והספר מאוד מאוד עזר לי עם זה, גם to spread the word לאנשים שאין להם כסף להביא אנשים מבחוץ. וגם פשוט להגיע לעוד לקוחות כזה בעולם ומאז פתאום אני עובד עם חברות בהולנד וביוון ואתה רואה פשוט את הגישות הכול כך שונות האלה ואיך ה-culture נראה שונה ואיך, לא יודע, אנחנו בתור ישראלים לא אכפת לנו יותר מדי מאוטוריטה. ואתה תדבר כמו שהייתי רגיל בתור רב"ט להגיד לסא"לים שהם טועים, אתה רואה את זה גם כמובן בחברות, ומנגד, לא יודע, אתה עובד עם איטלקים ויש להם גישה מאוד מאוד שונה לגבי האם זה בסדר להגיד לבוס שאתה לא מסכים עם מה שנאמר בחדר או לא. האם אני צריכה להגיד את הדעה שלי או שאולי לשמור את זה לאח"כ? אני רואה את זה פשוט בכל כך הרבה דרכים שונות, הישראלים רגילים לעבוד מול האמריקאים ולראות את הפוליטיקל קורקטנס ויש הרבה הרבה סוגים של culture שלדעתי זה מאוד מאוד מעניין.
ישי: זה קהל לקוחות שאתה עובד איתם, שבעצם הכירו אותך בעקבות הספר?
אביב: כן.
ישי: ובעקבות עכשיו, ספר טיפה על היום הזה שהספר יצא, אוקי, הכל מוכן, יצא, מה קרה אז?
אביב: כמו הרבה רליסים, זה לא כזה אני מוציא ובום, כן? כל העולם עליי,
ישי: איטרציות.
אביב: זה היה דווקא משהו שאני מראש ידעתי שאני רוצה לעשות את זה משהו שהוא בעצם סוג של הדרך שלי לנהל הרבה שיחות שבא לי לנהל. אז כשהספר ההוא יצא ידעתי שעקב זה, במיוחד אז זה היה עם הקורונה והרבה אנשים היו צריכים הרבה מהדברים שדיברתי עליהם בספר, מה זה אומר לנהל בעולם שאתה לא בחדר עם אנשים וכל מיני דברים כאלה, מזה יצאו המון המון הרצאות, סשנים ל portfolios של VCs בארץ, בעולם, כל מיני דברים כאלה, וזה מבחינתי מה שהיה לי מאוד מאוד כיף.
ישי: זה חלק, כאילו מסע קידום המכירות של הספר בעצם?
אביב: כן, זה מדהים כזה, יש צורך כזה בעולם של, אנשים תמיד רוצים לצרוך תוכן וברגע שיש משהו חדש, דרך טובה להגיע לעוד כל מיני קהלים כאלה, מיטאפים באירופה ודברים כאלה. ולי…אני מאוד נהניתי מזה כי אני תמיד שאני מדבר עם לקוחות או עם אנשים אני אומר להם, יש קטע כזה, יש אנשים שמאוד אוהבים ספורט. אבא שלי יכול לצפות שעות בכדורגל, אני, הכדורגל שלי ב-airquotes זה לעבוד עם חברות ולשמוע פשוט את הסיפורים. אני כל כך נהנה לשמוע את המור"קים ומה עברתם ודברים כאלה, סוג של איך שזה מתאים כמו כפפה כנראה התפקיד שהמצאתי לעצמי והאופי שלי. ואז מבחינתי כל שיחה כזאתי זה פשוט היה כיף לשבת, תמיד אני מגיע עם, נגיד לפני כמה שבועות הרצאתי פה לאיזה פורטפוליו ולסטארט אפים שממש ממש early stage והגעתי. כמובן תמיד אני יש לי את השלושה סליידים האלה למקרה שבאמת יש שם חבר'ה שרוצים לשבת רק ולהקשיב. אבל מבחינתי event טוב זה אם תוך רבע שעה אנחנו מגיעים למצב שיש הרבה שאלות ויש דיונים וזה לא רק אני אומר, כי סבבה, כן? אני מבין דברים אבל כל חברה היא עולם ויש לכל אחד את הזווית שלו וזה פשוט אני נהנה מהדברים האלה בצורה לפעמים קצת מוגזמת, כן? כמו שאמרתי עם הבנאדם הזה, הספוג שכל כך נהניתי לעבוד איתו, לפעמים אני אומר אני צריך לשלם על זה, אז זה קצת מה שיצא בחצי שנה אחרי הספר הראשון, מלא שיחות כאלה.
ישי: וזה event-ים שאתה דחפת והלכת ומצאת הזדמנויות? או ה-publisher? איך היה פה ה-,
אביב: זה היה כזה גם וגם, גם ה-publisher דואג לדברים קצת, למרות שבימינו כל ההוצאה לאור הזאת היא עסק שהולך למות בקרוב. לפחות העולם הטכני, כי אנשים מבינים ש-self-publishing זה הרבה יותר קל אם יש לך את היכולות. אבל גם זה, אני בהתחלה דחפתי ומשם זה נהיה סוג של snowballing, כי ברגע שאתה שם אז אנשים שומעים אותך בפודקאסט אחד, שומעים אותך באחד אחר והרצאות ודברים כאלה וזה היה מאוד כזה תקופה מאוד מאוד כיפית מהבחינה הזאתי, והספר השני זה היה, מתי התחלתי לעבוד עליו? לפני שנה וחצי בערך, שפשוט שמתי לב שאני עוד פעם חוזר על הרבה דברים אבל שהם לא היו לי מסודרים בראש. ואם היה משהו שאני קלטתי כשכתבתי את הספר הראשון זה שרק העבודה של לשבת רגע ולנסות לססטם לעצמי בראש את מה אני אומר בדרך כלל ומה נראה לי הגיוני וממש הצורך הזה לפרוט למה משהו הגיוני וכמה זמן הוא הגיוני ובאיזה מקרים הוא לא, מאוד מאוד עזר לי בעבודה שלי. אמרתי אוקיי, נראה לי שאני רוצה כבר לעשות את זה גם לסוגי אנשים הקצת פחות טכניים או חברות קצת יותר גדולות שאני עובד איתם, כי מצאתי את עצמי שוב ושוב אומר למנכ"לים איך הם יכולים לדעת האם הם צריכים לחשוד שאולי משהו לא בסדר, או להבין שלא. ככה נראה עולם הפיתוח, כן? זה לא, it's not an exact science, דברים יכולים להשתנות, אז הרגשתי שיש לי את הצורך הזה וישבתי פחות או יותר לעשות את אותו תהליך.
ישי: אותו publisher?
אביב: publisher אחר, יותר גדול, כי רציתי, שוב. אני אוהב תמיד לנסות דברים שונים, כמו זה שנדיר שאני אלך לאותה מסעדה פעמיים, אז אמרתי לא, נמצא publisher אחר ונראה מה יקרה, מצאתי באמת אחד שהוא היה קצת יותר גדול וזה גם היה תהליך מאוד מעניין והספר הזה יצא ביוני של השנה,
ישי: וואלה? ממש טרי.
אביב: כן.
ישי: תזכיר לנו מה שמו?
אביב: Capitalizing Your Technology, שהוא בעצם ספר שמיועד יותר למנהלי חברות סלאש פאונדרים שרוצים להבין איך נראית החיה הזאת שאנחנו מוציאים עליה מחצית מהתקציב שלנו, אם אתם סטארט אפ.
ישי: אז אם הספר הראשון פנה למנהלי הפיתוח, עכשיו הספר פונה למי שעובד איתם.
אביב: בדיוק, ויש בו כמובן גם המון לקחים של איך אני בתור CTO או בתור VP בחברה, מה בעצם יעזור לי להיות a real executive. אני עובד עם מלא אנשים פה, במיוחד בארץ, שאולי את הטייטלים מקבלים בקלות אבל את התפקיד לא עושים באמת, כן? מתנהגים בפועל כמו סוג של מש"קים וכל, לא חושב שיצא לי לשמוע אי פעם שיחה עם מנכ"ל שלא הגיע אחרי 10 דקות למשהו כמו אני רק רוצה שאנשים שלי יגידו לי מה הם צריכים, שיגידו לי מה לעשות, כל מנכ"ל טוב, כל מנהל טוב רוצה שהאנשים שלו תחתיו פשוט יבואו וייקחו את היוזמה ויעשו דברים. ואיכשהו אני רואה את זה המון אצל מתכנתים, אני רואה את זה גם יחסית הרבה אצל כזה engineering manager, first line managers אבל יש אנשים שכשהם עושים את ה leap, אם הם לא פאונדרים הם מרגישים שכזה מותר לי, לא מותר לי, אני צריך לבקש רשות, אני מחכה שיגידו לי, שישאלו אותי, ולפעמים אנחנו צריכים את הסוויץ' הזה במוח שלא, מה, אותה חוצפה שהייתה לך בתור senior engineer בחדר, שמישהו הציע איזה רעיון ואתה ישר אומר נראה לי שבמקרה הזה והזה יהיה לנו פה איזה race condition או כאלה ,אתה צריך לעשות אותו דבר גם in the big leagues. וזה משהו שלפעמים אנשים קשה להם וצריך לדחוף אותם לשם וזה קצת, הספר הוא פחות או יותר לפאונדרים שצריכים להבין מה קורה ולאותם tech executives שרוצים להבין איך רואים אותם ואיך אני יכול לעזור לא לעצמי ממניע אגואיסטי, אלא איך באמת למקסם את עצמי בחברה כי אני חושב שזה באמת ה-win-win-win האולטימטיבי.
(מוסיקת מעבר)
ישי: אז התפר הזה בין ה-tech executive או מי שמוביל את ארגון הפיתוח לבין מי שמסביבו מאוד מעניין אותי. גם מהתהליך של הספר ואיך הוא התקבל ומה שאתה שומע בעצם מהלקוחות שלך ומה-community. אתה יכול אולי ככה לזרוק לי אור על המה השאלות הכי נפוצות? מה האתגרים הכי נפוצים בתפר הזה? שמנכ"ל או board או אפילו VP Sales שרוצה לדעת קצת יותר על מה קורה ב-, על מה זה ה-engineering הזה ואיך לעבוד עם זה? מה, איפה האתגרים, איפה השאלות הכי נפוצות?
אביב: כן, תראה, קודם כל נראה לי שיש משהו שהוא בעייתי גם למתכנתים עצמם ואני חושב שאתה בתור מי שמגיע מ-LinearB גם רואה את זה, יש את העניין של are we doing good? אנשים הרבה פעמים מסתכלים, אתה יודע, המנכ"ל מסתכל על החברה ואומר זה הגיוני? זה לא הגיוני? אני מדבר עם co-founders והם אומרים לי הבאנו בשנה האחרונה עוד 20 מתכנתים, לא מרגיש איך זזים הרבה יותר מהר. זה בסדר? זה לא בסדר?
ישי: אני אגלה לך סוד, אתה כנראה לא זז יותר מהר (צוחקים).
אביב: כן, בדיוק, אז זה נגיד סוג השאלות שאני שומע כל הזמן, האם דברים בריאים, נכון? אתה בתור בן אדם, אם אתה חושד במשהו תלך לרופא, תעשה בדיקות דם, יהיה לך סוג של מדד אובייקטיבי לאוקיי, הנה איפה שאנחנו צריכים להיות. אין את זה כל כך בעולם שלנו. יש כל מיני ניסיונות לעשות את זה אבל זה מה שאני שומע המון המון המון, האם ה-CTO שלי מספיק טוב או לא? האם הארגון שלי גדל מספיק מהר או לא? סוג האנשים שאני מביא הם טובים או לא? אמרו לי הפרויקט הזה, הגדול, זה הדבר הכי חשוב שלנו, אמרו לי חצי שנה, הגיוני חצי שנה? לא הגיוני חצי שנה? באמת אי אפשר יותר מהר? זה נגיד סוג אחד, כל ההתעסקות הזאת סביב האם בכלל מה שקורה פה הוא הגיוני ובריא. עוד משהו שאני רואה זה במיוחד לאחרונה, זה סביב הגדילה של הארגון, סביב האם הגודל הזה שיש לנו הוא הגיוני או לא, כמה שאילון מאסק הוא לא בדיוק הדוגמא הכי טובה לניהול, יש משהו שאני כן רואה זה הרבה אנשים פתאום תוהים לעצמם רגע, אם טוויטר חתכו את הכוח אדם לאיזה 20 אחוז ממה שהם היו ווואלה, האתר רץ, נכון?
ישי: הכל עובד.
אביב: כן, עובד, כן? בוא,
ישי: סוג של.
אביב: היה באגים לפני, אז אם זה עדיין מתפקד והם רצים ככה ב-20 אחוז ווואלה, אפילו יש יותר, אני בתור מישהו שמשתמש בטוויטר אולי יותר ממה שבריא, אני שם לב שיש להם יותר רליסים ויותר אקספרימנטס משהיה להם בשנים, אם זה שהם חתכו ממש to the bare bones. אז מה זה אומר? האם אני בתור founder של סטארט אפ, אולי גם אני סתם משלם מלא כסף להרבה אנשים שלא באמת pulling their weight. אז זה משהו שגם רואים הרבה, ועכשיו יש את כל הדיונים האלה סביב מה בעצם ה-runway שאנחנו רוצים לשמר לעצמנו ומה הגודל ההגיוני לצוות וכמה להגדיל, זה נגיד גם משהו שאומרים המון ואם הייתי צריך לשים כזה את הדבר השלישי שהוא כנראה הכי בולט, זה כשאתה מסתכל על ארגון, על ארגון הפיתוח שלך מבחוץ, השאלה היא באמת כמה חיכוך צריך להיות עם העולם החיצוני? יש כאלה שמנסים להסתכל על זה כעל לא, לא, הם, אתה יודע, כמו האמנים המיוחדים האלה, תקיף אותם בחומה מרופדת, אף אחד לא מפריע להם, אף אחד לא מדבר איתם, תן להם את הטאסקים היפים שלהם ותן להם לעבוד. יש כאלה שרוצים הכי הרבה חיכוך, לא, לא, אני לא הולך ללעוס לך את הכל, לך תדבר עם ה-sales, דבר עם האיש ממרקטינג, תבין מה צריך לעשות וכל הסקאלה באמצע. והרבה אנשים מנסים להבין מה הגיוני, מה הדבר האולטימטיבי, מה הביא אותנו לדרך הפעולה הכי נכונה עבורנו וגם - כמו שאתה אמרת מקודם, הוספת אנשים, אתה לא זז יותר מהר? גם פה יש קטע של אין פה תשובה אחת נכונה, נכון, אני מאוד מאמין בזה שאנחנו צריכים to tailor את הארגון לכל מה שקורה מסביב. בין אם זה לדוגמה בחברה שמתעסקת ברפואה, ולא משנה כמה תנסה המתכנתים לא הולכים להיות כנראה domain experts ויכול להיות שגם מבחינת liability אתה לא רוצה שהם יחשבו שהם domain experts. יש את הדרך הנכונה לתפור את המבנה שם אל מול חברה שהיא חברת B2C שעושה מוצרים שאתה עובד עליהם ואימא שלך יכולה להשתמש בהם ואתה כנראה יכול להבין אותם מאוד מאוד טוב, אז צריך תמיד לדעתי לנסות להבין מה הכיוון הנכון לתרמוסטט הזה של החיכוך. כמה אני רוצה להוציא את המתכנתים החוצה לעולם.
ישי: בעולם של, רובנו חיים בעולם של SaaS, אבל באופן כללי פאונדר שרוצה לדעת אם חברה שלי מתפקדת טוב, יש לו, הולך לגוגל מוצא תוך שניה מלא benchmarks ומלא מטריקות קסומות יותר או פחות של מה היחס בין המכירות למשכורת של אנשי המכירות וכל מיני ראשי תיבות כאלה שתוך שנייה מגלים לו אם הוא נמצא במקום טוב ובמקום ש-investors אוהבים. אפשר לקבל משהו דומה לזה גם לאזור הזה של הפיתוח? ל-engineering? בסוף כל החברות האלה חברות טכנולוגיות, יש מלא מספרים ומטריקות ל-finance ולכסף, מה קורה עם הפיתוח?
אביב: כן, אז פה לדעתי אנחנו בעולם בעייתי, כמו שאמרתי יש לנו פה אמנות מוזרה. כי יש דברים שהם מאוד מאוד עוזרים, סוג של לקבל את ה-heartbeat, כל DORA Metrics ודברים כאלה שאני חושב, אני תמיד תמיד אומר ללקוחות שלי שווה, אם אתם לא, אין לכם את התחושה של איפה אנחנו עומדים מהבחינה הזאתי, שווה תמיד מלהתחיל להסתכל על זה כי זה מסוג הדברים שהם מאוד מאוד יעזרו לך פנימית בארגון להבין מה קורה והאם אנחנו משתפרים או לא משתפרים, תקופה יותר חלשה או פחות חלשה, אבל זה מסוג הדברים כשאני רואה שמנסים לתווך אותם החוצה לארגון, המנכל שתוהה, תוהה האם זה הגיוני או לא, זה כבר אוקיי, מה? כמה ריליסים עשינו השבוע? מה זה משנה? הם מבחינתם לא יודעים האם עשינו 100 ריליסים כי הצוות פירק את המוצר ל- 80 אלף microservices, אז בעצם אנחנו עושים 100 ריליסים כי מישהו שינה, אתה יודע, איזה סטרינג וצריך לגרום לו לפעפע בעולם. או כי באמת אנחנו זזים במהירות מטורפת, ויש פה עניין כזה שפשוט שאתה מסתכל על זה, זה גם משהו שהוא מאוד מאוד קשה להשוואה החוצה, המספרים האלה בצורה אבסולוטית. אין פה משהו יותר מדי, אני כן יכול להגיד לך אוקי, אם ה-cycle time שלך הוא בשבועות, משהו פה כנראה הוא בעייתי. אבל לדעת האם זה good enough או האם אנחנו צריכים עכשיו לשבת על זה עוד או לא, זה אזור מאוד מאוד בעייתי. ופה הרבה פעמים אני מוצא שזה מסוג הדברים שלפחות מה שאני רואה שעובד הכי טוב זה כשאני עובד עם החברות, אנחנו מנסים ממש למצוא את ה-bespoke measurement לעצמכם, האם הצוות צריך להוציא, נגיד בוא נסתכל על ה-road map שלכם וסוג של ננסה להבין ביחד מה הדברים שמונעים מאיתנו לדלבר בקצב שהביזנס היה רוצה. או מה הם הדברים שאנחנו מרגישים שהם החוזקות האסטרטגיות שלנו, הרבה פעמים לדבר עם לקוחות על אסטרטגיה, וזה מילה שנזרקת בכל מקום, נכון? אסטרטגיה, אסטרטגיה, זה גיוסים אסטרטגיים וזה, אנחנו עושים פה ריפקטור אסטרטגי,
ישי: הכל אסטרטגי.
אביב: בדיוק, הכל אסטרטגי, אבל בפועל אנחנו עושים טקטיקות רוב היום. ויש פה עניין של אם אתה מסתכל על החוזקות הבאמת אסטרטגיות שלך אני רוצה לראות שזה בא לידי ביטוי במבנה של הכוח R&D, בחברה שהיא טכנולוגית, כן? אם היינו, לא יודע, מייצרים כיסאות פלסטיק כתר זה משהו אחר. ואז לדוגמה כשאני מסתכל על ארגון אני אומר מבחינתי מדד טוב לארגון R&D טוב לדוגמה זה כמה innovation אני רואה שקורה באמת. עכשיו למדוד innovation זה עולם בפני עצמו וזה משהו שהוא מאוד מאוד קשה ויש לי לקוחות שנגיד מנסים ממש לשים לב לסוף שנה, בואו נספור כמה פיצ'רים / initiatives יש לנו שהם התחילו לא מפה, הם התחילו כי מישהו מ-,
ישי: אתה רוצה למדוד את ה-innovation הפנימי, מה ש-engineering מעלה לבד?
אביב: כן, לדוגמה, או מנגד כמה מהמוצרים שיש לנו עכשיו, לקוחות שיש לנו עכשיו, זה דברים שטכנולוגית לא היה לנו רקע בהם או לא היה לנו התקדמות בהם נגיד לפני שנה או לפני, תבחר את הווינדו שלך, אבל כל חברה שמתקדמת בימינו, במיוחד נראה לי שנגיד כל ה-Generative AI יש צורך לפעמים פשוט להמציא דברים מחדש ולהבין ש-what get you here won't get you there. מתישהו אנחנו צריכים להמציא דברים או ללמוד דברים בצורה אחרת, וזה נגיד מסוג הדברים שאני רוצה לראות שיש לנו לפחות hunch כלפיהם. אבל אני חושב שמרגישים פה, זה לא, אין לי, זה לא שאני מחביא בכיס איזה מספרים שרק שהם חייבים לי כסף אני אומר הנה, זה המדדים האמיתיים. אני באמת מאמין שברוב המקרים אנחנו צריכים להגיע למשהו שהוא ממש ממש מותאם לחברה. ומדדים אובייקטיביים הם נהדרים בשביל הניהול הפנימי, כדי שאני אראה מה קורה, או בשביל, סוג של לשים בייס-ליינים של ברור שיש פה בעיה, אוקיי? אם האוטו שלך לא מאיץ ל-60, יש פה בעיה, אבל האם האוטו אמור להגיע ל-300 קמ"ש? אני לא יודע, נכון? זה פה זה כבר העניין.
ישי: זה בכביש.
אביב: כן (צוחק).
ישי: אז אתה בעצם אומר שאולי קצת בניגוד למדדים האהובים על משקיעים ועל פאונדרים של הארגון, כאילו איך הסטארט אפ שלי נראה, כאן אין איזה סולם שקל להשוות ושמשקיע יכול להגיד וואלה, אתה במקום, ב-sweet spot שאני אוהב, אלא צריך פרשנות וצריך לפעמים מומחה מבחוץ שיעזור לי להבין מה נכון לי, מה נכון לחברה שלי ובמה אני משקיע.
אביב: נכון, לדוגמה אני אוהב להסתכל על מה בעצם is holding us back. מה הדברים שעוצרים אותנו? האם הבעיה היא בכלל ביזנסית, האם הבעיה היא שהפרודקט לא סגורים מספיק על מה אנחנו רוצים לעשות, או שאני שם לב שוואלה, בחברה יש כמעט תמיד ממש בק-לוגים מוכנים מסודרים כזה, מקוטלגים, רק מחכים ש-engineering סוף סוף יועילו בטובם להגיע אליהם. כי זה משהו שהוא מאוד מאוד משנה, הרבה פעמים אנחנו לא באמת מבינים את זה, מישהו, אתה יודע, שמנו את ה-roadmap אבל איפה זה נתקע? האם זה נתקע בגלל זה או בגלל זה, או בכלל כי יש מלא בעיות quality ואנחנו פשוט לא מגיעים לעשות את הפיתוח שאנחנו רוצים לעשות. זה רגע מסוג הדברים שצריך לפעמים להבין, וגם יש פה, אם אתה מסתכל על ארגון פיתוח בתור חיה כזאת מוזרה, צריך להבין שבאמת יש פה סקאלה שהיא מאוד מאוד שונה במה אתה רוצה לייצר, כי יש את ה-, לא יודע, הסקייל אפים שהייתי רואה פה בתל אביב שפשוט גייסו אנשים על ימין ועל שמאל, אנשים עם רקע ועם פחות רקע ואז זה להשוות תפוחים לתפוזים. אל מול הדוגמאות שאני תמיד אוהב לתת, זה הצוותים של וואטסאפ ושל אינסטגרם שבם נרכשו שהיה להם בערך תריסר מתכנתים שכל אחד באופן יחסי היה חי על עשרות מיליוני יוזרים בעולמות בטא לפני שהיה AWS, לפני שעשיתי קליק ופתאום יש לי מערכות מוכנות פה ושם. והם עשו את זה ואני תמיד אומר וואטסאפ, היה להם את ה-iOS native app ואת האנדרואיד app ואת כל ה-frame work הזה בענן לכל כך הרבה יוזרים בכל העולם והם עשו את זה באמת עם איזה 13 מתכנתים. והיום מנגד אני מסתכל על, אתה יודע, כל המגדלים היפים פה בתל אביב ויש להם 100 מתכנתים והם מוציאים, בהשוואה, דברים בקצב הרבה יותר איטי. והרבה מזה זה כי אנחנו בעצם בוחרים לעבוד בצורה הזאתי כי אם אתה בחרת ללכת בצורה שבה, לא יודע, לא אנחנו מפתחים דברים לעומק וזה לוקח זמן והכל חייב להיות ברף איכות מטורף, אוקי, אחלה, אז זה בחירה אסטרטגית, מצוין. אבל אם זה קורה פשוט כי אף אחד אחר לא מסתכל רגע לצדדים ואומר רגע, בעצם למה בעצם יש לנו את כל המורכבות הזאתי? או האם אנחנו יכולים לעשות דברים בצורה שונה? פה זה המקומות שבהם אני מדליק נורות צהובות ואני אומר בואו נחשוב מה אפשר לעשות שונה, האם זה הדבר שאנחנו רוצים בתור ה-culture של הארגון שלנו או לא, זה סוג הניעורים שלפעמים חברות צריכות מבחוץ.
ישי: הזכרת את הנושא של המבנה של ארגון ה-engineering. כמה יוצא לך להתעסק בשאלות האלה של ממש המבנה הארגוני? Reporting structures וסקוואדים, teams וכו'? כמה זה נפוץ שזה האזור שנוגעים בו?
אביב: במיוחד אם, אתה יודע, סאטראפים קצת יותר גדולים, בוגרים, זה משהו שאומרים הרבה כי קודם כל יש קצת טרנדים. סקוואדים זה משהו כבר כמה שנים כולם רוצים להגיד לעצמם שהם עושים סקוואדים או עושים פודים, אנחנו הלכנו ל-cross-functional teams או empower teams or whatever you wanna call it. ואני חושב שבתור מישהו שעזר לכל מיני חברות להיכנס למודי עבודה כאלה, יש סיבה גם שזה נהיה, יש את ההבדל בין טרנד ל-fad נכון? זה משהו שהוא סתם כי אנחנו צריכים משהו לכתוב עליו בטורי אופנה ועוד חודשיים נשכח ממנו ויש טרנד פשוט כי זה הכיוון כי זה באמת טוב. לפני 20 שנה דיברו על agile כי זה באמת היה שונה מאיך שפיתחו אבל ראו את ה-value וגם היום ידברו על אג'ייל אבל, אומנם זה לא הדבר שמדברים עליו כל היום אבל רואים את ה-value, זה היה טרנד הגיוני. אני חושב שהעולם הזה של ה-cross-functional development הוא באמת חשוב ובאמת עוזר, אז זה מה שאני רואה הרבה חברות המתעסקות באיך אנחנו עושים את זה, נגיד כשעזרתי ליוניקורן פה בארץ להחליט אוקיי, מה אנחנו הולכים לעשות, יש לנו את ה-150 מתכנתים שלנו, המבנה הנוכחי לא הגיוני, מה אנחנו צריכים לעשות מבחינת למקסם את זה ולאפשר לעסק להמשיך לצמוח בלי להרגיש שכל הזמן אנחנו כזה פה נהיה כבד. שם נהיה כבד ואתה מרגיש שאתה כל הזמן עושה ג'גלינג בתוך החברה כדי להחזיק דברים. זה נגיד משהו שאני רואה הרבה ומתעסק איתו אבל גם פה. בדיוק דיברתי עם סטארטאפ פה בארץ שהסברתי להם יש בעיה אמיתית עם לחשוב שזה ה-silver bullet, אני, הנה המדריך לאיך עושים סקוואדים. אנחנו פשוט עושים את זה וזהו ונעוף, כי סקוואדים טובים לדוגמה בחיים לא יעבדו, גם עם המתכנתים הכי טובים בעולם, בלי אנשי ונשות פרודקט מעולים, זה משהו שאני תמיד אומר, אם הפרודקט לא שם, אל תנסה את זה כי זה בד"כ לירות לעצמך ברגל, לדוגמה, או יכול להיות שאתם חברה שבה באמת יש deep tech אמיתי והמבנה ההגיוני הוא לאו דווקא שכולם יסתכלו רק על,
ישי: כולם עושים הכל.
אביב: כן. כי לפעמים זה פשוט, אולי זה מגניב. אולי זה נראה טוב, אולי זה עוזר ל-engineering brand אבל זה לא הדבר ההגיוני גם מבחינת התפוקה של האנשים וגם סוג האנשים שאתה רוצה לגייס, אז צריך תמיד להבין את זה. ואני חושב שההסתכלות הראשונה שלנו צריכה להיות בתור אנשים שרוצים לבנות ארגון פיתוח, אף אחד לא משלם לארגוני פיתוח כי המנכ"ל רוצה להדפיס את הקוד ולתלות אותו על הקיר בסופו של יום. כי זה לא, המטרה היא לא הקוד, המטרה היא בעצם מה שזה עוזר לביזנס להשיג, ואם היו יכולים להחליף את כולנו ב-GPT4 היו עושים את זה מזמן. אז בינתיים כמה שאתה רוצה יותר להישאר, אני חושב שמה שמאוד מאוד חשוב זה להבין איך אנחנו מביאים את ה-edge האמיתי של להבין מה הביזנס צריך ולבנות את הדברים סביב זה. אז לדוגמה לבנות ארגון פיתוח שהוא, יש לו בדיוק את רמת החיכוך ההגיונית לביזנס ול-sales ול-marketing כדי להבין איפה ה-edge הנוסף שאנחנו מוסיפים. כשאני עובד עם נגיד חברות, ישבתי עם מישהו מיפן ואז הוא אמר לי אתה יודע, אתה כל הזמן אומר לנו, האמריקאים יודעים שאני אומר "חוצפה", צריך להרגיש בסדר עם להגיד לא, אני לא מסכים. או אתה לא חייב להגיד זאת טעות אבל אתה יכול להגיד אולי, נכון? אתה תמצא את הדרך.
ישי: "כן, אבל"...
אביב: כן, ושמה לא, לא, מה, זה לא, גם בסטאראפים לפעמים יש את הגישה של לא, אני לא אמור להגיד למי שמעליי שזה לא נכון. וזה מסוג הדברים שאנחנו לא יכולים, בעצם מה קורה אנחנו עושים לעצמנו קאפ מאוד ברור של כמה טוב כל האימפקט של הארגון שלנו יכול להיות כי בעצם אנחנו מוגבלים ל-weakest link שיש לנו בשרשרת הפיקוד. ואם אנחנו מייצרים culture שבו אנשים יכולים לדחוף, יכולים להגיד דברים, את פתאום יכול לאפשר עולם אחר לגמרי להיפתח וגם פייר, להביא גם אנשי מקצוע שהם הרבה יותר טובים כי בסביבה שבה אני מרגיש חנוק אני כנראה לא ארצה להיות אם אני באמת ב-A player. וזה מסוג הדברים שאני רוצה לראות more of במיוחד בארץ כי אני מרגיש שבארץ אנחנו קצת שכחנו מה זה אומר לתת למתכנתים את הגישה החוצה. כי מלא מנהלים שאני מדבר איתם מדברים על לגונן על הצוות וחושבים שהם סוג של גננת כזאת שצריכה להיות שם שאף אחד לא יפריע למתכנתים, שהם הקדושים בצוות. ומנגד, בחו"ל אני רואה שזה דווקא ההפך, שאולי מפריעים להם יותר מידי אבל זה יותר במוד של אני אומר לך מה לעשות או זורק עליך דברים ולא במוד של לאפשר לך לדבר. אז איך אנחנו מייצרים ארגון שכל המבנה שלו בעצם מאפשר לא רק ל-R&D, לכל הביזנס להתקדם יותר מהר עם אימפקט אמיתי, כן? עכשיו זה מסוג הדברים שאצלי זה בלב, כן? כשאני מתחיל לדבר על חברה שעה אני כזה רושם לעצמי בראש אוקיי, פה נראה לי שיש להם בעיה או ה-culture פה מרגיש לי שהם, מישהו מדבר איתי עכשיו על התכנית שלו, לא קיבל אף פעם push back. שזה ישר אני מרגיש שאוקיי, אולי צריך לבדוק למה אנשים לא מדברים, למה הכלבים לא נובחים כמו ששרלוק הולמס אמר. אז אני רוצה לראות דברים כאלה אבל זה באמת, כל הקטע הזה של נראה שמרגישים כמה אני מתלהב מזה, כן? זה דברים שאני חי אותם, ויש פה עניין של לבנות ארגון פיתוח, מה המבנה הנכון, אין פה את השטנץ, יש פה את הבוא נמצא את הדבר שמתאים לכם וגם, כמו שאני אולי קניתי חליפה מאוד מחויטת במילאנו לפני כמה שנים, אני יודע שוואלה, מתישהו אולי העליתי קצת משקל, אולי זה הקורונה, אולי זה, מתישהו צריך לעשות עוד adjustment ואין,
ישי: אומרים שארגון פיתוח, בטח בסטארטאפ, כל חצי שנה צריך לעשות,
אביב: כן, אני מדבר על זה שברוב הארגונים, נגיד עד לפני שנה וחצי כשבאמת גדלנו בטירוף היה ממש דור, הרגשת דור עד שנה בכל ארגון. ממש זה היה מקסימום של זה היה דור אחד ואחרי זה דברים באמת משתנים לגמרי. היום אולי זה קצת יותר לאט, אולי יותר לכיוון ה-18 חודשים אבל באמת יש דורות כאלה, אתה חייב לראות שאתה תמיד עם הפנים קדימה ואתה משתנה כי אחרת הארגון is going to outgrow you ולא נראה לי שזה המקום שאנחנו רוצים להיות בו.
(מוסיקת מעבר)
ישי: דיברנו על מבנה ארגוני ועל גדילה ואני יודע שיש נושא שבטח בזמן האחרון חם של איך גדלים בצורה אחראית? ואיך לא רק בוא נגייס עובדים, בוא נגייס מפתחים ויהיה מה שיהיה. תספר לי טיפה על מה אתה רואה, מה הלקוחות שלך מחפשים, על מה מדברים בשאלה הזאת של איך אני גדל אבל עם איזושהי אחריות.
אביב: לי אישית זה קצת מרגיש כמו כזה finally moment. כי אני אישית שנים ניסיתי להגיד לאנשים לא, אתם גדלים בצורה שהיא אולי זה מה שאתם מרגישים שה-VCs, אולי זה מה שאתם רואים שקורה מסביבכם בבניין הגדול שלכם אבל הרבה פעמים גדלנו בצורה שהיא לא הגיונית מבחינת ליצור ביזנס אמיתי. וראיתי איך צוותים במשך שנים משקיעים אחוזי זמן לא הגיוניים לא בפיתוח המוצר אלא ב-on boarding ובאיך אנחנו מייעלים את ה-interviewing processes שלנו ואנחנו כל הזמן צריכים לצמוח ועד שמישהו התרגל לתפקיד פתאום אנחנו כבר צריכים לקדם את זה, ליצור פה צוות, לעשות אקסטרקטים, כל מיני ריפקטורינג ל-organization. והיה פה קטע שלי תמיד גם ניג'ס בראש, הדוגמאות שהבאתי על אינסטגרם וואטסאפ, שאפשר להשיג המון עם צוותים מאוד מאוד קטנים, והאמת זה גם הדוגמאות שראיתי, תמיד אני נותן דוגמאות של מה שאני רואה ב-8200 ששם כמה שאתה יודע, ידברו איתנו על בחרו בפינצטה את הילדים הכי, whatever, bottom line לקחנו ילדים בני 18, שמנו אותם על פרויקטים וזה בד"כ, אני הייתי בצוותים שנדיר שעבדתי עם יותר מ-2-3 אנשים ועשינו דברים. הגענו לתוצאות, לא היה ענן, לא היה בלגן, עשינו דברים, ומנגד אני תמיד משווה את זה לדוגמה בארה"ב אם תלך למודיעין שלהם, בין אם זה לא יודע, CIA, NSA, כל הגופים האלה. יש פי 100 תקציב בערך, יושבים שם רק PHD-ים ועדיין היו דברים שאתה יודע, הישראלים החאפרים האלה עם כל הדרכים שלהם לעגל פינות היו עושים דברים שהאמריקאים היו מסתכלים ואומרים איך הם עשו את זה.
״הרבה פעמים גדלנו בצורה שהיא לא הגיונית מבחינת ליצור ביזנס אמיתי״
ישי: השק"ש במדור.
אביב: בדיוק, ואני לא חושב שאנחנו צריכים לטחון שעות או הכל חייב להיות super scrappy, ממש לא, אבל אני כן חושב שיש משהו מאוד מאוד טוב בקונסטריינז ובגדילה שהיא יותר לכיוון האורגני הגיוני מאשר לרדוף אחרי הגדילה המטורפת. וזה, תמיד אני אמרתי שבמבנה האידיאלי זה כזה סוג של 6-6-6-6 שיש לנו צוות של 6 אנשים, מעליו יש את ה-6 מנהלים שהם בקבוצה של 6 צוותים כאלה וכן הלאה. וכמובן שאתה יכול ללכת לפה, לשם, יש לך הרבה סניורים, צוותים יכולים להיות יותר גדולים וכו', אבל זה סוג של ה-default שלי. ועוד משהו שאני במיוחד עם פאונדרים מדבר עליו, זה על הקונספט הזה של profitable R&D growth אם כשאתה מסתכל רגע על המבנה שלך ואתה מסתכל על איך אתה צומח ואתה מנסה לגזור רגע קדימה מה יקרה עם הסטארטאפ אם נמשיך ב trajectory הנוכחי, אתה תמיד צריך להבין שאתה רואה מצב, הולך להגיע מצב שבו ה-R&D לא חייב לצמוח בצורה ליניארית עם הביזנס, שזה משהו שאני רואה בהמון חברות, פחות או יותר ככל שאנחנו מביאים יותר לקוחות והעסק מתרחב, אנחנו בעצם חייבים להביא עוד ועוד ידיים עובדות רק כדי to keep the lights up, כי אנחנו מתעסקים בליצור סוג של מערכת כזאת שהיא לא, היא מאבדת את זה שהיופי בסופטוור זה שאתה רוצה להגיע לסוף שהמרג'ינג שלך הוא רק הולך וגדל עם כל יזום נוסף כי זה software.
ישי: זה בתנאי שאתה לא מפתח פיצ'ר לכל לקוח.
אביב: בדיוק, ואנחנו רואים את זה שבמלא מלא חברות, במיוחד ב-SaaS, אנחנו לדוגמה היו חברות שאני אישית בתור מישהו שמהצד שמע משהו שה-VP R&D מזכיר in passing ככה או ככה - ואני הלכתי לריב מול הפאונדרים לגבי לא, לא, אתם לא מבינים, כל סעיף כזה שאתם מרשים לצוות שלכם להתחייב רק כדי לסגור חוזה, זה הולך להגיע למצב שעוד חצי שנה 40 אחוז מה-R&D שלכם יהיה professional services ואתם לא קולטים את זה. או כל מיני הבטחות כאלה לדוגמה on pram זה משהו שאנחנו חייבים לפעמים לעשות ב-SaaS, אין מה לעשות, זה נותן value מטורף, אבל יש on prem ויש on prem, יש את האלה שאומרים אוקיי, סבבה, אתם תעשו את ה-on prem, אנחנו לא נכריח אתכם לעשות שדרוגים יותר מאיזה פעם בשנה, אנחנו נודיע לכם איזה חודשיים מראש על כל דבר, זה פתאום אתה שם לעצמך,
ישי: במקום לסרב.
אביב: בדיוק, שם לעצמך כל כך הרבה משקולות שאוקיי, תעשה את זה כשתהיה IBM, אבל כשיש לך בפועל כולה איזה 15-20 אנשים שעובדים על ליצור את זה, הם לא יכולים לנהל את המטריצה הזאתי של ה-80 לקוחות וכל אחד הוא חיה שונה כזאתי כי קומבינטורית זה לא יעבוד. ואני רואה כאלה שמנסים, אז אתה רוצה ליצור מצב שיש לך צמיחת R&D הגיונית שזה בא משני כיוונים, אחד זה לוודא שהביזנס באמת מבין איך עושים תוכנה בצורה שהיא scalable, שלפעמים זה לבדו קשה ואני פה אני יודע שלי יש קלף הרבה פעמים אני רואה, אני עובד עם לקוח או לקוחה VP Engineering שאני אומר להם את זה הם לא מבינים אותי או אומרים לי לא, לא, זה מה שהביזנס צריך, אבל אם אני בא מבחוץ ואני אומר עבדתי עם קצת יותר חברות ואפשר לעשות שונה, הם יקשיבו, אז זה מאוד נחמד שיש לי את הקלף הזה.
ישי: יתרון של האאוטסיידר.
אביב: כן, שזה לפעמים זה כזה unfair advantage אבל זה עוזר, אז צריך לפעמים לעזור לביזנס.
ישי: משלמים כסף בשביל ה-input הזה, זה חייב להיות אמיתי.
אביב: לגמרי. לפעמים אנשים צריכים להבין את זה שליצור ביזנס שהוא ביזנס תוכנה שבאמת הולך להחזיק עם הזמן, אנחנו חייבים להבין מה הביזנס ולא פשוט להגיד כן, כן להכל. ומנגד, כשמסתכלים על R&D צריך באמת, לפעמים אני מרגיש שמישהו מדבר איתי אה, אני רוצה לגייס מישהי לכזה תפקיד או אני חושב לייצר כזה תקן. למה? כי נראה להם מגניב, אני אומר אוקיי, מה יהיה התקן שלך להאם זה יצליח, איך תדע שהתפקיד הזה הוא באמת היה שווה את זה, האם זה שווה את האיקס כסף שאנחנו הולכים לתת למי שיאייש את הפונקציה הזאת? והרבה פעמים אנחנו לא חושבים על זה, האם הצוות הזה שיש לך פה, באמת היה צריך אותו? תחשוב על כל ה-value שהוא הביא לחברה בשנה האחרונה, האם זה היה הגיוני או שאולי היה עדיף לנו לפרק את הצוות ולעבות את כל הצוותים מסביב בעצם. או לחשוב על מוצר אחר, וסוג הזה של מה זה אומר לבנות profitable R&D, זה ארגון פיתוח שבעצם מבין שהגדילה שלנו חייבת להיות כזו שתומכת בביזנס והידיעה אם אנחנו מנסים לייצר גרפים, זה לא שה-head count שלי ב-R&D הולך בצורה שהיא שוב, ליניארית עם הגדילה של הארגון. אלא שאנחנו רואים שבאמת ה-R&D מתישהו אחרי איזה hump ראשוני יתנתק והוא לא חייב לגדול בכזה קצב. ואם הוא ממשיך לגדול מהר זה כי אנחנו מתפשטים לעוד סוגי שווקים או מנסים עוד מוצרים ולא כי אנחנו חייבים להביא עוד אנשים רק כדי לוודא שהדברים פה לא מתרסקים סביבנו.
ישי: בהרבה מקרים הסטארטאפ בלחץ של איזשהו land grab, אני מנסה לתפוס market share, אני לא כל כך אכפת לי מפרופיטביליטי אבל אני רוצה להיות שם ואז וואלה, אני יכול להגדיל קצת את ה-offering שלי, ללכת לעוד איזה כיוון, לפתח עוד איזה פרודקט ליד, וכמעט תמיד כל ה-engineering כבר עסוק,
אביב: בדיוק.
ישי: אני רוצה לעשות משהו חדש, אף פעם לא ראיתי צוות engineering שאומר תביא, תביא. יש לי capacity, הנה הפיצ'ר החדש, המוצר החדש, הכיוון החדש, יש לי בשבילו זמן, אז צריך לגייס אנשים, איך מתמודדים עם זה?
אביב: זו בדיוק הבעיה. כי זה קצת כמו אף אחד לא מחזיר באדג'ט בסוף שנה, נכון? אף לא אומר אה, נשאר לנו, קחו אותו, משתמשים בו. ויש פה עניין של איך אנחנו מייצרים ארגון שמבין את זה שתמיד, נגיד תמיד שמישהו מדבר איתי על נגיד ה-roadmap שלהם עכשיו מתחילים לדבר על 24. מסתכלים על דברים, אני אומר הדבר הכי חשוב להבין זה לא איך אנחנו מייצרים את הפיצ'רים האלה שהם אחלה ויופי. תמיד כשאני עובד עם לקוחות אני אומר בוא נחשוב על כל ה lifecycle של הדבר הזה כי באידיאל, אחרי שהוצאנו את זה, אולי היה שווה עוד כמה חודשים של טיונינג ו-whatever, אבל האידיאל תמיד צריך להיות שאנחנו עוברים מסוג של burst של הרבה attention למשהו כדי להביא אותו למצב מסוים. ואז משם הוא עובר למוד שבד"כ, אלא אם כן זה באמת משהו מתפוצץ. ואז אנחנו הולכים להשאיר צוותים שאקטיבית עובדים עליו בטירוף, זה משהו שהוא מגיע למצב שאוקיי, לפחות לתקופה אפשר רגע לשים אותו בצד ואפשר לתת לצוותים להסתכל על דברים אחרים. וזה צריך להיות המוד, ברגע שנתת לצוות שם של מוצר, מבחינתם הם אמורים לעבוד עליו לנצח, ואז החיה הזאתי, מבחינת המתכנתים האלה תמיד אמורים להעמיס עליהם עוד ועוד טסקים כי הם, חלילה שהם יקומו בבוקר והג'ירה שלהם לא מלא במלא דברים לעשות, וזה נהיה סוג כזה של self fulfilling prophecy. הם הולכים להמשיך לעבוד על זה, אבל אם אתה מנסה להסתכל על מוד של מה שהם עושים זה נגיד תלך על מודל OKR-ים שה-objective שלהם הוא objective דווקא ביזנסי של להצמיח את העסק או להיכנס לשווקים אחרים או whatever. מתישהו הם יגידו אוקיי, נראה לנו שסחטנו את הלימון הזה הכי הרבה שאפשר, אפשר עכשיו לשים את זה on the backburner או רק לתחזק את זה ובוא נסתכל על עוד דברים, או מנגד להביא את הביזנס למצב שהוא מסתכל על זה ומראש לא צובע את הדברים האלה בתור זה בעצם עכשיו ה-cost of keeping the lights on. הצוות הזה זה בעצם עכשיו הוא צבוע והוא מיועד רק לזה, אלא להבין שאנחנו מצפים מכל דבר שיש לו, שהוא עובד בכזה סוג של גלים ויש לייף סייקל לעולם וזה משהו שסטארטאפים קטנים עושים את זה כי אין להם ברירה אבל הבעיה היא שנכון, כמו שאנחנו עבדנו בצבא, הזמני הוא הקבוע, וברגע שאתה באופן זמני עשית, אפילו הרשית לעצמך במיילים או בסלק לקרוא לצוות הזה הצוות של מוצר איקס, יהיה אח"כ סופר קשה לעשות את הניתוק הזה ולעזור להם להבין שהם יכולים לעשות,
ישי: כי פתאום אין צוות ש-, אם משנים לו את השם או את הייעוד אז פתאום רגע, אז מי הצוות שמחזיק את המוצר ההוא?
אביב: בדיוק.
ישי: מצד שני מפתחים אוהבים לעבוד על דברים חדשים ומישהו צריך לעשות את התחזוקה, מישהו צריך להחזיק את ה-, בנינו מוצר, עבדנו חצי שנה מלא אנשים, הגענו לשלב שהוא קצת יותר stable אבל עדיין צריך להחזיק אותו. המוצרים האלה גובים מס, והמס הזה לא הולך וקטן.
אביב: נכון.
ישי: אז איך אני, זאת אומרת יש החלטות אינג'ניריות של ארכיטקטורה, של איך אני אבנה את זה ככה שהתחזוקה תהיה סבירה. אבל יש גם פרודקט ויש feature requests סביב המוצר הזה, זאת אומרת זה לא מת, איך אני בונה את זה ככה שבאמת יש איזה עתיד שהוא, ה-margin הולך וגדל?
אביב: אז פה נגיד זה מהמקומות שבהם כל החשיבה של סקוואדים / OKRs מאוד מאוד טובה שאנחנו מסתכלים על דברים לא במוד של יש לי את הצוות הזה, יש לו איקס capacity וצריך למלא לו את ה-backlog כי זה מה יש. אלא דברים שנכנסים בכלל לתכנית באים תמיד מהזווית של מה ה-value לביזנס כי לפעמים אתה, אני רואה אנשים שיושבים על איזה באג ואני אומר אבל בפועל למי אכפת? כן? משהו שנגיד אנשים לפעמים אומרים לי מה, לא, חייבים. ואני מסתכל וזה קרה לי פעם אחת שפשוט תפסתי מישהו אמרתי לו תגיד לי רגע כמה לקוחות מושפעים מזה? כי זה היה איזה באג שאני זוכר שסיפרו לי כבר איזה שלושה שבועות שאיזה מתכנת מסכן שמנסה להבין מה לעשות איתו, ב-bottom line זה היה איזה לקוח אחד עם איזה edge case, אתה יודע, טרלהללה. אמרתי להם השקעתם בזה כבר 3 שבועות של מתכנת ומדובר ב-SaaS לא מדברים על זה שמקבלים 3 מיליון דולר על כל לקוח, זה כנראה לא הולך להיות אף פעם ריווחי הלקוח הזה. פשוט תגידו די, תגידו די, אם נחזור עם עוד לקוחות, אוקיי, אולי זה הגיוני, אבל האם מה שאנחנו רודפים אחריו זה סוג של perfection סתם כי לשם להגיד שאנחנו, שה-maintenance שלנו מדהים? או שאנחנו מסתכלים על זה כעל ביזנס, נכון? כי בסופו של דבר לא הכל חייב להיות מושלם. אז כן צריך את זה, בגלל זה אמרתי למה פודים לא יכולים לעבוד בלי פוד מאוד מאוד טוב כי אנחנו צריכים, תמיד יש לו את היכולת להסתכל על הביזנס הזה. ואז כשיש לי את הצוות שהוא the A team, כן? הוא לא צריך להסתכל על מוצר מסוים אלא זה פשוט יש לנו את הצוות הכי טוב שלנו שפנוי לדברים בעולם הזה. יש לנו ה-B team שמסתכלים על הדבר הזה, לא AB ברמת כמה טובים אלא פשוט שמות גנריים, כן? אז ברגע שיש לנו את הצוותים האלה הם מסוגלים להסתכל על אוקיי, אנחנו הצוות שמזיז את המחט הזאתי ברבעון הקרוב. ופה אנחנו מסתכלים אומרים אוקיי, הגיוני לנו במסגרת כל המכלול הגדול הזה לבקש גם שנכניס את ה feature request הזה והזה או את ה-experiment הזה במוצר ההוא וזה מסתדר. וזה לדעתי משהו הגיוני, כי אז גם אין אף אחד שהוא כזה מרגיש שהוא המוקצה שיושב בצד ורק עושה maintenance בזמן שחברים שלו עובדים על הדברים המגניבים. ומנגד זה גם אומר שבאמת כל מה שאנחנו עושים אנחנו לא עושים רק for the sake of keeping busy אלא כי אנחנו באמת רואים את ה-value שמגיע מזה. עכשיו קשה, זה הרבה יותר easier said than done להגיד את זה ככה אבל כן, ברור, אוקיי, בוא נעשה הכל כי זה הגיוני עסקית, אבל זה מסוג הדברים שברגע שאתה רואה שצוותים מתחילים להגיע לשם ואני רואה את האור נדלק שם, מבחינתי אני יודע אוקיי, עכשיו זה הופך ל-, כל הדבר הזה הולך להפוך למערכת של delivery. כי ברגע שאנחנו עושים את זה, זה הקסם שאני רואה שפתאום הפאונדרים עוברים מהמוד הזה של הכל טוב שם? הכל טוב שם? פתאום עוברים לכזה איזה יופי, איזה מגניב, שהם פשוט,
ישי: וגם המפתחים מרגישים את זה בעצמות.
אביב: המפתחים, זה משהו מעניין שיש, לפעמים אתה צריך לדחוף מתכנתים מה-path of least resistance כי למה אנחנו אוהבים לדבר על ריפקטורינג ועל טסטינג ועל tech debt. כי אנחנו מרגישים שפה זה מקום שיש לנו את היכולת להיות סופר מקצועיים ולהעמיק ולהביא מלא value ויש לנו את האוטוריטה. אף אחד לא יבוא ויגיד לך, אם אני אומר לא, חייבים לעשות את השינוי הזה כי אחרת ה-API הזה הולך להפסיק להיות נגיש עוד חצי שנה או הסרטיפיקט הזה הולך לפוג עוד. אף אחד לא יגיד לך לא, אוקיי, זה כמו שרופא בא ואומר לי לא, אתה חייב לעשות איקס, אני כנראה אקשיב, אבל המתכנתים לפעמים מתאהבים בזה, זה הופך להיות סוג של get out of jail card. כי אני יודע שאני תמיד יכול להגיד סטופ, פוס משחק, אני צריך לעשות את זה. ואני אומר לא, לא, צריך לעשות כמובן את כל ה-maintenance ברמה ההגיונית ואי אפשר לצבור tech debt על ימין ועל שמאל אבל מנגד היופי האמיתי הוא לגרום למתכנתים להסתכל החוצה ולהגיד בואו נדבר בשפה ביזנסית וננסה גם לחשוב לא רק, אם אתה מדמיין איזשהו סוג של ספקטרום ויש את המתכנתים שהם בצד אחד רק על הטק, לא אכפת לי מה המוצר עושה גם אם זה לא יודע, מל"טים שהורגים סבתות, כל עוד אני מתכנן ב Rust אני טוב לי. ובצד השני של הספקטרום יש לנו את המתכנתים שאומרים לא אכפת לי אם זה לתכנת אסמבלי על מיינפריימים, אכפת לי מהמוצר, אכפת לי מהאימפקט. ואנחנו צריכים לאט לאט לדחוף יותר ויותר מתכנתים לעשות את זה ואני חושב שאם אתה עושה את החיבור והמתכנתים רואים את התוצאות של מה שהם עושים וכשאנחנו מדברים איתם אנחנו מדברים לא על הנה ה-shopping list של כל הפיצ'רים שאתם עושים ברבעון הזה. אלא הנה המטרה והנה למה ותיראו מה הלקוחות אומרים ותיראו מה השוק ו-whatever, אז אתה מחבר אותם לאט לאט באופן טבעי המתכנתים באמת אז עוברים כמו שאמרת, למצב הזה שהם מרגישים שהם עושים את הדבר הנכון וזה באמת נהיה סוג של flywheel, שלאט לאט דברים פשוט נהיים יותר ויותר טובים.
ישי: אז אתה טוען שאפשר להביא, או לפחות בתיאוריה להביא את המפתחים to care about the business ולהרגיש את האימפקט שהם עושים ושזה יהיה הדרייבר ולא רק הטכנולוגיה או הפקטור המקומי.
אביב: כן, if you explain it they will come. זה לא הולך לקרות עם כולם כי תמיד יהיו את האנשים שיגידו לא, לא, אני רוצה, יש לי חבר מאוד טוב שאמר מתישהו - אני רוצה לעשות on device AI, לא אכפת לי מה, לא אכפת לי זה, אני רוצה להתעסק בזה, התאהב בעולם, אחלה, יהיו כאלה. אבל אתה, אני מבטיח לך שלא כולם בצוות שלך כאלה וגם אם יש שהם אולי נוטים אולי נוטים יותר לצד של הטכנולוגיה בספקטרום, פשוט כי שוב, שמה הם מרגישים שיש להם הכי הרבה אייג'נסי ואוטונומי ואם תיתן להם את החיבור הזה ותחבר אותם, לאט לאט יהיה מעבר טוב לצד השני וזה בריא יותר לכולם.
(מוסיקת מעבר)
ישי: לקראת סיום אני רוצה שניגע בנושא שעכשיו פתאום התפוצץ, יש איזה פולמוס גדול, מקינזי כתבו משהו מאוד, תפס, קיבל הרבה תהודה סביב היכולת למדוד מפתחים וקיבל תגובות מ ל Kent Beck ואחרים, אז ככה בקצרה מה הדעה שלך, אפשר למדוד developer productivity? צריך למדוד?
אביב: אז אני חושב שיש היגיון מאוד גדול, שוב, פנימית להסתכל על הדברים האלה. כי אולי לא ברמת האינדיבידואל, ברמת הצוות, זה משהו שלמנהלים מאוד מאוד טוב, אני גם ראיתי את זה עם לקוחות שפתאום יש לך את היכולת לשים לב, אה, יש פה בעיה עם איזה צוות. או מאז שהתחלף שם מנהל, דברים לא זזים כמו פעם. אני חושב שיש לזה המון value, אבל אני כן מאמין כמו שאמרתי מקודם. יש בעיה מאוד מאוד גדולה עם לחשוב שיש סוג של תו תקן שאני יכול לדעת שזהו, הנה המספר ואם אתם לא מגיעים לזה אז צריך להחליף את האוטו. אני חושב ששם אנחנו לא נמצאים ועוד יותר אני חושב שלנסות להציג את המספרים האלה החוצה זה משהו שהוא הרבה פעמים יותר מבלבל מעוזר. וגורם ל-, אם אתה מנסה להציג החוצה, הרבה פעמים CTOs באים אומרים לי אני צריך להציג KPI, המנכ"ל ביקש שב-board meeting הבא יהיה KPI ל-R&D והם בד"כ באים עם כל מיני דברים כמו ה DORA metrics ודומיהם. ואני אומר לא. בעצם מה שאתה עושה זה אתה אומר היי, שלום, אנחנו cost center ותסתכלו עלינו בתור משהו שצריך לאפטם כי הנה כמה טוב אנחנו עובדים וכמה מהר אנחנו cranking out features. ומסתכלים עליך בצורה שאני אומר אוקיי, למה שאני לא אקח את כל המתכנתים החמודים והיקרים האלה בתל אביב, נחליף אותם במלא חבר'ה במזרח אירופה. ואני חושב שהמשהו מאוד מאוד בריא לעשות זה לנסות להוציא החוצה מטריקות שהן יותר ביזנסיות של מה אנחנו משיגים ברמת הביזנס. שזה מטריקות שהן הרבה יותר קשות כי הן בד"כ משותפות לפרודקט, דברים שהם באמת מה הצלחנו להשיג ברמת ה-OKR, הנה ה objective העסקי שעבדנו עליו עם פרודקט ועם, לא יודע, עם סיילס ועם מרקטינג בחצי שנה האחרונה והנה מה שהשגנו.
ישי: עבדנו על פרויקטים א, ב, ג, דילברנו את כולם. אוקיי, אפשר להשיג את זה עם חצי מהכמות מפתחים ובחצי מהקוסט במזרח אירופה? כאילו על זה לא עניתי. נכון? אני רק אומר דילברנו מה שתכננו, אפילו overachieving, אבל זה לא נותן ללא, למנכ"ל, לבורד, לאנשים אחרים להסתכל ולהגיד רגע, זה בכלל התפוקה מתאימה לקוסט? זה עובד בצורה יעילה? למה ארגון המכירות אני כן מודד ומסתכל על כמה הsales cycle שלי וכמה קוסט להבין כל דולר, אנשי המכירות זה גם טאלנט, לא קרוס סנטר, למה להתייחס בצורה שונה למפתחים?
אביב: אני חושב שפה יש פה עניין של, אם אתה מסתכל על sales. Sales באמת אתה יכול לראות את הכמה כל אחד שווה, זה מתחבר ישירות כי זה גם פחות טים initiatives, נכון? בסופו של דבר אנשים שהולכים ויש להם את הריליישנשיפ שלהם עם מקום. כשאני מסתכל על צוותי פיתוח, הרבה פעמים מסתכל על מבחוץ, כן? בתוך הצוות ברור שהייתי רוצה שכל מנהלת תדע אם יש לה אנשים שהם לא שם, כן צריכים עזרה או אולי לא ב fit טוב. אבל אני מסתכל החוצה ברמת כל ארגון הרבה פעמים זה לא שאתה יודע. לפעמים ראיתי את הבנאדם שמסתכלים, לא יודע, בג'ירה סגר הכי פחות טיקטים ברבעון האחרון אז זה בעצם כי זה הבנאדם שמפרפר ועוזר לכולם, נכון? לא תמיד יש לך את הידע הזה. בגלל זה אני אומר זה משהו שהוא הרבה יותר באזור ה vague לדעתי של האם אנחנו יכולים יותר או פחות ולדעתי צריך לעשות פה, מה שבפועל אני עושה עם חברות זה הרבה יותר experimentation. אין פה אף פעם את הדרך הנכונה לדעת ואתה חייב לדעת שאתה אקטיבית הולך לעשות שינויים. כי אתה אומר אני מרגיש איפה אפשר לעשות דברים, חלקם יעבדו, חלק לא יעבדו, צריכים לבדוק מה קורה. אז אולי ברבעון הקרוב או החצי שנה הקרובה ננסה לגדול יותר לאט ונראה האם דווקא דברים משתפרים או עזבו שני אנשים, אולי ננסה רגע לא ישר נאייש את התקן הזה, ניתן איזה רגע, איזה חצי שנה, נראה מה קורה עם הצוות. ואני חושב שזה מסוג הדברים שאקטיבית אנחנו צריכים לעשות אותם ולא, שוב, לא ללכת ל default הזה של האוקיי, מישהו עוזב ישר לאייש, מישהו אמר לנו שהם הולכים לצאת לחופשה וישר לחשוב איך אנחנו מעבים את הצוות כדי להחזיק את החופשות הקרובות או whatever. להגיע למצב שלפעמים זה בסדר שדברים לא יהיו מושלמים על הנייר כי הצוות הוא אורגניזם חי ולפעמים מתגלה שהוא יכול לעשות דברים שלפני זה התרגלנו לעשות עם האקסטרה pair of hands. ואין, שוב, אני עוד לא גיליתי את ה-silver bullet הזה.
ישי: אני מסכים שזה מאוד קשה לייצר כמו אמרת silver bullet או מדד אחד שמשקף החוצה שהכל טוב או לא טוב, מה שאני רואה מ-, בעיני הצורך של מנהלי פיתוח כן להראות החוצה מדדים וכן לדבר על מספרים ועל טרנדים ועל goals. אפילו פחות מהמספר עצמו, אתה צריך להראות כמנהל פיתוח שאתה על זה. שאכפת לך מה productivity של הצוותים, שיש לך visibility ויש לך plan. עכשיו יכול להיות שאתה עושה experimentation ואתה לא תמיד ה-plan זה הפתרון קסם אבל יש הבדל עצום בין להגיד נראה לי שזה עובד טוב, פה אני מבסוט ופה אני פחות, לבין להגיד יש לי מספרים, יש לי benchmarks, יש לי איך לשפוט ואיך לשקף החוצה את ההתקדמות שלנו ויש לי plan להתקדם, פה אני משקיע וברבעון הבא אני אראה לכם איך זה השתפר ולמה אני בחרתי את המטריקה הזאת, למה בעיני היא חשובה אז זה צריך להיות מנומק, היכולת הזאת להגיד בזה אני משקיע ואני על זה, יש לי איזושהי תכנית עבודה, עושה הבדל עצום ב trust שאתה מקבל ממנכ"ל, מבורד, משאר הפירז שלך.
אביב: מסכים, אבל ההבדל הוא בין להגיד אני מסתכל על הדברים האלה וזה מה שאני משתמש בו, לבין להגיד הנה ה-KPIs ואז אתה רבעון אחרי רבעון אתה יש את השקף הזה של R&D ואתה מראה הנה, זזנו ככה בסייקל טיים או whatever. כי אז אני חושב שזה כבר, אתה יודע, זה קצת יותר מידי, זה כמו כשאתה, שוב, האזורים שאני לא מבין בכדורגל, אני לא מבין במכוניות, אני קונה אוטו, לוקחים אותו לבדיקה, מביאים לי איזה 80 דפים כזה של הבדיקה של המכון,
ישי: תמיד תמצא משהו.
אביב: כן, לא, המנוע כאילו יש לך מלא גרפים ואוקיי, מה זה אומר לי? זה או שאני, כמו שיש לי בדיקות דם ויש משהו שהוא כזה ב-0.2 מעל התוצאות ואני אומר רגע, זה הגיוני? זה לא הגיוני? מתחיל להתאבסס על זה. שזה בערך אני לא רוצה, אני צריך לדבר עם איש מקצוע שיגיד לי האם זה הגיוני או לא הגיוני,
ישי: חד משמעית.
אביב: או שפשוט אתעלם מזה ואז מבחינתי זה רעש ואני מתחיל להתעלם מזה. either way הרבה פעמים השקפים האלה לא באמת עוזרים. כן לבוא ולהגיד אנחנו משתמשים ב-XYZ ואגב, הנה השיפורים שאנחנו ראינו מבחינת תוצאות הרבעון כי, לא יודע, דברים חיכו פחות זמן או השגנו איקס אחוז ממה שהיה לנו ב-roadmap. זה יהיה הרבה יותר בריא. אז לא חושב שלא צריך למדוד, פשוט חושב שהשימוש במדדים האלה צריך להיות הרבה יותר פעמים לכיוון הזה מה שאני משתמש בו בשביל לעבוד טוב. אל מול הנה איך שאתה צריך למדוד אותי, מישהו מעליי שלא מבין את העולם, אתה מבין? זה ה nuance פה. וגם יש פה קטע שהרבה פעמים אומרים לי לפעמים אני, לפני שכתבתי את הספר הראשון שלי - שאלתי מלא אנשים איך אתם מגדירים הצלחה, כן? CTOs, VPs of Engineering, מה זה אומר ארגון טוב ואז בד"כ מה שאומרים לי אם אנחנו עומדים ב-roadmap, ויש פה בעיה מבחינתי כי יש פה סוג של גם,
ישי: לפעמים מאוד קל לעמוד ב-roadmap.
אביב: בדיוק, למה? כי אנחנו הגענו למצב שעם הזמן הרגלנו את הארגון לעבוד בכזה לאט או פשוט תפרנו את ה-roadmap ל-roadmap שאנחנו עומדים בו - ואז זה כזה אוקיי, אז מה, זה כזה סוג של participation award. אה, יופי, עשית מה שצריך לעשות, עשית את המינימום שהגדירו. וזה לדעתי משהו שאנחנו חוטאים בו לעצמנו והרבה פעמים גם המדדים האלה בגלל שהם רלטיביים לעצמנו קשה לך לשים לב מבחינת הטרנד האם אנחנו אוקיי, זה טוב? או לא טוב? אז זה עולם מאוד מאוד קשה, יש סיבה שמשלמים לנו הרבה כסף,
ישי: אמת, יש סיבה שיש market לדבר הזה.
אביב: בדיוק, כן, אני חושב שיש טעם להמשיך תמיד להסתכל על איך אתם עושים ולמדוד הכל, אבל לשים לב שבסופו של דבר מה שתמיד צריך לעניין החוצה זה מה השגתם? לא כמה מהר אנחנו כותבים את הקוד אלא מה השגנו אם כתבתם - אם הייתי יכול לדלבר את כל מה שיש ב-road map ביום הראשון שמתחיל ה quarter, אבל היינו מבינים שזה לא קשור בכלל בעצם למה שהלקוחות רוצים וכל הקווארטר הזה היה נעול, זה לא עזר, נכון? אני רוצה לראות שאנשים באמת עושים את מה שעוזר לביזנס bottom line.
ישי: אמת. אני תמיד מבקש מהאורחים שלי לתת בסוף איזשהו טיפ אחד והפעם אני אבקש ממך לתת טיפ למישהו או שבא מהעולם הזה של טכנולוגיה שרוצה לחשוב על לכתוב ספר. טיפ אחד, איפה להתחיל, איך לחשב על זה, איך לדעת אם זה בכלל מתאים לי או לא.
אביב: אז אני חושב שקודם כל זה צריך להתחיל מזה שאתה צריך לשבת, אני אגיד את ה process שלי, כן? שזה הדבר שלי הכי קל, ישבתי, כתבתי את העשרה פרקים, פירקתי את העשרה פרקים האלה לכל אחד למשהו כמו ארבעה חמישה topics שאני מרגיש שכל אחד מהם יש לי איזה בוא נגיד בלוג פוסט בראש כדי לכתוב עליו. ואם יש לכם את זה, הקסם זה שמפה זה רק לשבת ולעבות את הדבר הזה ואולי להוסיף סיפורים ודוגמאות וכו'. אבל ברגע שיש את זה יש לכם skeleton, ומפה לי בתור מישהו שאהב בתור מתכנת תמיד לשבור דברים כדי להבין שאוקיי, אין פה איזה משהו feasible שאני מה שאני הולך לעשות, ברגע שיש לי הארט ליין הזה ויש לי בעצם את התכנית עבודה, אני יכול לרוץ קדימה וזה תמיד מה שעבד אצלי בכל הפעמיים האלה.
ישי: 50 בולט פויינטס מחולקים לאיזה עשרה פרקים.
אביב: Pretty much.
ישי: מעולה. אביב, תודה רבה, היה כיף לארח אותך וכיף לדבר.
אביב: היה גם לי.
ישי: להתראות.
אביב: צ'או.
** לינקים למשאבים שהוזכרו בפרק - כאן.**
Yishai: In this episode, I am happy to host Aviv Ben Yosef, a coach and advisor for engineering managers and a writer who wrote two important books in the field, Hello Aviv,
Aviv: Hello.
Yishai: Good you came
Aviv: Good to be here
Yishai: So as usual I will ask you about the path you have taken until today, tell us a little about where you started? How did you evolve and how did you get to where you are today?
Aviv: Ok, I started like many people at my age, it seems like there was no way to learn to be a programmer yet, we looked for things on the internet by ourselves. I learned to program at about the age of 9, something like that. And I rolled into this world of hacking at the time because it seemed the coolest to me as a kid like that, if I really want to understand how computers work I must know to the depths how things function, then the next step is always visible I must understand exactly how it works, if I know hack into it, means I really know how it works. And that's where I rolled, it was like a period of hacking into Iranian government servers because my head was like, okay, I'm a kid, I don't want to go to jail, what am I going to do? No one will ever hand me over to Iran in my lifetime, probably, so it's probably the right thing to do, and this, it's a bit like how I spent my high school years as a hobby. Unsurprisingly, it turns out that it is also something that helps you get into the intelligence corps in the end, so I served there for a few years and it was really fun and I learned a lot. Then I was at IBM for a year, I got there right after an acquisition and everyone told me no, no, it's still a start-up, you'll see, no, it wasn't a start-up, it was IBM. I ran away after about a year. I was the first employee at a start-up, which is also a crazy schooling process and shortly, I’ll have been independent for 11 years. At first I was this kind of freelancer, I worked with another good friend and we ran with a lot of startups here in Israel and helped them get things up very, very quickly and slowly but surely,
Yishai: Did you write code for hire?
Aviv: Yes, and a lot of companies that were acquired / did IPOs / all kinds of good things like that, and since then over the years it has evolved a bit more in the directions of, I simply wanted more impact, as much as I love programming and it's something that has fascinated me since I was a little kid. I felt that there was a limit to how much impact I could give to the company by typing on the keyboard, and slowly I started to help in other ways, it was like this once I was a type of, today it is called Fractional CTO or Fractional Chief Architect and all kinds of things like that. I did it for a few years and something like–it's been 3, 4 years that I've been mainly accompanying & consulting to companies because I felt that I didn't want to be this band-aid from the outside that we don't have a CTO, we don't have a VP Engineering, we want someone to help us for a certain period of time, but I said no, I want to work with companies that have these people and just help them get better. And that's pretty much what I've been doing a little bit since before COVID.
Yishai: So it's kind of what? Mentoring and accompanying executives in the field and leaders of engineering organizations?
Aviv: Yes, it's more or less if I work with the CTO or VPs of Engineering it's really one on one work, because I think each of us can always learn a lot. I also have a coach myself for years, and I feel how it always helps me develop and evolve, also the one work on the one hand, and also the organizational development of what the organization should look like and what the next step is and how we always strive to improve and not stay stuck. And sometimes I also work with CEOs or CPOs regarding how to look at the company's product engineering machine. How it should look, where we should aim, things like that.
Yishai: And here in Israel? Do you also work abroad?
Aviv: Today half of my clients are not in Israel.
Yishai: Walla?
Aviv: Yes, COVID helped a lot in this respect.
Yishai: Which, like specific geographies? Or startups everywhere?
Aviv: Startups literally everywhere. But you know, naturally I see more in Western Europe and of course the USA. I mostly enjoy working more with companies in Europe, simply in terms of the time zone because I'm lazy, and I don't like making calls at night. But beyond that, for wherever it takes me, after one of the books I published I suddenly see there, it's amazing that suddenly someone from Singapore and people from Australia and New Zealand and all kinds of places in the world turn to you and you see that you have these things in common around the world, that people have the same problems and want to hear these things, so wherever it's needed I'm there.
Yishai: Is there a typical company size or stage you usually work with?
Aviv: I'll tell the truth, I kind of invented my line of work for myself, it kind of evolved. That I just enjoy everything, as I enjoyed in the world of hacking, entering every level of the operating system and understanding it, there are companies, companies that have literally just raised money and the founders bring me on the first day they have their first two programmers because they want to work with me, and I work with companies publicly-traded and everything in between. Yes, I will say that now with the mess we see in the tech industry, so I have less chance to work with small companies because they seem to me to be the most strapped for cash and it's a shame for me because I really enjoy working with them too but what comes out and who needs help and I enjoy it, as long as it's mutual benefit, I'm there.
Yishai: How long is your engagement more or less? How long have you been involved in the life of such a company?
Aviv: The average is something between six months and a year, I would say. There are some who are this kind of start stop, start stop, I give them loads of homework / directions. And something like six months, a year later, when they have grown up, reached the next level, they want to do more sessions like this once again. But it really depends, there are the people who come, recently I worked with someone who you saw was simple, I would always say that he is the human sponge. Everything I said to him I felt that in the next conversation that's it, it's already been realized, it's not like ‘oh I didn't have time’, no, they were on top of everything and this was someone who 3 months after I brought them so many things, made so much progress. It was like go, go, like let go, you don't need the training wheels, go alone and fly with it, and on the other hand I have,
Yishai: You have to be careful not to be too successful in consulting
Aviv: (Laughs) Look, I really believe that in these things there it’s not possible to do too much good, if they can fly with it, even if it means you, we finished only after 3 months and for me I know it's just a good sign of what can be achieved - and I'm crazy about it . And I also know that in the end things always evolve and we, people want to get more feedback or things change and it's great to see this development. So he is, for example, someone for 3 months, really one of the people, I had the most fun working with them in all the years I've been independent. On the other hand, I have clients who have been working with me for two years in a row simply because they constantly see that they want the ongoing extra pair of eyes who can come and tell them whether it makes sense, whether it doesn't make sense, with someone from the outside to consult with, it really depends on the person, in the company. And again, there are companies that I tell them, I think you should stop. And there are companies that I flow with it because I see that they really get value, and it's not, they don't need it because,
Yishai: Because your therapist says you should stop.
Aviv: Exactly, it's about if you see that they can do it on their own, it's always nice to have more money in the bank, right, but if you want to create a situation where they use it because they need and get value and not because they're used to it, and you don't want to create dependence, right? It's like I don't know, I'll have a lot of fun playing with my kids for years, but someday I want them to play with other kids, or I want them to try walking down the street a little bit alone, with the big one, right? We're trying to do it, it's fine, at some point we have to do it because it's what's best for them, even if it's nice for you, so it's a bit of an observation.
Yishai: You mentioned your books, tell me a little about how you got into this field of not only tools, but also writing books in the field.
Aviv: Yes, I like to write, it's something that always comes easily to me, I have, I've been maintaining existing blogs, I don't know, since I was 16 years old. And I've always written relatively a lot, more or less when COVID started and I stopped going to Tel Aviv a few times a week, and suddenly these hours became vacant. I have relatively many hours - I said ok, I can just go and let it be thrown on Twitter or I can find something more sensible to do in that time. And I decided to try to write a book and I also decided that I want to “do this right” in airquotes. I don't want to write a mediocre self-published book, I really want to find a publisher abroad who wants to do this whole process, because I wanted to experience it and it was a process that I did for some half a year or so you write a book proposal of what you want to do, who you want to help, how you're going to market it, and luckily I found a publisher that I really enjoyed working with and I wrote the book relatively quickly, I think about 3 months.
Yishai: In which subject? What did you choose?
Aviv: It was a book, my firstThe Tech Executive Operating System It was more or less a collection of lessons, systems and a type of personal algorithms for engineering managers, whether it's first timers or people who are in the process of growing fast and they want to make sure that they continue to progress faster than how fast their team grows, and it was such a collection of lessons from all my customers. Whether it's about what your week should look like, how you should do one on one's at the level of VP of Engineering, what that’s like,
Yishai: This is what? A cookbook like this? Recipes?
Aviv: Yes, more or less, because there is such a name, let's say there is a name, I made a very, very large diagram of how we put out fires in the organization, all kinds of things like that, and it was the first book I wrote. Again, I had time and I said I think it will be an Interesting exercise for me as someone who has never done it. And to be fair, there was something very cool here for me because as someone who comes from the blessed network of 8200, most of my clients were more or less from there, and I really wanted to taste what was happening beyond, outside of this very magical bubble. Because I knew that not everyone behaves in this way of, oh, everyone knows everyone or in the hope of one more or less, and you always have the background on everyone and there is, you know where people came from and what types of culture exist. I really, really wanted to see what was happening outside and the book really, really helped me with that, also to spread the word to people who don't have money to bring people from outside. And also to simply reach more such clients in the world and since then suddenly I work with companies in the Netherlands and Greece and you simply see these completely different approaches and how the culture looks different and how, I don't know, we as Israelis don't care too much about authority. And you will speak as I was used to as a corporal to tell lieutenant colonels that they are wrong, you also see this of course in companies, and on the other hand, I don't know, you work with Italians and they have a very, very different attitude about whether it is okay to tell the boss that you disagree with what has been said in the room or not. Should I say my opinion or maybe save it for later? I see it simply in so many different ways, the Israelis are used to working with the Americans and seeing the political correctness and there are many, many types of culture that I think are very, very interesting.
Yishai: Is this a clientele you work with, who actually got to know you through the book?
Aviv: Yes.
Yishai: And following now, tell a little about the day the book came out, ok, everything is ready, it's out, what happened then?
Aviv: Like a lot of releases, it's not like I take it out and boom, yeah? the whole world is on me
Yishai: Iterations.
Aviv: It was actually something that I knew in advance that I wanted to do, something that is actually a kind of way for me to have a lot of conversations that I want to have. So when that book came out, I knew that because of it, especially then it was with COVID and a lot of people needed a lot of the things I talked about in the book. What it means to manage in a world where you are not in the room with people and all kinds of things like that, from that came lots and lots of lectures, sessions for VCs' portfolios In Israel, in the world, all kinds of things like that, and that's what I had a lot of fun with.
Yishai: It's part, like the book's promotional campaign actually?
Aviv: Yes, it's amazing like that, there is such a need in the world of, people always want to consume content and as soon as there is something new, a good way to reach all kinds of other audiences like that, meetups in Europe and things like that. And I...I really enjoyed it because I always, when I talk to clients or people I tell them, there is such a section, there are people who really like sports. My father can watch football for hours, me, “my football” in airquotes is working with friends and simply hearing their stories. I really enjoy hearing the battle stories and what you've been through and things like that, kind of like how it fits like a glove, probably the role I invented for myself and my character. And for me, every conversation like that was just fun to sit in. I always come with, let's say a few weeks ago I gave a lecture here for some portfolio and start-ups that are really, really early stage and I arrived. Of course, I always have these three slides in case there really are guys there who just want to sit and listen. But for me, a good event is if within fifteen minutes we reach a situation where there are many questions and there are discussions, and this is not I'm just saying, because it's fine, yes? I understand things, but every company is a world and everyone has their own angle and it's just that I enjoy these things in a sometimes a little excessive way, yes? Like I said with this man, the sponge that I enjoyed working with so much, sometimes I say I have to pay for it, so this is a bit of what came out six months after the first book, full of such conversations.
Yishai: And are these events that you pushed and went and found opportunities? Or the publisher? How was the–
Aviv: It was like this and both, the publisher also takes care of things a little, even though nowadays this whole publishing business is a business that is going to die soon. At least the technical world, because people understand that self-publishing is much easier if you have the skills. But even this, I initially pushed and from there it became a kind of snowballing, because as soon as you are there, then people hear you in one podcast, hear you in another one and lectures and things like that and it was a very, very, very fun period from that point of view, and the second book was, when did I start to fool him? About a year and a half ago, I just noticed that I was once again repeating a lot of things but they were not organized in my head. If there was something I realized when I wrote the first book, it's that just the work of sitting down for a moment and trying to organize in my head what I usually say and what seems logical to me, and this need to explain why something makes sense and how long it makes sense and in which cases it doesn't, really helped me in my work My. I said okay, it seems to me that I want to already do this for the slightly less technical types of people or slightly larger companies that I work with, because I found myself repeatedly telling CEOs how they can know if they should suspect that something might be wrong, or Understand that no. This is what the world of development looks like, yes? It's not, it's not an exact science, things can change, so I felt that I had this need and sat down to more or less do the same process.
Yishai: the same publisher?
Aviv: Another, bigger publisher, because I wanted, again. I always like to try different things, like the fact that it's rare that I'll go to the same restaurant twice, so I said no, we'll find another publisher and see what happens, I actually found one that was a little bigger and it was also a very interesting process and this book came out in June of this year,
Yishai: Walla? really fresh
Aviv: Yes.
Yishai: Remind us what his name is?
Aviv: Capitalizing Your Technology, which is actually a book intended more for company managers slash funders who want to understand what this animal looks like on which we spend half of our budget, if you are a startup.
Yishai: So if the first book addressed the development managers, now the book addresses those who work with them.
Aviv: Exactly, and of course it also has a lot of lessons about how I am as a CTO or as a VP in a company, what will actually help me to be a real executive. I work with a lot of people here, especially in Israel, who may get the titles easily but don't really do the job, yes? Acting in practice like some kind of NCOs and all, I don't think I've ever heard a conversation with a CEO who didn't come after 10 minutes to something like I just want my people to tell me what they need, to tell me what to do, every CEO is good , every good manager wants his people under him to simply come and take the initiative and do things. And somehow I see it a lot with programmers, I also see it relatively a lot with engineering managers, first line managers, but there are people who, when they make the leap, if They are not pounders, they feel that I am allowed, I am not allowed, I have to ask for permission, I am waiting to be told, to be asked, and sometimes we need this switch in the brain that no, what, the same audacity you had as a senior engineer in the room, that someone suggested which An idea and you straight up say it seems to me that in this case and this we will have some kind of race condition or something like that, you have to do the same in the big leagues as well. And this is something that sometimes people find it difficult and you have to push them there and that's a bit, the book is more or less for pounders who need to understand What happens to those tech executives who want to understand how they are seen and how I can help myself not from an egoistic motive, but how to really maximize myself in the company because I think it's really the ultimate win-win-win.
(transitional music)
Yishai: So this seam between the tech executive or whoever leads the development organization and those around him is very interesting to me. Also from the process of the book and how it was received and what you actually hear from your customers and the community. Can you perhaps shed some light on what the most common questions are? What are the most common challenges in this seam? That a CEO or board or even VP Sales who wants to know a little more about what is happening in, what is this engineering and how to work with it? What, where are the challenges, where are the most common questions?
Aviv: Yes, look, first of all it seems to me that there is something that is also problematic for the programmers themselves and I think that you as someone who comes from LinearB also sees it, there is the matter of are we doing good? People often look at, you know, the CEO looks at the company and says does it make sense? It doesn't make sense? I talk to co-founders and they tell me that in the last year we brought in 20 more programmers, I don't feel like we're moving much faster. Is that okay? Wrong?
Yishai: I'll tell you a secret, you probably don't move any faster (laughing).
Aviv: Yeah, exactly, so that's the kind of question I hear all the time, are things healthy, right? You as a human being, if you suspect something go to the doctor, get blood tests, have some kind of objective measure of okay, here's where we need to be. We don't have that much in our world. There are all kinds of attempts to do this but this is what I hear a lot and a lot, is my CTO good enough or not? Is my organization growing fast enough or not? Are the type of people I bring good or not? They told me this project, the big one, is our most important thing, they told me half a year, does half a year make sense? Doesn't half a year make sense? Is it really not possible faster? It's one type, let's say, all this fussing about whether what's happening here is even logical and healthy. Another thing I see is especially recently, it's around the growth of the organization, around whether this size we have makes sense or not, how much Elon Musk is not exactly the best example of management, there is something I do see is a lot of people suddenly wonder to themselves, if Twitter cut the man power to like 20 percent of what it was and voila, the site runs, right?
Yishai: Everything works.
Aviv: yes, works, yes? come on
Yishai: Kind of.
Aviv: There were bugs before, so if it still functions and they run like this at 20 percent and voila, there are even more, I as someone who uses Twitter maybe more than is healthy, I notice that they have more releases and more experiments than they have had in years, if it is that they really cut to the bare bones. So what does that mean? Am I as a founder of a start-up, maybe I'm just paying a lot of money to a lot of people who aren't really pulling their weight. So this is something that is also seen a lot, and now there are all these discussions about what is actually the runway that we want to keep for ourselves and what is the logical size for the team and how much to increase, this is also something that is said a lot and if I had to put the third thing that is probably the most prominent, it is When you look at an organization, at your development organization from the outside, the question is really how much friction should there be with the outside world? Some try to look at it as no, no, they're, you know, like these special artists, surround them with a padded wall, nobody bothers them, nobody talks to them, give them their beautiful tasks and let them work. There are those who want the most friction, no, no, I'm not going to chew everything up for you, go talk to sales, talk to the man from marketing, understand what needs to be done and the whole scale in between. And many people are trying to understand what makes sense, what is the ultimate thing, what brought us to the most correct course of action for us and also - as you said earlier, you added people, aren't you moving faster? There is also a part here that there is not one right answer, right, I strongly believe that we need to tailor the organization to everything that is happening around. Whether it's for example in a company that deals with medicine, and no matter how hard you try, the programmers are probably not going to be domain experts and it may be that even in terms of liability you don't want them to think they are domain experts. There is the right way to sew the structure there in front of a company that is a B2C company that makes products that you are working on and that your mother can use and you can probably understand them very, very well, so I think you should always try to understand what is the right direction for this friction thermostat. How much I want to get the programmers out into the world.
Yishai: In the world of, most of us live in the world of SaaS, but in general a founder who wants to know if my company is performing well, he has, goes to Google and finds in a second full of benchmarks and full of more or less magical metrics of what is the ratio between sales and the salary of the salespeople and all kinds of acronyms Those who tell him in a second if he is in a good place and in a place that investors like. Is it possible to get something similar to this also for this area of development? for engineering? At the end of the day, all these companies are technology companies, there are lots of numbers and tricks for finance and money, what happens with the development?
Aviv: Yes, so here I think we are in a problematic world, as I said we have a strange art here. Because there are things that are very, very helpful, kind of getting the heartbeat, all DORA Metrics and things like that I think, I always always tell my clients it's worth, if you don't, you don't have the feeling of where we stand in this respect, it's always worth starting Look at it because this is the type of thing that will very, very help you internally in the organization to understand what is happening and whether we are improving or not, a weaker or less weak period, but this is the type of thing when I see that they are trying to mediate them outside the organization, the CEO who wonders, wonders if it makes sense Or not, it's already okay, what? How many releases did we do this week? What does it matter? From their point of view, they don't know if we did 100 releases because the team broke the product into 80,000 microservices, so basically we do 100 releases because someone changed, you know, some string and we need to make it flutter in the world. Or because we are really moving at crazy speed, and there is such a thing here that simply when you look at it, it is also something that is very, very difficult to compare externally, these numbers in an absolute way. There is nothing too much here, I can tell you ok, if your cycle time is in weeks, something here is probably problematic. But knowing whether it is good enough or whether we should now sit on it more or not, is a very, very problematic area. And here many times I find it's the kind of thing that at least what I see works best is when I work with the companies, we really try to find the bespoke measurement for yourselves, should the team take out, let's say let's look at your road map and kind of try to understand Together, what are the things that prevent us from deliberating at the pace that the business would like. Or what are the things that we feel are our strategic strengths, a lot of times talking to clients about strategy, and that's a word that gets thrown around, right? Strategy, strategy, this is strategic recruitments and this, we are doing a strategic refactoring here,
Yishai: Everything is strategic.
Aviv: Exactly, everything is strategic, but in practice we do tactics most of the day. And there's a matter here of if you look at your strategic strengths, I want to see this reflected in the structure of the R&D force, in a company that is technological, yes? If we were, I don't know, making crown plastic chairs, that's something else. Then for example when I look at an organization I say for me a good measure of a good R&D organization for example is how much innovation I see really happening. Now measuring innovation is a world in itself and it is something that is very, very difficult and I have clients who, let's say, really try to pay attention to the end of the year, let's count how many features / initiatives we have that didn't start from here, they started because someone from
Yishai: Do you want to measure the internal innovation, what engineering brings up alone?
Aviv: Yes, for example, or on the other hand, some of the products that we have now, customers that we have now, these are things that technologically we had no background in or we had no progress in say a year ago or before, choose your window, but any company that is progressing nowadays, especially it seems For me, let's say all Generative AI, it is sometimes necessary to simply reinvent things and understand that what gets you here won't get you there. Someday we have to invent things or learn things in a different way, and that's the kind of thing I want to see that we at least have a hunch about. But I think people feel here, it's not, I don't have it, it's not that I'm hiding some numbers in my pocket that only show that they owe me money, I'm saying here, these are the real indicators. I really believe that in most cases we need to reach something that is really, really adapted to society. And objective metrics are great for internal management, so I can see what's going on, or for, kind of putting baselines of obviously there's a problem here, okay? If your car doesn't accelerate to 60, there's a problem here, but is the car supposed to reach 300 km/h? I don't know, right? That's the point.
Yishai: It's on the road.
Aviv: Yes (laughs).
Yishai: So you're actually saying that maybe a little contrary to the measures that investors and funders of the organization like, like how does my start-up look like, here there is no scale that is easy to compare and that an investor can say voila, you are in the right place, in the sweet spot that I like, but you need an interpretation and sometimes you need an expert From the outside who will help me understand what is right for me, what is right for my company and what I invest in.
Aviv: True, for example I like to look at what is actually holding us back. What are the things that stop us? Is the problem at all a business one, is the problem that the product is not closed enough about what we want to do, or do I notice that, wow, the company almost always has back-logs that are ready and organized like this, cataloged, just waiting for engineering to finally do their best to get to them . Because this is something that is very, very important, many times we don't really understand it, someone, you know, we put the roadmap but where does it get stuck? Is it stuck because of this or because of that, or in general because there are a lot of quality problems and we just don't get to do the development we want to do. It's a moment of the kind of thing that you sometimes have to understand, and also here, if you look at a development organization as such a strange animal, you have to understand that there really is a scale here that is very, very different in what you want to produce, because there are the, I don't know, the scale-ups that were I see here in Tel Aviv that they just recruited people on the right and left, people with background and with less background and then it's comparing apples to oranges. In front of the examples I always like to give, it's the teams of WhatsApp and Instagram where they were acquired that had about a dozen programmers who relatively each lived on tens of millions of users in beta worlds before there was AWS, before I clicked and suddenly I have ready systems here and there. And they did it and I always say WhatsApp, they had the iOS native app and the Android app and all this framework in the cloud for so many users all over the world and they really did it with some 13 programmers. And today, on the other hand, I look at, you know, all the beautiful towers here in Tel Aviv and they have 100 programmers and they release, in comparison, things at a much slower pace. And a lot of it is because we actually choose to work in this way because if you chose to go in a way where, I don't know, no we develop things in depth and it takes time and everything has to be at a crazy quality bar, ok, great, so it's a strategic choice, excellent. But if it happens simply because no one else looks aside for a moment and says wait, why do we actually have all this complexity? Or can we do things differently? These are the places where I turn on yellow lights and say let's think about what can be done differently, is this what we want as the culture of our organization or not, this is the kind of shaking that sometimes companies need from the outside.
Yishai: You mentioned the issue of the structure of the engineering organization. How often do you get to deal with these questions of the actual organizational structure? Reporting structures and squads, teams, etc.? How common is it that this is the affected area?
Aviv: Especially if, you know, slightly older, mature satraps, that's something that's said a lot because first of all there's a bit of a trend. Squads have been around for a few years now, everyone wants to tell themselves that they are doing squads or pods, we went to cross-functional teams or empower teams or whatever you wanna call it. And I think that as someone who has helped all kinds of companies enter such work modes, there is a reason that it has become, there is a difference between a trend and a fad, right? It is something that is just because we need something to write about in fashion columns and in another two months we will forget about it and there is a simple trend because this is the direction because it is really good. 20 years ago they talked about agile because it was really different from how they developed but they saw the value and even today they will talk about agile but, although it is not the thing that is talked about all day but you see the value, it was a logical trend. I think this world of cross-functional development is really important and really helps, so that's what I see a lot of companies dealing with how we do it, say when I helped the unicorn here in Israel to decide okay, what are we going to do, we have the 150 Our programmers, the current structure doesn't make sense, what should we do in terms of maximizing it and allowing the business to continue growing without feeling like we're always like this here becoming heavy. It gets heavy there and you feel like you are constantly juggling within the company to hold things. Let's say something I see a lot and deal with, but also here. I just spoke with a startup here in Israel that I explained to them that there is a real problem with thinking that this is the silver bullet, me, here is the guide for how to make squads. We just do it and that's it and fly, because good squads for example will never work, even with the best programmers in the world, without great product people, this is something I always say, if the product isn't there, don't try it because it's usually a shot For yourself, for example, or it could be that you are a company where there really is real deep tech and the logical structure is not necessarily for everyone to look only at,
Yishai: Everyone does everything.
Aviv: Yes. Because sometimes it's simple, maybe it's cool. Maybe it looks good, maybe it helps the engineering brand, but it's not the logical thing both in terms of the productivity of the people and the type of people you want to recruit, so you always have to understand that. And I think our first look should be as people who want to build a development organization, nobody pays development organizations because the CEO wants to print the code and hang it on the wall at the end of the day. Because it's not, the goal is not the code, the goal is actually what it is helps the business achieve, and if they could replace all of us with GPT4 they would have done it a long time ago. So in the meantime, as much as you want to stay, I think what is very, very important is to understand how we bring the real edge of understanding what the business needs and building the The things around it. So for example to build a development organization that is, it has exactly the logical level of friction for business and sales and marketing to understand where the extra edge is that we add. When I work with let's say companies, I sat with someone from Japan and he told me you Know, you keep telling us, Americans know I say "insolence", should feel okay about saying no, I don't agree. Or you don't have to say it's a mistake but you can say maybe, right? You'll find a way.
Yishai: "Yes but"...
Aviv: Yes, and her name is no, no, what, it's not, even in startups sometimes there is the attitude of no, I'm not supposed to tell those above me that it's not true. And that's the kind of thing we can't, actually what's happening is we make ourselves a very clear cap of how good the entire impact of our organization can be because we're basically limited to the weakest link we have in the chain of command. And if we create a culture where people can push, can say things, you can suddenly allow a completely different world to open up and also Fair, to bring in professionals who are much better because in an environment where I feel suffocated I probably wouldn't want to be if I really am an A player . And this is the kind of thing I want to see more of especially in Israel because I feel that in Israel we have somewhat forgotten what it means to give programmers access to the outside. Because a lot of managers I talk to talk about protecting the team and think that they are some kind of kindergarten teacher who should be there so that no one disturbs the programmers, who are the saints of the team. And on the other hand, abroad I see that it is actually the opposite, that perhaps they are disturbed too much but it is more in the mode of telling you what to do or throwing things at you and not in the mode of allowing you to speak. So how do we create an organization whose entire structure actually allows not only -R&D, for the whole business to move forward faster with a real impact, yes? Now this is the kind of thing that I have in my heart, yes? When I start talking about a company, for a moment I think to myself OK, here I think they have a problem or the culture here feels to me That they, someone is talking to me now about his show, has never received a push back. Which is honest, I feel that okay, maybe we should look into why people don't talk, why the dogs don't bark like Sherlock Holmes said. So I want to see things like that but it's really, This whole thing about seeming to feel how passionate I am about it, yeah? It's stuff I live,And there is a matter of building an engineering organization, what is the correct structure, there is no such thing here, there is the come, we will find the thing that suits you and also, like I may have bought a very tailored suit in Milan a few years ago, I know that Wala, at some point I may have gained a little weight, maybe it is the corona virus, maybe it, at some point I need to make another adjustment and there is no,
Yishai: They say that a development organization, certainly in a startup, every six months should do,
Aviv: Yes, I'm talking about the fact that in most organizations, let's say until a year and a half ago when we really grew like crazy, there was really a generation, you felt a generation up to a year in every organization. Literally it was a maximum of it was one generation and after that things really change completely. Today maybe it's a little slower, maybe more towards the 18 months but there really are generations like that, you have to see that you always face forward and you change because otherwise the organization is going to outgrow you and I don't think this is where we want to be.
(transitional music)
Yishai: We talked about organizational structure and growth and I know there is a topic that must have been hot lately of how to grow responsibly? And how not only let's hire employees, let's hire developers and whatever happens. Tell me a little about what you see, what your customers are looking for, what is being talked about in this question of how I grow but with some kind of responsibility.
Aviv: For me personally, it feels a bit like a finally moment. Because I personally for years tried to tell people no, you are growing in a way that maybe this is what you feel the VCs, maybe this is what you see happening around you in your big building butMany times we have grown in a way that does not make sense in terms of creating a real business. And I've seen how teams for years invest illogical percentages of time not in product development but in onboarding and how we optimize our interviewing processes and we constantly have to grow and until someone gets used to the position suddenly we already have to promote it, create a team here, make extracts , all kinds of refactoring for the organization. And there was a section of mine that always had niggles in mind, the examples that I gave on Instagram, WhatsApp, that you can achieve a lot with very, very small teams, and the truth is that these are also the examples that I saw, I always give examples of what I see in 8200 where as many as you know, they will talk to us They chose with tweezers the best kids, whatever, bottom line we took 18 year old kids, put them on projects and that's usually it, I was in teams that rarely worked with more than 2-3 people and we did things. We got results, there was no cloud, there was no A mess, we did things, and on the other hand I always compare it for example in the US if you go to their intelligence, whether it doesn't know, CIA, NSA, all these bodies. There is about 100 times the budget, there are only PHDs sitting there and there were still things you know, these digging Israelis with all their ways of rounding corners would do things that the Americans would look at and say how did they do it.
Yishai: The section in the section.
Aviv: Exactly, and I don't think we need to grind for hours or everything has to be super scrappy, absolutely not, but I do think there is something very, very good about constraints and growth that is more in the organic direction that makes sense than chasing crazy growth. And, I've always said that in the ideal structure it's this kind of 6-6-6-6 where we have a team of 6 people, above it there are the 6 managers who are in a group of 6 such teams and so on. And of course you can go here, there, you have a lot of seniors, teams can be bigger, etc., but this is kind of my default. And another thing that I especially talk about with founders, is about this concept of profitable R&D growth if you look at your structure for a moment and you look at how you are growing and you try to cut a moment ahead what will happen with the startup if we continue on the current trajectory,You always have to understand that you see a situation, there is going to be a situation where R&D does not have to grow linearly with the business, which is something I see in a lot of companies, more or less as we bring in more customers and the business expands, we actually have to bring in more and more working hands just to keep the lights up, because we are busy creating a kind of system that is not, it loses it The beauty of the software is that you want to reach the end and your merging is only increasing with each additional initiative because it is software.
"There is going to be a situation where R&D does not have to grow linearly with the business."
Yishai: This is provided that you do not develop a feature for each client.
Aviv: Exactly, and we see that in a lot of companies, especially in SaaS, we for example were companies that I personally as someone from the side heard something that the VP R&D mentions in passing one way or another - and I went to fight with the funders about no, no, you don't understand , every such clause that you allow your team to commit to just to close a contract, it's going to get to the point where in six months 40 percent of your R&D will be professional services and you don't realize it. Or all kinds of promises like that, for example on pram is something we sometimes have to do in SaaS, there's nothing to do, it gives crazy value, but there's on prem and there's on prem, there are those who say okay, fine, you'll do the on prem , we will not force you to do upgrades more than once a year, we will inform you about two months in advance about everything, it is suddenly up to you,
Yishai: instead of refusing.
Aviv: Exactly, put so many weights on yourself that okay, do it when you're IBM, but when you actually have all of 15-20 people working on creating it, they can't manage this matrix of 80 customers and each one is such a different animal Because combinatorially it won't work. And I see those who are trying, so you want to create a situation where you have logical R&D growth that comes from two directions, one is to make sure that the business really understands how to make software in a way that is scalable, which sometimes is difficult on its own and here I know mine has a card many times I see, I I work with a VP Engineering client. When I tell them this, they don't understand me or tell me no, no, that's what the business needs, but if I come from the outside and say I've worked with a few more companies and it's possible to do something different, they'll listen, so it's very Nice to have this card.
Yishai: Advantage of the outsider.
Aviv: Yes, that is sometimes such an unfair advantage, but it helps, so sometimes you have to help the business.
Yishai: You pay money for this input, it must be real.
Aviv: Completely. Sometimes people need to understand that to create a business that is a software business that is really going to last over time, we must understand what the business is and not simply say yes, yes to everything. And on the other hand, when you look at R&D you really need to, sometimes I feel like someone is talking to me oh, I want to recruit someone for such a position or I'm thinking of producing such a standard. Why? Because they think it's cool, I say okay, what will be your standard for whether it will be successful, how will you know that this position was really worth it, is it worth the X amount of money that we are going to give to whoever will staff this function? And many times we don't think about it, did this team you have here really need it? Think about all the value he brought to the company in the last year, did it make sense or maybe it would have been better for us to break up the team and condense all the teams around basically. Or think about another product, and this kind of what it means to build profitable R&D, it's a development organization that basically understands that our growth must be one that supports the business and knowing if we're trying to produce graphs, it's not that my head count in R&D is going the way it is again, linear with the growth of the organization. But we see that in reality the R&D will disconnect at some point after some initial hump and it does not have to grow at such a rate. And if it continues to grow fast, it's because we're expanding into other types of markets or trying more products, not because we have to bring in more people just to make sure that things here don't crash around us.
Yishai: In many cases the startup is under pressure from some kind of land grab, I'm trying to grab market share, I don't care that much about profitability but I want to be there and then voila, I can increase my offering a little, go in some other direction, develop some other product next door , and almost always all the engineering is already busy,
Aviv: exactly.
Yishai: I want to do something new, I've never seen an engineering team that says bring, bring. I have capacity, here is the new feature, the new product, the new direction, I have time for it, so I need to recruit people, how do you deal with it?
Aviv: That's exactly the problem. Because it's a bit like nobody returns a budget at the end of a year, right? Neither says oh, we have some left, take it, use it. And there is a matter here of how we create an organization that understands that always, let's say always someone talks to me about let's say their roadmap now they start talking about 24. Looking at things, I say the most important thing to understand is not how we create these features which are great and beautiful. Always when I work with clients I say let's think about the entire lifecycle of this thing because ideally, after we've released it, it might have been worth a few more months of tuning and whatever, but the ideal should always be that we go through a kind of burst of a lot of attention to something to bring it to a certain state. And then from there it goes to the normal mode, unless it's really something that explodes. Then we're going to leave teams actively working on it like crazy, it's something that gets to the point where, okay, at least for a while you can put it aside for a moment and you can let the teams look at other things. And There should be the mod, as soon as you give the team a product name, from their point of view they are supposed to work on it forever, and then this beast, from the point of view of these programmers, they are always supposed to be burdened with more and more tasks because they, God forbid, they get up in the morning and their Jira is not full of things to do, and that We will become this kind of self fulfilling prophecy. They are going to continue working on it, but if you try to look at a model of what they are doing, let's say go for the OKR model, whose objective is a business objective of growing the business or entering other markets or whatever. Someday they'll say okay, we think we've squeezed this lemon as much as possible, we can now put it on the backburner or just maintain it and let's look at other things, or on the other hand bring the business to a situation where it looks at it and doesn't paint in advance these things in line is actually now the cost of keeping the lights on. This team is actually now hypocritical and is only intended for that, but to understand that we expect from everything it has, that it works in this kind of waves and there is a life cycle to the world and this is something that startups Little ones do it because they have no choice, but the problem is that it is true, as we worked in the army, the temporary is the permanent, and once you temporarily did, you even allowed yourself in emails or beets to call this team the team of Product X, it will later be super difficult to do the this disconnection and help them understand that they can do,
Yishai: Because suddenly there is no team that, if the name or designation is changed, then suddenly wait a minute, then who is the team that owns that product?
Aviv: exactly.
Yishai: On the other hand, developers like to work on new things and someone has to do the maintenance, someone has to maintain the, we built a product, we worked for half a year full of people, we reached a stage where it is a little more stable but it still needs to be maintained. These products are taxed, and that tax is not getting any smaller.
Aviv: Right.
Yishai: So how do I, I mean there are engineering decisions of architecture, of how I will build it so that the maintenance will be reasonable. But there is also a product and there are feature requests around this product, I mean it is not dead, how do I build it so that there really is some kind of future, the margin is increasing?
Aviv: So here we will say that this is one of the places where all the thinking of squads / OKRs is very, very good that we look at things not in the mode of I have this team, it has X capacity and the backlog needs to be filled because that is what there is. But things that go into the program at all always come from the angle of what is the value to the business because sometimes you, I see people sitting on some bug and I say but in practice who cares? Yes? Something we'll say, people sometimes tell me what, no, we have to. And I look and it happened to me once that I just grabbed someone and said to him, tell me a minute, how many customers are affected by this? Because it was some bug that I remember being told for about three weeks that some poor programmer was trying to figure out what to do with it, in the bottom line it was some one customer with some edge case, you know, lol. I told them you've already invested 3 weeks of a programmer in this and it's SaaS, we're not talking about getting 3 million dollars for each customer, it's probably never going to be profitable for this customer. Just say enough, say enough, if we come back with more customers, okay, maybe it makes sense, but is what we're chasing a kind of perfection just to say that we, that our maintenance is amazing? Or we look at it as business, right? Because in the end not everything has to be perfect. So yes we need it, that's why I said why pods can't work without a very, very good pod because we need, he always has the ability to look at this business. And then when I have the team that is the A team, yes? He doesn't have to look at a particular product but it's just that we have our best team available for things in this world. We have the B team looking at this thing, not AB at the level of how good they are but just generic names, yes? So once we have those teams they're able to look at okay, we're the team that's moving that needle this coming quarter. And here we look and say okay, it makes sense to us within the framework of this whole big complex to also ask that we insert this and that feature request or this experiment in that product and it works out. And in my opinion, something makes sense, because then no one who is like that feels like he is the assigned one who sits on the sidelines and only does maintenance while his friends work on the cool stuff. And on the other hand it also means that really everything we do we do not just for the sake of keeping busy but because we really see the value that comes from it. Now it's difficult, it's much easier said than done to say it like that but yes, of course, okay, let's do everything because it makes business sense, but it's the kind of thing that as soon as you see teams start to get there and I see the light go on there, for me I know Okay, now it becomes, this whole thing is going to become a delivery system. Because once we do that, it's the magic that I see that suddenly the pounders go from this mode of everything is good there? Is everything good there? All of a sudden they switch to something so beautiful, so cool, that they're just,
Yishai: And the developers also feel it in their bones.
Aviv: The developers, it's an interesting thing to have, sometimes you have to push programmers from the path of least resistance because why do we like to talk about refactoring and testing and tech debt. Because we feel that language is a place where we have the ability to be super professional and go deeper and bring full value and we have the authority. No one will come and tell you, if I say no, we have to make this change because otherwise this API is going to stop being accessible in six months or this certificate is going to expire again. No one will tell you no, okay, it's like a doctor comes and tells me no, you have to do X, I'll probably listen, but the programmers sometimes fall in love with it, it becomes a kind of get out of jail card. Because I know I can always say stop, stop play, I have to do it. And I say no, no, of course you have to do all the maintenance at a reasonable level and you can't accumulate tech debt left and right, but on the other hand the real beauty is to get the programmers to look outside and say let's talk in business language and try to think not only, if you imagine some kind of a spectrum and there are the programmers who are on one side only about the tech, I don't care what the product does even if it doesn't know, drones that kill grandmothers, as long as I plan in Rust I'm fine. And on the other side of the spectrum we have the programmers who say no I care if it's assembly programming on mainframes, I care about the product, I care about the impact. And we need to slowly push more and more programmers to do it and I think if you make the connection and the programmers see the results of what they're doing and when we talk to them we're not talking about Here's the shopping list of all the features you're doing this quarter. But here's the goal and here's why and see what the customers say and see what the market is and whatever, so you connect them little by little naturally the programmers really then move, as you said, to this state they feel that they do the right thing and it really becomes a kind of flywheel, that little by little things just get better and better.
Yishai: So you claim that it is possible to bring, or at least in theory bring the developers to care about the business and feel the impact they make and that this will be the driver and not just the technology or the local factor.
Aviv: Yes, if you explain it they will come. It's not going to happen with everyone because there will always be the people who say no, no, I want, I have a very good friend who once said - I want to do on device AI, I don't care what, I don't care this, I want to deal with it, fall in love In the world, great, there will be such. But you, I assure you that not everyone on your team is like that and even if some of them may lean maybe lean more towards the technology side of the spectrum, simply because again, that's where they feel they have the most agency and autonomy and if you give them that connection and connect them, slowly Slowly there will be a good transition to the other side and it is healthier for everyone.
(transitional music)
Yishai: Towards the end, I want us to touch on a topic that has suddenly exploded, there is some big controversy, McKinsey wrote something very catchy, received a lot of resonance around the ability to measure developers and received responses from Kent Beck and others, so briefly what is your opinion, is it possible to measure developer productivity? Need to measure?
Aviv: So I think it makes a lot of sense, again, internally to look at these things. Because maybe not at the individual level, at the team level, it's something that managers are very, very good at, I've also seen it with clients that you suddenly have the ability to notice, oh, there's a problem with some team. Or since the manager changed, things don't move like they used to. I think it has a lot of value, but I do believe as I said before. There is a very, very big problem with thinking that there is some kind of standard character that I can tell it is, here is the number and if you don't reach it then the car needs to be replaced. I think that's not where we are and even more so I think that trying to present these numbers out is something that is many times more confusing than helpful. And causes, if you try to present outside, many times CTOs come and tell me I need to present a KPI, the CEO requested that at the next board meeting there be a KPI for R&D and they usually come with all kinds of things like the DORA metrics and the like. And I say no. Basically what you do is you say hi, hello, we are a cost center and look at us as something that needs to be adapted because here is how well we work and how fast we are cranking out features. And they look at you in a way that I say okay, why don't I take all these cute and expensive programmers in Tel Aviv, we'll replace them with guys in Eastern Europe. And I think that something very, very healthy to do is to try to bring out slams that are more business-like of what we achieve at the business level. Which is from slams that are much more difficult because they are usually shared with the product, things that are really what we were able to achieve at the OKR level, here is the business objective that we worked on with product and with, I don't know, with sales and with marketing for the last six months and here is what we achieved.
Yishai: We worked on projects A, B, C, we deliberated them all. Okay, can you get it with half the amount of developers and half the cost in Eastern Europe? As if I didn't answer that. Right? I'm just saying we delivered what we planned, even overachieving, but that doesn't allow the CEO, the board, other people to look and say, wait, does the output even match the cost? Does it work effectively? Why does the sales organization measure and look at how much the sales cycle Mine and how much it costs to understand every dollar, the sales people is also a talent, not a cross center, why treat the developers differently?
Aviv: I think there is a matter of, if you look at sales. Sales you can really see how much each one is worth, it connects directly because it is also less team initiatives, right? In the end people who go and have their release with a place. When I look at development teams, I often look at outsiders, yes? Within the team, it is clear that I would like every manager to know if she has people who are not there, do need help or maybe not in a good fit. But I look out at the level of any organization a lot of times it's not you know. Sometimes I've seen the man you look at, I don't know, in Jira closed the fewest tickets in the last quarter, so it's actually because he's the man who flutters around and helps everyone, right? You don't always have this knowledge. That's why I say it's something that is much more in the vague area in my opinion of whether we can do more or less and in my opinion we should do here, what I actually do with companies is much more experimentation. There is never the right way to know and you must know that you are actively going to make changes. Because you say I feel where things can be done, some will work, some won't work, we need to check what's going on. So maybe in the next quarter or the next six months we'll try to grow more slowly and see if things actually improve or if two people left, maybe we'll try an odd moment to staff this standard, we'll give it some time, some six months, we'll see what happens with the team. And I think this is the kind of thing that we should actively do and not, again, not go to this default of okay, someone leaves straight to the staff, someone told us they were going to go on vacation and straight away think about how we condense the staff to hold the upcoming vacations or whatever. To reach a situation where sometimes it's okay for things not to be perfect on paper because the team is a living organism and sometimes it turns out that it can do things that before that we got used to doing with the extra pair of hands. And, again, I haven't discovered this silver bullet yet.
Yishai: I agree that it is very difficult to produce, as you said, a silver bullet or one index that reflects outwardly whether everything is good or not good, from what I see from, in my eyes, the need for development managers to show out indicators as well as talk about numbers and trends and goals. Even less than the number itself, you need to show as a development manager that you are on it. That you care about the productivity of the teams, that you have visibility and you have a plan. Now it may be that you are experimenting and you don't always have the plan, the solution is magic, but there is a huge difference between saying I think it works well, here I am satisfied and here I am less, and saying I have numbers, I have benchmarks, I have how to judge and how to reflect outline our progress and I have a plan to move forward, here I am investing and in the next quarter I will show you how it improved and why I chose this metric, why to me it is important so it should be reasoned, this ability to say I am investing in this and I am for it, I have some kind of A work plan makes a huge difference in the trust you receive from the CEO, from Bord, from the rest of your peers.
Aviv: I agree, but the difference is between saying I look at these things and this is what I use, and saying here are the KPIs and then quarter after quarter you have this slide of R&D and you show here, we moved like this in cycle time or whatever. Because then I think it's already, you know, it's a bit too much, it's like when you, again, the areas I don't understand about football, I don't understand about cars, I buy a car, they take it for inspection, they bring me some 80 pages of the institute's inspection ,
Yishai: You will always find something.
Aviv: Yes, no, the engine is like you have a lot of graphs and ok, what does that tell me? It's either me, like I have blood tests and there is something like that 0.2 above the results and I say wait, does that make sense? It does not make sense? Starting to build on it. which I don't want, I need to talk to a professional who will tell me whether it makes sense or not,
Yishai: Unequivocal.
Aviv: Or I'll just ignore it and then for me it's noise and I start to ignore it. either way many times these slides don't really help. Yes to come and say we use XYZ and by the way, here are the improvements we saw in terms of quarterly results because, I don't know, things waited less time or we achieved X percent of what we had in the roadmap. It will be much healthier. So I don't think that you shouldn't measure, I just think that the use of these measures should be much more often in this direction what I use to work well. In front of here is how you should measure me, someone above me who doesn't understand the world, you understand? This is the nuance here. And there is also a passage here that is often said to me, sometimes I, before I wrote my first book - I asked a lot of people how you define success, yes? CTOs, VPs of Engineering, what does it mean to have a good organization, and then usually what they tell me if we are meeting the roadmap, and there is a problem here for me because there is also a kind of
Yishai: Sometimes it is very easy to stick to the roadmap.
Aviv: Exactly why? Because we got to the point where over time we got the organization used to working slowly like this or we simply sewed the roadmap to the roadmap we are following - and then it's like okay, so what, it's this kind of participation award. Ah, nice, you did what needed to be done, you did the minimum they defined. And I think it's something we sin against ourselves and many times also these indices because they are relative to ourselves, it's hard for you to pay attention in terms of the trend, are we okay, is it good? or not good? So it's a very, very difficult world, there's a reason they pay us a lot of money,
Yishai: True, there is a reason there is a market for this thing.
Aviv: Exactly, yes, I think it makes sense to always continue to look at how you are doing and measure everything, but to notice that in the end what should always matter is what you have achieved? Not how fast we write the code, but what we achieved if you wrote it - if I could devise everything that is in the road map on the first day that the quarter starts, but we would realize that it has nothing to do with what the customers want and that this whole quarter would be locked, it is not Helped, right? I want to see that people really do what helps the business bottom line.
Yishai: Truth. I always ask my guests to give one tip at the end and this time I will ask you to give a tip to someone or someone from this world of technology who wants to think about writing a book. One tip, where to start, how to calculate it, how to know if it even suits me or not.
Aviv: So I think that first of all it should start with you having to sit down, I'll tell you my process, yes? Which is my easiest thing, I sat down, wrote the ten chapters, I broke these ten chapters down into something like four or five topics for each of which I feel that each of them I have some let's say a blog post in mind to write about. And if you have it, the magic is that a map is just to sit and thicken this thing and maybe add stories and examples, etc. But as soon as you have that, you have a skeleton, and for me, as someone who as a programmer always liked to break things in order to understand that okay, there is nothing feasible here that I am what I am going to do, as soon as I have this art line and I actually have the working plan, I can run Go ahead and that's always what worked for me both of these times.
Yishai: 50 salient points are divided into some ten chapters.
Aviv: Pretty much.
Yishai: Excellent. Aviv, thank you very much, it was fun to host you and it was fun to talk.
Aviv: I had too.
Yishai: Goodbye.
Aviv: Ciao.
(transitional music)
Go to devinterrupted.com where you will find both our episodes in English and our discord server, and I would like to introduce you to Gitstream, our smart engine for continuous merge, only 2 minutes of installation and of course it is free. Go to gitsream.com I'm Yishai Beeri, we'll hear from you in the next episode.
Links to the nifty tools and resources mentioned in the episode:
