יום שבת, 26 בנובמבר 2022

451 Structuring dev orgs with Daniel Kandel

פרק מספר 451 של רברס עם פלטפורמה - אורי ורן מארחים בתאריך הפלינדרומי 22/11/22 את דניאל מחברת Island, לשיחה על איך בונים ארגוני פיתוח.



[01:07]
(רן) ולפני כן - דניאל, כמה מילים עליך ועל החברה?
  • (דניאל) אז אני דניאל קנדל - בן 45, נשוי + 2 ילדים , גר בתל אביב.
  • בשנתיים האחרונות אני VP R&D של Island - נדבר תיכף אולי קצת על מה שאנחנו עושים.
  • התחלתי - במקור-במקור, לפני 20 שנה - כמפתח Backend
    • התחנות המרכזיות שלי היו ב-Imperva - חברה גדולה היום . . . הייתי מפתח, העובד השלושים-ומשהו בארץ, לדעתי.
      • הייתי שם יותר משמונה שנים - ראיתי אותה גדלה לחברה ענקית, עושה IPO והכל
      • בסוף ניהלתי את אחת הקבוצות.
    • אחר כך הייתי VP R&D של Skycure 
      • פיתחנו מוצר שמגן על Mobile מפני התקפות מסוגים שונים, לארגונים
      • הצליח יפה, נמכרנו ל-Symantec
    • אחר כך VP R&D של Explorium, שמפתחים פלטרפורמה ל-Data Science.
    • ובשנתיים האחרונות ב-Island - מפתחים Enterprise Browser.
    • אז הבנתי שאני אוהב להיות VP R&D של חברות מתחילות - זה מה שאני עושה בשלושת התפקידים האחרונים.
  • זהו, אז ב-Island זה Enterprise Browser . . . 
(רן) מדוע העולם צריך Browser נוסף? . . . .
  • (דניאל) כן ... זו תמיד השאלה - “מה רע ב-Chrome?!” . . . .
    • אז שום דבר לא רע ב-Chrome . . . . זה אפילו דפדפן טוב
    • ואפילו  בטוח - אנחנו לא מוכרים לאף אחד ש-Chrome אינו דפדפן בטוח.
  • אבל פשוט אם תסתכל על כל האפליקציות שאתה עובד איתן ביומיום בארגון - ולמען האמת, אין הרבה כאלה חוץ מהדפדפן . . . 
    • אנחנו - המפתחים - עובדים עם IDE, עובדים עם Slack . . . . 
    • ועל כל האפליקציות האלה השקיעו . . . הושקע בהן הרבה זמן כדי שהן יתאימו לאנשים בארגון.
  • ועל ה-Browser  -האפליקציה שאנחנו עובדים איתה, שהרבה אנשים עובדים איתה במשך רוב היום שלהם - היא אפליקציה ל-Consumers . . . 
    • ואני - הצרכים שלי שונים מאלו של הילדים שלי, שמשתמשים ב-Browser
      • בוא נגיד שכדאי לראות YouTube, אבל בשאיפה גם דברים אחרים.
    • והם צרכים יותר מתקדמים.
    • והצרכים של הארגון הם יותר מזה - הם גם כן צרכים משמעותיים אחרים
      • אם זה בעולמות של Security, של Control . . . דברים כאלה.
(אורי) ובמקביל - ה-Browser היום הוא סביבת העבודה: המון מהשירותים שאנחנו משתמשים בהם עברו ל-SaaS . . . .
  • (דניאל) . . .  בדיוק . . . 
(אורי) . . . אז עובדים בהם מעל Browser?
  • (דניאל) בדיוק
  • אם כשאני התחלתי את החיים המקצועיים שלי, אז באת והתקנת על המחשב הרבה כאלה Thick Client Apps” - אז היום זה לא קיים
    • כל דבר שאנחנו עושים הם דרך ה-Browser.

[03:58]
(אורי) אני חושב שאנחנו גם רגילים להסתכל על סביבת העבודה שלנו, כמפתחים. אבל ארגוני פיתוח - ותיכף נדבר על ארגוני פיתוח וכו’ - ארגון פיתוח הוא יחסית “נשלט” בצורת העבודה שלו, בעבודה בצוותים . . . . הרבה מאוד מהארגונים, וארגונים גדולים - מקומות של Support ו-Customer Success ואנשי מכירות - מסתובבים בעולם לפעמים עם המחשב שלהם, ויש לך מעט מאוד שליטה על מה שהם עושים עם המחשב שלהם.
  • (דניאל) נכון מאוד . . . . Contructor-ים, עובדים בארגון עם המחשבים הפרטיים שלהם . . . .
    • וכולם משתמשים בעיקר ב-Browser, תמיד ככה
  • עכשיו, היום, אם אתה רוצה מחשב שיש בו רק Browser או מחשב שיש בו את הכל חוץ מ-Browser? - רוב האנשים שתשאל אותם את השאלה הזו יעדיפו שיהיה להם רק Browser . . . .
