Podcasts about dropbox business

Our guest today is Melissa Tan, GM of Self-Service and Head of Growth at Webflow and formerly Head of Growth and Monetization for Dropbox Business. In today's conversation, she unpacks the nuances between the two PLG businesses and how growth strategy changes for a more complex product like Webflow, including:  Designing and structuring a growth org The right way to tackle goal-setting How Webflow's pricing and packaging has evolved How to calibrate pricing feedback You can email us questions directly at review@firstround.com or follow us on Twitter @firstround and @brettberson.  

Oliver Jay (OJ) is one of the most successful sales leaders of the last decade. Most recently, OJ spent 6 years as CRO @ Asana and grew the team from 20 to over 450, becoming a master in sales onboarding in the process. Before Asana, OJ spent 4 years at Dropbox, where OJ was Head of APAC & LATAM. Jordan Van Horn is a Revenue Leader @ Monte Carlo. Prior to this role, Jordan spent 4 years at Segment as VP of Sales, leading a sales team of 50+ Account Executives. Before Segment, Jordan was at Dropbox for 4 years leading enterprise sales for Dropbox Business. Dannie Herzberg is a Partner @ Sequoia Capital and before Sequoia, Dannie spent 4 years at Slack as their Head of Enterprise Sales, growing the business from $100M – $1B in revenue. Before Slack, Dannie spent over 5 years at Hubspot building sales teams. Zhenya Loginov is the CRO @ Miro. At Miro, Zhenya runs the go-to-market team of 700+ people across. Prior to Miro, Zhenya was the COO @ Segment where he built and ran the global go-to-market team of 200+ people. Pre-Segment, Zhenya led a 100-person team at Dropbox across different functional areas. Lauren Schwartz is VP of Enterprise Sales at Fivetran, where she has scaled the team to nearly 100, while more than tripling enterprise revenues. Previously, Lauren spent close to 4 years at Segment where she started as the first female AE and ultimately built and led sales teams in enterprise and growth. Kyle Parrish is VP Sales @ Figma, where he built the sales engine from scratch to today, with over 100 in sales. Before Figma, Kyle spent over 5 years at Dropbox in numerous different roles including Head of Sales, and Global Partnerships lead, responsible for growing Dropbox's partner ecosystem. In Todays Episode on Sales Onboarding We Discuss: 1.) How should the onboarding process for all new sales reps be structured? 2.) How should the onboarding process for a new sales leader be structured? 3.) What specific things can leaders do to set both reps and leaders best up for success? 4.) What are the single biggest red flags in the first 30 days that a rep is not going to work out? 5.) What tools and software can be used to improve this process of ramping new reps?

Jordan Van Horn is a Revenue Leader @ Monte Carlo, the world's first data observability company. Prior to this role, Jordan spent an incredible 4 years in sales at Segment including as VP of Sales leading a sales team of 50+ Account Executives and leading the first international expansion for the company into Dublin. Before Segment, Jordan was at Dropbox for 4 years leading enterprise sales for Dropbox Business in California. In Today's Episode with Jordan Van Horn We Discuss: 1.) Entry into the World of Sales: How did Jordan make his way into the world of sales first with a vineyard? What are 1-2 of the biggest takeaways for Jordan from seeing the scaling sales teams at both Segment and Dropbox? How did seeing that impact his mindset? What does Jordan know now that he wishes he had known when he entered sales? 2.) The Sales Playbook: How does Jordan define "the sales playbook"? What is it not? What five core things should the sales playbook help you accomplish? Should the founder be responsible for the sales playbook? Can it be created by a Head of Sales? How does Jordan advise founders on three signals that now is the right time to bring in a sales hire? How does Jordan advise founders on whether the first sales hire should be a rep or a leader? 3.) The Secrets to Pricing and Discounting: Why does Jordan not care what price customers pay in the early days? If it is not about ARR, what should teams be optimizing for? When does price discipline become important in a company journey? What are the dangers of not having price discipline? What two tools do sales leaders have to use in order to create urgency in a deal closing process? How should sales leaders think about building multiple champions within a potential customer? At what price point is it worth it? 4.) The Hiring Process: How does Jordan structure the hiring process for all new sales hires? What are the must-ask questions that Jordan asks all new candidates? What does he want to see in those answers? Who else does he bring into the hiring process? At what stage do they get involved? What are they testing for? Does Jordan use case studies with candidates? What makes the best? What makes the worst? 5.) The Onboarding: What is the ideal onboarding process for new sales reps? What should founders do and prep for when onboarding their first sales hires? What materials and recordings should they have ready? What are some early signs that a new hire is not working out? How do we measure their impact? For enterprise sales, it takes a long time to close new deals, how can one determine effectiveness of new reps when the sales cycle is so long?

Darius Contractor is one of the pre-eminent growth leaders of the last decade. As a growth OG, he has been VP Growth @ Airtable, where he led the growth, engineering, and product teams. Before Airtable, Darius was Head of Product Growth @ Facebook Messenger and finally, before Facebook, Darius spent 4 years as Head of Growth Engineering at Dropbox; here, Darius helped drive Dropbox to $100M in net new revenue through Dropbox Business. If that was not enough, Darius is also an active angel and fund investor with a portfolio including Calm, Airtable, Clubhouse, Census and LP checks in Maven Ventures and Long Journey Ventures. In Today's Episode with Darius Contractor You Will Learn: 1.) Darius Contractor: Entry into Growth: How did Darius make his way into the world of growth? What was that first entry position? What are 1-2 of the biggest takeaways for Darius from his time at Airtable, Dropbox and Facebook? What 1-2 pieces of advice would Darius give to a growth leader starting a new role today? 2.) When is the Right Time: What does the term"growth" really mean to Darius? How do so many confuse it? When is the right time to make your first growth hire as a startup? Should this hire be a junior growth person or a growth leader? Should this initial growth team be placed inside an existing team or as a standalone team? Where do so many startups make mistakes when making this first hire? 3.) Who To Hire: How does one structure the process for your first growth hire? What are the stages? What are the qualities that we are looking to uncover in these first hires? What are the 4 interview stages to go through to test for these qualities? How should founders use case studies and practicals as a way to test for these qualities? 4.) Onboarding and Integration: What does the optimal onboarding process for new growth hires look like? What do the best growth hires do in the first 30/60/90 days? What are some early red flags that a new hire is a mis-hire? How can leaders encourage cross-functional communication between growth and the rest of the org?

