166: בקצרה – איך יודעים שהגיע הזמן לשינוי במבנה הארגוני?

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

מוזיקת פתיח

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

ערן: אז, במשך הרבה מאד זמן היינו במודל של Task Forcing. בגדול, Task Force הוא מודל אופורטינסטי בוא נקרא לו – מזהים איזה שהיא בעיה בעולם, קם צוות ייעודי לפתור את הבעיה הזאת, יש לו מטרה מאד ברורה, KPI מאד ברור, הוא מדלוור את המקסימום אימפקט, ובעיקרון הוא מתפרק לאחר מכן. זה גוף שהוא זמני ביסוד שלו, מה ממאפשר לנו מאד מהר לבנות כאלה, להשיג מטרות, לפרק, להשיג מטרות אחרות וכן הלאה. Domains, להבדיל מ – Task Force, זה גוף שהוא קבוע, כלומר זה לב הסיפור. אז אם בעצם לקחנו את כל עוגת המוצר נקרא לזה, חילקנו אותה לחתיכות בגדלים בגדול שווים, וכל חתיכה כזאת היא Domain. כלומר, Domain הוא אחראי על חלק במוצר, כל חלק כזה הוא מאד גדול, זאת אומרת, Domain לא באמת יכול בכל רגע נתון להתעסק בכל הדברים שחולים אצלו. הוא בעצם סוג של מחפש את ההזדמנויות בתוך אותו Domain ומפעיל קצת כמו את שיטת ה – Task Force, כלומר במה מתמקדים עכשיו, מה הניצחון וכן הלאה, שהיתרון הגדול פה זה שבעצם קבוצת האנשים האלה בתוך הדומיין מכירים את הדומיין לאורך זמן, הם קבועים שם, יכולים לפתח Expertise, ועוד דברים שנרחיב עליהם בהמשך.

דניאל: נגיד עם ניקח את עולם ה – Task Forces, אז בפן הפרקטי גם חשוב להגיד שכשעבדנו ב – Task Forces אז הייתה איזה שהיא חלוקה של זמן, זאת אומרת, 50% מהזמן אנשים היו עובדים ב – Task Forces כמו שערן אמר, על איזה שהוא KPI, ו – 50% הם היו עובדים מסגרת אחרת, של הצוות האורגני שלהם לפי הסדיסיפלינה.

ערן: אז בעצם אפשר להגיד שהיה 50%, או 50-50 על התקדמויות מוצר בדברים חדשים, ו – 50% ניהול של כל השאר. אז קודם כל אני חושב שנורא חשוב להבין שבסוף ה – Structure, המבנה שבו עובדים, הוא קצת מכתיב את ה – Day to day. נכון? קצת, אם אני אתן אנלוגיה יותר קלה, אם יש לך מחלקה מסוג מסוים אז עושים את הדבר הזה, ואם אין לך אותה אז לא עושים את זה. אז גם בעבודה השוטפת זה היה ככה. אז כשדיברנו קודם על ה – 50-50, נכון? 50% מהזמן עובדים ב – Task Force על התקדמויות, ו – 50% מטפלים בכל השאר, זו הייתה המציאות. וזה היה נורא קשה, כי ה – 50% האלה היו שונים אצל כל בן אדם. בסדר? נגיד היו מפתחים מכמה צוותים שונים שעובדים על כמה דברים, כל אחד מהם בעצם ניהל את ה – 50 שלו מתי שבא לו, ואז אתה בא לעבוד עם הבן אדם, הוא אומר לך "לא לא לא, עכשיו אני ב – 50 השניים", ואז יכול להיות שאתה ב – Money time של איזה משהו ואתה בא לאחד המפתחים שאתה עובד איתם ואומר לו יאללה, בוא נרביץ את זה – לא, אבל הוא עכשיו ב – 50 הנוספים. עכשיו זה חוויה מאד מתסכלת מצד אחד לי, כ – Product בחברה, מצד שני גם לאותו בן אדם זה חוויה מתסכלת, כי גם הוא רוצה להצליח ולתת בראש ולהתקדם לצוות, אבל יש לו עוד דברים שהוא עושה. אז בעצם מ – 50-50 עברנו בעצם ל – 7/3, כלומר שבעה ימים בעצם בתוך ה- Task Force, עושים Product Increment  ומתקדמים, ושלושה ימים בעצם באותו מודל של כל המסביב, בסדר? ה – Performance והכל, יש שם דברים חשובים, וזה מאד שיפר את המצב. כי קודם כל, עכשיו לדעת אני כ – Product שיש לי שבעה ימים מלאים עם הצוות שלי לעבוד איתם, זה לא כל אחד הולך מתי שבא לו, אבל מצד שני, אתה מתחיל להגיד רגע רגע, אתה עובד, אתה מתקדם, אתם ב – Money Time של משהו, ואז מגיע ה – 3, ואתה אומר זה לא חשוב במירכאות, כמו מה שאני רואה לנגד עיניי. בוא, בוא נטרוף את זה. עכשיו אתה גם שואל איך מתעדפים, נכון? כלומר פתאום יש שני קונטיינרים, יש קונטיינר ה – 7 ואת קונטיינר ה – 3, ואנחנו עושים תיעדוף פנימי בתוך כל קונטיינר. אבל מה אם אני מחזיק ביד של ה – 7 במירכאות את הדבר הכי גדול בעולם? הוא לא מתועדף בכלל בתוך ה – 3. ואז הדבר הזה, אחד, הוא יוצר שוב, את אותם תסכולים מפעם, נכון? כי כולם רוצים להתקדם, וכולם גם רוצים לשפר את ה – Performance, ונוצר פה איזה מין מבנה שהוא יוצר Friction אינהרנטי. כאילו, זה מצחיק, נכון תמיד האמת היא בפרטים הקטנים? נגיד כבר אפשר להסתדר עם ה – 7/3, אנחנו מכירים את החיים, משימה שהתחילה ב – 3 יכולה לקחת 4, ואז אני מורט שיערות מהראש, נכון? אני חייב את היום הזה, אנחנו חייבים לנצח – 