(רן) . . . יקחו Chromebook, כן . . . 
(אורי) . . . “חיים ב-Browser” . . . .
(רן) . . . במקום לבנות מערכת הפעלה שיותר מותאמת לארגון, בואו נבנה Browser שיותר מותאם לארגון - זה יותר קל, ולשם נכניס את ה-Controls  . . . 
(אורי) . . . בינינו - זה באמת ככה - Browser היום הוא באמת מערכת הפעלה.
(רן) בסדר - אז זה מה שעושים ב-Island . . . עכשיו הבנתי למה צריך  . . .

[05:24]
(רן) אז איך בונים ארגון פיתוח? אולי נתחיל מההתחלה - אמרת שאתה אוהב להיות מנהל של ארגונים שקמים, אז איך בוחרים את האנשים הראשונים? אתה בוחר את המפתחים הכי טובים? את המנהלים הכי טובים?לא זה ולא זה? מהי האסטרטגיה שלך?
  • (דניאל) אז זה מצחיק, כי באמת אחרי כמה פעמים לפעמים אנשים שואלים אותי “בטח יש איזושהי נוסחא!” . . . 
    • “אתה בא ועושה 1-2-3 - והנה, יש לך ארגון פיתוח שעובד כמו שצריך ועובד טוב” . . . .
  • אני פחות מאמין בנוסחאות ואני חושב שכל אחת מהחברות שהייתי בהן בסוף הוקמה בצורה שונה והתנהלה בצורה קצת שונה.
    • וכדי להקים את הארגון אתה צריך לדעת לאן אתה מכוון.
  • ו-Island אולי דווקא הייתה יוצאת-דופן בתוך הדבר הזה, כי בדרך כלל כשאתה מתחיל ארגון פיתוח אז כמו שאומרים, “קח את החמישה מפתחים הכי חזקים שאתה מכיר ורוץ איתם קדימה כמה חודשים - תגיעו ל-Demo” . . . .
(אורי) . . .  אתה מתחיל הכי חזק שלך - ולאט לאט אתה מגביר” . . . ואנחנו יודעים שזה לא ככה. [אותך לקרמבו].
  • (דניאל) כן, בדיוק [גם אותך]
  • אבל יש מקומות שזה עובד להם טוב - נדבר על זה אולי אחר כך.
  • ב-Island התחלנו קצת אחרת - היה לנו ברור מראש שאנחנו רוצים ומתכוונים להקים חברה גדולה, מתכוונים לבנות מוצר שיהיה איתנו הרבה זמן ושיהיה חשוב . . . 
    • מכיוון שה-Browser הוא פלטפורמה,  חשוב לנו שיהיה מאוד מאוד קל להרחיב אותו ולבנות מעליו עוד ועוד קומפוננטות (Components), שלפעמים יש חברות שלמות שמפתחות אותן
      • אם זה DLP או Zero-Trust - דברים שאנחנו בונים בתוך ה-Browser.
    • והצורך הזה - שנוכל להמשיך ולרוץ מהר גם כשאנחנו בגדלים יותר גדולים - גדלנו בשנתיים האלה מכלום למעל 60 מפתחים היום - זה מה שבעצם התווה כמעט את כל השנה הראשונה שלנו.
    • זה השליך על ההשקעה בתשתיות ועל עוד הרבה דברים - וזה גם השליך על האנשים.
  • אני חוזר לשאלה - זה השליך על האנשים שגייסנו - כי האנשים  שגייסנו היו מנהלים דווקא
    • מנהלים שניהלו בדר”כ עשרות אנשים בחברות שבהן הם עבדו לפני כן
    • והם באו - ובחצי השנה הראשונה הם - ועוד אנשים - כתבו קוד. שזה היה מוזר . . .
(אורי) אבל מראש ידעתם שאתם הולכים, נגיד בחצי השנה הראשונה, לגייס - כמה אנשים? על איזה Runway רצתם?או באיזו מהירות רצתם על ה-Runway? זה יותר . . . .
  • (דניאל) אז הייתה לנו פריבילגיה שאין להרבה חברות - שידענו שיש לנו עכשיו את ה-Runway המספיק כדאי לרוץ
    • אם זה מבחינה פיננסית, אם זה מבחינת ולידציה (Validation) מול לקוחות פוטנציאליים
    • היה לנו בטחון.
  • ובחצי השנה הראשונה הזאת היו 10-15 אנשים . . . אחר כך 20 - אבל . . .
(אורי) אבל מהרגע שקמתם, היה לכם אופק קדימה לגיוס של בערך 20 איש - זה נכון להגיד?
  • (דניאל) אני חייב להגיד שפחות התעסקנו בזה . . . .
  • התעסקנו בלהביא את האנשים שהתאימו לתפקידים שהיינו צריכים שם - ויש הרבה . . .
    • פיתוח של Browser זה דבר מורכב - יש הרבה Expertise.
    • חוץ המנהלים אתה צריך גם את האנשים הנכונים במקומות הנכונים.
  • אבל לא דהרנו ל”בעוד שלושה חודשים אנחנו צריכים להציג משהו שעובד!”
    • וזה נורא הכתיב את איך שהייתה העבודה בשנה הזאת.