[קישור לקובץ mp3] בפודקאסט מספר 418 [!I'm a teapot] של רברס עם פלטפורמה - וזהו קרבורטור מספר 31.התאריך היום הוא ה-17 באוגוסט 2021 ואנחנו בכרכור באולפן הבייתי שלנו בבית של אורי . . . הי אורי! (אורי) אהלן . . . רן, אתה מחזיק את המיקרופון ביד בהחזקה אופיינית לתבורי . . . (רן) בבקשה, הרמתי את האצבע . . . החלטתי להישען בפודקאסט הזה, היה לי יום ארוך של נסיעות . . . אז אנחנו בקרבורטור - ובקרבורטור, כמיטב המסורת, אנחנו מארחים את נתי שלום, אז הנה - שלום לנתי שלום!(נתי) שלום לכם! כמה זמן כבר שלא נפגשנו? כבר איזה חודשיים בערך?(רן) כך וכך חודשים [שישה וחצי] . . . אז נתי, אנחנו שמחים לארח אותך שוב . . . (נתי) האמת שזה די מדהים שכל פעם אנחנו מוצאים איזה נושא מעניין כזה שמדליק פתאום את החושים - כל פעם אתה זורק איזה WhatsApp על משהו ושולח אותי לשבועות של מחקר . . . (אורי) בנושא טעון . . . כמו ענן שחור כבד שעולה במערב . . . (רן) זה הפרק שבו אורי יגיד לנו “אמרתי לכם!” . . . אז בואו נראה מה הולך לקרות פה היום . . . (אורי) אמרתי לכם! . . . (רן) לגמרי.אז לפני מספר שבועות, או אפילו כמה חודשים [May 27, 2021], התפרסם מאמר מעניין בבלוג של Andreessen Horowitz שנקרא The Cost of Cloud, a Trillion Dollar Paradox - שבו, למעשה, הם מתארים, שני המחברים - Sarah Wang ו-Martin Casado את מה שהם קוראים לו “פרדוקס” בתחום של עלויות ענן, או אם נתמצת את זה - מתי “נכון” להיות בענן ומתי “לא נכון” להיות בענן.התשובה לא איחרה לבוא, מפי Corey Quinn, שאמנם לא עובד ב-AWS אבל הוא בדרך כלל בעדם, והוא בא ושובר את כל הטיעונים שלהם לחלקים . . . אז פשוט שלחתי את שני המאמרים האלה ב-WhatsApp לנתי - ופה נקודת ההתחלה שלנו . . . לא נקריא אותם פה בשידור ואתם כמובן מוזמנים ונוסיף רפרנסים [יש] - ובגדול, השאלה היא “האם Cloud נכון לחברה בשלבי ה-Growth השונים? מה העלות האמיתית שלו? האם יש פה אכן פרדוקס?”.(רן) אז בוא, קודם, נכנס ככה למאמר - ולפרדוקס, לכאורה, שהם מתארים. . . (נתי) אז בוא נדבר באמת קודם על מה זה הפרדוקס - הפרדוקס בא ואומר שחברות . . . חברות נמדדות על Velocity, והיום יש Incentive שונה בין Velocity ל-Efficiencyזאת אומרת שרוב החברות משקיעות ב-Velocity, וכשאני אומר ש”יש Incentive” זאת אומרת שהן מתוגמלות בשוק, בבורסה, בצורה שבה החברות נמדדות ב-Valuationומכאן בעצם יש בעצם שרשרת של התנהלות שאומרת “אוקיי, אני צריך להוציא כמה שיותר מוצרים, כמה יותר פיצ'רים כמה שיותר מהר” - וה-Cloud זו פלטפורמה אידיאלית לדבר הזה.בדרך, שוכחים את הצד של העלות של ה-Cloud . . . ואז, כשמסתכלים פתאום על זה התוכן של החברות האלה ועל ה-Portfolio וה-Breakdown של ה-Revenue שלהן, מוצאים נתון די מדהים, לדעתי, שאיכשהו, כשמישהו שם אותו על הלוח, זה הפך להיות משהו מדהים - הרבה מאוד חברות SaaS שהן ב-Scale - אם זה Asana וכמובן Elastic ואחרים - נמצאות במצב שבו אחוז גדול מסך כל ה-revenue שלהן הולך ל-Infrastructure של Cloud . . .ויותר מזה - האחוז הזה הולך וגדל . . . זאת אומרת - ופה נכנס הפרדוקס - מצד אחד, הם גדלים, ומצד שני הריווחיות שלהן הולכת ונשחקת, במגמה כזאת, שהיא לא יכולה להדביק את הריווחיות שלהן . . .זאת אומרת שיש פה איזושהי מגמה שבה אני לא יכול לגבות עבור המוצר שלי בקצב שבו אני מוציא כסף . . . (רן) למה זה נשחק?(נתי) זה נשחק כי אני לא יכול לגבות . . . יש לי מוצר נתון בענן, וכל פעם יש לי דרישה להוסיף לו פיצ'רים ולהגדיל אותוהמשמעות של זה היא יותר ויותר Infrastructureעכשיו, יש הרבה “איים של Inefficiency” [בזרם?] שעוד מעט נדבר עליהם - ומה שקורה לאורך זמן זה שהעלות שלי הוא די קבועה, זאת אומרת שהיא גדלה באופן די קבוע - אבל ההכנסה שלי היא הרבה פעמים Flat, זאת אומרת, מבחינת מבנה ההכנסות . . . אז יש פה שחיקה - בעבור אותו מוצר, אני מתחיל להוציא יותר ויותר . . .(רן) ההכנסה פר-לקוח . . . (אורי) זה סוג של Inefficiency of Scale . . . אנחנו רגילים להגיד שצריך להיות לנו Efficiency of Scale מבחינת עלויות . . . (נתי) אנחנו כמעט ולא נמדדים עליו . . . כל המאמר מתמקד בנקודה הזאת, שאתה מודד את כל החברות על עד כמה מהר הם מביאים עוד לקוחות וכמה מהר הם גדלים, כמה פיצ'רים הם מוציאים . . . אז ברור שהצד השני - כמעט ואף אחד לא יסתכל עליו . . . הרבה פעמים אני זוכר בשיחות שהייתי הולך ו . . . זה בעיני הערך הכי גדול של המאמר הזה . . . הייתי הולך ומדבר עם מנהלי פיתוח ומדבר איתם על כל מיני דברים של איך כן לעשות דברים של Efficiency, והיו אומרים לי “אין לי זמן” . . . “אין לי זמן, אני עסוק כרגע, יש לי מיליון דברים לעשות - זה איפשהו ב-Back-Burner . . .”וכמעט תמיד זאת התשובה שהייתי שומע . . .(אורי) אני רוצה להגיד משהו עם . . . בוא נשים שנייה את הבורסה בצד, בסדר, ונחזור ל-Basics של הכנסות-הוצאות: היכולת לייצר Efficiency of Scale מאפשרת לך, בגדול, To Scale the business more - כי, אם נסתכל על זה בצורה מאוד בסיסית, יש לך “דלי של כסף”, ואתה יכול, בגדול, להוציא אותו על שלושה דברים עיקריים - על Sales & Marketing, על פיתוח ועל Infrastructure . . . זה, נגיד, שלושת הדברים . . . ההוצאות הכבדות שיש.ב-Sales & Marketing ובפיתוח אתה משקיע באנשים - וזה הכוח שלך קדימה, בסדר? ה-Infrastructure הוא מקום ש - עד כדי הפגיעה בהתקדמות של אחרים, של האנשים - איפה שאתה יכול לאפטם (Optimize), תאפטם . . . כי כל השקעה ב-Human Capital . . . לא ה-Human Capital עצמו אלא ב . . . Human Capital יביא מכפילים על הכסף, בסדר? ו-Infrastructure, ברוב המקרים, לא יביא יותר מ-1:1 . . . זאת אומרת: שרת שמשרת X בקשות ביום - היום הוא ישרת X בקשות ומחר הוא ישרת X בקשות.איש מכירות עשה מכירה - מחר המכירה הזו ממשיכה לעבוד ולהביא Revenue, והמכירה שהוא יעשה מחר מביאה עוד Revenueזאת אומרת שיש עליו Revenue אינקרמנטלי . . . אנשי פיתוח, ואני חושב שגם Marketing, הם באותו מקום, ומוצר וכו' - הם הופכים את איש המכירות ליותר יעיל, הם נותנים לו עוד כלים למכור והם גם לפעמים משקיעים ב-Infrastructure והופכים אותו ליותר יעיל . . . אז יש להם, אני חושב, תרומה אקספוננציאלית ל-Business.עכשיו - יש לך את הדלי הזה של הכסף, ותחשוב איפה אתה ועל מה אתה שם אותו: ב-Economy of Scale, תשים אותו על מה שמגדיל את ה-Business, ולא על מה שמביא תרומה יחסית קטנה או קבועה.ואת ה-Basics הזה אנשים שכחו . . . (נתי) נכון . . . ואני אומר, וזה למשל משהו ש-Corey Quinn דיבר על הנקודה הזאת באמת - הוא טוען שהטיעון של Martin Casado מופרך, מכמה סיבות - 1 - מי שקרא את המאמר היה רואה שהוא מתבסס מאוד על המודל של Dropbox . . . מה Dropbox עשו? באמת עשו Repatriation, מהמילה “Patriot” - “לקחת את ה-Cloud הבייתה”.(רן) בוא נזכיר רק . . . לא נקרא פה את כל המאמר, אבל בגדול - הוא מתאר סיפור של Dropbox לפני ההנפקה, שעשו, כמו שאמרת Repatriation, שזו מילה ממש קשה . . .(נתי) . . .נכון, אני עשיתי חזרות לפני כן . . . .(רן) . . . שזה בגדול אומר “לרדת מההענן וללכת ל-Datacenter משלהם” - לחלק מהשירותים שלהם - בוא נגיד שלא לכולם, בעיקר לשכבת ה-Storage, שהיא כנראה יחסית גם מאוד יקרה בענן וגם מאוד סטטית מבחינת . . . (אורי) לא רק . . .זה עד כמה שהיא בשלה . . . (רן) בדיוק - בשלה, תודה אורי. אז הוא בא ואמר שכשהם עשו את הצעד הזה לפני ההנפקה, זה העלה מאוד את הערך של Dropbox בזמן ההנפקה, והם הגיעו שם למספרים די אסטרונומיים - משהו כמו פי-25, אני לא זוכר בדיוק מה המספרים, אבל בצורה מאוד משמעותית, לא ב-30 אחוז . . . גם אם, לצורך העניין, הם הצליחו להשיג הוזלה של 30%, השיפור במכפיל שלהם, או ב-Value או במה שאני לא זוכר . . . (נתי) זה היה X24 . . . (רן) . . . זהו, זה לא היה 30%, אלא זה היה פי-24 . . . ויש להם איזשהו הסבר ללמה זה?(נתי) בדיוק . . . (אורי) כי גם משקיעים מבינים את הדבר הזה שנקרא Economy of Scale . . . זה פינה ל-Dropbox הרבה מאוד כסף כדי להשקיע בחזרה בהגדלה של ה-Business . . .(נתי) נכון, אבל שווה רגע להתעכב על זה טיפה, כי אני חושב שזה הטוויסט הכי גדול בעלילה, במאמר הזה . . .עד היום, בכל השיחות של Efficiency, מה עשינו ומדדנו? אמרנו אוקיי, כמה עולה עכשיו . . . ניקח סתם “להרים VM”? אז עולה לך X$ בשעה וולצורך העניין, בענן פרטי אתה יכול להראות שאולי זה פחות.ואז אתה מגיע למיליונים. אבל ברגע שאתה מזיז את המדד הזה מ”כמה עולה ב-Datacenter שלך לעומת שרת בענן?” ל-”איך זה משפיע על הווליואציה (Valuation) של החברה?”, אתה מגיע פתאום למיליונים, ל”טריליון דולר” הזה שהוא מדבר עליו, ה”Trillion Dollar Paradox”.כי אתה כבר לא מודד את ההבדלים ב-Cost של ה-Infrastructure . . . . (אורי) . . . כי הוא הכפיל את זה במספר החברות ש . . . (נתי) . . . לא רק מספר החברות - אלא איך החברות, איך כל דולר שאתה חוסך משפיע על הווליואציה.וברור שהווליואציה הרבה יותר רגישה למספר הזה - היא לא לינארית, היא לא אומרת “אה, חסכת דולר? אז המנייה שלך תעלה בדולר” אלא “חסכת דולר? אז כמובן במכפילים של כמות העסקאות שיש לך והלקוחות שיש לך זה שווה הרבה יותר”וזה הפך את זה ל”Trillion Dollar Paradox” ולא ל”Million Dollar Paradox” . . . (רן) אגב, שווה לציין שזה טיעון שונה מהטיעון שלך, אורי - אתה אומר “חסכת דולר? תשתמש בו להשקעה ב-Human Capital או במשהו אחר”, והוא לא בא ואומר את זה . . . (אורי) לא, אני חושב שזה פשוט . . . אתה יודע, אנחנו מדברים פה על מכפילים לווליואציות (Valuation), אז מכפיל לווליואציות - המשקיעים בוחרים על מה הם שמים את המכפיל . . . [כאן יש הסבר אפשרי מעניין]אז לפעמים הם שמים את זה על הגדילה, לפעמים הם שמים את זה על ה-Gross Revenue - והרבה פעמים הם שמים את זה על ה-EBITA, אז . . . (נתי) אז פה הוא מדבר על זה שהרבה פעמים מודדים ARR, בלי בהכרח למדוד את הדברים האחרים . . . (אורי) נכון . . . (נתי) . . ואם אתה מראה גדילה משמעותית ב-ARR, הווליואציה שלך בהכרח גדלה, גם אם אתה עושה את זה על חשבון זה שאתה מקטין את הרווחיות שלך . . . (אורי) . . . אני אומר שיש שווקים מסויימים ויש סגמנטים של שוק, שבהם דווקא מסתכלים על ה-EBITA ועל הגדילה ב-EBITA - וזה מדד לריווחיות ול”בריאות החברה”.(רן) אורי - תזכיר למאזינים: EBITA? מה זה?(אורי) תכל'ס - זה הרווח הנקי . . .(רן) הרווח הגולמי?(אורי) לא - הרווח הנקי . . . Earnings before interest, taxes, and amortization (EBITA) וכל הקללות האלה ש . . .(רן) כמו שאומרים בקופה ראשית - מה שנשאר בסוף בכיס . . . זה מה שהרווחנו.(אורי) כן . . . אז ה-EBITA הזאת היא מדד ל”בריאות ה-Business Model” של החברה, והרבה פעמים מקבלים על זה את המכפילים - ויש לא מעט חברות שאם הן תעבירנה את . . . אתה יודע מה, אני לא יודע . . . אבל ההבדל בין לרוץ ב-Cloud או לרוץ On-Premise הוא בין EBITA בריאה לבין אפס EBITA . . . (נתי) כן - אבל אם אתה מסתכל, אז רוב השוק של ה-Unicorns, שעכשיו זה השם הנפוץ ביותר במדינה, פחות או יותר, כשאתה מסתובב היום בהרצליה ובתל אביב . . . (רן) עוד חודשיים, כשנקליט את זה, זה יהיה כבר יהיה תטא-קורן . . . (נתי) כן . . . אז בסוף יש לך חברות, בסופו של דבר, כמו Uber, שאם הייתה מודד אותה על EBITA, לא היית נותן להם את הווליואציה שיש להם היום, אתה מסכים איתי, נכון? כי המודל הוצאות והכנסות שלהם לא היה, לפחות עד לא מזמן, לא כזה הגיוני . . . [ה-understatement הגדול בהיסטוריה?]מן הסתם, רוב החברות שהן יוניקורן, לפחות עד השלב שהן מגיעות לזה שהן יוניקורן ומתחילות להימדד על זה, הן נמדדות על ARR ועל גידול ובשלב הזה הן אפילו, חלקית [חלקית?] הפסדיות . . . (אורי) אתה יודע מתי חברות מתחילות להימדד על EBITA? במשברים . . . (נתי) נכון . . . אז אנחנו בבועה, לצורך העניין, וזה איזשהו מדד מסויים, כנראה, גם של בועה - אבל היא לא אומרת שהיא הולכת להתפוצץ מהר . . . [לא אומרים משפטים כאלה . . . לא קראת קומיקס אף פעם?]יש איפשהו איזה כסף אינסופי שאני לא מצליח להבין אותו - טפו-טפו, כן - אבל אני חושב שזה היה, כשאני ככה “מקזז את זה”, זה היכולת להסתכל לא על “כמה עולה לי שרת ב-Datacenter שלי וכמה עולה לי שרת בענן” ולמדוד את זה שם ו”להישאר במגרש של הגרושים”, לצורך העניין - אלא להביא את זה פתאום לחברה . . . זה הפך את זה ל-”Trillion Dollar Paradox” מ-”Million Dollar Paradox”.וזה, פתאום, שם איזושהי מראה של “אוקיי, מה קורה פה? . . . “ יש פה משהו לא הגיוני.(רן) אז נסכם, רק שנייה, את המאמר הזה של Andreessen Horowitz, שאני ממליץ, אגב, לקרוא, למי שמתעניין - אנחנו ממש נסכם אותו בקצרה - הוא בא ואומר “חבר'ה, מאיזשהו גודל מסויים, אתם לא צריכים להיות בענן - אתם צריכים לעשות Repatriation ל-Service-ים שלכם, זאת אומרת - לקחת את ה-Service-ים, להוריד אותם מהענן ולבנות אותם ב-Datacenter שלכם”.בא Corey Quinn - וסותר אותו:הוא בא ואומר “תראו חבר'ה, זה לא נכון, כל הסיפור הזה - זה אולי נכון במקרה של Dropbox”“למה זה נכון במקרה של Dropbox?” אז . . .(נתי) במקרה של Dropbox הוא אומר ש”מדדתם לא נכון כי הסתרתם חלק מהמידע” . . . (רן) יכול להיות - אבל הוא אומר למה זה: אולי זה נכון במקרה של Dropbox - אני אזהר פה - כי אומר ש”Dropbox סיימו לחדש” . . . . זאת אומרת, אין להם כבר פיצ'רים חדשים להוציא, הם הגיעו פחות או יותר לתקרת הזכוכית מבחינת איפה שהם יכולים לגדול ולחדש - אז כל מה שנשאר להם זה להיות יותר Efficient . . .אז אם אתם חברה כזאת, שכבר אין לה לאן לגדול - “סבבה, תלכו להיות Efficient” [זה מגיע עם תנועת יד ספציפית?]אבל לרוב החברות בעולם - יש להן עוד הרבה מאוד לאן לגדול, אז יותר נכון לגדול, גם אם זה על חשבון ה . . . EBITA? איך אמרנו?(נתי) כן . . .(אורי) אה . . . (רן) זה הטיעון שלו . . . (אורי) כן, אתה יודע - ואז בא נתי שלום ואומר, בצדק אני חושב - תקן אותי אם אני טועה . . . Dropbox לא גמרה לחדש, בסדר? אין חברה חפצת-חיים שגומרת לחדש, כולם מחדשים.וה-Sweat-spot הוא לדעת לתמוך בתשתית שנותנת את האג'ליות בחידושים - ולדעת לעשות אופטימיזציה ל-Core Business, על המקום שבו ה-Economy of Scale הוא מאוד מאוד חשוב.(נתי) אז א' - במקרה של Dropbox, יש שם איזושהי אנומליה שהוא מתאר, שבעצם כשאתה מסתכל על הספרים וכשאתה מסתכל על ההוצאות שלהם על Infrastructure אז לכאורה זה נראה נמוך, אבל מאחורי זה מה שמסתתר זה סעיף אחר - של הוצאות על אנשים והוצאות על Datacenters ,שלא נכללו בסעיף ההוא, והם מופיעים פשוט בסעיף אחר . . .ואז הוא אומר שיש פה משהו שבסך הכל המספרים הם לא כמו שהם מתארים. זה עדיין יותר זול, אבל . . .(אורי) נתי - בתור אחד שמכיר את המספרים מהחברה שלו וזה . . . - ההוצאות על האנשים שתומכים ב-Infrastructure הזה הן Fraction of a fraction ממה שעולה . . . עליות של Cloud. זה טיעון של מישהו שלא בדיוק יודע איך עובדים ב-Cloud . . . (נתי) אז זה לא סותר את התיאוריה, זה רק אומר שהמספרים הם לא “כצעקתם”, מה שנקרא.לכן אני שם את זה שנייה בצד ואומר - יש כאן טיעונים, צריך להכיר אותם, וכנראה ש-Dropbox, מה שנקרא, “מינפו את הפוזיציה” הרבה יותר ממה שהיא באמת, אבל הגרעין של הטיעון - הוא עדיין עומד עליו . . .זה הניתוח שלי לפחות - שלמרות כל הרעש על זה והביקורת שלעשות Repatriation זה דבר שהוא גם מאוד יקר ופוגע באג'יליות - בסופו של דבר, אני חושב שהטיעון המרכזי זה Efficiency vs. Velocity היום חברות נדרשות ל-Tradeoff הזה, וזה הגורם העיקרי.עכשיו - יש הרבה מאוד דרכים, ואולי נדבר גם על זה, לעשות Efficiency בתוך הענן - לפני שאתה עושה Repatriation, בעצם, Repatriation הוא אחד האמצעים לעשות אופטימיזציה - מאוד קיצוני יחסית, ויש הרבה יחסית שאיחרו את הרכבת, או שלחילופין המהלך הזה יהיה להם מאוד מאוד יקר וכואב, למי שלא בנה את זה מראש, כמוך [אורי], או למי שלא תכנן את זה - זה לא יהיה לו טריויאלי.אבל הטיעון המרכזי הוא Efficiency - אני צריך לייעל את הצורה שבה אני צורך משאבים ואני צריך להסתכל על איך אני צורך משאבים בצורה מאוד נכונה.עכשיו - למה זה מורכב? כי אם אתה מסתכל היום מה הן האפשרויות שלי להגדיל את ה-Efficiency בענן, אז בוא נסתכל על הפתרונות שיש לי . . .יש לי פתרון אחד, שזה כל מיני כלים שנותנים לי Cost . . . מה הבעיה עם זה?א' - זה בדרך כלל After the factב' - ההמלצות שאתם תראו אם תשתמשו בכלים שנותנים לכם Cost מקסימום יגידו לכם “הנה Alert על איזה מישהו טיפש שהשאיר את המכונה שלו ולא סגר את זה!”אוקיי, סבבה, מתישהו אתם לומדים גם לנהל את ה-Policy הזה - אבל . . . .לפעמים הוא גם יגיד לך אם אתה מחזיק מכונות גדולות ואתה יכול להקטין אותן וכל מיני דברים כאלהאבל אתה תמצה את המהלך הזה יחסית מהר, ה-Value של האינפורמציה הזו הוא די יגיע למיצוי בתוך כמה חודשים, וכבר הגעת למיצוי של מה שאתה תקבלואז אתה תתחיל לקבל הרבה מאוד “רעש” כזה, כמו בחברות Security - המון רעש על Alert-ים, וזה בעצם יהיה רעש ואתה לא תקשיב לזה בכלל, וזה יכנס לך ויצא מהאוזן השנייה.אז זה כל החברות Cost . . .הדבר השני שיש לנו זה כל החברות אוטומציה - מה הבעיה עם אוטומציה? נתתי דוגמא דווקא מ[יובל] נח-הררי, שמאוד אהבתי את ה . . . מאמר אחר לגמרי, לא קשור בכלל לנושא הזה . . (רן) “מאזיננו יובל” . . . (נתי) כן, יובל נח-הררי, חבר שלי מהמסטינ”ג . . . לא, סתםיש לו אגב פודקאסט מאוד מעניין עם [מארק] צוקרברג, גם נושא לשיחה אחרת . . .אז הוא בא ואמר משפט שאני עכשיו נוהג לצטט אותו הרבה - “כלי בסוף תלוי במה שאתה עושה איתו” . . . והוא נתן את הדוגמא של הסכין - שזה כלי שאתה יכול לחתוך איתו סלט ולהכין אוכל מצויין, אבל אתה גם יכול להרוג איתו . . . זה אותו הכלי.אותו הדבר לגבי כלי האוטומציה - אנחנו הרבה פעמים אומרים “אוקיי, איך אני אחסוך? אני אעבוד ל-Spot!” או “איך אני אחסוך? אני אעבור ל-Kubernetes!” או “איך אני אחסוך? אני אעבור ל-Terraform!”מה קורה בדרך כלל לחברות אחרי שהן עושות את המהלך ל-Kubernetes? אתה שואל אותן “איך היה המעבר? עד כמה זה באמת היה Efficient יותר?”אז הם אומרים לך “אג'ילי! אג'ילי! אג'ילי! - אבל ב-Cost זה Sky-rocketing . . . “למה? כי נוצרה גם, עם המעבר לכלי האוטומציה הזה, איזושהי אבסטרקציה עוד יותר גדולה ל-Cost, כי עכשיו אתה לא באמת יודע מה רץ ואיפהוגם עניין של קלות - פתאום עכשיו להרים סביבות ו-Containers ניהיה נורא קל, אז מעיפים Container-ים על ימין ועל שמאל, והרבה מאוד סביבות . . . אתה מכיר את זה גם, אני חושב . . .הרבה יותר ממה שהיית צורך קודם, אפילו ב-Monolith . . . אם תשווה את ה-Monolith שהיה לך קודם לעומת ה-microServices שיש לך היום, ואת כל הסביבות Development שאתה מריץ לצד זה, וכל ה-Overhead-ים שיש לזה . . . פתאום רואים שהעלות שלהם גדלה וגדלה וגדלה - בקצב מאוד גבוה.והסיבה היא שכלי האוטומציה באמת נותנים Efficiency - הם מביאים אותך ל-Efficiency, אבל הם גם, באותה מידה, מורידים את ה-Efficiency מעצם זה שהם עושים אבסטרקציה ו”מחביאים” את ה . . . (רן) מייצרים שכבת Overhead משמעותית, לא זניחה . . .(נתי) והיום, אין את היכולת באמת לתווך בצורה טובה בין המשתמש ל-Infrastructure - וכך אנחנו מגיעים לנקודה הזאת, ואז יש . . .(אורי) אני חושב שמהניסיון שלי, אין תחליף למישהו שמדי פעם מסתכל על ה-Cost ואומר “חבר'ה, ברחנו פה . . . בואו, תעשו סיבוב ותראו איך אתם מאפטמים . . . “[ובינתיים, ב-Pinterest . . . ](נתי) נכון - ואני אגיד לך שגם זה בעייתי, ותיכף גם נגיע לאיזשהו, הייתי אומר “Pattern של פתרון” או כיוון מסויים של פתרון, שקיים בכמה תעשיות כבר . . . (רן) זה מה שהזכרת כ”חברות ה-Cost” - חברות שמציפות את ה-Cost הבעייתי . . . (נתי) זה כמו חברות Security, באיזשהו שלב . . . כי מה הבעיה? בוא, אני אראה לך ואפרוש לך עכשיו את כל הכלים של אופטימיזציה, ואז תבין איפה הבעיה - יש לך בעצם ארבע קטיגוריות של אופטימיזציה:יש לך קטיגוריה אחת שזה ברמת ה-VM, ה-Compute וה-Storage - אז אתה יכול ללכת מ-Spot ל-Reserved ל-VM יותר גדול . . . עם GPU, בלי GPU, כל מיני - אופטימיזציות ברמה הזאת, של ה-Infrastructure.יש ברמת Policy - שזה בעצם להגיד “אוקיי, מכונה שלא השתמשת בה, אתה יכול להרוג”, “אם זה ב-Development תעשה ככה” - ויש כל מיני נושאים של מדיניות.ויש ארכיטקטורה - Kubernetes ו-Containers, אם זה Fargate או לא Fargate, או שזה Serverless או לא Serverless - כל מיני היבטים כאלה.[עוד קטיגוריה?]ועכשיו, כשתסתכל על כל הדבר הזה, ותגיד “אוקיי, אני רוצה לעבור, למשל, מ-VM ל-Spot” - אז זה, לכאורה, פשוט: אתה לא צריך לעשות כלום . . .איפה אתה נופל? אם האפליקציה שלך היא Stateful, אז לא בדיוק בדיוק יעבוד, זה דורש שינוי ארכיטקטוני . . . זה כמעט כמו לעבור ל-microServices - השינוי הארכיטקטוני הזה הוא כבר שינוי קוד, ושינוי קוד זה כבר לא דבר פשוטזה לא שמישהו יצעק לך “אתה מאוד לא Efficient פה!” - ומחר אתה יכול להיות 30% יותר Efficient . . . (אורי) מה שאתה אומר זה שזה לא משנה אם אתה תעבור מ . . . לא יודע, מ-Cloud ל-On Premise או מ-Monolith ל-microService - עצם זה ששינית State of Mind ואתה מתחיל להיות Mindful, למודעות - זה יצריך ממש השקעה . . (נתי) בדיוק - הרבה השקעה ולאורך לא מעט זמן, כי בוא ניקח את הדוגמא הכי טובה לחברות שיודעות לעשות Scale - אלו חברות ה-Cloud עצמן . . .מה קורה בחברות האלה? הן . . .(אורי) אגב - הם ידעו כל כך טוב לעשות Scale שהן הרימו את ה-Cloud . . .(נתי) נכון . . . אבל אני אומר “איך הם עושים את זה?” אפשר ללמוד מהן, זאת אומרת - יש להם על כל צוות, על כל מוצר, כשהם עושים S3, הצוות הזה לא עובר רק לפתח את הפיצ'ר הבא אלא הוא עובד מאוד מאוד חזק בלמצוא פתרונות שמורידים את ה-Cost עבורםולצורך העניין מגדילים את ה-Margin ואת כל האופטימיזציות שיש אחרי זה, לאורך זמן - משקיעים בזה המון.זה לא שזה קורה “כדרך אגב”, זה לא שמישהו אומר להם “אה, ה-Cost שלך יקר, בוא תוריד אותו” - ופתאום משקיעים בזה, עושים שינוי של Priorities ומשקיעים בזה.זה חלק מאוד מאוד משמעותי בהתנהלות שלהם, זה חלק חלק מאוד משמעותי ב-Incentives שלהםזה יכול להיות חלק מאוד משמעותי באיך שהם מתכננים את ה-Roadmap-ים שלהם - וזה פיצ'ר לכל דבר ועניין, והוא מקבל את אותה עדיפות כמו פיצ'ר שהוא Customer-facing . . .אז זה, קודם כל, משהו בצורת ההתנהלות שצריך להיות מאוד שונה - ולהבין שזה On-going, זה קשה, אין פתרונות קסם פה ולא יבוא איזה “פתרון מהצד” ויפתור לכם את הבעיות. זה כל הזמן צריך להיות . . . (רן) זאת אומרת, אתה אומר ש”Cost צריך להיות פיצ'ר”, לצורך העניין? . . .(נתי) כן . . (רן) “אל תייצר לי פיצ'ר שנותן ל-User לעשות File Upload - תייצר לי פיצ'ר שנותן ל-User לעשות File Upload בפחות מ-5 מילי-סנט . . .”(נתי) בדיוק - ותמדוד את זה, ותתגמל על זה . . . כמו שאתה מתגמל על דברים אחרים.ואז זה הופך להיות, ברמת ההתנהלות, זה הופך להיות משהו חשוב שה-Business מודע אליו - ואז אתה מייצר את התרבות הזאת, שאתה נותן לזה Attention . . . - וזה, לכשלעצמו, עדיין לא מספיק.(רן) אבל אז, זאת אומרת, אנחנו חוזרים ל-Tradeoff שהצגת בהתחלה - האג'ליות מול ה . . . סליחה - ה-Velocity מול ה-Efficiency: ברגע שאתה עובד על ה-Efficiency, אתה באותה רגע פוגע ב-Velocity . . . (נתי) אז נתתי את הדוגמא של חברות ה-Cloud - הם מצאו פתרון לזה . . . אז הם באו ואמרו - ובואו נלמד מהם, כי אני חושב שיש כאן איזה בית ספר שאפשר ללמוד ממנו.אז עובדה שהם משקיעים בזה הרבה, וכן - זה בא על חשבון Velocity, לכאורה.אבל זה לא באמת בא רק על חשבון Velocity, כי זה פיצ'ר - ושוב פעם זו הסתכלות מאוד לא נכונה על Efficiency . . . (רן) לא, אני הייתי אומר שזה בא על החשבון - וזה בסדר: ברור שזה בא על חשבון זה, כי את זה הבנו, וזה Tradeoff ואי אפשר להתחמק מזה . . .(נתי) כשאומרים ש”זה בא על חשבון”, אני אומר . . . הרי מה המטרה שלך בפיצ'ר? בסופו של דבר, אתה מביא פיצ'ר כדי להגדיל ערך - אבל פה גם הגדלת ערך! רק במימד אחר . . . [איפה אסימוב כשצריך אותו?]שפחות רואים אותו ופחות יודעים עליו - רואה אותו רק מי שמסתכל בסוף על המספרים . . . אתה פחות רואה את זה . . . אתה לא יכול לשים איזה PR ולהוציא על זה Announcement . . .(רן) דרך אגב, מכל הסיפור הזה של מדידת עלות בענן, של אוטומציה של עלות וכו' - יש לזה כבר שם, אז בואו ניתן לזה אתה השם: היום קוראים לזה FinOps [!], לא יודע אם כבר ראיתם או לא . . . ויש כמה חברות בתחום הזה וגם כמה חברות ישראליות . . . אז אם נתקלתם בשם הזה שנקרא FinOps - אז זה כל התחום של עלויות בענן ו”ייעול בענן”.(אורי) אני רציתי להגיד עוד משהו על האג'ליות של המוצרים החדשים וזה . . . אתם יודעים, זה סוד כזה שאולי קצת לא מדברים עליו, אבל נתקלתי לפחות בחברה אחת שאומרת “רגע! אני באתי, ייצרתי מוצר שהוא SaaS בענן, ובעצם אני עשיתי את ה-Trail & Error, אני בניתי . . . וברגע שהוכחתי שזה עובד וזה הצליח לי - באו AWS והעתיקו אותי ו . . . “(רן) הקלטנו על זה פרק [קוסמי! 365 Carburetor 26 - open source politics], אבל . . . זה נכון, וזה נושא כאוב ומעניין . . .(אורי) אז אתה אומר, כאילו - באיזה Innovation בדיוק הם משקיעים, אם הם . . . וואלה, יש חברות אחרות שלוקחות את ה-Cost של ה-Trail & Error, ואז הם פשוט באים, עושים את אותו הדבר ו . . . (נתי) מיקרוסופט המציאו את הדבר הזה, כשעוד הייתה להם את מערכת ההפעלה והם עשו את הדבר הזה . . .וכן, זו מציאות שאני חושב שלא תשתנה, כנראה, ועל זה יש לנו פחות שליטה, אז אני פחות מתעסק בזה.כולם חווים את הכאב הזה - וזה כואב וזה מעצבן, ואני לא רואה את זה משתנה בדינמיקה הזאת יותר מדי . . .(אורי) אני רוצה לומר שרוב ה-Cost שיש ביצירת Innovation היא בטעויות . . . (נתי) נכון, אז אתה אומר שבהגדרה השלב הזה הוא עוד לא Efficient כי אתה לומד מטעויות . . .(אורי) כן . . .(נתי) אז זה סבבה - אבל בוא נלך שנייה על איפה אני חושב שכן יכולה להיות הקפיצה הבאה, ויש פה, לדעתי, איזושהי בשורה שאפשר כן לצאת ממנה בשיחה הזאת, ולפחות . . . חשבתי על זה הרבה והגעתי לאיזושהי תובנה בהקשר הזה ואני אחלוק אותה איתכם:התובנה באה ואומרת כזה דבר - אם אנחנו מסתכלים על הנקודות Scale בעולם ה-Cloud, אז יש כל מיני נקודות, שראינו את הקפיצה פתאום - נקודה אחת זה כשיצאו ה-VM-ים והפכנו מכונות פיזיות לווירטואליות, ובנקודה הזאת בכלל נוצר הענן - בלי זה בכלל לא היה לנו היום ענן ולא היינו מדברים בכלל.הנקודה השנייה הייתה המעבר ל-Containers ואחר כך ל-Kubernetes, שבעצם הביאו לנו את היכולת לנהל מערכות מאוד מורכבות וגדולותיצאנו מ-VM-ים ל-Container-ים וזה היה, דרך אגב, גם נקודה סינגולרית מאוד מאוד משמעותית.אחרי זה יש את ה-Infrastructure-as-a-Codeוהיום, אחת הבעיות לאופטימיזציה - ואני בא קצת מעולם של Databases אז אני מכיר את זה טוב - זה מאוד קשה לעשות אופטימיזציה כשהעולם שלך הוא Security Group וכשהעולם שלך זה VPC, וכשהעולם שלך הוא כל מיני נקודות כאלה ב-Infrastructure . . . כי ככל שאתה מסתכל על “הפסיפס” ואתה מנסה לעשות אופטימיזציה, מאוד מאוד קשה לך לראות את התמונה הגדולה ולראות איפה “ה-Pocket הכי גדול שלך” ולעשות את האופטימיזציה שם . . ואנחנו קצת תקועים פה . . .עכשיו, לדעתי צריך להיות . . .(אורי) “תקועים בפרטים”, אתה אומר . . .(נתי) תקועים בפרטים, בדיוק - ולכן ה-Complexity הוא זה שמייצר את המורכבות, שלא מאפשרת לעשות את ה . . . תיארתי כל מיני שיטות לאופטימיזציה - זה יכול להיות Policy זה יכול להיות לעשות Scaling או שזה Spot, שזה היכולת לשלוט ב-VM-ים - אבל היכולת ליישם את זה היא מאוד מאוד קשה.ואז, אם אני לוקח את זה הלאה, אני אומר “אוקיי, חייב להיות פה משהו נוסף שמשנה את המשחק בעוצמה של המעבר מ-VM-ים ל-Container-ים, בעוצמה של המעבר מ-Container-ים ל-microServices ול-Infrastructure-as-a-Code”והדבר הבא שאני מסתכל עליו זה היחידת בניין - “Templatized Environments” . . . היום, אני כבר לא מסתכל על Container, או אפילו על microService - יש לי Template לכל דבר.היום אני אמצא Template ל-Machine Learning ו-Template ל”איך אני עושה Monitoring?” ו-Template . . .יש לי המון Tamplte-ים מסוגים שונים וחלקם כתובים ב-Terraform וחלקם ב-CloudFormation וחלקם ב-Azure Hub, חלקם בשפה אחרת - אבל אני כבר יכול להסתכל על Building Blocks יותר crossgrade - מערכות . . נגיד “RDS כמערכת” - לא מעניין אותי איך ה-RDS הזה בנוי, אני מקבל אותו כיחידהועכשיו, כשאני מסתכל עליו כיחידה, אני מנסה לאפטם (Optimize) אותו כיחידה ולא את כל ה-Bits וה-Bytes - את זה כבר מישהו אחר עשה.וזה מאפשר לי, פתאום, להסתכל על אופטימיזציה של מערכותולאן זה מביא אותי? זה . . . (רן) רגע, אני לא בטוח שאני איתך . . . בוא, אני אגיד את זה בשפה שלי ואתה תגיד לי איפה אני טועה:אתה אומר שיש כל מיני סוגים של Workloads - נגיד Database רלציוני זה סוג אחד של Workload ו- Web Service זה סוג אחר של Workload (נתי) Kubernetes Cluster זה גם . . .(רן) אוקיי, נגיד Spark או Big Data Processing זה גם סוג אחר של Workload . . . (נתי) נכון . . .(רן) אז בוא נשים כל אחד מה-Workloads האלה “בתוך קופסא” - נגיד שניתן להם APIs וניתן להם שם - ועכשיו, את כל אחת מהקופסאות האלה אנחנו נוכל לאפטם, בצורה שהיא לא שקופה החוצה, זאת אומרת - ה-API אליהן לא ישתנה.לצורך העניין, אם אני שולח בקשה ל-Database אני תמיד אקבל תשובה - ולא חשוב איך הוא בנוי, בין אם זה ממומש ב-SQL או שזה ממומש ב . . .(נתי) בוודאי . . .(אורי) אבל הקופסא היא Optimized . . . (נתי) הקופסא Optimized - אבל כשאנחנו אומרים “Optimized”, זו אף פעם לא אותה האופטימיזציה - ועכשיו תיכף נגיע לשלב הבא . . . אז השלב הראשון היה להגיד, כדי בכלל להגיע לרמה הבאה, אנחנו צריכים לעלות קומה - כמו שעשינו עד עכשיו, אנחנו צריכים לעלות קומה בגרנולריות (Granularity) וביכולת שלנוהאבן-בניין צריכה להשתנות - מפסיפס ללבנים ומלבנים לבלוקים ומבלוקים לאיטונג, או לא יודע איך נקרא לזה . . .אז כשהאבן-בניין גדלה, אז אני יכול להסתכל על גורדי-שחקים - כשאני עובד עם פסיפס, אני לא אבנה גורד-שחקים, מקסימום אני אבנה קומה אחת . . . אז האבן-בניין היא נקודה מאוד קריטית פה.השלב השני זה באמת מה שהתחלת לגעת בו - זה היכולת לעשות Decoupling בין ה-Workload ל-Infrastructure.כי ברגע שאני יכול לעשות את ה-Decoupling הזה, אני יכול באמת להגיד עכשיו על כל יחידה שהיא אופטימלית - ועכשיו אני יכול להדביק את ה-Workload ליחידה הכי אופטימלית לצורך הזה . . .ואם אני עושה את זה סטטית, אז אני אהיה Semi-optimal, כי קיבלתי את ההחלטה בנקודת זמן מסויימת ולא בטוח שהיא תמיד תיהיה נכונה לאורך זמןכי המשפט הזאת של “אופטימלית” הוא דבר דינאמי - כי ה-Load משתנה. (אורי) אני זוכר שהקלטנו פעם פרק עם חברה . . . אני לא זוכר איך קראו לה, היא ישבה פעם ביקנעם [עדיין], זה היה שם משהו עם ”ז' באדר ב'” או משהו כזה [א'] . . .(רן) כן, חברת Storage בשם Zadara [זה - 372 Zadara] . . .(אורי) אבל הם נותנים פתרון Storage לכל העננים, לכל ה-API-ים של העננים למיניהם - ושאלנו אותו איפה הוא בתכל'ס מאחסן - והוא ענה ש”אנחנו לא מאחסנים בענן - אנחנו יושבים ליד העננים וכו', אבל האופטימיזציה שלנו ל-Cost היא בזה שיצאנו החוצה, ואנחנו נותנים, לצורך העניין, Building Blocks הרבה יותר גנריים של ‘הנה - Storage!', פתרון Storage אופטימלי” . . .(נתי) נכון . . .(אורי) אז אני אומר - אוקיי, למה ש-RDS לא יהיה ככה? למה שכל ה-Building blocks האלה . . .(נתי) אני אומר שאפילו אם זה בענן, אפילו אם זה בענן - ושוב פעם פרשנו “מיליון אופציות” על להריץ את אותו הדבר בענן, יש לך רק על Kubernetes את Fargate ויש לך את . . .(רן) אפשר לחזור לדוגמא של Dropbox - יש להם כמה סוגים של Services, ואחד מהם זה Storage.יש להם גם Services מסוגים אחרים - יש להם User Interface, יש להם . . . (אורי) יש להם Docs! . . . [הפנייה מעגלית ל-Paper](רן) יש להם Docs . . . יש להם הרבה סוגים של Services, והם לקחו את אחד מהם - רק את ה-Storage - בודדו אותו, ורק אותו הוציאו מחוץ לענן . . .(נתי) אז אני אומר . . . (אורי) אני חושב שבתור חברה אתה רוצה לאפטם את החלקים הגדולים של ה-Cost model שלך - גם Netflix, עם כל הסיפור של “אנחנו בענן . . . “ - את ה-CDN הם הוציאו החוצה.(נתי) אז אני מסתכל על זה קצת יותר רחב - אני אומר שזו אחת האופטימיזציות, כנראה המשמעותית יותר, אבל לא לכל דבר היא מתאימה ואני חושב שזה די ברוראבל יש עוד הרבה אופטימיזציות, הרבה דברים שלא דורשים בהכרח דברים כאלה קיצוניים או דרמטיים - ופרשנו פה כמה מהדברים האלה.אבל היכולת שלי להשתמש בהם - זה החלק המורכב: אם אני אהפוך את היכולת שלי להשתמש בהם ליותר פשוטה, אז אני אוכל להגיע לנקודה הזאת.ופה אני אומר - אם אני יכול להגיע לאופטימום, שזה The right infrastructure for the job, ואני אגיד עכשיו איזה משפט שאני חושב שכל אחד יסתכל על העולם שלו ויבין על מה אני מדבר:היום, כמה פעמים אנחנו בעצם מריצים את ה-Workload שלנו מסיבה שהיא "Least-Common-Denominator”?זאת אומרת שאת ה-Production system שלנו, למשל, אנחנו נריץ הרבה מאוד Dev ו-Test ועוד כל מיני דברים על אותה Production Environment.עכשיו - אני לא צריך ל-Dev ו-Test את ה-SLA של RDS - אני יכול סתם להשתמש ב-Database לצורך העניין . . . אני לא צריך Network מורכב, אני לא צריך עוד המון דברים, ברמת ה-SLA, שיש לי היום בסביבת Production . . . אבל מסובך לי לייצר עכשיו סביבה שהיא ייעודית ל-Development אז אני לא אעשה את זה - ואז אני נשאר במכנה המשותף הזה שצריך לשרת הרבה מאוד Workloads.אז בהגדרה, אני לא Optimized . . .(אורי) אלא אם כן אתה מגיע למצב ש”You couldn't care less”, אוקיי? . . . (נתי) תסביר לי את המשפט הזה, איך זה יכול להיות? . . .(רן) כשזה גם ככה לא עולה כלום . . . (אורי) לא - כשזה שקוף לך איפה זה רץ . . .(נתי) לא - אז השקוף זה תנאי, אתה צודק . . . השקוף זה תנאי, אבל אני צריך בסוף להגיד, וניתן את הדוגמא של Dev-Production כי זו הדוגמא שהכי קל לאנשים להבין אותה - אם אני יכול, לצורך העניין - אני רוצה עכשיו רק לבנות פיצ'ר ולבדוק אותואני לא צריך עכשיו שתריץ לי EKS בשביל הדבר הזה . . . אם תיתן לי Kubernetes שרץ לי על VM, או minikube או K3S או Whatever - את אותו API של ה-RDS, שזה בעצם Postgres, את אותו Storage של S3, שזה יכול להיות MinIO, בסביבה שהיא Sandbox - סבבה לי.אני יודע לעשות את זה . . . תמיד יהיו לי את ”החיצים החוצה”, כי אני לא אריץ את הכל באותו VM - אבל אני מקבל פה מה שנקרא היום, ה-Buzzword החדש בעולם של ה-DevOps - זה “הדמוקרטיזציה של ה-Development”.היכולת שלי באמת לא להיות תלוי ב-Shared Environment, להגיע ל-Agility, להגדיל את כמות הטסטים וכל מיני דברים מהסוג הזה.אבל אני יכול ממש לבנות Stack, די בקלות, במיוחד כשיש לי Building blocks שחוזרים על עצמם, שזה בדרך כלל Kubernetes ו-Terraform ו-Ansible - כל מיני יחידות כאלה שהן . . . אני יודע כבר למדל אותן בתוך כאלה “קופסאות קטנות” - לקופסא גדולה.אני יכול להגיד עכשיו שאני מריץ את זה ב-Dev - אני לא צריך GPU, אני יכול להריץ את זה בלי GPUוזה, דרך אגב, ירוץ יותר לאט - אבל אני לא חייב את המכונה עם ה-GPU ה-High-end כדי לבדוק את הפיצ'ר עצמו ברמת הפונקציונאליות.עכשיו, אני זורק כל מיני דברים - ברור שזה לא יתאים להכל, אבל העיקרון הוא שאם אני יכול כן להגיע למקום שבו אני יכול להצמיד את The right infrastructure for the workload, אני אגיע למקסימום אופטימיזציהועכשיו יש את המציאות - אני אף פעם לא אגיע ל-100% של זה, כי זה תמיד מסובך, אבל אני יכול להגיע קרוב לזה.וככל שאני אגיע קרוב לזה, אני אהיה קרוב לאופטימום.[על פניו, נראה שבאינטל עכשיו טוענים שהם יכולים לעשות משהו דומה ברמת ה-Hardware . . .]וחלק מה-right infrastructure for the workload זה גם ה-Repatriation - להריץ בזה . . . כי ל-Workload הזה, למשל, של Storage או של CDN, המשמעות של “The right infrastructure” זה On-Prem . . . ולמשהו אחר, שזה Dev Environment, זה דווקא לא On-Prem, כי זה משאב שהוא מאוד מתאים ל-Production use-case ולא מתאים ל-Dev Use case.(אורי) אז מה שאתה אומר זה שב-Dev אני משתמש בפחות Load - אני צורך פחות משאבים . . .(נתי) . . זה גם לא ה-SLA שלי, שזה העיקר - ה-SLA שלי הוא בכלל . . . אני לא צריך SLA של Production . . .(אורי) נכון - ואני יכול לנסות את זה גם בסביבה “יקרה”, כי אין כאן Economy of Scale, להיפך - יש פה Economy of Velocity . . .(נתי) נכון . . . וכמה עושים את זה?(אורי) אני חושב שזה הפתרון, נגיד . . . לא יודע אם זה הפתרון, אבל זה השימוש הנכון בעולם כזה - שאנשים מבינים שאין דרך אחת: יש כמה דרכים, יש כמה פתרונות, וצריך To use the right tool for the problem.וצריך להבין - Cloud זה Optimized ל-Velocity . . .(נתי) על חשבון Cost אפילו . . . (אורי) על חשבון Cost - כי Cost לא מעניין אותנו בשלב הזה, הוא . . . ה-Velocity מעניין אותנו ולא ה . . . ו-On-Prem, לצורך העניין, או סביבות יותר אופטימליות - זה במקום שאתה צריך Economy of Scale.(נתי) אז אני מתמצת את זה בזה שאני אגיד ש-The right infrastructure for the Job הוא האופטימום . . . עכשיו שכל אחד יעשה את החושבים אצלו ויגיד “כמה באמת אני קרוב לאופטימום הזה?”אני חושב שהרוב יסתכלו ויגידו “וואו, אני רחוק שנות אור מהדבר הזה - אבל יש לי פה מקום אחד שאני יכול להגיע לזה . . .”שזה, למשל, Dev-Test, שזה משהו שאני מתחיל לראות כאיזשהו Pattern שמתחילים להתמודד איתו . . .(אורי) אבל Dev-Test זה לא אצל מי שעושה Repatriation . . . (נתי) לא לא לא . . . (אורי) ה-Repatriation . . . (נתי) אמרתי - ה-Repatriation, למי שלא עשה את זה כמוך, בהתחלה - זו עצה מצויינת, מאוד קשה ליישום . . .יהיו כאלה שבאמת יש להם Workload שהם יודעים כבר לאפיין אותו טוב וה-Benefit הוא כל כך גדול שהם יהיו מוכנים ללכת את ה-Journey הזה והם יעשו אותו, אבל זה יהיה במקרים מאוד מאוד ספציפיים - וב-Scale מאוד מאוד גבוה . . . (רן) אבל בואו נזכור שזה לא צריך להיות All-or-Nothing . . .(נתי) נכון - זה אחד הבילבולים . . . זו אחת הטעויות, לדעתי, גם בכתיבה של המאמר - שהוא שם את כל ה-Bucket על Dropbox, אז כאילו אנשים יצאו על זה ואמרו “רגע! אבל אני לא Dropbox, מה זה אומר?”ואני חושב שהעיקרון שלו היה Efficiency ולאו דווקא Repatriation . . . (אורי) אני חושב שיש פה כמה מפתחות, ואתה יודע - אני עכשיו מחליף רכב להיברידי-נטען, וכשאני מסתכל על כל הרכבים החדשים בשוק - אין כבר מנועי בנזין “נטו” . . . יש היברידי והיברידי-נטען, וכבר מתחילות להיכנס חשמליות ובעוד 10 שנים - זהו.אני חושב, והמאמר הזה היה פוקח עיניים, למי שלא נפקחו לו העיניים עד עכשיו . . .(נתי) לא אמרת “אמרתי לך” . . . (אורי) נכון . . . (נתי) הייתה לך פה הרמה להנחתה עכשיו . . . (אורי) . . . ואנחנו נתחיל לראות, כמו שיש את כל החברות ש”מעבירות ל-Cloud”, אנחנו נתחיל לראות חברות שעוזרות לעשות Repatriation - והמפתח פה הוא ידע.זה מסוג האומנויות שנשכחו, והמפתח פה הוא ידע, ועם הידע הזה מגיעה גם הקלות - כמו שניהיו מלא מוצרים שהופכים לך את המעבר ל-Cloud לקל, אז יהיה גם ההיפך. ואני יכול להגיד שגם, אתה יודע - ב-Outbrain הגענו למצב שזה לא משנה למפתח איפה זה רץ, חוץ מזה שאנחנו יכולים לדאוג לעניין של העלות - הוא פשוט את ה-Deployment יעשה ל-Datacenter X או ל-Datacenter Y וכן - Datacenter X נמצא ב-Cloud, וזה אותו Deployment . . . (נתי) ואני אומר שאפשר להגיע למקום עוד יותר גבוה מזה, במרחק נגיעה ממה שאתה אומר עכשיו - שהוא גם לא יצטרך לדעת באיזה Datacenter זה רץ - הוא פשוט יגיד “אני רוצה Dev Environment”, ואתה תדע להגיד לו מה ה-Environment המתאים“אני רוצה Production Environment ואני רוצה Machine Learning” - ואני אגדיר לו את ה-Environment הנכון עבורו . . . הרבה פעמים זה סוג של . . .(אורי) . . . סביבה זה . . . יש לנו ב-Datacenter אחד סביבה כזו וסביבה כזו . . . (נתי) אפשר, בגישה הזאת, כשהולכים איתה, אפשר ממש לגדול ברמת Efficiency - בשנייה שאתה מצליח לעשות את ה-Decoupling הזה, אז על הציר הזה, שבין ה-Workload ל-Infrastructure יש המון המון מקום לחוכמה.יש משפט, שהרוב לא יגיעו אליו כי הוא ממש בסוף המסמך, ממש למטה, שהוא מסכם את זה ככה: The biggest potential זה חברות שיצליחו לפצח את הממשק בין ה-inefficient code ל-Infrastructure - ושם טמון הפוטנציאל הגדול ביותר.למה שם טמון הפוטנציאל הגדול? כי שוב פעם - אנחנו היום מסתכלים על Security פה ו-Infrastructure פה ו-VM פה - ו-Kubernetes worker node כזה או Kubernetes worker node אחר - וזה העולם שלנו.ושם גם פחות או יותר, כשאנחנו מדברים על אופטימיזציות, אנחנו מגיעים עד לתקרה הזאת.אבל כשאנחנו מסתכלים על ה-End-to-End Service, אנחנו אומרים “עכשיו בוא נסתכל על כל ה-End-to-End Service, ונראה איפה הטרנזקציה של ה-User עוברת ואיזה תחנות היא עוברת בדרך ואיפה באמת התחנה שהכי יקרה לי” - אני יכול לגלות “Pocket-ים” אחרים לגמרי.ואז אני יכול להסתכל על זה ברמה של, לפעמים , ארכיטקטורה, שזו דרך להגיע לאופטימום הרבה יותר גבוהלפעמים זה יכול להיות Policyלפעמים זה יכול להיות באמת ה-Dev-Productionאפשר להסתכל על זה מהזוית הזאת, ואז לתקוף את זה מזוית אחרת לגמרי מאשר “תביא לי את ה-Cost Report ותגיד לי ,וואי, היה לך איזה User שהעלה לך איזו מכונה ועכשיו היא רצה הרבה יותר זמן מאשר הייתה צריכה להיות'” . . .(רן) בסדר, אז בוא, ככה, נתקדם לסיכום - קודם כל, הייתי חייב להגיד, נתי, שבעצם מה שאתה אומר זה ש”אם יש לך Bug ב-Design אז ז*ן ב-Debug” . . . תעשו Design כמו שצריך, או במילים אחרות - אתה בא ואומר שאם נעשה חלוקה הגיונית בין ה-Workload-ים השונים, נוכל את כל אחד מהם בנפרד לאפטם, ואם נעשה חלוקה הגיונית בין ה-Workload עצמו לבין ה-Infrastructure, אז נהיה גם אגנוסטים ל-Infrastructure ואז יהיו לנו יותר קל.בעצם ”נפתח את הדלת לעתיד”, אם נרצה . . . (נתי) האימפקט של ה-Change יהיה הרבה פחות דרמטי, וזה חוזר חזרה לדוגמא של החברות Cloudהם עושים אופטימיזציה - ואתה לא יודע בכלל שעכשיו ה-S3 עולה להם חצי ממה שעלה להם קודם . . .אתה לא יודע שעכשיו ה-EKS. . . (אורי) זו בדיוק הבעיה - שזה עולה להם עכשיו חצי, וזה לא משתקף במחיר שלך . . .(נתי) נכון - אבל זו גם הגדולה של זה: הם יכולים To continuously optimize it, אבל יש Decoupling מאוד ברור בין השירות לבין מה שאתה משתשמש בו - ולכן הם יכולים לעשות את זה והם לא צריכים להגיד לך שום דבר.ובהרבה פעמים, מה שאנחנו מוצאים זה שיש המון Coupling היום בין ה-Workload לבין ה-Infrastructure - ואז, בשניה שיש את ה-Coupling הזה, אתה תקוע.עכשיו, חברות Cloud, בשונה ממה שהם עושים לעצמם - ללקוחות שלהם הם מעודדים לעשות את ה-Coupling הזה . . .“תשתמש בכל השירותים של ה-Cloud, כי זה מאוד קל ומאוד מהיר . . . . תשתמש . . . אה! יש לי פה עוד פיצ'ר ב-EKS שאם תשתמש בו בכלל תעוף . . .”ואז אתה מוצא את עצמך במקום ש . . . “אופס, אני כבר לא יכול לזוז משם” . . . (אורי) אני לא יכול לזוז - וזה עולה לי . . . זה לא בחינם.(נתי) וזה לא רק זה - אני גם לא יכול לזוז משם, וזה המחיר היותר גבוהאני לא יכול עכשיו, אם יש לך משהו שהוא יותר יעיל - אני לא יכול להשתמש בו.אני לא יכול להשתמש בו כי אני “תפור” שם מ . . . (רן) אז נמשיך בסיכום . . . זה פרק מרתק, אנחנו מסכימים, אבל בגדול - הצגנו את מה שנקרא “הפרדוקס של הענן”, שבא ואומר שבימים הראשונים של החברה זה בדרך כלל סופר-משתלם להיות בענן, אבל באיזשהו שלב צריך לחשוב האם זה באמת המקום הנכון בשבילכם לרוץ - ולפעמים אתם כבר תקועים, זה מה שאתה אומר . . . לפעמים, אם לא השארתם לעצמכם איזשהו “פתח מילוט”, אז אתם כבר יכולים להיות תקועים, גם אם מצאתם דרך יותר יעילה לעבוד - עלות המעבר היא כל כך גדולה שזה לא שווה את זה.(אורי) ולפעמים אין ידע . . . אין ידע, וזה הדבר שמבחינתי הוא הכי חבל. ידע זה כלי, זה כח, ואנשים איבדו את השריר הזה.(נתי) הייתה לי שיחה עם אייל פינגולד מ-Check Point, והוא אמר שבאמת יש סוג-של “שני מחנות” של אנשים, כשהם מקבלים החלטות על Infrastructure - יש את אלה שבאים ואומרים “זה בענן, ב-AWS, אני לא מחפש לעשות Multi-Cloud, לא מחפש ללכת לפתרונות אחרים, הם יודעים מה שהם עושים”ויש את אלה שאומרים “לא - אני רוצה את ה-Decoupling, אני רוצה אקח באמת Elastic מ-Elastic ולא את Elastic שלהם, אני אקח DataDog ולא את ה-CloudWatch . . .” זה ממש “שתי אונות במוח” - אתה רואה ממש שני מחנות, כמו הדמוקרטים והרפובליקנים . . . זה בערך . . . העולם מתחלק, פחות או יותר, לדברים האלה.ואני אומר - אנחנו צריכים יותר את הצד של ה-Decoupling, כי המחיר של הלא-Decoupling ב-Short-term באמת נראה עם Gain מאוד גבוה, אבל ב-Long-run הוא בסוף, כמעט תמיד, מוכיח את עצמו כמשהו שתוקע אותך והוא לא משתלם.ואני חושב שזו איזושהי תובנה שלא קיימת היום - והמחנה, אני לא יודע אם לקרוא לו דמוקרטי או רפובליקני, המחנה שמוכן “ללכת עד הסוף עם הענן”, הרבה פעמים עושה את זה עם הרבה מאוד נאיביות.(רן) טוב - בנימה אופטימית זו, אנחנו מסכמים פודקאסט מרתק על עלויות ענן ו”אמרתי לכם!” . . . (אורי) אני יכול להגיד עוד משהו? . . . (נתי) יש פה רעיונות להרבה-הרבה סטארטאפים, עכשיו מהשיחה הזאת . . . למי ששמע: דברו איתנו . . . (רן) טוב - תודה רבה אורי, תודה נתי, היה מרתק, להתראות.המאמר של נתי ב-TheNewStack על Reducing Cloud Spend Need Not Be a Paradoxויש גם את ה-thread הזה של Or Hiltch על MemoryDB האזנה נעימה ותודה רבה לעופר פורר על התמלול!

Joining me today to talk business growth and help out a fellow business leader on The Virtual Hotseat is Roland Vanbuchin. Roland is a disruptor, serial Entrepreneur and Author of the Dream Selling Business. He's executed go-to market strategies, digital selling and sales enablement activities for Fortune 100 companies like Dropbox Business, BMC Software and Oracle Corporation. Today he runs VANX Digital, VANX Business Consulting and is an International Sales Trainer at the VANX Sales Academy, which empowers B2B sales professionals to sell digital and reach C-level decision makers faster by combining digital media advertising with sales enablement and personalized video messages.  Roland actually used one of these videos to get my attention and I have to say that it's without a doubt the most original, personal and most effective outreach message I've ever been on the receiving end of, so I'm a total advocate and I know you will too after today's episode.   Plus we help out another business leader on The Virtual Hot Seat where we're answering the question... “How Do I Find Qualified Leads For My Service?” Mentioned On This Episode Grab Your Free Revenue Multiplier Calculator The Growth Accelerator Implementation Programme Visit VANX Digital Connect with Roland on LinkedIn Connect with Adam on LinkedIn Get My Free Book Conversational Relationship Marketing Get More Free Business Growth Resources on The B2B Growth Think Tank Listener Gift Page  

They say hindsight's a wonderful thing, but knowing what you know now - with your wins and failures of the last decade behind you - what would you do differently if you could press a wipe-clean button and restart how you keep your tech stack secure? With big swathes of your teams and ecosystem now working flexibly, and with many set to stay that way, Brian Brackenborough, CISO at Channel 4, believes now is the time to act: “It's hard to think of any new business starting up these days without a cloud-first strategy, which gives them the jump on existing companies that have legacy services. The 2020 pandemic demonstrated how Cloud eased the transition from office-based working to Home-based working, and for those that hadn't made the jump, it's time to bite the bullet, with focus on digital security.” So, when it comes to rethinking how to keep your data, workflows and teams safe in the cloud, where do you start? With this new hybrid of home workers versus office-based teams, anyone responsible for a company's digital security faces a challenge. In this panel session, Brian is joined by Debra Okwuzi, Security and Compliance expert at Dropbox, and Nick Smith, IT & Digital Operations Director at 1,000heads, to discuss the role of cloud solutions, and how you can use them to retain trust, security and compliance with your data, no matter what's going on in the world.Speakers:Brian Brackenborough, Chief Information Security Officer, Channel 4Nick Smith, IT & Digital Operations Director, 1,000headsDebra Okwuzi, Security & Compliance Expert, Dropbox Business

It's hard to imagine that there was a time when the word “cloud” was eschewed in technology, but for Sheila Vashee, it was an imperative in the early days of Dropbox. Instead of droning on the next tech buzzword, Sheila helped Dropbox stay relentlessly focused on customer love, making sure people understood the concrete benefits of the technologies Dropbox was developing to make their lives easier and help them work more productively. In her talk with Jesse, Sheila shares what drove her interest in technology, how her early experiences at well-established brands prepared her to guide Dropbox through its leap from consumer brand to enterprise platform, and what compelled her to join Opendoor at a time when Dropbox was hitting its stride as a public company. Sheila also draws on her knowledge of today's technology landscape as an investor at Basis Set Ventures to offer a glimpse of what the future might hold for workplaces in every industry.Guest BioSheila Vashee is a Partner at Basis Set Ventures, an early stage venture fund focused on investing in the future of work. Previously, she was the VP of Growth at Opendoor, where she oversaw the marketing, partnerships, and product teams responsible for growth across the buyer and seller marketplace. Sheila took Opendoor from 4 to 21 markets and billions in GMV in a few years. Prior to that, she was the second marketing hire at Dropbox, where she launched every major product, including Dropbox Business, and helped 12x the Dropbox user base to 600m users and >1Bn in revenue.Helpful LinksSheila's podcast: Hypergrowth: The Early YearsForbes article on Sheila joining BSV Basis Set VenturesSheila on LinkedIn and Twitter

Dropbox announced recently that Dropbox Business has been recognised as a collaboration solution of choice for SMEs in Singapore under the ‘Productivity Solutions Grant’ (PSG) and ‘Tech-Celerate’ from Enterprise Singapore. James Ang, Head of Partnerships, Dropbox APAC shares more about this partnership strategy and how it can help our businesses in Singapore.  See omnystudio.com/listener for privacy information.

Neste episódio de PodCafé vislumbraremos um mundo sem papel, salvando árvores e assinando seus documentos eletronicamente. Com a presença de nossa convidada Nathalie True da HelloSign/Dropbox, dê o play para um bate papo divertido sem gastar nenhuma folha de papel. https://podcafeti.com.br/Figo INC seu parceiro Dropbox Business no Brasilhttps://www.figoinc.com/PodCafé da TI é um podcast da ACSoftware seu parceiro ManageEngine no Brasil.https://www.acsoftware.com.br/manageengine

In this panel session, Rob Scott delves into the world of Dropbox and how UC resellers and service providers can take advantage of their modern workspace solution. Sponsored by Nuvias UC.Host: Rob Scott, UC TodaySpeakers:- Tim Britt, Northern and Central Europe Channel Lead at Dropbox https://www.dropbox.com/en_GB/business- Alex Whitford, Head Of New Business Sales at Nuvias Unified Comms https://www.nuvias.com/nuvias-practices/nuvias-unified-communications-practice/- What is Dropbox Business?- How can Dropbox compliment my UC and Collaboration portfolio?- How can a reseller best position Dropbox with UCaaS?- How to start selling Dropbox BusinessHosted by Rob Scott, Publisher at UC Today News - Unified Communications, Collaboration & CX Tech NewsThanks for watching, if you'd like more like this don't forget to subscribe.Follow our YouTube channel to get all the latest video roundups, and join in the conversation on our Twitter, LinkedIn and Facebook pages.For more Unified Communications News visit uctoday.com #teamcollaboration #collaboration #dropbox

The freemium model is a particularly interesting one, as it requires a very specialised form of customer and user experience in order to turn users of the free version of your product into paying customers with lifetime value. Dropbox has mastered this model and managed to turn it in to a powerful SaaS growth tactic – the company has also managed to thrive in a market that has become fiercely competitive over the last number of years, and found a very clever way of substantially growing its non-freemium Dropbox Business products. Our guest for this episode is Adrienne Gormley – VP of Global Customer Experience for Dropbox. We talk about: + establishing 'listening posts' to hear the customers' perspective + the Dropbox philosophy of making sure education arrives in the moment of need + how to best use bots in CX + the challenge of getting freemium users to invest in premium features + competing with cheaper and bundled products + how tech companies can win the battle for talent

Rob and Jason are joined by Alex Allain from Dropbox to talk about Dropbox's Djinni code generator and Alex's book Jumping into C++. Alex Allain is a Director of Engineering at Dropbox. He was one of the first engineers on the Dropbox Business product before leading Dropbox's Product Platform group, whose initiatives includes the Dropbox Sync Engine, shared mobile C++ and developer tools. Alex has run Cprogramming.com since 1998 and is the author of Jumping into C++, a book for new programmers. News CppChat: The Great Functor Debate (Ben, Jackie, and Jonathan) Monads in C++ COMMS Library Undefined behavior in C and C++ programs Alex Allain @alexallain Links CppCon 2014: Alex Allain & Andrew Twyman "Practical Cross-Platform Mobile C++ Development" cprogramming.com Jumping into C++ (Amazon) Sponsor Backtrace JetBrains  

Rich, Cecilia, and Matt are back with Episode #6 of ChannelPro Weekly! Rich managed to stop in at Eaton's Partner Summit and SMB TechFest, and even though there's some disagreement over whether or not electricity and power is sexy, there are a lot of interesting takeaways from the event. In other news, we discuss Intel's announcement of layoffs in conjunction with continuing shifts in its business strategy, and a callout to long-time friend Shannon Mayer who recently landed a VP role at The ASCII Group. Naturally, digital signage is evolving to customer engagement, and there's a fascinating discussion around what opportunities that means for business and potential security risks worth thinking about. Plus, Rich interviews Hank Humphreys from Dropbox on the company's recent alliance with Ingram Micro and its channel offering. All this and more. Subscribe and listen now! Subscribe to ChannelPro Weekly! Look for us in your favorite podcast app. If you don't see us (yet) then you can subscribe using this link: http://www.channelpronetwork.com/rss/cpw, or in iTunes: https://itunes.apple.com/us/podcast/channelpro-weekly-podcast/id10955685... Show Information: Episode #: 006Title:  That Squishy Mid-MarketDuration: 1:07:58File size: 62MBRegulars: Rich Freeman - Senior News Editor, Cecilia Galvin - Editor in Chief, Matt Whitlock - Technology Editor Topics and Related Links Mentioned: Eaton Partner Summit Six Surprising Predictions from Eaton's Herve Tardy The ASCII Group Appoints Shannon Mayer as Vice President of Channel Development Intel Announces Major Layoffs in Conjunction with Shift to New Business Strategy Talking Back to Digital Signage Interview: Hank Humphreys of Dropbox Business on the company's recent alliance announcement with Ingram Micro (http://www.channelpronetwork.com/news/ingram-micro-adds-dropbox-business...) and why channel partners should partner with Dropbox for file sync and share services. May Issue Teaser 20/20 Visionaries The Dangers of Cloud Powered Hardware Where's Joel? Matt's Tech Pick: Linksys LAPAC1750 Dual-Band Access Point ICYMI/What’s Up This Week preview