תמלול: דוד בן-בסט | Fireblocks | איך בונים צוותים מנצחים?
מנחה: אייל דוד · אורח: דוד בן-בסט · חזרה לעמוד הפרק
· עודכן:
דוד בן-בסט התחיל את דרכו כאיש QA ב-2002, עבר בדל, Quest ו-Fanbox, והיום מוביל את הנדסת הפלטפורמה בפיירבלוקס, חברה שמאבטחת נכסים דיגיטליים לאלפי לקוחות. בשיחה עם אייל דוד הוא מסביר למה בעיניו פרודקט ו-R&D הם ישות אחת, למה מפתח צריך לקחת אחריות על הקוד גם אחרי שעלה לפרודקשן, ואיך הוא בוחן מועמדים בשאלה אחת: איזה אימפקט ייצרת. דוד מפרט איך בוחרים ראש צוות (תשוקה לגדל אנשים, ותקופת ניסיון של שלושה חודשים), איך בונים צוות סניורי לפני שמגייסים ג'וניורים, איך מגדירים לכל squad אסטרטגיה מדידה במקום רשימת מכולת, ואיך one-on-one שבועי הופך לכלי האימון המרכזי. בסוף הוא מונה את הסקילז שהוא מחפש במנהל מוצר: נראות רציפה, חשיבה אסטרטגית, דרישות לא-פונקציונליות, תכנון וחשיפת הצוות לביזנס.
בפרק הזה
- המדד להצלחה של צוות הוא לא כמה פיצ'רים סומנו כבוצעו, אלא האם ה-KPI שהם אמורים להזיז אכן זז. דוד נותן דוגמה: צוות שבונה סביבת פיתוח פנימית נמדד לפי השימוש של R&D בסביבה, לא לפי רשימת הפיצ'רים.
- מעבר ממפתח (IC) לראש צוות הוא לא קידום אלא תפקיד אחר. הסיבה היחידה הנכונה לעשות אותו היא תשוקה לגדל אנשים, וכדאי להתחיל אותו כניסוי של שלושה חודשים שמותר להיכשל בו.
- בארגון בצמיחה צריך קודם צוותים סניוריים, כולל סופט סקילס, ורק כשהצוות יציב מגייסים ג'וניור אחד בכל פעם. להכפיל את הצוות בבת אחת הוא מתכון לבעיות.
- פידבק עובד רק כשהוא מחובר לעבודה של השבוע האחרון. בוחרים יחד עם העובד 'ביג רוק' אחד לשפר, ובכל one-on-one שבועי מחברים אליו מקרה אמיתי.
- מפתח אחראי על הקוד שלו גם אחרי שעלה לפרודקשן: מוניטורינג, תפקוד והשפעה על ה-KPI. סימן לארגון סקיילבילי הוא שיותר ויותר מפתחים, ולא רק המנהלים הוותיקים, מטפלים באינסידנטים.
- במקום פתרון short term ואחריו long term שלא קשור אליו, חושבים long term ומספקים ערך בצורה אינקרמנטלית, כך שכל שלב מקדם את החזון.
אייל דוד: [00:01] היי חברים, זה אייל. הגעתם לפרודקט בילדר ופה תוכלו להקשיב לשיחות המוצר הכי מעניינות. המסע שלי החל ב-2012 כשלמדתי מה זה פרודקט בסטארט-אפ שלי. מאז עבדתי בתעשייה ומ-2017 החברה שלי מייעצת למגוון חברות. הדרייב שלי הוא לעזור לכולנו להשתפר כאנשי מוצר. ולפני שמתחילים, אם אתם נהנים להאזין לפרודקט בילדר, דרגו אותנו בבקשה בחמישה כוכבים בספוטיפיי. זה ייתן לי אחלה פידבק שהפודקאסט נותן לכם ערך, וזה ישמח אותי מאוד. אז יאללה, מתחילים. היי דוד, מה העניינים? מה נשמע? איזה כיף שבאת. בשמחה. אז ממש אחרי ראש השנה מגיע לנו דוד בן-בסט מפיירבלוקס, VP פלטפורם אינג'ינרינג. בוא תספר טיפה, טיפה על עצמך, עם מי אנחנו מדברים.
מ-QA לפיתוח: ראייה הוליסטית ואחריות על הקוד בפרודקשן
דוד בן-בסט: [00:50] האמת שאני בתעשייה כבר תקופה ארוכה. התחלתי את דרכי ב-2002. התחלתי כאיש QA, ואז את משבר 2002, מי שזוכר, וכזה כל משרה בהייטק הייתה מבורכת. ובדיעבד, אני שמח שככה התחלתי, כי ההסתכלות של איש QA היא אמורה להיות הוליסטית, וכך ראיתי את המוצר ואת האקוסיסטם שבזמנו עבדתי בו. מצד אחד, מצד שני, גם כשעברתי לפיתוח, שזה היה השלב הבא, משהו כמו קצת פחות משנה אחרי, מהר מאוד הפכתי להיות אחראי על מה שקראנו לו ה-support או second level כזה, שבהמשך לראייה ההוליסטית של כל המוצר וכל מה שאנחנו עושים בעצם, גם קירב אותי מאוד ללקוחות, למה הם מרגישים, למה הם חווים, להאם הקוד או מה שאנחנו, הדליברבלס שלנו, הם קל לדבג אותם, קל למצוא את הבעיות ולתת תמיכה טובה יותר. ובאמת בשנים הראשונות, אני חושב שזה בעצם מה שעיצב אותי בהמשך, ותמיד עד היום אני דוגל מאוד מאוד בראייה הוליסטית, ככה אני גם מגדל את הדורות הבאים, וזה הופך אותך למתכנת יותר מחוספס אם תרצה, כי אתה כבר מסתכל לא רק על הקוד שאתה מדלבר, אלא איך יצרכו אותו, ואיך אתה תדע להתמודד איתו ביום שלאחרי. זה גם יוצר המון המון אקאונטביליות, אבל היום אני מאוד, שוב, זה עוד נושא שהוא קריטי להצלחה, ואונרשיפ ואקאונטביליות של פיתוח, של מפתחים, על הדליברבלס שלהם, ברגע שמשהו עולה לפרודקשן, בעצם משם מתחילה העבודה. בסדר, זה מה שלפעמים מפוספס, כתבתי משהו, זה בפרודקשן, אני יכול להמשיך לדבר הבא. אני יכול להמשיך לדבר הבא, אבל האחריות שלי על אותו דליברבל שעלה לפרודקשן רק התחילה, מבחינת מוניטורים, מבחינת האם הוא עושה את העבודה שלו, והאם, וזה אולי הדבר הבא שאותו התחלתי להבין בהמשך, האם הוא עושה את ההבדל, או האם הוא מזיז את המחט, או במילים קצת יותר מקצועיות, האם הוא מקדם את ה-KPI, את ה-Key Performance Indicator, שרצינו כארגון לקדם.
אייל דוד: [03:20] תראה מה זה, אני שנייה, אני שומע אותך ונורא כיף לי כזה. אנחנו מדברים בעצם בכובע של R&D, או Engineering, אתה נכון? ואתה בעצם מדבר איתי פרודקטית. נכון. ביזנסית. נכון. הקרבה של R&D לפרודקט,
פרודקט ו-R&D כישות אחת
דוד בן-בסט: [03:38] הייתי אומר שהיא צריכה להיות מאוד מאוד גבוהה, מאוד הדוקה, אבל אולי הניסוח היותר נכון, זה שאין באמת גבולות. אני מאמין שפרודקט ו-R&D זו בעצם ישות אחת. זוכר ששוב, בשנים הראשונות שלי בקריירה, היה כזה, בסדר, הפרודקט מגדיר מה צריך לעשות וה-R&D מבצעים. וכשזה מצליח, אז כל הכבוד לפרודקט מנג'ר, או אולי גם ל-R&D, כשזה פחות מצליח הפרודקט מנג'ר אשם, הוא לא הגדיר נכון, בסדר? זה משהו שהוא לא נכון מיסודו, כולנו בסירה אחת, כולנו צריכים לחשוב ביחד על הדברים, צריכה להיות הבנה עמוקה של הביזנס. נכון שבסוף יש מישהו שהוא יותר ריספונסיבל לדומיין שהוא אחראי עליו, חד משמעית, ויש גם התמחות שאתה מייצר עם השנים, עם הזמן, אבל הדברים צריכים להיות משותפים וכולם צריכים לזכות בהצלחה או לשאת באחריות ולהשתפר. זו גישה הרבה הרבה יותר בריאה ובסופו של דבר מובילה להצלחה. כאילו זה גם, לכולנו יש מטרה משותפת,
אייל דוד: [04:48] וגם אתה כנראה עוזב איזשהו מקום עבודה, אתה רוצה לצאת עם איזושהי הצלחה שהבאת, שעבדת עליה, זה דבר נגיד שאתה שואל עכשיו מועמדים שמגיעים אליכם,
השאלה היחידה בראיון: איזה אימפקט יצרת?
דוד בן-בסט: [04:57] מה הזזת וכאלה? האמת שאני נוטה לשאול מועמדים שמגיעים שאלה אחת בלבד, בסדר? שאני מתחיל משאלה ובעצם אנחנו מפתחים אותה בדיון. השאלה היא, בסופו של דבר במקום שעבדת בו, במקומות שעבדת בהם, שעבדתם בהם, מה האימפקט שייצרתם? זו השאלה שמעניינת, כי בסופו של דבר זה מה שמעניין את מקום העבודה. מקום העבודה הוא ביזנס, הוא רוצה לקדם את הביזנס שלו, ובשביל לקדם את הביזנס שלו הוא צריך להעסיק אנשים שיקדמו אותו. זה מה שאנחנו רואים, להזיז את המחט בארגון, לייצר אימפקט חיובי על אותם KPI'ים שהארגון מעוניין להזיז את האימפקט בהם. אני חייב לומר שלא כל המועמדים מבינים מה בדיוק אני רוצה מהם בשלב ראשון, ואז אנחנו כזה יורדים יותר לפרטים ואני מסביר יותר את המטרה ומה עומד מאחורי זה. אבל בסוף זה מה שמעניין ארגונים. מפתח או engineer אטרקטיבי הוא כזה שיודע לייצר אימפקט במקום שהוא נמצא בו, להבין מה ה-KPI'ים הנדרשים, בסדר? מה, לאן הארגון שואף. זה יכול להיות KPI של velocity, זה יכול להיות KPI של availability, זה יכול להיות KPI מוצרי כזה או אחר. ואז בעצם לממש דברים מאחורי זה שמקדמים ולמדוד אותם כמובן, מדידה זה אלמנט קריטי, להתחיל במדידה, לייצר איזשהו baseline, לדלבר איזשהו משהו ותוך כדי למדוד אותו כל הזמן ולראות שבאמת הוא משנה, הוא מזיז את המחט בכיוון חיובי עבור אותו KPI,
אייל דוד: [06:30] בסוף זה מה שמשנה לארגונים. יש למשל איזושהי תשובה שאתה ככה זוכר שהייתה ממש טובה? לצורך...
דוד בן-בסט: [06:38] אמ... אני זוכר שמפתחים נוטים לספר על ה... להתמקד ביכולות הטכניות שלהם, וכל הנושא באמת העסקי וההשפעה על הארגון, על הביזנס, הוא פשוט לא נמצא שם. אמ... ואנחנו מדברים על חבר'ה מאוד מאוד חכמים, עם המון המון ניסיון, עם המון המון יכולות טכניות, אבל בסוף בלי זה אין אימפקט, ואם אין אימפקט זה לא מקדם את הארגון, אוקיי? אז זה מה שארגונים מחפשים, וכך אני גם בונה את המפתחים שאני מוביל, או שיש לי השפעה עליהם, ב... ב... לא... אני מוביל אותם לאוריינטציה הזו. בסדר? זו האוריינטציה שאנחנו מצפים שהיא תהיה למפתחים.
אייל דוד: [07:23] אז תראה מה זה... טוב, מי שמגיע להתראיין אצל דוד, אז כבר קיבלתם טיפ. אה... אחלה טיפ. אז בעצם בוא נרוץ שנייה זריז על הקריירה, אז בעצם דיברנו על Dell, ועבדת ב-Quest, ו-Fanbox, וגם ככה בעצם יצא לנו לדבר במעלית. כן. ובעצם עכשיו אתה כמעט שנתיים כבר בפיירבלוקס. נכון.
מה עושה פיירבלוקס ואתגרי הסקייל
דוד בן-בסט: [07:44] תספר לנו טיפה על פיירבלוקס בכמה מילים. בעצם הרעיון מאחורי פיירבלוקס מחבר בין עולמות האבטחה לעולמות הבלוקצ'יין. בעצם הפאונדרים של פיירבלוקס הבינו שעולמות הבלוקצ'יין הם עולמות רגישים יותר, ובעצם הם באו עם פתרון אה... שמאפשר אה... אבטחה, Security End-to-End, אה... עבור הלקוחות. ללקוחות גדולים יותר בעצם. נכון. זה, זה נכון עבור כל הלקוחות, אבל בוודאי שזה הרבה יותר קריטי ללקוחות שהם גדולים יותר, ללקוחות Enterprise. אה... למשל, אחד הלקוחות של פיירבלוקס, Bank of New York. אה... בעצם לקוחות שמנהלים אה... אה... Digital Assets, נכסים אה... דיגיטליים, אה... בין אם אה... אחסון של נכסים דיגיטליים, העברה של נכסים דיגיטליים, וכל הנושא הזה חייב להיות מאוד מאוד מאובטח. יש לקוחות אה... שעושים את זה... עבור עצמם, יש לקוחות שא-שבעצם מנהלים את זה עבור היוזרים שלהם, אה... ויש פה עניין של אה... מן הסתם של רפיוטיישן ושל הביזנסים, הביזנס שהם מנהלים, וה... הנושא של הסקיוריטי הוא קריטי בהקשר הזה. אולי ניתן כאן איזה דוגמה קטנה, סתם, אם אני עכשיו אה...
אייל דוד: [09:02] ארגון בסדר גודל שאתה ציינת, ויש לי עכשיו, לא יודע מה, יש לי אה... יש לי, לא יודע מה, מיליארד דולר בקריפטו, אני לא יכול שמישהו אחד בארגון יחזיק את המפתח לדבר הזה, נכון, אלא אני צריך פתרון הרבה יותר טוב לזה. נכון.
דוד בן-בסט: [09:17] אז פיירבלוקס בעצם נותנת את הפתרון הזה באמצעות טכנולוגיית MPC, Multi-Party Computation, לא ניכנס לטכניקה מאחורי זה, אבל בסוף זה מאפשר לאותם ארגונים לישון בשקט בלילה, לדעת שהן בידיים בטוחות, ועובדה, היום לפיירבלוקס יש מעל 2,000 לקוחות, כולל לקוחות אנטרפרייז גדולים, כמו שציינו, ועל גבי פיירבלוקס עד כה עברו למעלה משישה טריליון דולרים, אז אני חושב שהמספרים מדברים בעד עצמם, חברה באמת מובילה בתחום. והיום אנחנו כבר מדברים על, אנחנו מכוונים לסקייל הרבה יותר משמעותי, הן מבחינת availability, במונחי ת'רופוט גם אנחנו מדברים על, יש בלוקצ'יינים היום מאוד מתקדמים, ששואפים להגיע רחוק עד למספרים של לצורך העניין של ויזה, מבחינת טרנזקציות בשנייה. אז המספרים מאוד מאתגרים, בהחלט פיזיביליים, אבל שוב, זה מצריך המון מיקוד,
אייל דוד: [10:29] ואנחנו בדרך לשם. אז בוא תספר כזה, יש גם אתגרים כנראה שמקצב צמיחה כזה גדול, אפשר לחוש אותם בעצם בתוך החברה, בתוך הארגון, ועל זה באת בעצם לדבר, איך בונים ארגון סקיילבילי או קבוצה סקיילבילית. בוא אבל שנייה לפני זה רק תספר שנייה, איך נראה היום-יום שלך? שאלה מעולה, כי באמת היום-יום משקף את הפרדיגמה שלך, כן? את האני מאמין שלך.
איך נראה היום-יום של VP Engineering
דוד בן-בסט: [10:58] אז אם ככה מציצים בקלנדר שלי, אפשר לראות שהוא מורכב קודם כל מאחד על אחד, בין אם אלה one-on-one עם ה-direct reports שלי, החבר'ה שמדווחים אליי ישירות, יש לי סקיפ לבלס שאני עושה כל הזמן, בסדר? עם עובדים ברחבי הארגון, פירים, המון המון one-on-one עם פירים ואחרים, סטייקהולדרים כאלה ואחרים. זה מרכיב מהותי בקלנדר שלי. יש כמובן את הדיסקשנס הטכניים, all over, בנושאים שונים. חשוב לי להיות מעורב בהם, לחבר את הדברים לביזנס, כמו שאמרנו מקודם, לראות שהדברים הם make sense, לתת את ה-two cents שלי במקומות שצריך. והרבה מאוד להקשיב וללמוד, בסדר? סטטוס מיטינגס, אני מאוד מאוד מאמין בזה. בכלל, בכל הנושא של היצמדות לדדליינים, זה משהו שאני מאוד דוגל בו. יש בזה, וזה מייצר המון המון אקאונטביליות. כשעובד מגיע ועובדים מגיעים ובעצם מגדירים לעצמם, בסדר? מה הציפייה שלהם בשבוע הקרוב לצורך העניין, או בספרינט, כן? בשבועיים הקרובים. הם מגדירים והם מסבירים אם הם עמדו או לא ולמה. וברוב המקרים, האיחורים, אם הם קורים, הם אובייקטיביים לחלוטין. אבל חשוב שנבין מה עומד מאחוריהם, ואז נוכל להשתפר כארגון, בסדר? versus פשוט רק להסביר איפה אני עומד ומה עשיתי, בלי שום מחויבות, בסדר? אז זה פחות יעיל. ויש גם כל מיני איבנטים שאנחנו אוהבים לעשות, זה בתדירות פחות גבוהה. חשוב לי מאוד לשמור על Team Building כאלה. למשל, לאחרונה היה לנו איזשהו אוף-סייט של כל הלידרים בקבוצה שלי. לידר משמעו מישהו שאנשים רוצים to follow, בסדר? הוא לא בהכרח People Manager. יש ארכיטקט ראשי, הוא לידר, הוא מוביל את הארכיטקטורה בארגון. ארכיטקט דאטה הוא לידר של עולמות הדאטה בארגון. וראשי צוותים, מנהלים אחרים, הם גם מובילים דומיין וגם הם גם People Managers. מופקד בידיהם ההון האנושי. אז חשוב לנו להיפגש בשביל לדסקס וככה לדבר על נושאים שהם יותר קשורים ללידרשיפ, כי זה הבסיס לכל דבר בעיניי. אני מאוד מאוד מאמין בלידרשיפ. וזה בעצם מה שעוזר לנו לייצר את האימפקט שדיברנו עליו. כן, לגמרי, אתה יודע,
אייל דוד: [13:46] אני שומע אותך וזה קצת מחזיר אותי באמת לשיחה שעשינו מקודם. אתה בעצם מאמן, זה מה שאתה עושה. וחלק גדול מהזמן, אתה מציב יעדים, נכון? אתה עוזר להציב יעדים, ובעצם, איך זה נראה? אז נכנסת לארגון שכנראה גדל מאוד מאוד מהר, עבד לא כל כך עם יעדים מוגדרים ויעדים קצרי טווח מוגדרים, כי זה מה ששמעתי אותך אומר. והתחלת להשריש את הדבר הזה, עכשיו אתה גם אומר, אני עושה המון פגישות עם Peers, עם Stakeholders, עם מי שלא יהיה, אז אתה גם מחדיר בעצם את הגישה הזאת גם לשם. איך זה נראה? כאילו, עם העובדים שלך מול בעצם החבר'ה שהם לא תחת הפיקוח שלך, איך זה נראה בעצם? קודם כל,
בחירת ראש צוות: תשוקה לגדל אנשים ותקופת ניסיון
דוד בן-בסט: [14:26] אני משתדל מאוד מאוד להשפיע across the board. אני באמת שם את טובת הארגון לפני הכל ומסתכל על הכל הוליסטית. כי רק כשהכול עובד זה מצליח, בסדר? כל נושא נישתי כזה או אחר לא באמת עוזר. מצד שני, אני מאוד מאמין ביצירת אפקטיביות בארגון דרך בניית צוותים. אתה מייצר צוות אחד שעובד נכון, ואז אתה מייצר עוד אחד כזה, או מגדל עוד אחד כזה, יותר נכון, וכולי וכולי, ואז זה מתפשט בארגון. זו הסקיילביליות. בדיוק, זו הסקיילביליות שאנחנו מדברים עליה. זה בעצם סקייל אנושי, סקייל צוותי. ויש תורה שלמה מאחורי יצירת צוות אפקטיבי. זה קודם כל מתחיל בראש הצוות, בסדר? איך בעצם בוחרים ראש צוות? הרבה פעמים יש לנו נטייה לתפוס את המתכנת הכי טוב בצוות ולהגיד לו, זכית, קודמת להיות ראש צוות. אז קודם כל אני לא מאמין במילה הזו, כי להפוך מ-IC, מ-individual contributor, למנהל, זה לא קידום, זה תפקיד אחר, בסדר? זה חשוב. כי יש קידום בכל מיני אספקטים. אני יכול כ-IC להתקדם כל החיים, וזה מצוין. בסדר? אבל זה בעצם אחריות אחרת. האחריות עוברת מהאחריות על עבודה, שכ-IC יש לי באופן ישיר, לאחריות על אנשים שהם בעצם אחראים על העבודה. חשוב להבין שאת ה-transition הזה לא הרבה מבינים, לא הרבה מסוגלים לעשות, וגם לא הרבה מעוניינים בו, בסדר? אבל אנשים לא תמיד יודעים את זה. ולכן אנחנו צריכים לחדד את זה ולהסביר את זה. אז כשמגיע עובד, תמיד מגיע לאיזשהו ראש צוות ואומר לי, מישהו מהצוות שלי, X מהצוות שלי, רוצה להיות ראש צוות. אז השאלה הראשונה זה למה? למה אתה מעוניין? למה את מעוניינת להיות ראש צוות? ולשאלה הזאת יש רק תשובה אחת. אפשר לנסח אותה בכל מיני אופנים, אבל התשובה היא, כי יש בי תשוקה, יש בי צורך לגדל אנשים. זו התשובה. בסדר? אפשר להגיד אותה שוב בהמון וריאציות, אבל זה מה שעומד מאחורי זה. תשובות כמו כי אני רוצה לייצר אימפקט יותר גדול בארגון, כי אני רוצה להשפיע יותר, כי אני רוצה לקבל החלטות. מצוין. כל התשובות האלה מצוינות, אבל אפשר להגיע אליהן גם כ-ICs, לא צריך לנהל אנשים בשביל זה. דווקא גם לא נכון לנהל אנשים. אם אין בי את התשוקה, לא נכון עבורי ועבור הארגון, שאני אהיה מנהל בארגון. וברגע שכן יש את התשוקה, שזה דבר ראשון. הדבר השני זה להתחיל את התהליך כניסוי. זה מאוד מאוד חשוב. מה, אז אתה עושה פיילוט? איך זה נראה? אתה עושה פיילוט. כמו שאתה עושה POC בנושאים טכניים, גם פה אתה מגדיר איזשהו תקופת זמן, נגיד שלושה חודשים, איזושהי אבלואציה כזאת, תקופת הערכה. שהיא הדדית. נכון. אתה כמנהל תומך בעובדת, בעובד, מגדיר להם בדיוק מה היעדים, נמצא שם עבורם. בתום השלושה חודשים אפשר להיכשל, כי זה ניסוי. בסדר? אם זה היה ניסוי טכני והוא לא היה מצליח, בסדר, אז עוברים ל-POC אחר, בודקים טכנולוגיה אחרת, גם פה. ואז זה לא מייצר את אותה תחושה של כישלון, של "התחלתי כמנהל ולא הצלחתי", וזה גם מייצר confidence ו-trust בשני הצדדים. וכשזה צולח, מעולה, אז ממשיכים הלאה ויש לנו כבר את אותו ראש צוות מיועד ומתחילים את הדרך. איך זה עובד? שנייה, אני אקח אותך. אז בעצם יש כל מיני צלחות פטרי שאפשר בעצם לעשות בהן את הניסוי הזה.
אייל דוד: [18:15] לאו דווקא שאותו ראש צוות מיועד מתאים לכל הצוותים, אז אתה בעצם מוסיף אותו עכשיו לצוות שמתאים לו, צוות שיש בו חוסר, איך זה נראה?
דוד בן-בסט: [18:25] אז זו שאלה מצוינת. בכלל, כל הנושאים האלה, יש בהם, מה שעומד מאחוריהם זה נושא באמת ההתאמה. זה נכון גם בגיוסים, מן הסתם, באותו באותו אופן. יש בוודאי תכונות קריטיות לראש צוות באופן כללי, אבל יש גם את נושא ההתאמה לצוות, ופה בעצם המשקל של המנהל של אותו צוות פוטנציאלי נכנס לתמונה, והבנייה היא ביחד עם אותו עובד. בסדר? אנחנו מכוונים את העובדים לצוות הנכון, שאנחנו ביחד מאמינים שזה יהיה, יכול להיות פה ווין ווין. זה תמיד צריך להיות ווין ווין, בסדר? ווין עבור העובדת או העובד, ווין עבור הארגון, בסדר? זו הנקודה, ונעשה את הכל בשביל לייצר את ההתאמה הזו. יש פה גם עניין של טיימינג, יכול להיות שזה כרגע לא רלוונטי, אבל זה יהיה כן רלוונטי בעוד שלושה חודשים. ברגע שבניתי טראסט עם העובד, שתכף נדבר על זה, ואני יודע מה השאיפות שלהם, בסדר? של העובדים. אנחנו בקשר הדוק, אז אנחנו נדע למצוא את הטיימינג הנכון, זה יהיה בראש מעיינינו, נדע למצוא את הטיימינג הנכון, בשביל לקחת את העובד למקום הזה, לתפקיד החדש. שוב, זה לא קידום, זה תפקיד אחר. זה קידום מבחינת, אולי אותו, בנקודות מבט של העובדים, הקריירה שלהם, זה הנקסט-סטפ שלהם, הם מאמינים בו, אז מבחינתם זה קידום מצוין. אבל הם צריכים להבין את כל התורה שמאחורי זה, הם צריכים לקבל את התמיכה, את ההכוונה, לבצע את התהליך נכון, כמו שאמרנו, ושוב, ברגע שאותו עובד הופך להיות ראש צוות, זה לא נגמר, שם זה רק מתחיל, ואנחנו ממשיכים לעבוד ביחד.
אייל דוד: [20:09] מהמם. אז שנייה לפני שנמשיך, אז אני שומע פה עוד משהו שהוא כנראה מעניין את המאזינים. בעצם מה שאתה אומר, קודם כל, אם אני רוצה, יש לי שאיפה עכשיו בעצם להיות ראש צוות, או להיות כל דבר בעצם, אז בוא קודם כל תגיד את זה לארגון, אל תחביא את זה לעצמך, כי כנראה שתהיה או את ההזדמנות, או שיהיה את הצ'מפיון הזה שישמע את זה, אני חייב לומר את זה, יש משפט שנהגתי לומר אותו כשהייתי מנהל צעיר. הייתי תמיד אומר לעובדים בסוף כל ישיבה או כל פיץ' כזה או אחר, תזכרו תמיד שהדלת שלי פתוחה. ויום אחד קראתי איזשהו מאמר שדיבר בדיוק על הנקודה הזו, ואמר, זה לא בהכרח משפט מספיק טוב, כי יש עובדים שאין להם את האומץ להיכנס בדלת. ואז אמרתי, אוקיי, אז אני כל הזמן דואג לגשת לעובדים. זה מה שתיארת מקודם, כל הזמן. נכון, כל הזמן, לבנות איתם את האמון. אז בוא אני אחזיר אותך חזרה בעצם לאיפה שהיינו, דיברנו על ראש הצוות, אולי בוא נדבר שנייה על מבנה הצוות?
מבנה צוות: סניוריות קודם, ג'וניורים במינון
דוד בן-בסט: [21:13] כן, אז גם מבנה הצוות צריך להיות מאוד מאוד תואם את אופי הארגון ואת הטיימינג שהארגון נמצא בו. אני יכול להגיד שארגון שנמצא בצמיחה, חייב level גבוה של סניוריטי בצוותים. כשאני אומר סניוריטי, יש נטייה לאנשים לחשוב על האספקטים הטכנולוגיים, זה נכון, אבל אני מדבר על כל החבילה, אני מדבר גם על הסופט סקילס. עובדים שיודעים לתקשר, עובדים שיודעים לשאול את השאלות, עובדים שהם פרואקטיביים, עובדים שיודעים לקחת דברים end-to-end ולגרום להם לקרות והם oriented ל-KPI, הם מטרתם לייצר אימפקט. ברגע שהצוותים נבנים לאורך זמן מעובדים באופי שתיארתי עכשיו, כמובן לצד ניסיון טכנולוגי ישיר, חבר'ה שעשו דבר או שניים בחייהם ויודעים לקדם את הדברים נכון, גם מקצועית וגם בכישורים הרכים יותר, החברה מגיעה לאיזושהי נקודה שעכשיו כשהצוותים כבר יציבים, ניתן לגייס עובדים צעירים יותר. חשוב גם לגייס עובדים צעירים יותר בזמן מסוים, כי מה שנקרא, אתה אומר, אני רוצה להתחיל לבנות את דור העתיד. אבל גם אז חשוב לגייס אותם במינון הנכון, בסדר? יש הרבה סטארט-אפים שאומרים, אוקיי, זה הזמן להכפיל את עצמנו. בסדר? זה דרך אגב אחד המשפטים שהיום מעידים על... חוזרים איתם, כן. כן. זו לא גישה בריאה. הגישה הבריאה אחרי שיש לך סתם שלושה חברי צוות והצוות יציב לגייס את הרביעי.
אייל דוד: [22:51] ולא לגייס עוד שלושה. ככה בונים מכונה. בדיוק. והיום אתם בעצם, אתה רומז, ואתם בעצם כן מגייסים צעירים יותר? היום עדיין לא.
דוד בן-בסט: [23:00] אנחנו עדיין ככה באשורת של עדיין לשפר את level הסניוריטי. גם משום שאנחנו נדרשים היום להגיע למספרים מאוד מאתגרים בכל מה שקשור ל-availability, throughput, latency. שזה אחד האתגרים, ציינת מקודם. נכון, ופה אתה צריך חבר'ה שעשו את זה, או עשו דברים דומים לפחות.
אייל דוד: [23:21] בסדר? אבל שוב, לצד הסופט סקילס. בלי זה זה לא שווה. אוקיי, בסדר. אז יש לי צוות שיודע לעבוד כמכונה, יש לי ראש צוות שבעצם הוביל אותו. איך זה נראה ביום-יום? יש איזה שגרות? אז זהו, אז בעצם אנחנו
אסטרטגיה מדידה לכל squad במקום רשימת מכולת
דוד בן-בסט: [23:39] בצוותים השונים, אוקיי? עובדים מול אנשי הפרודקט. השאיפה הראשונה היא לבנות אסטרטגיה לצוות. זה המפתח. יש נטייה הרבה פעמים גם לאנשי פרודקט, גם לאנשי פיתוח, להגדיר איזושהי רשימה טקטית, רשימת מכולת. לא, הן יפו את הטק. בדיוק, לא רק, אבל רשימה של דברים שהם מאמינים שצריך לעשות, ואז להסביר למה זה עוזר לארגון. אבל תכלס, האוריינטציה צריכה להיות הפוכה. לכל אזור, domain, בסדר? בוא נגיד squad, צריך שתהיה איזושהי אסטרטגיה שהיא מיושרת עם ה-KPI הארגוני. ושהוא מדיד, בסדר? אם הוא לא מדיד, לעולם לא נדע אם שיפרנו אותו, הוא חייב להיות מדיד. יש בהחלט נושאים כמו ולוסיטי שקשה יותר למדוד, צריך למצוא את הדרך, ויש נושאים שיותר קל למדוד, כמו availability, בסדר? או טלמטריה כזו או אחרת שמאפשרת לדעת אם הפיצ'ר שהוצאתי באמת מזיז את המחט בצד העסקי. דברים שהם מדידים. חייבים למדוד את זה. ואז בעצם לבנות רודמאפ או רשימה טקטית של אייטמים שנגזרים מזה. בסדר? זו הדרך. ושוב, ברגע שאתה מדליבר משהו, באמת למדוד אם הוא השפיע, אם אפשר תוך כדי הפיתוח מעולה, אם אי אפשר אז בדיעבד. לפעמים זה אפילו לוקח טיפה זמן עד שזה יתפוס בשוק, תלוי מה בדיוק עשינו. אבל עדיין חייבים לעשות את הלופ הזה של לשחרר, למדוד, להפיק לקחים ולשפר כל הזמן. אז זו בעצם השגרה, היא צריכה להיות KPI oriented, מאוד מאוד להקפיד על זה. וגם, אתה יודע, גם ממקום של לקדם משהו עד כדי הזזת המחט, בסדר? למשל, סתם דוגמה, אנחנו בונים, יש לנו איזושהי יכולת להקמת סביבת פיתוח עבור מפתחים, שהיא הוכחה כמאוד יעילה מבחינת המיינטיינביליות שלה, ואנחנו מעוניינים, כארגון, שרוב המפתחים ישתמשו בה. אז ראינו שיש סט של פיצ'רים שחסרים שם, ואם נשלים אותם, אז אנחנו מאמינים שבאמת רוב המפתחים ישתמשו בזה. המדד להצלחת הצוות שמפתח את זה, הוא לא אם על כל הפיצ'רים יש צ'ק, אלא ה-usage של R&D באותה סביבה.
אייל דוד: [26:15] בסדר? תגיד, וכמה באמת אתה, אז אני שומע בין השורות, אבל כמה אתה מעודד את חברי הצוות בעצם להיות אקטיביים ולקחת, במקרה הזה הם גם כנראה פרסונה, כן? זה מאוד קל לחבר את זה, אבל כמה אתם מעודדים על זה, לצורך העניין?
דוד בן-בסט: [26:29] אנחנו כל הזמן מדברים על זה, אנחנו כל הזמן מנחים את האנשים סביב זה. תראה, זה גם מצד אחד הסברה, בסדר? חינוך, יש הרבה חינוך פה, אבל בסוף זה גם יתחבר לפרפורמנס שלהם. יש להם כנראה רצון מאוד חזק מהצד של כל אחד שעובד באיזשהו ארגון, לגרום לארגון להיות יותר טוב. אז זהו, כשאתה מבין גם את הנקודה שדיברתי עליה מקודם, שאתה בעצם הופך להיות אטרקטיבי בתעשייה, בסדר? אני אף פעם לא מצמיד את זה לארגון שאנחנו נמצאים בו, כי זה בעצם של העובד. אנחנו מייצרים את ה-incentive אצל העובדים, אחרי שהם מבינים שזה הופך אותם לאטרקטיביים, בתעשייה, אומרים, אוקיי, אז אם אני באמת אייצר אימפקט, מחר גם ארגון אחר ירצה אותי, ועוד ארגון ועוד ארגון, אני צריך להיות אטרקטיבי. אז צריך למצוא תמיד את הקו שבין הגדילה האישית של העובד,
אייל דוד: [27:25] את האיזון הזה, להצלחה של הארגון, את ה-win-win, וזה מתקשר גם ל-personal growth. כן, דיברנו על זה שאתה מאמן, אז אוקיי, בוא, בוא, תספר לנו שנייה איך אתה עוזר בעצם, עכשיו מגיע אליך עובד,
דוד בן-בסט: [27:38] איך אתה עוזר לו בעצם לגלות איך הוא לוקח את הקריירה שלו קדימה? אז קודם כל חשוב להבין שדאגה ל-personal growth של העובד, או לטראג'קטורי שלו, זה לא פרויקט. זה לא משהו נקודתי שאתה עושה, סיימתי, זהו, סגרתי את הפינה, אני עובר לעובד הבא. לא. זו שגרה, בסדר? עכשיו, אמרנו שזה מתחיל בבניית אמון, כי העובדים צריכים להאמין שאתה כראש צוות, כמנהל שלהם, באמת רוצה בטובתם האישית. ברגע שנבנה האמון, הם איתך. הדבר הבא זה להתיישר על איזשהו אזור ששניכם, שני הצדדים, מאמינים שזה הביג רוק של אותו עובד. מה זאת אומרת? זאת אומרת שיש, לכולנו יש חוזקות וחולשות, אבל כנראה שיש איזושהי חולשה ששיפור בה ייצר את האימפקט הכי גדול, בסדר?
אייל דוד: [28:31] אנחנו צריכים לבחור אותה ביחד, ואז להתחיל לעבוד עליה. ובדרך כלל הם מגיעים, הם מגיעים אפויים לזה מספיק. לא תמיד, לא תמיד. אתם עושים איזשהו, יש איזשהו תהליך, שאתם מזהים את החוזקות, איך זה עובד? אז זה בעצם, אנחנו כבר גולשים, אבל זה בעצם מהות ה-one-on-one.
one-on-one, הביג רוק ויציאה מאזור הנוחות
דוד בן-בסט: [28:48] הוא בעצם הבסיס לבניית האמון ולגדילה האישית של העובד, ולווין ווין הזה שאנחנו מדברים עליו, שזה גם לטובת הארגון. זה הבסיס, ה-one-on-one הזה. שם אנחנו בונים את הכול, לכן ה-one-on-one הזה הוא קריטי. הוא מתחיל מבניית אמון, הוא ממשיך בהסברה והכוונה, ומהר מאוד אנחנו, מתישהו אנחנו מגיעים לאיזושהי הסכמה על אזור שאנחנו רוצים לשפר אותו. יש גם את אותם performance review שחברות נוהגות לעשות פעם בחצי שנה או שנה, מבחינתי זו רק פורמליזציה של אותם one-on-one'ים. אין בזה שום דבר מעבר, כי הכול כבר נאמר ודנו בו. עוד דבר שיפה ב-one-on-one, אחרי שאנחנו מזהים את אותה חולשה, מסכימים עליה ומתחילים לעבוד עליה, ה-one-on-one'ים השבועיים מדברים על אותה חולשה בקונטקסט שבועי. זה חייב להיות מחובר לקונטקסט. עצור, תקן כזה? עצור, תסתכל, תקן? לא, זה אומר, זה אומר, זה אומר, קח את העבודה שעשינו נגיד בשבוע או בשבועיים האחרונים, ובוא נחבר את זה לשיפור האישי שלך. זאת הנקודה, בדיוק. ולא כזה משהו out of the blue, משהו שהוא מאוד מחובר. פידבק שבא בקונטקסט הוא פידבק אמיתי, הוא פידבק אחר, הוא פידבק שבאמת מצליח לשנות. כי אז העובד מבין על מה אתה מדבר, הוא גם יודע מה לעשות עם זה, כי אתה מדבר איתו או איתה בקונטקסט, וזה ההבדל הגדול. סתם מסקרנות, איך אתה מנהל את כל האירוע הזה? יש לך גוגל דוק נפרד לכל עובד? כן. יש לנו, משתדלים להקפיד, אבל בגדול יש לנו ב-one-on-one'ים מול כל עובד, יש לי איזשהו מסמך כזה, שזה גם עוזר כזה להסתכל על מה השבוע שעבר או לפני שבועיים, וזה דרך אגב, give and receive, כן? אז אני מקבל פידבק מהעובדים, ואני גם צריך לעשות עם זה משהו. וזה חלק מהמקום שלי בבניית האמון, מעבר לזה שזה טוב לארגון, זה גם בניית אמון מול העובד. אז אני בדרך כלל לוקח ועושה עם הדברים משהו, ואני גם מצפה מאותה עובדת או עובד בהתאם. ושוב, אנחנו מדברים על משהו של נגיד פעם בחצי שנה כזה, של להגדיר איזשהו אזור שאנחנו רוצים לשפר אותו, והוא שם, הוא נמצא באג'נדה כל הזמן, והוא מובא בקונטקסט של אותו שבוע, בסדר? נגיד למשל עבודה עם פירים. יש עובדים שמתקשים בעבודה עם פירים, אבל ב-day to day שלהם זה must, וכל שבוע יש איזשהו נושא אחד לפחות שמצריך עבודה עם פירים, ואז אני מדבר עם אותה עובדת או אותו עובד, בהקשר הזה, הוא אומר, אוקיי, אז איך ניהלת את השיחה השבוע עם איקס, ואיך אנחנו משפרים את זה בשיחה הבאה בשבוע הבא? אנחנו ממש יורדים לרזולוציות האלה, ואם העובד, מה שנקרא, איתנו, איתי, אנחנו מיושרים, והוא מבין שזה תורם לו ברמה הכי אישית בעולם, מעולה, יש פה רווח אדיר, ותנחש מי עוד מרוויח מזה? הארגון, או הסובבים, כן? אז על זה אני מדבר.
אייל דוד: [31:55] מהמם, אז בעצם אני אמלק את זה רגע, אז מה שאתה עושה, זו ממש גישה אימונית, אז אתה אומר, אנחנו עושים רטרואים שבועיים, שממוקדים בעצם בעובד, אנחנו מגדירים את המטרה לפני כן, וכל מיני דוגמאות בעצם שאנחנו בכיוון, ואתה גם כל הזמן מוציא אותו ממקום הנוחות, או אותה, נכון, כדי בעצם לגדול, כן, אבל כל זה קורה בעקבות זה שבתחילת הדרך הגדרתם משהו שכנראה היא או הוא מאוד רוצים לעבוד עליו, ולכן הם מוכנים לצאת ממקום הנוחות שלהם. אמת, ואמרת בדיוק,
דוד בן-בסט: [32:23] ואני מאוד מתחבר גם לאמרה שלך של לצאת מאזור הנוחות, לצאת מה-comfort zone, כל פרק זמן די קצר באופן יחסי, ואני אומר את זה מניסיון אישי, כי עשיתי הרבה טעויות בהקשרים האלה ולמדתי מהן, צריך לצאת מאזור הנוחות. כשאתה נמצא באזור הנוחות, בהגדרה, אתה לא מתפתח. אתה יכול לעשות עבודה טובה, אבל אתה לא מתפתח. כשאתה יוצא מאזור הנוחות, שם אתה מתחיל לגדול. אז למשל, עשינו לאחרונה איזשהו שינוי בקבוצת הדבאופס, שהיא הבשילה לכדי השינוי הזה. מה שעומד מאחוריו, וזה דרך אגב מבוסס פידבקים שהגיעו מהשטח, מה שעומד מאחוריו זה בעצם להוציא את הדבאופס אנג'ינירס מאזור הנוחות הנוכחי שלהם לעולם חדש. ויש חששות, מצוין, אם לא היו חששות זה אומר שאנחנו לא באמת מייצרים פה שינוי. שינוי מביא איתו חששות, שינוי גם מוציא מקומפורט זון. כמובן שאנחנו מאמינים בשינוי, ולכל דבר יש פלוסים ומינוסים, אז אנחנו נדע להתמודד עם אותם מינוסים ולנהל אותם כך שבאמת נוציא מזה את הטוב ביותר. אבל יש פה גדילה אישית מדהימה לאותם עובדים. כל הזמן מנהל צריך לאתגר את העובדים שלו בלהוציא אותם מהקומפורט זון, וכל מה שאנחנו מדברים עליו, שים לב, זה שגרה, וזה פרסונל גרואת'. ממש, ובעצם גם מה שאתה אומר,
אייל דוד: [33:50] בשביל להפוך את המכונה הזאת לסקיילבילית מאוד, אני צריך גם להשריש את כל הדבר הזה בעצם לעובדים תחתיי, שבעצם ייקחו את זה כלפי מטרוקולידה. יכול להיות שזה יהיה קסקיידד לכל הארגון. מהמם. ואתה מרגיש שזה זולג בעצם גם למחלקות אחרות, זה מה שאני מבין. זה כל הזמן זולג, אבל זה מצריך עבודה.
דוד בן-בסט: [34:09] זה לא זולג ביי דיפולט, כי יש מחסומים שצריך להתיר אותם, ששוב, אין בשלות מספקת. חבר'ה שהם ראשי צוותים צעירים, מדהימים. עם פוטנציאל אדיר, אבל בסוף זה לוקח זמן. ואת הדברים, את הנושאים האלה, אני לא אגיד תמיד, אבל ברוב המכריע לומדים ברגליים. אין קיצורי דרך, ועם הרבה הרבה טעויות, וצריך לתת לאנשים לעשות טעויות, וללמוד מהן. ואנחנו נותנים את ההדרכה ואת ההתוויה, וגם, שוב, מצמידים את זה גם לביצועים האישיים של כל עובד, אז אנחנו מעודדים את זה יותר מהר, ובצורה מאוד מפוקסת. אבל זה לוקח טיפה זמן, צריך גם סבלנות, וזה כן, זה מחלחל. זה מחלחל, ובמקומות שזה פחות מחלחל, אנחנו עוזרים לזה לחלחל. עוזרים לזה לחלחל. אני אגיד לך מהצוות שלי,
אייל דוד: [35:02] שאני עובד איתם בצורה מאוד דומה, ואחד הדברים שמונעים לצאת מאזור הנוחות, זה החשש מכישלון, ואז בעצם צריך להגיע הרגע שבו אתה עוזר למדוד את הסיכון ולמצוא לו גם תרופות. איך אתם מתמודדים עם זה? זו שאלה מצוינת.
דוד בן-בסט: [35:20] זה תלוי, זה מאוד מאוד תלוי באותו כישלון, מה המגניטודה שלו. אז שם אנחנו נמצאים כמנהלים, אנחנו כן צריכים לתת לאנשים לעשות את אותן טעויות שהנזק שלהן כנראה לא גדול, אבל יש להן אימפקט או תרומה מאוד מאוד גדולה על הגדילה האישית שלהם. ולסימן שאין פה, אתה יודע, שאף אחד לא מפיל פה את פרודקשן, לצורך העניין. אז אנחנו כל הזמן נמצאים במתח החיובי הזה.
אייל דוד: [35:49] אז זה מצריך באמת הסתכלות יומיומית, כמו שאנחנו אומרים, אבל זו המטרה. לגמרי. אני מנסה גם לעשות את הניהול סיכונים הזה יחד עם הצד השני. בעצם קצת להפוך את החששות, ואוקיי, מה הכי טוב שיכול לקרות זה שיהיה מוצלח. מה לא? בואו נפרט אותם, ואז אנחנו מתחילים בעצם לנהל את הסיכונים האלה. אני משער שגם אתם עושים את זה.
דוד בן-בסט: [36:11] וזה בעצם מאפשר לצאת לדרך הרבה יותר מהר, לפחות מהניסיון שלי. נכון, בשביל שחברה תהיה באמת רזיליאנט, היא צריכה מנגנונים ותהליכים. ואנחנו כל הזמן משרישים עוד ועוד כאלה. גם ברמה ה... אתה יודע, דיברנו על פרודקשן, אז כל מה שקשור למוניטורינג של פרודקשן, יש לנו צוות SRE שרק הולך ומשתבח, ויש פה אלמנטים של חינוך, מה שנקרא השיפט-לפט של SRE לכיוון R&D, לכיוון המפתחים, כל הזמן. אז כל מה שקשור לניטור הדברים האלה, אנחנו משפרים כל הזמן את התהליכים בתוך הארגון, מבחינת צורת העבודה, עבודה בתוך צוותי R&D, עבודה עם פרודקט. אנחנו מעלים את הרף כל הזמן, בסדר? זה מאוד מאוד חשוב. כשעובד מגיע לאיזשהו רף מסוים, הדבר הראשון שצריך לעשות זה פשוט להעלות את הרף. אנחנו מנטרים את הנושאים האלה בכל מיני ישיבות סטטוס שציינתי, כאלה ואחרות, כמו מיני אוברסייט מיטינג. רוצים לראות שהדברים גם מתקדמים, אבל גם מתחברים הוליסטית, בסדר? כשארגון גדול, לא דיברנו על זה, יכולים בקלות להיווצר סיילוס, שלפעמים יש לזה יתרון, כי זה קצת גם, אתה יודע, מקדם את הווילוסיטי של כל אזור מצוין. יחד עם זאת, צריך לראות שכולם בסוף אליינד עם ה-KPI'ים של כל הארגון, והדברים מתחברים ביחד בכל מיני אספקטים, באספקט הארגוני, באספקט המוצרי,
אייל דוד: [37:44] באספקט הארכיטקטורי. זהו, זה כנראה ניהול סיכונים שעבד טוב אחרי שחזרת עם המסקנות. אני רוצה, שנייה, באמת עברת בהרבה ארגונים, אני הייתי רוצה, שאלה שבדרך כלל אנחנו שואלים פה, מה הם בעיניך הפרודקט סקילס הכי חשובים במנהל מוצר?
הסקילז החשובים במנהל מוצר
דוד בן-בסט: [38:03] אז אוקיי, אז קודם כל דיברנו על באמת על נושא של פרודקט ו-R&D, שבאמת יושבים יחד והם אינגייג'ד ועובדים יחד, אפילו פיזית יושבים יחד, אתה יודע, באותו חדר.
אייל דוד: [38:15] זה נושא ראשון. אני חושב שמה שאתה מתכוון אליו כאן זה בעצם הצורת עבודה והקומוניקציה,
דוד בן-בסט: [38:22] ובעצם התחושה הזו של דוחפים יחד את העגלה הזאת. אבל גם ברמת ה-accountability, בסדר? ההצלחה היא ההצלחה של כולנו. זה מה שאמרתי, דוחפים יחד את העגלה הזאת, ממש. בדיוק, בדיוק. visibility, בסדר? צריכה להיות visibility מאוד מאוד איכותית, גם מצד הפרודקט, גם הפרודקט דורש בעצם מאותו צוות שהוא עובד איתו. אני קורא לזה Continuous visibility, כל הזמן, כל הזמן לתקשר, כי אתה יודע, יש דברים שאני לא יודע להעריך את הזמנים, אני אתן הערכה גסה עכשיו, ועם הזמן כל הזמן אעדכן אותה. זה סריף, פשוט זה סריף. בדיוק. Strategic thinking, כמו שדיברנו, הרעיון הוא להתחיל מבניית אסטרטגיה, בסדר? ולא מרשימה טקטית, רשימת מכולת, מבניית אסטרטגיה שבאמת תהיה אליינד עם מטרות הארגון. בשנייה שיש אותה, מפה זה כבר קל. מפה כבר אפשר לגזור את הפיצ'רים או את היכולות שבעצם יקדמו. כל פעם ננגוס עוד צעד באסטרטגיה הזאת. נגיע בסופו של דבר, גם אם זה ייקח עוד הרבה זמן, למקום הרחוק יותר. וגם, אתה יודע, יש את הנושא של short term versus long term. תמיד היינו אומרים, טוב, בוא ניתן עכשיו איזשהו פתרון short term, ואחר כך נעשה את ה-long term, שאין קשר בין ה-short term ל-long term, כן? אז, וכמובן שבסוף אנחנו נשארים עם ה-short term. אז זו מחשבה שהיא קצת ארכאית היום. הגישה האפקטיבית יותר אומרת, אתה צריך לחשוב רק long term, אבל כן לתת value בצורה אינקרמנטלית. זאת אומרת, כל פעם עוד נתח ועוד נתח שנותן value, נגיד עסקי אפילו, כן? ועדיין מקדם את ה-Long term vision הזה, גם אם הוא אף פעם לא יסתיים ב-100%, אבל הוא יסתיים באחוזים משמעותיים, וכל פעם נקדם אותו בעוד מידה. זו גישה הרבה יותר בריאה, הרבה יותר נכונה. כי לא סתם הגדרנו את ה-Long term, יש לזה סיבה, זה נושק לאסטרטגיה שלנו, בסדר? עבודה עם KPI, פרודקט צריך להקפיד על עבודה עם KPI, הוא צריך לדגול בזה, וכך לחנך גם את צוות הפיתוח. זו צריכה להיות האוריינטציה. כל דבר אחר לא מעניין. עוד דבר שחשוב לי בצד הפרודקט, זה הסתכלות גם על ה-non-functional requirements. לא רק על ה-functional, הרבה פעמים אנחנו מפספסים, אבל בסוף, אם הפיצ'ר שדליברתי הוא לא מספיק available, או לא מספיק resilient, או לא מספיק scalable, ובסיטואציות מסוימות הוא לא מתנהג כמו שהייתי רוצה שהוא יתנהג, אז פספסנו את המטרה. בסדר? הכל צריך לבוא bundle ביחד. צריך להסתכל על כל הרכיבים ולדאוג שהצוות מקדם את זה. בהקשר הזה אני גם אגיד, להיות מאוד מאוד קשוב לצוות. הצוות זה לא קונטרקטור. זוכרים? אנחנו יושבים בסירה אחת. לצוותים בדרך כלל, בסדר? יש חובות טכניים. זה תמיד יש, כי זה דבר טבעי שנוצר, וצריך לראות איך אנחנו שוזרים את ה-tech debt האלה בתוך ה-roadmap המוצרי. כל עובד בארגון צריך לייצר אימפקט. בשביל לייצר אימפקט הוא צריך להסתכל הוליסטית. זה לא רק הפיצ'ר, זה גם כל החובות הטכניים שבסוף. לפעמים מאטים את הצוות, ואז זה יאט אותו מפיתוח הפיצ'ר הבא, או פוגעים במוניטורינג או בדיבאגינג של בעיות שיש בפרודקשן, וכולי וכולי. אז לשים לב גם לזה. תכנון, תכנון זה מילת המפתח. אני מאוד דוגל בתכנון. יש לנו, סתם, לכל אינישיאטיב בארגון Slack Channel שמאפיין אותו, עם כל הקבוצה שעובדת עליו, ותמיד אני ככה מסתכל בבוקמרק של למעלה בצ'אנל, לוודא שבאמת יש איזושהי תוכנית בשאיפה אפילו ברמת הג'ירה בורד, ששוב, מעודכן. יודעים לאיפה הולכים. יודעים לאיפה הולכים, הכל מתוכנן, בהחלט יש בלת"מים ומעדכנים את זה on the fly מצוין, כמו שאמרנו, אבל יש תוכנית, עובדים לפי תוכנית. אם לא עובדים לפי תוכנית, לא נגיע לשום מקום. חשיפה לביזנס, גם על זה דיברנו. אני משוכנע שאותו פרודקט מנג'ר חשוף מאוד לביזנס, אבל האם ה-Squad R&D שלו חשוף, ואם לא, הוא צריך לעשות משהו בנידון, גם ממקום של לחשוף אותם, וגם ממקום של שוב, לתת את האינסנטיבים, להסביר למה זה גם מקדם אותם ברמה האישית. פרודקט מנג'ר, לא אמרתי את זה, הוא לידר, בסדר? אני יושב פה וממש יושב על זה, אז ממש מרבית הדברים שאמרת הם באמת צובעים לידר מכל מיני אזורים,
אייל דוד: [42:52] וזה נראה שזה דבר חשוב, זו אחלה תשובה. ותגיד, יש לך איזושהי עכשיו, היום, עבודה בממשקים בעצם עם מנהלי מוצר? זה בעצם השיחות שאתה עושה בעצם עם סטייקהולדרס אחרים?
צוותי אינפרה, אינסידנטים ו-Production is a reflection
דוד בן-בסט: [43:04] כן, תראה, היום אני מוביל גם קבוצת מוצר. דרך אגב, רוב הקריירה שלי הובלתי קבוצות פיתוח לצד, לצד קבוצות מוצר, ועבדתי צמוד מאוד עם מנהלי, מנהלי מוצר. תמיד, תמיד עבדנו ביחד, ממש זה לצד זה, ונתנו פידבק אחד לשני, כן, כל הזמן, וככה בנינו את זה. אבל אני מוביל גם קבוצות אינפרסטרקצ'ר, שהם בעצם אנחנו, ה-Engineers, אנחנו הפרודקט של עצמנו, אבל זה מצריך המון המון הבנה של מה שקורה למעלה, מה שנקרא, לא רק מבחינת להקשיב, אלא גם להיות מעורב. וזה משהו שאני מאוד מאוד דוחף אליו, כי הסכנה בקבוצות אינפרה, שיש לזה המון המון יתרונות, זה קצת ניתוק מהביזנס, קצת ניתוק מקבוצות ה-R&D. אז חשוב שזה לא יהיה ממקום של כזה, לשבת ולתת עצות או לבנות איזושהי תשתית בין אם היא רלוונטית או לא, אלא באמת לחוש את הכאב. וזה אומר להשתתף יותר ב-Production Incident, שבשאיפה יהיו כמה שפחות, אבל כשיש חשוב שיותר ויותר אנשים יהיו שם. אפרופו Production, משפט שאני אוהב להגיד, Production is a reflection. Production בעצם הוא מצב יותר, מצב לחץ. כמו שאנחנו אומרים, במצבי לחץ אנחנו רואים את התמונה האמיתית. אז יש באמת, כשיש אינסידנט, יש לנו את ההסתכלות על כמה מהר הבעיה נפתרת, שזה סופר חשוב. יש לנו גם הסתכלות מעבר, שאומרת האם אנחנו דואגים לזה שהבעיה באמת לא תחזור על עצמה. ויש הסתכלות נוספת, שאני מאוד מאמין בה, והיא מי האנשים שעולים לאותו אינסידנט ובעצם מטפלים בבעיה. וככל שיותר ויותר אנשים עושים את זה, ככל שבעצם יותר מפתחים ופחות מנהלים או אנשים שהיו בסטארט-אפ ברגע שהוא הוקם עושים את זה. זו אינדיקציה מאוד מאוד טובה לסקלביליות של ארגון, לארגון שהוא בעצם הופך להיות בריא יותר וממנף באמת את כל העובדים שלו או את רוב העובדים שלו. זאת כנראה מכונה שעובדת. נכון, מהמם. היה סופר מעניין עד עכשיו, בואו נסגור, בואו נתקדם לעבר הסגירה,
אייל דוד: [45:34] העטיפה של הפרק, אז אני שואל גם את השאלה הזאת, איפה אתה רואה בעצם את עצמך עוד עשר שנים, מה אתה מאחל לעצמך?
דוד בן-בסט: [45:41] בעצם התשוקה שלי לגדל אנשים, לגדל צוותים, לגדל דור של לידרים, כמו שאמרנו, בין אם הם people managers או אחראים על דומיין מסוים, זו התשוקה הכי גדולה שלי. יש בה בעצם בנייה של אותם אנשים ברמה הכי אישית בעולם, לצד תרומה לארגונים שבהם הם נמצאים באותו שלב או בעתיד. אז זה באמת הווין-ווין הזה שאני מאוד מאמין בו, וזה משהו שהייתי רוצה להמשיך ולעשות יותר ויותר, יותר להשפיע על עוד אנשים, על עוד ארגונים, לייצר הצלחות, זה פשוט נותן לי סיפוק אדיר. לצד גדילה ארכיטקטורית, סקייל ארכיטקטורי, של מערכת, כמו מה שדיברנו היום. רק שאני חושב שבאמת האתגר הגדול יותר הוא בסופו של דבר האנשים. בטכנולוגיה יש המון המון אתגרים, אבל וכמובן גם בביזנס יש המון אתגרים, זה עוד מימד. אבל עם השנים מצאתי שהאתגר באמת מעל כולם הוא האתגר האנושי, ואולי אחד ההבדלים המהותיים שכשעוסקים באתגר אנושי, כשאתה מדבר עם אנשים, אתה לא מדבר רק אל הרציונל שלהם, כמו שאתה מדבר באספקטים טכנולוגיים, גם, אבל גם ללב שלהם. וזו יכולת, זו יכולת שמפתחים אותה עם הזמן, ופשוט כשאתה מרגיש שיש לך את זה ואתה תורם, קשה מאוד לוותר על זה, וזה משהו שהייתי רוצה להמשיך ולעשות אותו.
אייל דוד: [47:32] מהמם, דוד, אז בוא נעזור לך. אז אם יש עכשיו מאזינים שרוצים לפנות אליך כדי, אתה יודע, להתייעץ לגבי הצמיחה האישית שלהם, לגבי הארגון שלהם וזה, איך פונים אליך, איך יוצרים איתך קשר? אפשר ליצור איתי קשר דרך הלינקדאין.
דוד בן-בסט: [47:45] בשביל לשלוח לי הודעה, ואפשר בשמחה לתאם איזושהי שיחונת קצרה. אני חושב ששוב, יש לי ניסיון בזה שהוא מבוסס על המון המון טעויות. למדתי מהן, ואני אשמח לתת עצות, הכוונה לכל מי שירצה. מהמם, אז כדי לפלטר גם קצת,
אייל דוד: [48:08] מה בעצם המינימום שצריך להגיע כשפונים אליך? מה צריך להיות מצוידים?
דוד בן-בסט: [48:15] צריך להיות מצוידים עם הבנה של בעצם המקום שאני נמצא בו בארגון, מה מטרות הארגון, מה הארגון מצפה ממני. אני חושב שאלה שיעורי בית שחשוב לעשות בכל מקרה. כל עובד צריך לשאוף ולהבין מה הציפיות ממנו. אל תחכו לאף מנהל לבוא ולהגדיר לכם מה הציפיות מכם. אם זה קרה, מצוין. אם לא, שבו ותגדירו לעצמכם, וכן תיישרו קו עם המנהל, מנהלת, עם המערכת. תעשו את האדג'סטמנטים שצריך, ושימו לעצמכם יעדים, בסדר? אל תיתנו לאף אחד למנוע את ההצלחה שלכם בקריירה. זה עליכם. תבנו את זה בעצמכם. אם אתם מקבלים את הפידבק מעולה, אם אתם לא, תדאגו לקבל אותו, כי זו הצלחה שלכם. בסדר? זה גם, יש פה קצת up management, אבל זה נושא שהוא מאוד מאוד חשוב. מהמם. אחלה סיומת.
אייל דוד: [49:12] אז תודה רבה, דוד. בכיף. ויאללה, עד הפעם הבאה. ביי בינתיים. ביי ביי, תודה. היי, חברים, תודה על ההקשבה. אם מצאתם את הפודקאסט הזה בעל ערך, תוכלו להירשם, לעקוב אחרינו, כמובן לפרקים נוספים בספוטיפיי, אפל פודקאסט או כל אפליקציה אחרת. כמובן שאם לא מצאתם אותנו באיזושהי אפליקציה, אשמח שתכתבו לנו. נשמח מאוד לחמישה כוכבים בכל פלטפורמה ושתעקבו אחרינו, כדי שעוד מאזינים יוכלו להיחשף אלינו ולמצוא את הפודקאסט. אתם גם יכולים למצוא את הפרקים הקודמים בכל אפליקציה או בערוץ היוטיוב, יש לנו לינקים בתיאור. עד הפעם הבאה, יאללה, תהיו יעילים וביי ביי.