(אורי) לא דהרתם לזה?
  • (דניאל) לזה לא דהרנו  . . . .
  • דהרנו וזזנו מהר כל הזמן - אבל בתשעה חודשים - שנה ראשונה זזנו מהר בתשתיות וב-CI/CD ובאוטומציה ובבנייה של הארכיטקטורה בצורה שתתאים לתזוזה מהירה אחר כך.
  • ואפשר להגיד שכאילו בשנה האחרונה, נגיד, כשכבר אנחנו מוכרים ועוברים ל-Mode שהוא יותר מפוקס על Feature-ים שלקוחות בסוף נהנים מהם, אנחנו קוצרים את הפירות של השנה הראשונה ההיא
    • שבה אולי פיתחנו אחוז אחד ממה שהמוצר יכול להיות - אבל עשינו את זה בצורה שתתאים קדימה.
(אורי) ובחברות קודמות עשית את זה בצורה שונה?
  • (דניאל) כן . . . כן.
  • והרבה חברות, אני חושב, מתנהלות בצורה אחרת - שיותר מתאימה להן.
  • כשהצטרפתי ל-Skycure היו חמישה מפתחים - וזה כבר היה אחרי יותר משנה.
    • וזה מאוד התאים למקום שהחברה הייתה אז - לגדילה בריאה של החברה כמו שהיא הייתה אז.
  • צריך להיזהר - תמיד יש את ה”מתי?” . . . . “מה אתה עושה עם המפתחים האלה?” ו”מתי ה-Demo שלך הופך למוצר?”
(אורי) קוראים לזה Product-Market-Fit . . . .
  • (דניאל) כן . . . 
  • ולפעמים מפספסים את את הנקודה הזאת - ואתה מגיע עם מוצר כשהוא בנוי כ-Demo . . . .
(רן) כן, אבל זה עדיף מהפוך - עדיף על זה שלא יהיה Fit . . .
  • (דניאל) תמיד . . .
(רן) דרך אגב - התלבטות כזאת, אני חושב,  קיימת גם בקטנה - כשרוצים להקים צוות חדש: האם תגייס ראש-צוות ואז תיתן לו לגייס עובדים, או שתתחיל לגייס עובדים ואז תחפש ראש-צוות? . . . גם פה אני מניח שזה מאוד, ככה לגופו של עניין?
  • (דניאל) נכון - הרבה תלוי בטכנולוגיה הרלוונטית, הרבה תלוי באנשים שיש לך . . . .
(אורי) ןאני חושב שזה גם מאוד מאוד תלוי ב-Runway שיש לך . . . .
  • (דניאל) נכון . . . 
(אורי) . . . כי אם יש לך מעט Runway, אתה מנסה כמה שיותר מהר להגיע לולידציות (Validations) עם הדברים הכי קטנים, הכי Quick & Dirty - וקודם כל צריך אנשים שיבנו משהו. כשיש לך Runway ארוך, אז אתה אומר “אוקיי, אני  . . . .”, Runway ארוך כמו שהיו הגיוסים בתקופה הזאת, אני לא יודע אם זוכרים, כשהיו מגייסים Round A של 100 מיליון דולר? זה, וואלה - איפה היו לנו דברים כאלה? . . . . 
(רן) אבל אני חושב שהסכנה שאני רואה בדבר כזה זה הסימפטום של חברה שמרגישה בטוחה מדי בעצמה, ומייצרת את השומן כבר מהימים הראשונים, כמו שאני מניח שיש כמה דוגמאות כאלה שאתם יכולים לחשוב עליהן. אז גם צריך להיזהר מזה, השאלה אם . . . 
  • (דניאל) ברור, ברור . . . .
  • והרצון - מה שמניע את הכל - הוא הרצון לזוז מהר.
  • יש לנו שני “מוטואים” שככה חוזרים לאורך הזמן, וזה “לזוז מהר ולהיכנס לפרטים” . . .
    • תשאל כל מפתח אצלנו על מה צריכים לעשות - אז זה זה.
  • וזה שהשקענו בשלב ההוא בתשתיות לא אומר שלא זזנו מהר - נכון, וזה התאים למקום שהיינו בוא אז
  • ומהצד השני - לפעמים כן, אתה צריך להגיע  . . . . אפילו היום, אם יש דיל של מיליון דולר שתלוי בזה שנראה משהו שאנחנו יודעים שהוא לא ”Enterprise Grade” ואנחנו יודעים שנצטרך לחזור אליו - ברור שנעשה את זה
    • ברור שניתן שם עבודה כדי להגיע לשם.

[13:24]
(רן) אז בוא נעוף ככה כמה שנות אור קדימה: אז מגיעים לאיזשהו, ככה, מוצרים - כשיש כבר יש Product-Market-Fit והחברה גדלה. ועכשיו, כמו כל חברה, נתקלים בדילמה של האם לפרק - האם להמשיך בקבוצות-מוצר? האם להתחיל לעבוד לפי התמחויות רוחביות? לצורך העניין, אולי היה לך צוות Frontend אחד וצוות Backend אחד - ועכשיו פתאום יש לך שני מוצרים . . . . האם כל אחד מהצוותים מספק שירותים לכל אחד מהמוצרים, או שאתה עכשיו שוב עושה את זה אחרת?
אז יש פה שתי שאלות - (1) זה האם יש לך איזשהו Take על הדילמה הזאת, ו-(2) זה מתי מרגישים, אם אני עכשיו מנהל ארגון כזה - אלו Signal-ים אני יכול לחפש כדי להבין שאני עכשיו לקראת החלטה כזו?
  • (דניאל) אז אני חושב שכמעט לכל דבר אני אענה לך ב”תלוי בסיטואציה” או “תלוי בחברה” . . . 