דניאל: רק חשוב לי פה כדי לאזן את זה קצת, כי אנחנו כאילו, בגלל שאנחנו היום ב – Domains ולגודל שלנו ברור שזה מתאים פי מיליון, וזה היה, אתם יודעים, בנקודה שהגענו לנקודת רתיכה זה כבר ממש ממש הרגיש לא טוב, אבל לפני זה, אם נסתכל על ה – Task Forces, במבנה שהוא יותר קטן, באמת כאילו הכמות דברים שהתמודדנו איתם, היא עשרות מונים, זאת אומרת, אני יכול להגיד שגם בעבר היה לנו ניסיונות קודמים בכל מיני חלקים של ה – R&D, לקחת איזה שהוא איזור לפרק אותו ל – Domains מה שנקרא, אבל זה היה בן אדם אחד בכל Domain או משהו כזה, כי היינו נורא קטנים – 

אדווה: זה היה נורא מלאכותי, כן.

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

מוזיקת מעבר

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

דניאל: אנחנו אוהבים להגיד ש-, זה כמו ה – Rule of thumb שלנו למתי להקים צוות חדש, או למתי להקים Domain חדש, וזה כמו כזה פרקטל, שזה צורה שאתה עושה עליה זום ואתה רואה את אותה צורה בדיוק – לדעתי הנקודה לעבור, והנקודה הטובה להקים Domains, זה ברגע שאתה מרגיש שברגער שפיצלת את זה ל – Domain, עדיין ה – Domain הוא עולם מלואו. בסדר? ואני יכול להגיד שכשהיינו קטנים לא הרגשנו ככה, אמרנו אם אתה תתעסק רק בזה, זה נורא מצומצם, זה נורא קטן, זה לא מספיק, כאילו יש לך עוד מלא דברים שאתה יכול לעשות – היום ב – Domains, זה עולם. יש לזה את ה – quality ויש לזה את ה – Performanceויש לזה את ה – Long Term Planning של זה ויש את ההזדמנויות הארוכות, וכו' וכו'.

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

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

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

מוזיקת מעבר

אדווה: שינוי ארגוני הוא באמת אף פעם לא פשוט. יש לא מעט סיכונים שמגיעים איתו.