(רן) “תלוי” זו תשובה נכונה, תמיד . . .
  • (דניאל) אז תלוי  . . . לדוגמא ב-Skycure, היה לנו צוות שבו כמעט כולם עשו הכל, החל מ-Mobile דרך Frontend ו-Backend - כולם עשו הכל, וזה עבד לנו מאוד יפה.
  • וב-Island הלכנו על גישה שונה - שוב, מטעמים של ה-Domain הטכני של החברה . . . 
(אורי) סתם שאלה - בצוות שבו כולם עושים הכל, עד איזה גודל זה החזיק לכם?
  • (דניאל) זה החזיק יפה עד איזור ה-30-35 מפתחים . . . .
    • זה לא אומר שלא היו Expertise - היו אנשים שהיו להם Expertise מסויימים, שאתה יודע שאם עכשיו יש לך משהו בתחום של Network Detection אז אתה הולך לבנאדם הזה . . . .
    • אבל אחרי שקיבלת ממנו את ה-Input-ים, בדרך כלל כולם יכולים לבצע כל משימה.
  • ב-Island זה היה שונה - התחום של פיתוח דפדפן, ודפדפן מבוסס Chromium - יש בו חלקים שהם לגמרי לא טריוויאליים.
  • אז בעצם התחלנו עם שלוש קבוצות - 
    • אחת שאחראית על הפיתוח של הדפדפן עצמו
    • אחת שאחראית על “שירותי-Cloud” - זה microServices וכל מה שקשור בזה
    • ואחת שיותר פונה לאיזורים של ה-Enterprise - זה Management Console ו-Data pipeline ו-Analytics ודברים כאלה.
  • וזה עבד לנו יפה מאוד ב . . . לדעתי תשעת החודשים הראשונים . . . 
    • הפוקוס אז היה באמת עדיין על תשתיות, והצוותים עבדו מאוד מאוד יפה ביחד.
  • ואז, לאט לאט, התחלנו לראות שזה עובד פחות טוב . . . .
    • וככל שהפוקוס ניהיה יותר מוצרי ויותר על ה-Feature-ים, האינטגרציה (Integration) הפכה להיות יותר קשה בין הקבוצות האלה.
    • ה-Priorities לא היו דומים, Feature-ים חיכו לאנשים מקבוצות אחרות שהתפנו, בעצם . . . 
    • וראינו שאנחנו מתחילים לזוז פחות מהר - והחלטנו לעשות שינוי.

[16:45]
(אורי) והשינוי היה ל-Domain-ים מוצריים, או עסקיים - או דווקא ל”איזורים טכנולוגיים”?
  • (דניאל) אז השינוי אצלנו היה ל-Domain-ים עסקיים, ל-Business Domains.
  • הזכרתי קודם את זה שבעצם יש אצלנו חלקים שלמים שלפעמים חברות בנויות עליהם - 
    • אם זה Data Protection או איזורים כמו DLP או של Network כמו Zero-Trust ועוד הרבה . . . .
    • ואיזור של User Experience, שהוא בכלל בתחום אחר . . . 
  • ופירקנו למה שאנחנו קוראים לו “איילנדס” (Islands) . . . .
(אורי) מעניין למה . . . .
  • (דניאל) מקורי . . . .
  • איזושהי וריאציה (Variation) של Squad-ים, בחברות אחרות . . . .
    • אבל באמת עם הדברים שמתאימים לנו
    • שוב - כי מודל נוקשה . . . עכשיו, Squad-ים זה הולך “1-2-3 - אנחנו עושים בדיוק ככה” - הרגשנו שזה בכל מיני מקומות פחות מתאים לנו.

(רן) אז יש פה כמה שאלות שכאילו קצת נגעת בהן, אבל רציתי להעמיק - בשינוי של המבנה הארגוני הזה.
אתה אומר שאוקיי, משהו לא חרק, או שמשהו חרק ולא עבד כל כך טוב - אז באמת, זאת אומרת,  אילו Signal-ים רואים? איך מכינים את האנשים לזה? איך עושים את השינוי הזה בצורה אופטימלית?
כי, אתה יודע - יש אנשים שכשהם חושבים על שינוי ארגוני אז פתאום דברים, ככה, מתחילים לרעוד אצלם . . . .
אז איך מתקשרים דבר כזה? איך נראה היום שאחרי? האם יש “גלי-הדף” ותיקונים? איך עושים את אותם תיקונים?
בגדול - איך נראה תהליך שינוי כזה, מההתחלה ועד הסוף?
  • (דניאל) אז קודם כל, הייתי אומר שצריך להבין לאן אתה שואף . . . .
    • מה הם היעדים שלך ואיך המבנה הארגוני משרת אותם, בעצם.
  • ועשינו על זה - בפורום של המנהלים - הרבה חשיבה
    • עוד לפני שבכלל שהוצאנו מילה החוצה שמשהו כזה פוטנציאלי
  • באמת חשבנו על זה - וקראנו גם
    • אני מכיר את המודל של ה-Squad-ים של Spotify - שהם טוענים שעבד להם בהתחלה, ואז הפסיק לעבוד . . .  [ד”ש לנתי - 432 Carburetor 32: 2022 DevOps Predictions]
    • למה הוא יכול להתאים לנו ולמה הוא לא יכול להתאים לנו
    • ובסוף, הגענו למשהו שאנחנו מרגישים שהוא יחסית ייחודי - אבל מתאים לנו.
  • סתם, בתור דוגמא - הזכרתי שהפיתוח מעל Chromium הוא מאוד מורכב ומיוחד, אז למרות שהצוותים ב-Island הם ב-Business Domains מסויימים, או אחראים על Business Domains מסויים, האנשים שמפתחים מעל Chromium הם בעצם “מושאלים” ל-Island-ים האלה והם פחות חלק אינטגרלי מהם.
    • שזה, נגיד - לא משהו שקראנו באיזשהו מקום
    • אבל הרגשנו שהוא מאוד מתאים לנו - בגלל הטכנולוגיה.

[19:51]
(אורי) ו . . . . אני רוצה לשאול - לפני כמה זמן עשיתם את השינוי הזה?
  • (דניאל) לפני קצת יותר משנה . . . 
(אורי) . . . ומאז - נשארתם אותו הדבר? אתה חושב שזה עדיין מוצלח? היו תזוזות מאז?
  • (דניאל) אז דבר ראשון - גם כשעשינו אותו, עשינו את השינוי בצורה מאוד הדרגתית.
  • זה אולי קצת בגללי - אני, מעצם האופי שלי, זהיר - בעבודה, בחיים האישיים . . . הולך בזהירות.
  • אז לא ביום אחד באנו ואמרנו לכולם “תראו, זה איילנד- עובדים ככה ומעכשיו לכולם זו החלוקה”
    • “צאו לדרך!”
(רן) . . . . נועלים את המשרדים, ביום שני אף אחד לא מגיע, שולחים מכתבים מ-HR . . . .
  • (דניאל) כן . . . . אז ניסינו, והקמנו איילנד אחד לדוגמא
    • שהיה אחראי על איזורים של Data Protection - זה היה ה-Domain שלהם.
    • נתנו להם - בהבנה שלנו - את כל מה שהם צריכים: Product Manager ו-Designer ומפתחים מכל האסכולות השונות
    • כל ה-Expertise שהם צריכים.
    • ואמרנו להם “יאללה - צאו לדרך!”
  • וזה המשיך - בלי שיצרנו עוד איילנד למשך כמעט חודשיים . . . . שזה הרבה זמן
    • במונחים של Startup זה הרבה זמן - חודשיים לעבוד עם ארגון  שאתה לא בטוח שמותאם בדיוק-בדיוק למה  שאתה צריך.
    • אבל היה חשוב לנו לראות שזה עובד, ולתקן איפה שצריך.
  • שאלת האם מאז שינינו? . . . .
(רן) אבל רגע - במהלך החודשיים האלה, קודם כל היו את אלו שהיו “חלק מהניסוי”, נקרא להם “קבוצה A”, ויכול להיות שהם אמרו לעצמם “אוקיי, יכול להיות שזה רק עניין זמני, אני צריך להעביר את הזמן הזה של חודשיים, ואחר כך באמת הכל יתייצב”, ואת אלו שהיו ב”קבוצה B”, ואולי חשבו, לא יודע - “איזה שינוי בכלל הולך לקרות אצלי? לא כל כך ברור לי למה מושכים את הזמן . . . .” - האם זה לא מייצר איזושהי תקופה כזאת של חוסר ודאות, גם לקבוצה A וגם לקבוצה B מהסיפור הזה?
  • (דניאל) אז אנחנו התחלנו את “הניסוי הזה”, נקרא לו, כשניסינו לצמצם כמה שיותר את ההשפעה הפרסונלית
    • המנהלים של האנשים לא השתנו בתקופה הזו - נשארו עם אותם המנהלים
    • וזה מצחיק, כי זה התחיל, אני חושב, מאיזשהו חשש אצל האנשים שהיו ב”איילנד-לדוגמא” הזה
      • “רגע, אנחנו לא בטוחים איך מתנהלים”
      • “אני עכשיו מושאל לצוות שלא עוסק בטכנולוגיה שאליה אני רגיל - מה זה אומר?”
  • ולאט-לאט, כשראו את הדברים עובדים שם, אז איפשהו גם ה-Vibe עבר ואנשים במקומות אחרים התחילו לשאול “רגע, מתי גם לנו יהיה איילנד? למה מה השאני מתעסק בו לא מספיק חשוב כדי שכמו Data Protection - תיצרו לו איילנד משלו?”.