ערן: א', פחדנו פתאום שאנשים שירטטו קווים מאד ברורים בין ה – Domains כאילו משהו שלא יהיה סופר Well Defined הם יגידו זה לא שלי, זה כן שלי, ואחד מהדברים שאנחנו נורא אהבנו, שכולם, הבעיה, כל בעיה היא בעיה של כולם. פחדנו מאד לייצר ראייה צרה אצל אנשים, כי מאד חשוב לנו שאנשים יראו את כל העולם, ופחדנו מאד מחוסר סינרגיה בין מאמצים. כי פתאום איך אתה, יש לך עכשיו עשרה Domains לצורך העניין – איך הם עובדים על פרויקטים שהם Cross Domain? היה לנו הרבה שאלות לגבי המיקום, מה זה Leadership של Domain. נגיד היה לנו התלבטות מאד גדולה לגבי המקום של הראש צוות. כי פתאום אם אתה אומר ראש צוות הוא חד חד ערכי ל – Domain, לפני זה ראש צוות היה מנהל אופרציה הרבה יותר גדולה. אז רגע, שניה, אז מה זה אומר עכשיו? שאנחנו צריכים פי 2 אנשים כדי לנהל את אותה כמות של Content וכו'? הרי זה לא הגיוני, וגם הדברים האלה בסופו של דבר הם כולם סביב אותו פחד שאולי Domain זה קצת לצמצם את האנשים ולהגיד להם תקשיבו, זה העולם שלכם, תתעסקו בעולם שלכם. ה – Bigger Picture זה ב – Domain של מישהו אחר. בואו נגיד ככה, אנחנו עם כל זה שיש לנו מבנים מאד מאד מוגדרים, אנחנו מסתכלים על מבנה כעל גלגלי עזר וכל המטרה שלו הוא לעזור לנו. זאת אומרת שברגע שהוא מפריע לנו אז אנחנו מנסים לשנות אותו, ויש לנו גם המון דברים שהם Customized ב– Domains. גם ב– Domains לדוגמא עכשיו, יש לנו מקרים מסוימים שראש צוות הוא ראש צוות בוא נגיד מאד מנוסה ובכיר, הוא מצליח להיות Leadership של שני Domains, בסדר? ואנחנו מרגישים ששם נגיד הקסטומיזציה היא מאד מאד נכונה.

דניאל: אני יכול לשתף שלי היה פחד אדיר שהחזקתי מאד חזק, ובדיעבד כאילו הייתי צריך לשחרר אותו הרבה יותר מוקדם, שאמרתי רגע, כאילו, זה באמת קומפלקס ברמה, יש פה קונטקסט מטורף, כדאי עכשיו להחליט האם ה – Security זה הזה יותר חשוב מהבאג הזה, יש פה קונטקסט מטורף שצריך לתת כלים כלפיו. וצריך פתאום שנגיד בישיבות Sync שאנחנו עושים, שעד אותו רגע רק דיברו על מה הדברים החדשים שעשינו ואיך הם משפיעים עם העולם וכו', פתאום רגע, צריך לדבר על מה שאנחנו קוראים לו מדדי חום מנוע, איך אתה יודע שאתה לא רץ מהר מדי ונשרף? ואיך אתה מודד Quality ואיך אתה מודד Craftmanship, ואני חושב שאחד הדברים המגניבים בשינוי הזה זה שבעצם לקחנו את העולם, כאילו, באיזה שהוא מקום, כמו שערן אמר, היום Domain הוא מספיק גדול ויש לו את הדינמיות של ה – Task Forces בתוכו. ואני מאד אוהב את זה שכל Domain עובד בצורה אחרת, ואני מאד אוהב את זה שבאמת אנחנו עושים קסטומיזציה לגבי של המבנה שלנו בתוך כל Domain לגבי המאמצים שה – Domain הזה צריך לעשות, יחד עם זה שיש לנו איזה ראייה עם סטנדרטים מסוימים על איך מסתכלים על Quality, על מסתכלים זה, ועדיין, אספקטים שאנחנו מסתכלים עליהם ברמה כוללת.

מוזיקת מעבר

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

דניאל: אז התחלנו בלהגדיר פורום של אנשים שהוא בעצם ה – Leadership של ה – Product, ה – Dev וה – Design, ובעצם קבענו סשנים, וקבענו להם אג'נדה. הסשן הראשון היה סביב למפות את הבעיות, למפות את מה אנחנו רוצים לשמר.

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

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

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

דניאל: להוריד את זה לפרקטיקה ודוגמאות, וגם לא לנסות לפתור הכל בסשן אחד. זאת אומרת, לאפשר זמן בין סשן לסשן לדברים לשקוע. יש המון דברים שעושים שינוי כזה, אתה אומר טוב, נעשה ככה וככה, ואז התגובה הראשונה של כולם זה "רגע רגע רגע רגע, עצור". צריך גם להיות פה בקטע של לא להגדיר עד הסוף ולהבין שכאילו עוד יהיה שינויים ומה עקרוני ומה לא עקרוני ולהתקדם פשוט. ואז בעצם דיברנ ועל איך אנחנו הולכים לתקשר את זה ו – To roll out. אז מהפרטים הלוגיסטיים של מתי Effectively מתחילים לעבוד ככה, עד פרטים של איך אנחנו משמרים ניהול של אנשים שאנחנו רוצים, שיש להם Career Growth ודברים כאלה, אז ניסינו להתאים את זה ככה שגם יהיה שינויים שנראים לנו הגיוניים.