(רן) כן, זאת אומרת ש”יצרת גזר” מה . . . או “לימונדה מהלימון”, אם נמשיך עם האלגוריות האלה . . . .
(אורי) לא, זה  . . ..  אני יכול לגמרי להתחבר לזה שזה יוצר Excitement במקומות שעוד לא עברו . . . אבל רציתי לשאול האם חוץ מזה שעשית פה איזשהו שינוי ארגוני - שינוי בתהליכי עבודה ודברים כאלה - האם גם “במאחורה של זה” רצית לייצר תרבות אחרת? או שזה שלא חשבת במונחים של תרבות, אלה במונחים של “אוקיי, אני מאפטם (Optimize) עכשיו את צורת העבודה שלי לצרכים של החברה”?
  • (דניאל) לא רצית להחליף או לשנות את התרבות הארגונית . . . .
    • באופן כללי, האמונה שלי היא שתרבות ארגונית זה איך שאתה מתנהג - זה איך שאנחנו מתנהגים בתור מנהלים ואיך שהאנשים בצוותים מתנהלים
    • אז זה-זה.
  • ואנשים, בשלב הזה וגם היום, הם מאוד מאוד Committed - והרגשנו שאם ניתן להם את הפוקוס על ה-Business Domain, הם יהיו עוד יותר Committed.
(אורי) אז רצית שהם יהיו יותר Committed ל-Business Domain, שיהיה להם יותר Context על ה-Business Domain - שיהיה להם אכפת מה-Business Domain . . . בסוף זה שינוי תרבותי - כי מאוד קל ל-Engineer שיהיה לו אכפת מהטכנולוגיה שהוא מייצר ואכפת לו מזה שהוא מדלבר (Deliver) בזמן - ושלא יעירו אותו בלילה . . . 
  • (דניאל) נכון . . . 

[24:45]
(אורי) . . . . אז זה הכל שאלה של . . .  אני אומר את זה מה שנקרא “מדם ליבי” - כי בשנה ומשהו האחרונות אנחנו ב-Outbrain עושים גם איזשהו סוג של שינוי, שהתחלנו אותו כתהליך עבודה, אבל בשלב מסויים הבנו שאנחנו באמת, בתכל'ס, רוצים לשנות תרבות. וכשעשינו את התהליך ההדרגתי הזה, אז העברנו צוות אחד את התהליך, שינינו להם את התהליך; ואחר כך לצוות אחר שינינו את תהליך העבודה . . . 
וכשהתחלנו, באיזשהו מקום, התחלנו לקבל התנגדות - כי אנשים לא ממש הבינו למה צריך לשנות להם את תהליך העבודה, ואז הבנו שההתנגדות הזאת מגיעה מזה שאנחנו מנסים לדחוף תרבות אחת מעל תרבות אחרת, ואנחנו לא אומרים להם שאנחנו משנים תרבות. אז הבנו שאוקיי - אנחנו צריכים לעשות שינוי תרבותי, ואז לתת לשינוי התרבותי הזה לחלחל - וממנו כבר יגיעו התהליכים הנכונים  . . . התרבות תייצר לעצמה את התהליכים והכלים הנכונים.
זה עבד לנו פעמיים בעבר - כשהיינו 30 איש וכשהיינו 70 איש - לעשות את זה על 300 איש זה הרבה יותר מאתגר . . . . וזה תהליך ארוך - אנחנו בתוכו, אני לא יודע, כבר שנתיים, וממשיכים - אבל ממשיכים וזה משתנה ומתקנים וזזים, אבל אין מה לעשות . . . .
  • (דניאל) ברור שיש את האתגרים, וגם אנחנו כל הזמן מתקנים
  • ונכון שבגודל שלנו - של 60+ מפתחים - הדברים עוד יותר קלים ואתה יכול לשים אנשים ספציפיים במקומות ספציפיים ומאוד מאוד לתרום לסיכויי ההצלחה של השינויים שאתה עושה . . . 
(אורי) יש גם . . . כשעשינו את זה, בפעמים שעשינו את זה כשהיינו יותר קטנים, אז יש את הקשר האישי . . .  אתה, בתור מנהל - VP R&D - CTO - לא משנה מה - אתה יכול להגיע לאחרון העובדים בצורה די . . . [ישירה] ולהסביר את עצמך ולהיות שותף להחלטות וללמד איך מקבלים את ההחלטות - ללמד את התרבות החדשה.
ב-300 [איש] - וואו . . . . יש את המספר-קסם הזה, שנקרא  . . . סביב ה130-150 איש? [!Dunbar’s Number], שבהם “כבר לא מרכלים ביחד” . . . והדברים האלה פתאום נהיים הרבה יותר קשים - אבל  . . . . סתם, אני לא לוחץ פה בהחלטה . . . .
  • (דניאל) לא, לא . . . (א) אני לא מכחיש שבכל זאת זה יותר קל, אבל ראינו גם את ההתלהבות מהפוקוס הזה.
  • כשאתה עולה לשיחה עם לקוח - ומפתחים אצלנו עולים על המון שיחות עם לקוחות - אז הוא לא מדבר איתך על “איך עשיתם פה מערכת כל כך Scaleable-ית ו-Auto-scaling” וכאלה
      • הוא מדבר איתך על ה-Feature-ים שפיתחת
    • וזה באמת-באמת מכניס מוטיבציה - ואותי זה מרשים
(אורי) זה גם אחד הדברים שראינו - את היכולת הזאת פתאום לקבל Context, פתאום לראות איך לקוח מדבר ועל מה הוא מדבר ומה מעניין אותו  . . . .
  • (דניאל) דרך אגב - זה מוביל להרבה אתגרים באיזור השני, כי התשתיות שלך זה דברים, שגם אם עשינו עבודה נהדרת בתשעת החודשים הראשונים, אתה אף פעם לא מפסיק להשקיע בתשתיות ואתה צריך את האנשים ושימשיך להיות אכפת להם - לפחות ברמה שלאנשים אחרים אכפת מה-Business Domain שלהם.
(רן) אבל גם לתשתיות יש משתמשים - זה ממש המפתחים לידך . . . אז גם מהם אתה מקבל את הפידבק ולפעמים זה פידבק לא טוב, אבל עדיין אתה מקבל מהם פידבק מאוד מהיר.

[29:01]
(רן) מה שרציתי לשאול זה איך אתה דואג שלא לעשות Over-Do לזה, Over-Engineering? 
זאת אומרת - בכל רגע נתון אתה בטח רואה Bug-ים במבנה הארגוני ובכל רגע נתון אתה יכול לחשוב על שיפורים שאתה יכול לעשות - ומצד שני, יש אנשים שגם צריכים את ה-Peace of Mind ואת ה-Stability לאיזושהי תקופה, וכאילו - בוא, אל תאפטם (Optimize) להם כל שנייה את כל מה שאתה יכול . . .  
אז איך אתה עושה Pacing לסיפור הזה? 
  • (דניאל) שאלה טובה . . . .
  • אני באמת משתדל להסתכל על הצדדים החיוביים - זה אולי יותר פסיכולוגי מהכל, אבל אני משתדל להסתכל על הצדדים החיוביים במבנה הנוכחי
    • ולהסתכל על המקומות שהיו קשים לנו לפני כמה חודשים - ועכשיו הם יותר קלים.
  • ולפעמים אני רושם בצד את הדברים שאני רואה שעדיין הולכים פחות טוב - וזה יחכה לפעם הבאה שתיהיה הזדמנות
    • וההזדמנות זה יכול להיות כי “עכשיו גייסנו עוד עשרה אנשים ואולי אפשר לעשות איתם משהו קצת שונה” . . . אפשר לנסות את זה.
(רן) אז אני “שם את זה ב-Buffer” - ומדי פעם עושים Flush ל-Buffer הזה . . . 
  • (דניאל) משהו כזה, כן . . . 
(רן) . . . מדובר בהנדסה, לא? . . . .
(אורי) אבל זו נקודה מאוד נכונה - להסתכל גם על אילו בעיות פתרת. יש הרבה דברים כאלה ש . . .  אנחנו הלכנו לכיוון של Impact והבנו שבסוף Impact לא זורם, הוא לא מושג על ידי צוות אחד - הוא תמיד יצטרך כמה צוותים כדי ש . . . . ובעבר זה היה לוקח לנו - לעשות תיאום של פרויקט שיוצר איזשהו Impact - וואלה,Nightmare . . . ועכשיו “פתאום” יש KPI ורוצים להזיז אותו - ויש את כל מה שצריך כדי שביחד נזיז את ה-KPI הזה. דומה, נכון?
  • (דניאל) נכון . . . .
(אורי) . . .  זה מוריד הרבה Friction.
  • (דניאל) נכון - והקבועי-זמן ב-Startup הם מאוד מאוד קטנים
    • באמת, כשאני רואה איזשהו פרויקט שעכשיו נתקע שבועיים בגלל איזשהו משהו “ארגוני” נקרא לזה - Priorities, בנאדם שבדיוק חייב לסיים את מה שהוא עושה . . . 
    • באמת כואב לי - כי אלו שבועיים שהלקוח יקבל את זה מאוחר יותר . . . 
      • פוטנציאלית, זה לקוח פחות מרוצה ופוטנציאלית זה Deal שפיספסנו . . . .
(רן) וגם המפתחים יותר מתוסכלים . . . . מי שיושב ורואה שהעבודה שלו הולכת לפח, או שסתם מתעכבת בגלל דברים שלא תלויים בו . . . .
(אורי) עוד פעם - זה אלמנט מאוד תרבותי, כי לפעמים המפתח הוא לא מתוסכל, אם אתה לא מדגיש לו מה חשוב . . . . אם חשוב שהקוד שלו יגיע ושישתמשו במוצר שלו אז זה דבר אחד, ואתה יודע - דבר אחר זה “אני דילברתי (Delivered)  - שלום!” . . . .
  • (דניאל) השאלה היא אם המפתח השני, שחוזר לזה אחרי שבועיים, ופתאום מגלה שהמפתח הראשון צריך לעשות שינוי ב-API שהוא חשף לו - והמפתח הראשון כבר ב-Context לגמרי אחר וצריך לחזור לזה . . . זה תסכול בטוח.