ערן: אני חושב שבסוף, כאילו, היינו בחדר כמות מסוימת של אנשים, ויש הרבה יותר אנשים שזה משפיע עליהם, ויש עוד, כאילו, זה שלב בדרך, לחשוב בעצם על מה כל אחד ישמע, כשנציג את הדבר הזה, נכון? כלומר, אנחנו רוצים להגיד משהו אחד, לא בטוח שכולם ישמעו את אותו דבר. ואז אתה אומר אוקיי, בוא נחשוב מה אנשים עלולים לשמוע שזה לא מה שהתכוונו. כלומר, זה לא כזה שיחה שמקשקשים אותה ויוצאים לדרך. ממש צריך לחשוב מה כל אחד עלול לשמוע, מה זה יגרום לו להרגיש. בסוף השינוי הזה הוא נאר נואר חיובי וצריך לשקף לכולם בצורה מאד מאד טובה את כל התהליך ואת הבעיות, ואת מה שהם אולי ישמעו לחדד בצורה מאד טובה, ולנסות להעביר את זה בצורה הכי קלה שאפשר, ואני ממש זוכר שהייתה את השיחה, דני עוד שניה ירחיב, אבל בסוף השיחה היה ממש רשימה של שאלות, נכון? כמו FAQ באתר, אתה אומר, האם זה אומר שאני 1,2,3? מדברים על זה, האם זה אומר ש – מדברים על זה. כלומר, וזה נואר נורא חשוב, גם כי אני חובש שזה נוגע בנקודות שאולי בטעות איך שהוא התפספסו במהלך ה – Flow, אני חושב שזה גם משדר שהאנשים הם בפוקוס, ואולי נקודה אחרונה, שזה לא Done Deal. כלומר זה לא התנ"ך, אף אחד לא ירד עם ספר הפתרונות משום מקום – זה קונספט ראשוני שהיה בהתהוות, כנראה יש בו מלא חורים שלא חשבנו עליהם, בסוף צריך שכולם ירתמו לדבר הזה ויצאו את החורים ביחד כדי לפתור אותם, לא כדי להגיד הנה יש פה חור. אנחנו לא עובדים ככה. זה למה הוא נורא חשוב. כנראה שהפתרון, יש בו טעויות, בסדר? כמו כל דבר שאנחנו עושים בחברה הזאת. אבל אם כולם מבינים את הלמה, אז כולם ביחד פותרים את הטעויות האלה שלא שמנו לב אליהם.

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

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

דניאל: אני גם חושב שזה תהליך שהוא לא Flip the switch וממחר כאילו Domains, אלא יש פה המון המון דברים, נגיד סתם, היה דוגמא נהדרת שזה היה שונה ב – Domains שונים, Domains מסוימים לקחו את השינוי הזה, עשו אותו מיד, Domains אחרים היו צריכים יותר הכוונה ויותר עזרה, Domains מסוימים היינו צריכים לדבר איתם על Skill Set חדש שצריך לבנות בתוך ה – Domain, ואת כל הכלים שלנו לעדכן. מה שאני מנסה לומר זה שזה באמת שינוי שהוא מאד מאד רחב, הוא משפיע על המון המון דברים, ואני חושב שעשינו אותו Gradual, תוך כדי Training של דברים. בהתחלה היה הרבה דברים שלא עבדו טוב. זאת אומרת, אני חושב שגם יש בעיות שפתרנו אחרי זה באמצעות Adjustments על המבנה הזה. כשאנחנו עברנו ל – Domains נגיד, אחד הכאבים פתאום שהיה לנו זה שהיינו צריכים הרבה יותר אנשים בכל Domain ולקח לנו זמן להגיע לשיווי משקל שם, ואם היינו עושים את זה יותר מוקדם, זה פשוט היה קורס, השיטה לתוך עצמה. כאילו, לא היינו – אז אני חושב שאני מאד מתחבר לדברים, ובאמת, אין פתרון אחד במבנה שמתאים להכל. מבנה זה משהו שהוא Customized, שצריך בכל נקודת זמן להבין מה אנחנו רוצים, וגם לא צריך לנסות לייצר איזה שהוא Template ולהכיל אתוו על כל הארגון. אני חושב שאחד הדברים שאנחנו מאד מאד אוהבים ומבינים היום זה שצריכים להיות לנו המון המון סוגים של שרירים והמון המון סוגים של מבנה, ויש שונות מסוימת בצוותים שהיא נהדרת והיא עוזרת, וצריכים צוותים מכל מיני סוגים לכל מיני מאמצים, וזהו, זה כזה – 

ליאור: הסיכום שלך.

דניאל: סיכום, כן.

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

[מוזיקת סיום] WETEXTשירותי תמלול