(רן) ריצ’רץ’ .  . . כן.

[32:25]
(רן) בסדר, אז אנחנו כבר כמעט לקראת סיום - אבל יש עוד משהו שרציתי לשאול: האם היו . . .יצרתם את ה”איילנדס” - האם היו שינויים מאז? מה קורה, נגיד, אם נדרשת איזושהי התמחות באחד מאותם איילנדס?
  • (דניאל) אז אחד הדברים שלמדנו לאורך הזמן זה ש”לא כל האיילנדס הם שווים”, אפשר להגיד.
  • יש מקומות שבהם האחידות הטכנולוגית היא יחסית גבוהה, איילנדס שמתעסקים באיזורים שמצריכים Expertise יחסית אחידים
    • ואם יש שם מנהל פיתוח שמוביל אותו, אז יש לו יחסית יכולת הבנה גבוהה ויכולת להוביל את האיילנד שלו ל . .  . 
(אורי) . . .  אחידים - בטכנולוגיות שהוא מצריך? . . . 
  • (דניאל) יחסית קרובים . . . נגיד, אם הזכרתי קודם Enterprise מול Cloud, אלו איזורים שהם לא רחוקים ברמה שאתה אומר “וואלה, מנהל אחד עכשיו לא יכול להשתלט על האיזורים האלה”.
  • ולעומת זאת, יש איילנדס שהגיוון של האנשים בהם הוא מאוד גדול - ושם . . . 
(אורי)  . . .  הגיוון של של ה-Expertise של האנשים . . . .
  • (דניאל) נכון . . . .
  • נגיד, משהו ששמנו לעצמנו הוא שאנחנו לא רואים עכשיו מפתח מעל Chrome עם ++C, שמנהל מישהו שהוא בכלל בטכנולוגיות Cloud - ולהיפך.
    • השינוי שם הוא  . . . השונות היא מאוד גבוהה.
    • והרצון שלנו הוא שהמנהל יכיר את מה שהעובד שלו עושה, את מה שמפתח שלו עושה, לפרטים - וזה יותר קשה באיזורים האלה.
(אורי) אגב - הוא המנהל הישיר שלו?
  • (דניאל) באיילנדים שבהם השונות היא נמוכה - כן.
(אורי) ואיפה שהשונות היא גבוהה?
  • (דניאל) איפה שהשונות גבוהה אז באמת היינו צריכים לחשוב קצת . . . 
    • במקומות האלה, התחלנו מנקודה שבה איש ה-Product שנמצא באותו איילנד מוביל את האיילנד הזה
    • אבל הבנו מהר מאוד שהוא צריך איזשהו Counterpart שחוזר מהפיתוח - שלא כל כך עקרוני מאיזו טכנולוגיה הוא יהיה
      • אבל הוא יוכל להיות “הקול של המפתחים” ולבוא ולהגיד”רגע! פה אנחנו צריכים השקעה בתשתית הזאת ופה את ה-Feature הזה יותר נכון לפתח יותר ככה . . . .”
      • בעצם לעזור - יחד עם ה-Product, ביחד - לבנות את ה-Sprint.
    • אז לתפקיד הזה שהמצאנו אנחנו קוראים Navigator - בהמשך לקונוטציות הימיות . . . .
(רן) . . . אבל גם אותו מפתח - נניח שהוא מגיע מעולם ה-Browser-ים, אז הוא לא מכיר את עולם הענן . . . איך פתרת פה את הבעיה?
  • (דניאל) נכון, אבל הרבה יותר טבעי לו לדבר עם המפתחים של האיילנד, שהם מה-Domain של הענן, ולהבין מה הקשיים שלהם ולהבין על מה הם רוצים או חושבים שצריך להתמקד.
(אורי) אני רוצה להגיד גם עוד משהו שאנחנו ראינו: מפתחים ב-Effort שהוא מאוד הטרוגני, שיש בו הרבה Expertise,  - גם המפתחים בכזה Effort, או איילנד, איך שאתם לא קוראים לזה - גם המפתחים בכזה Effort צריכים להיות מנוסים יותר  . . . הם בעצם “השגרירים” של ראש הצוות שלהם, כי הצוות מחזיק את הטכנולוגיה. הם בעצם השגרירים של ראש הצוות ב-Effort הזה, והם צריכים להיות מאוד עצמאיים . . . הם צריכים ויכולים לייצג את הצוות, לצורך העניין, ב-Effort - וזה לא תמיד מתאים לכל מפתח.
  • (דניאל) נכון - וזה חלק מהמיקס הזה שנקרא “איילנד” . . . 
  • זה צוות עבודה - הוא מאוד עדין ומאוד חשוב.
(רן) טוב - מעניין ביותר, הנדסת המבנה הארגוני . . . מעניין איך זה גם ימשיך, יהיה מעניין להסתכל ככה ב-Retrospective ולראות מה קרה. [או לחזור למהנדסים תרבות]

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

תודה רבה דניאל! להתראות.
 האזנה נעימה ותודה רבה לעופר פורר על התמלול!