AppChat

Ron Huddleston, Chief Partner Officer at Twilio, joins the AppChat Podcast to discuss the importance of building out ecosystems and the differences he has seen building multiple ecosystems for various companies. Other subjects include breaking down various ecosystem models, how Huddleston's previous experience prepared him for working at Twilio, and the importance of trust and credibility in the industry. Here are the key topics, with timestamps, as well as the full interview transcript: Key Topics 00:00-01:58 Introducing the AppChat and our guest, Twilio's Chief Partner Officer Ron Huddleston 1:59-3:28 The challenges of indirect software sales 3:29-8:43 The importance of software companies building out an ISV and/or SI ecosystem 8:44-12:34 The differences in building out an ecosystem for Salesforce and Microsoft 12:35-17:10 The differences between a pure, cloud-based ecosystem, and a hybrid model including cloud and on-premise 17:11-20:02 How much Huddleston uses his previous experiences building ecosystems for Twilio, and how much he has to continue to discover and invent 20:03-25:54 The importance of trust and credibility when building out ecosystems 25:55-29:06 Building an app and sticking to the commitment you made to your ecosystem 29:07-30:22 Closing out and how to get in touch Full Transcript Intro: 00:01 You're listening to the AppChat, a podcast focused on SaaS growth strategies, plus successes in the Salesforce ecosystem, and beyond. Here's your host, CodeScience CEO, Brian Walsh. Brian Walsh: 00:14 All right. We're back on the AppChat Podcast. And today, I'm joined by Ron Huddleston, who, Ron, you have an incredible background when it comes to building out ISV ecosystems. Let me get this right. So you're currently the Chief Partner Officer at Twilio. Ron Huddleston: 00:31 Yeah. Brian Walsh: 00:32 Before that, CVP, One Commercial Partner organization at Microsoft. Ron Huddleston: 00:35 Yeah. Brian Walsh: 00:36 SVP of the AppExchange at Salesforce. Ron Huddleston: 00:38 Yep. Brian Walsh: 00:39 And started the OEM, ISV program at Oracle, where you were vice president. Ron Huddleston: 00:44 Yes. Brian Walsh: 00:45 Are there any bigger partner programs in the world to run than that? Ron Huddleston: 00:51 Amazon, maybe, now? Brian Walsh: 00:53 Maybe now, yeah. Ron Huddleston: 00:54 Yeah. Yeah, they're breaking new ground. But the Microsoft thing was definitely a big one. They've all been really fun. I do think that the folks at companies that get to build ecosystems, ISV, or SI, or any type of partner ecosystem, I think that it's probably the most fun job you can have at a bigger technology company, because you get exposed. It's not the same thing over and over. You get to really understand how to work with other folks and understand what's important to them. And so I stuck with it -- it was probably my 20th job at Oracle -- and when I found it and started building it, I just realized it was the most fun, like exciting, interesting, technically satisfying, from a business perspective, satisfying thing you could really do. So just from a personal perspective, I think it's probably the most fun you can have in cloud technology for a job. Unless you're like the CEO of a startup, or doing what you're doing, like building things. But if you're going to work for somebody else, I think it's a great job. Brian Walsh: 01:59 But I mean, I find that sometimes indirect sales, especially indirect software sales, can be extremely challenging. Like you're not actually doing that final license sale. You're lining up the partners and enabling them. I mean, is there something wrong in your head? Ron Huddleston: 02:14 No, there's not. It does carry its own set of complexities. But the strange thing is, whether it was on-premise or the cloud, those complexities repeat each other over, and over, and over again. So there really, after 20-odd years of doing this, there's not much you haven't seen, because where things get complicated is around human behavior, not necessarily around bringing really great solutions, and great partners, and technology together to solve problems. That's kind of the easy part, just to like address customer problems. Where things get a little crunchy is how human start, where things can get complicated, is when you're aligning different people, different organizations, different teams. That's where things get a little more complicated. I think everything up to that is not as complicated. But again, it's a pattern. And the patterns tend to repeat themselves. So you can sort of see around corners, the longer you do these kind of things, which makes it easier every time. This is, what, my third, fourth- Brian Walsh: 03:18 Fourth one. Ron Huddleston: 03:19 It kind of makes it a little easier every time you do it because you know, I probably made 10,000 mistakes. And you only make the same mistake three or four times. Brian Walsh: 03:29 Eventually, you get it right. So why an ecosystem? I mean, there's a huge amount of effort and investment. Why is it important for a software company to actually build out an ISV and/or SI ecosystem? Ron Huddleston: 03:44 Yeah. There's a lot of reasons. It depends on, are we talking about the technology company themselves that want to build an ecosystem? Brian Walsh: 03:51 Yeah. Ron Huddleston: 03:52 So you have to be a bigger company in order to do that, obviously. It's really hard to do it, otherwise. You can certainly build a small, little portfolio of folks that you work with if you're a smaller company. But there's nothing better than a broad ecosystem because it does a couple things. First things first is, if there's any way, shape, and form you're trying to prove out the sort of platform nature of the technology that you're trying to provide, the long road to get to that level of credibility is trying to do it yourself; trying to hire all the people in the world with the right expertise to sit down with a customer and explain to them, "No, bet on us. We're future-proofed. And you can do all of these things with us. We're a platform," it is really hard. The easier way to do it is to work with an ecosystem of technology, or IP, ISVs, and SIs; and the ones that are trusted in the space, that are maybe already trusted by the customers that you want to serve, and work with them to have them understand how your platform can help. And then build what's essentially, if those are the ingredients, then you know, the recipe book is how all those ingredients come together to help essentially cook a meal, like serve a beautiful meal for the customer, right? And so that's why it's a cool job. You get to be the chef, kind of. That's a good analogy, I'm going to use that analogy -- 20 years, I just discovered a new analogy. But you know, if you think about it that way, as ecosystems, as, you know, sure, you can call it one broad ecosystem, but really, it's a bunch of small solution maps, or what I was just calling recipes. It's a group of technologies, partners, companies, expertise, that solve particular problems. And no one company can really solve anything complicated on their own, really. Like it is just hard to do that over, and over, and over, and over again. You know, if you want to be broad-based, it makes it ... If you want to be a broad solution, like a platform, it makes it really hard to also solve problems, complicated problems, by yourself, right? If you want to stay really narrow and be like a really verticalized application or SI- Brian Walsh: 06:12 You can go super deep. Ron Huddleston: 06:13 You can go super deep. You can solve things on your own. But if you want to be big and broad, it's just the permutations of options are almost impossible. That's why ecosystems are so important. They drive credibility, but they also are the only way to solve really hard, complicated problems if you're trying to solve a lot of them. Those are the two reasons that it's great for the partner, or the platform, but it's great for all these companies that are sort of looking. It's great for cutting-edge companies. Like in the cloud, it was a wonderful thing. People actually all start relational databases. Like there were a lot of companies that were building up relational database practices back in the day. And there were these little, small startups that were building relational databases, or were driving Java for, like J2EE or something. Brian Walsh: 07:05 Yep. Ron Huddleston: 07:05 And I know this is going to sound really old. Brian Walsh: 07:07 We, you and I sound ancient right now. But keep going. It's great. We're reminiscing. Ron Huddleston: 07:10 Yeah. But the point was these companies, these smaller companies that would never have -- it was going to be a long time until they were big enough to where people really get exposed to them. Having an ecosystem, being part of a partner's ecosystem, of a vendor, a big platform's ecosystem, helped the companies that were the best, the most innovative, had the best technologies, sort of punch above their weight class, and could help change the market really quickly. So it's this symbiotic relationship between these platform players that need partners for the two, you know, for lots of reasons, but the two reasons I highlighted; but it's also great for partners, for ISVs and SIs, because it helps the best rise to the top. It helps the best innovate. And you know, it also, if you are the type of SIs or ISVs that are specialized in a particular place or industry, it helps you get access to customers where you might not get access before. So it's a real symbiotic thing when it's working really well, and nothing stands in the way, and there's no friction. And it's really just about sort of, you know, matchmaking. Like, you know, you're a cook. All your ingredients are great. You cook the best stuff. Everything, your oven works. Your waiters are awesome. I guess waiters would be sales in this analogy, right? Brian Walsh: 08:31 Yeah. Ron Huddleston: 08:32 Yeah. The waiters understand stuff. Brian Walsh: 08:35 Sales ops are your line chefs, right? Ron Huddleston: 08:37 Right, there you go. I'll work this analogy out at some point. I think it has legs. I'm thinking about it. Brian Walsh: 08:44 There's always an interesting thing, like if I compare where Microsoft has embraced their ecosystem, and I look at where Salesforce has, around capital efficiency, right? Because in the Salesforce world, there was almost no investment, outside of VC investment, almost no investment of, "Hey, let's invest in you to bring this product to market." Whereas we've seen, even on the Oracle and Microsoft side, lots of investment into ISVs to help them get started with an ecosystem. Ron Huddleston: 09:09 Yeah. I think Salesforce would argue, particularly back in the day when they were building it up, when we were building it up, where we didn't really have as much market presence. There are two things that companies can do to invest in you. They can certainly invest time or technology, but they can also -- I'm sorry, they can certainly invest money or technology, but they can also invest time and access. And at Salesforce, the way I pulled the AppExchange together was, you know, there were limitations around technology, and dollars, and investment dollars, which eventually got solved in one way, or shape, or form. But there was really very little limitation to time and access that could be provided. And so the big strength that Salesforce had at the time was, they were leading in the cloud. So they had, they were innovators, had access and had a sales organization. So a lot of the beginnings of that ecosystem were built around people receiving essentially go-to-market support, help, and guidance from Salesforce, in return for their technical investment in building something with Salesforce. And that was the trade-off that they made. Microsoft is a different beast, and they grew up through partners, and they always had partners. But they'd gotten to such a point where they were so dominant in the marketplace that they'd essentially become demand fulfillment. The partner channel was super optimized for really educated customers to come in and want to buy something. And they would go to very specific partners that would then fulfill that. And it was very educated demand fulfillment to a very educated market, which is entirely different than what we were setting up the One Commercial Partner team to do, which was to create demand. So, instead of having 1,000 points of connection with super-specialized partners, have partners that could show up in front of customers and say, "What problem do you have? What question do you have for my answers?" And then they could represent the full cadre of everything that Microsoft could do. You know, it's a huge technology portfolio. So they were just really limited historically because partners had to sort of pick their lane and stick with it. And so one of the things that's a great thing we did there, was break that down and only create very few lanes. So partners were expected to really lead the way and create demand. But in order to do that, we also had to change the finances. We had to change economics. We had to create a lot of incentives for the direct sales organization to work with them, which is a big part of it, too, because selling stuff, versus taking orders, is expensive. And so we had to make sure the partners could make money doing it. And so in that particular case, you know, the trade-off was, being able to represent Microsoft across the board is a tough thing to do, but if they'd invest their time, and energy, and attention, in learning how to sell and create demand, we made the economics work so that they could get a payback, which is a little different. It's almost the opposite of what Salesforce was doing. And so they're just very different situations. Brian Walsh: 12:29 Got it. Ron Huddleston: 12:30 But like I said, you know, you do this long enough, you've seen almost everything. Brian Walsh: 12:35 Well, let's actually study one more difference within that, which is you had a pure, cloud-based model. And then within Microsoft, you actually had this hybrid. You had cloud, right, like this emerging cloud ecosystem with Office 365 and Dynamics. You also had this gigantic on-prem, you know, basis of licenses. Is there a huge difference between those two types of ecosystems? Or are they basically the same? Ron Huddleston: 12:59 No. There really isn't. I mean, the economic models are different. But enough folks, I would say 8 years ago, 10 years ago -- God, 10 years ago, 15? I don't know ... Like 2008, 10 years ago, 2007, 2006, '07, '08, that's when the financial model differences, forget the technical differences, the relationship differences, the functional selling -- Brian Walsh: 13:24 Customer success, all that stuff. Ron Huddleston: 13:25 All that stuff, the actual financial models of how people expected to generate revenue and make a living, being a technology company or a consulting company, they were so different between cloud and on-prem that moving financial models was the primary thing holding people back from taking the step to the cloud. People liked the technology, but they couldn't take the jump. Like a lot of companies failed because they tried to put a foot in both camps, and you just couldn't. There's one financial model, on-prem, it's very short-term focused; one financial model, cloud, is very longterm focused. And if you're trying to serve both masters, you'll make bad, suboptimal decisions. And so I had a bunch of rules about the cloud. One of them was, you have to pick one or the other. You have to like, divest to one or the other. I think those days have changed, where even if people are doing a lot of on-prem stuff, like there's even the Microsoft SIs, or resellers, they've worked it out in such a way, through financing, through managed services, through something that they're emulating software as a service, financially. And so the technological flip is just a matter of time and opportunity. It wasn't a matter of this big burden, I'm sorry, barrier, an obstacle which is changing their whole financial model, which is really hard. I mean, I literally had sought out, the same way you guys were product development outsourcers, I'd sought out financial development outsourcers, as well, that helped to finance companies through the gap, like the two or three-year revenue gap when they make the transition, because the financial model transition was a lot harder than the technical transition, back in the day. Now, I don't think it's as hard. At Microsoft, it's, you know, some of the companies are so big, I think that the inertia is probably harder than the finances, you know? Just the daily grind, inertia of things makes things tough. Brian Walsh: 15:17 And I think some of your work in there really paid off; the Lighter Capital helping with MapAnything. Ron Huddleston: 15:22 Oh, yeah, I bet they made a crushing at that. Yeah. Brian Walsh: 15:26 Yeah. And now, I think Series D, and they're gigantic. Ron Huddleston: 15:29 Is Lighter Capital doing pretty well? I haven't talked to those guys in a while. Brian Walsh: 15:32 I think they're doing great. Ron Huddleston: 15:34 It's a great business model, I mean. Brian Walsh: 15:35 It is. Ron Huddleston: 15:35 Yeah. Brian Walsh: 15:36 It's interesting. They were so far ahead on that non-equity based funding for it. And now, I see Indie.vc. I see a lot of players coming in. Ron Huddleston: 15:44 Yeah. No, it's a good way to do it. Here at Twilio, there's so much. The funny thing is, it really feels a lot like the initial cloud, call it, revolution in 2007-08. Brian Walsh: 15:57 Yep. Ron Huddleston: 15:58 It's just in communications. And there's a lot of folks that are in the exact same spot; not that they're in financial, a big financial difference, model-wise. But telecommunications is like a different financial model, in a weird way. It's very like, usage oriented. It's got spikes. It's got a lot of weird things they're not used to, particularly if people are selling cloud seat kind of stuff. It's just a different sort of world for them. And a lot of folks don't have specialization in a lot of these things. And so, you know, building things like PDOs and financial development outsourcers are things that we're going to have to do here at Twilio as well, because there's thousands and thousands of ISVs and SIs that, whether they know it or not, are going to be using Twilio in the next couple years, because it just fits. Everybody who's moved to the cloud, there's probably an opportunity -- and touched a customer in some way, shape, or form -- there's an opportunity for them to work with Twilio. And you know, we've just got to make it easier. That was one of the things that, you were around at Salesforce when we did that, too. We just made it easier for people. Brian Walsh: 17:04 Totally. Well, let's jump into Twilio while we're here. You're assembling an amazing team. Ron Huddleston: 17:10 Yeah. They're good people. Brian Walsh: 17:11 It seems like you're applying all of your lessons from the past, you know, experiences building an ecosystem. How much do you have to continue to discover and invent? How much of this is just pulling out your playbook and running with it? Ron Huddleston: 17:24 You know, a lot of it is playbook stuff. I will say, the difference between communications technology, like it carries a lot of legacy with it. Like there is, you know, a whole lot of underlying technology that, if you're unfamiliar with it, which I am, you know, like the seven layers. That's just, there's a bunch of crazy stuff. Brian Walsh: 17:45 Yep. Ron Huddleston: 17:45 If you're unfamiliar with it, there's a lot going on there that has significant material impacts on business models that could work or couldn't work. So you bring the same playbook, and then you have this set of realities, constraints, and the technology as it exists, that then make things viable or not viable. And it is, you know, it's fundamentally a bit of a different thing, because it's a very API-forward company, which leads people down a lot of weird roads. Like what is an SI? What is an ISV? Which, by the way, we can get philosophical on this. Brian Walsh: 18:23 How do you differentiate? Ron Huddleston: 18:26 Like at Salesforce, people would just like get their heads wrapped around an axle, because you know, back in the day, when we were creating the partner program, I always tried to explain reselling, and OEMing, and trying to get like, I think, Veeva kept it on their first contract to sell Salesforce underneath their technology set. People were like, you know, "The technology is staying here. These are ours, it's in our -- this isn't the Salesforce," what do they call those things? I'm sorry. Do you remember those, at Salesforce, they have a name for the PODs that- Brian Walsh: 18:59 The ORGs? Ron Huddleston: 19:01 Not the ORGs, but whatever. It's Salesforce property. We're running it in our own data centers. Brian Walsh: 19:07 Right, in a POD. Ron Huddleston: 19:07 So how are you reselling anything? I'm like, "Well, it's, you know," even, and then licensing, which is just a human, you know, construct. It's not real. Like all these things, applying them to the cloud, it's semi-nonsensical, but it is a way to put these constructs together, and rules together, that help enable ecosystems to exist and thrive. There's something that they can sell, that they can put margin on, that they can build a business on. There's something that they can learn about, and then configure, and then leave with the customer. If you don't have the concepts of ownership, and passing ownership, and control, which don't make a lot of sense when you think about like a multi-tenant cloud, but if you don't have those things, you can't build businesses. And so, you know, a lot of it is building the faith that these human constructs exist, and that you can sell them, which for API companies, is a new thing. Like, I don't think AWS even does that yet. Brian Walsh: 19:59 No. But- Ron Huddleston: 20:00 It's weird, I know that I'm like waxing philosophical, but it is a- Brian Walsh: 20:03 But I mean, it all comes down to trust, right? Ron Huddleston: 20:06 Yeah. Brian Walsh: 20:07 You have to build trust with this partner that you will create these things, that you gave them your word, that they can actually invest millions of dollars to go forward with it. Ron Huddleston: 20:16 Yeah. Trust and credibility, in this space, is kind of what it's all about. And it's a thing about companies, too, is you know, they can, over time, their perspective on the importance of ecosystems and what the value is can change. But if you're leading up those ecosystem efforts, like you've got to try hard as hell to live up to the commitments, and consistencies, and visions that you put out there -- to the point where you're willing to sort of, you know, throw yourself in front of a train to make sure that like, you know, people don't change the philosophies you put in place, because people are betting their lives, their businesses, on what you're laying out as the vision and value of the partner program you're putting out there. And you're making these commitments, and anything that drives inconsistency, anything that's not committed, anything that violates trust in those things is a huge, huge problem. Like you know, you can spend years building up the trust that's required to build an ecosystem. And in one day, you can blow it. So that's, by far, the most important thing that you need people to understand who are setting up partner programs, or building teams, or you know, maybe looking to hire someone to build up their organization. Make sure that she or he, you know, the first thing out of their mouth needs to be like trust and consistency because without that, none of the rest of this really matters. Brian Walsh: 21:48 Yeah. And it's also, I think, the confidence that these larger organizations are actually going to stay in it, right? Ron Huddleston: 21:54 Yeah. Brian Walsh: 21:55 You know? This is not going to be a one-year test, then we're going away, because we're asking the likes of major companies to actually invest their future in this opportunity. Ron Huddleston: 22:04 Yeah. And you know, a lot of them don't take the jump and wait a year, wait two years, to see. I mean, the cloud took forever. It took four or five years for the bigger companies to jump. Brian Walsh: 22:15 Yep. Ron Huddleston: 22:15 But now, things are happening a lot faster. But there'll still be some companies that'll wait a year or two to jump. But you'll recall this, the ones that made it first in the cloud, the ones that were really successful were all the first ones, the people who moved fast. The consulting companies that moved fast, the ISVs that moved fast, the companies that jumped in there and took the risks were the ones that succeeded in the end. The ones that played on the sidelines, unless they were super dominant, they were playing catch-up, and still are. Brian Walsh: 22:44 And you watch the outcomes and success of those. ServiceMax, I mean, that was coming about when Service Cloud wasn't even fully baked, and almost a billion dollar exit. Veeva went public. DocuSign just went public. Ron Huddleston: 22:56 Yeah. Those were all the early ones, yeah. Brian Walsh: 22:58 Yep. They all came in. All right. So there is a PayPal Mafia: Peter Thiel, Elon Musk, Reid Hoffman. Ron Huddleston: 23:06 I don't know any of them very well. Brian Walsh: 23:08 Yeah, I know, but that's your social circle, I'm sure. You go surfing with them. I propose that there's actually an AppExchange Mafia as well now. We have you out there, Avanish at ServiceNow, Leyla took back over of the AppExchange, Todd Surdey is now at FinancialForce, Sean Hogan at Nintex, Brian Snyder at GE. That original crew, those people who were there on those early, Wild West days, are out there in the SaaS ecosystems. Ron Huddleston: 23:36 Yeah. Ross Eberhart's over here. Mike Rosenbaum's running product over there. Like, yeah, and a lot of trust amongst all those people. And we will, I'd love to work with any of those people. Avanish and I are always trying to figure out how we can do stuff. That's just a great group of people that, I think a lot of them learned a ton through that phase. There's even some folks that were from Oracle that are still in the Mafia, if you're going to call it that. Like, because Molly Bellero Fischer is still doing it. Ross is still doing it. Anders is still doing it. Ryan Begin's still doing it. Annie Heppberger, I think, runs partners now for Oracle. Brian Walsh: 24:23 Brent Floyd. Ron Huddleston: 24:24 Yeah. There's a lot going on; Kevin Walsh is still doing it. He's an Oracle person. Yeah. There are- Brian Walsh: 24:30 Joanne Pantuso is still doing it. Ron Huddleston: 24:32 That's right. Once you get a taste of working in ecosystems and partners, you don't really want to do other stuff, just because it's so fulfilling to help companies do something new, and grow, and to be part of their story. It's really fun. Like I said in the very beginning, in the opening when we were talking, if you could, you know, I had a lot of, I probably had 15 different jobs at Oracle. And this was by far the most fun. And I was a young man back then. And I had decided like, this is the thing I wanted to do. If I was going to work for somebody else, this is it, because there's no beating it. Like there's nothing, there's really not beating it once you get it going. That's why Twilio is so exciting, by the way. It's like the new Wild West. Brian Walsh: 25:13 Yep. Ron Huddleston: 25:13 It just reminds me of like the cloud. And a lot of those people are the same people, the Mafia you just mentioned, there's a lot of those same people that all recognize the same thing I do. Which means like, you're not running around saying, "Oh, trust me. This happened before." There's a bunch of people here that have lived it and are like, "Oh, my God. This is so interesting. It's exactly the same. And let's-" Brian Walsh: 25:34 We get to do it right the first time, this time. Ron Huddleston: 25:35 Yeah, yeah. Here's the thing -- we did it right before. I think I'd argue the Microsoft One Commercial Partner is set up the right way. We'll do it right here, it's just things are happening much faster. Instead of taking three or four years, it's happening in like 12 months. Brian Walsh: 25:52 Wow. Ron Huddleston: 25:53 It may be faster. It's crazy. Brian Walsh: 25:55 Well, and strategically, like technology-wise, adding in the whole serverless infrastructure, so you can host code now. You've got Flex, so you can start building out sort of UIs and the whole thing. Ron Huddleston: 26:05 Yeah, it has a face. Yep, that's a real thing. You'd be surprised how much having a face matters to LOB leaders, versus developers. Brian Walsh: 26:12 And I bet it also adds to some of the defensibility of it, right? Like, there's less attrition as you start adding even more and more layers, people can get deeper into your system, rather than just an API. Ron Huddleston: 26:23 Yeah. The thing about Flex, the most interesting part about Flex is the underlying technology. I don't want to give percentages, but I'd say a vast majority of the underlying technology has been around, you know, started 10 years ago, and it's been enhanced ever since. The moment that Flex came out, where it was a way to put a face, a UI, on what was possible in Twilio, the interest was a thousandfold, because it opened up people's minds to what Twilio was. Versus an API, which is a very difficult thing for non-developers to understand. You put a UI on it and explain what it is, you've just cracked open a huge market that should have been already there. It's just, people didn't understand what this, what Twilio could possibly do. And Flex wrapped that up nicely. Now the challenge is, when a platform, an API platform, which is a beautiful offering for SIs and ISVs, because it's like the cookbook that you need to do anything, which is just perfect for a partnering system. Brian Walsh: 27:21 And it's so damn easy to use at Twilio. Ron Huddleston: 27:23 Yeah. When you build an app, though, you, no matter what, unless you're picking exactly the right space, are probably going to bounce up into some elbows of people that have already built on your platform. And so, same problem at Salesforce, same problem at Microsoft, when you start expanding what you do and putting, you know, faces on things, and making new applications, like you mentioned Service Cloud and ServiceMax, that is a, you've got to tread very slowly, and know what you're doing, and make very considered decisions, because the chance that you are violating a commitment that you made to your ecosystem is probably very high. Now Twilio had never had a partner program, and really made a ton of commitments in that direction. But understanding the effects of things like this, and what's important, and what's not, is critical to our business going forward. And George and Jeff totally get it and understand. And so the idea of having governance, like a buy-build partner governance, and the impact that doing any of those actions, besides partner, if you buy or build, taking all that into consideration is one of the reasons why I feel really good about being here. Because they're super dead serious about it. And what they're focused on is, if they do buy or build, they're doing it underneath, like on the platform layer. Like even Flex, sure, it's a face. It's a UI. But if you really look at it, it's like an SDK for a UI. You know what I mean? It's not really a -- you could technically use it out of the box, but no one will. Brian Walsh: 29:02 Right. It's just the starting point. "Here, let me help you imagine this." Ron Huddleston: 29:06 Right, yeah. Brian Walsh: 29:08 That's fantastic. Well Ron, thank you very much for joining us. What's the best way, if somebody either wants to find a great job in an ecosystem, or they're looking to partner with Twilio, for them to get ahold of you and your team? Ron Huddleston: 29:20 If people want to do either of those things, the best way to get partnering going is to go online, and go to "become a partner," and go to the community. And then you'll get routed to like the person that you'll, you know, one of the 50-odd people that you'd be dealing with in to learn and become a partner. And there's people that are there just to quickly follow up and make sure you know how to do it and what's important. But if you're interested in getting a job, you can email me at rhuddleston@twilio.com, because we're hiring. We're going to hire another, you know -- lots. We're in super hiring phase right now. Brian Walsh: 29:59 Fantastic. Well, Ron, thank you very much for taking the time today, and glad we got this scheduled, and finally do it. Ron Huddleston: 30:04 Yeah, no. I'm very, very impressed by your fancy equipment and the level of professionalism in putting this podcast together. Brian Walsh: 30:11 Hey, look, I've grown up just as much as you have, okay? Ron Huddleston: 30:15 Yes, clearly you have. Brian Walsh: 30:18 All right, Ron. Thank you so much, everybody. Ron Huddleston: 30:20 All right. I'll see you around the water cooler. Bye. Outro: 30:22 Thanks for listening to this episode of the AppChat. Don't miss an episode. Visit AppChatPodcast.com, or subscribe on iTunes. Until next time, don't make success an accident.

Yeva Roberts of PFL.com joins the AppChat Podcast to share what her role as Senior Director of Strategic Alliances & Innovation entails and how relationship building plays an integral role. Also addressed is the critical gatekeeper role of Salesforce solution engineers, successful tactics PFL uses to interact with them to drive sales, and what to look for in a great Alliances Manager of your own. Here are the key topics, with timestamps, as well as the full interview transcript: Key Topics 00:00-00:50  Introducing the AppChat and our guest, Printing For Less’ Yeva Roberts 00:51-2:23       Defining the role of Strategic Alliances and what it means 2:24-4:37          The history of Printing For Less 4:38-10:42       How Yeva got involved with PFL and the changes she has seen 10:43-11:55      Bridging the digital and print worlds to ensure people understand the value, importance, and opportunity 11:56-15:31       The breakdown of relationship building vs. business development in Strategic Alliances 15:32-20:04     The role of solution engineers and how to interact with them 20:05-22:39     How to identify the SEs that are going to help you the most to get established 22:40-26:21      Tips on managing relationships with your partner account managers (PAMs) 25:32-28:52      PFL's versatility across multiple clouds at Salesforce 28:53-30:15      What to look for in a great Alliances Manager 30:16-30:52      Closing out and how to get in touch Full Transcript Intro: 00:01 You're listening to the AppChat, a podcast focused on SaaS growth strategies, plus successes in the Salesforce ecosystem and beyond. Here's your host, CodeScience CEO, Brian Walsh. Brian Walsh: 00:13 Welcome back everybody. We are back on the AppChat podcast and today I'm joined by someone I think is absolutely fascinating. I had the honor of working with her for the past, I think a year and a half, two years. We've been on and off again, been working on things, having conversations, meeting up at conferences -- and so with us is Yeva Roberts who's the Alliances Manager for PrintingForLess.com. Welcome. Yeva Roberts: 00:39 Thanks, Brian. I'm so excited to be here. Brian Walsh: 00:41 It is great to be here. I'm sorry everybody else doesn't get to see the video of this because your smile just makes me want to speak in a really happy tone. So thank you for that. How would you define your role as an Alliance Manager? What does that mean? Yeva Roberts: 00:56 Wow. So, that's a tough one. So I guess it depends on what stage of growth you're in. As an ISV, I think for us being a startup within a larger company, it means that you get to wear multiple hats. So initially if you're the very first Strategic Alliances, evangelists is what we call each other, you get to be the channel operations person, the channel sales, channel marketing, what have you, because you're really trying to prove your worth in an AppExchange exchange of 4,000 apps. So for you and me, I think it's a matter of just being open to wearing multiple hats and navigating the ecosystem, and being that internal subject matter expert on Salesforce. As well as being that external subject matter expert on PFL, in my case to all the Salesforce solution engineers, account executives, marketing teams, PR, as well as all the SIs and ISV partners. Brian Walsh: 01:55 That is such an interesting role. I once heard it described to me as you're in charge of making sure two large companies, corporations, actually can speak the same language and understand each other. Yeva Roberts: 02:06 Yeah, it's funny. I love that because you're essentially a translator. You're getting to look at the world through a keyhole, really two keyholes, right? So you get to see your worldview as an ISV and then you get to advocate for and evangelize the second worldview of your partnership. Brian Walsh: 02:24 So why don't we back up a second and actually talk about Printing For Less. What is PFL? What do you do? Yeva Roberts: 02:33 So PFL is actually about 20-year-old company and it got its start as America's first eCommerce only print shop. So imagine in 1996 and 1998, that time period where eCommerce was still in its infancy, PFL had this idea really. The founder, Andrew, and his partner had an idea of, "Hey, we're in Montana, you know what would be really cool is to open up a print store." But because as you can imagine, the population in Montana doesn't really require you to have a storefront, they decided why don't we copy what Amazon user experience is like. At the time Amazon was just launching it and so they went live with the storefront on website only, so there was no physical store. And then fast forward, they accumulated about 125,000 small business customers. Those small business customers grew up and they thought that while Printing For Less -- or PFL now -- was doing a great job with print, what they were starting to do is really adopt tools like Salesforce for their CRM or marketing automation platforms and digital marketing platforms. And then they said, "Hey, you do a great job for us in print and since you are a marketing technology company first, meaning you have the API and the tech stack, why don't you integrate and make our lives so much easier. Integrate with these CRMs and these marketing automation platforms. And so that's when PFL, Andrew, and the team decided to pivot. It's been really about five years ago now that they decided to pivot and really take the company into a new direction. And we still have our 125,000 small business customers to serve on the direct side of the business. But now we're working within Salesforce and other ecosystems as well. Brian Walsh: 04:24 All right. So their printing shop, they've built up 125,000 customers, start pivoting into actually a channel model working with different marketing automation, different CRM and sales process on there. How did you get involved? Yeva Roberts: 04:41 I love that story. It's one of my favorites, so I'm actually a digital marketer by training. So I spent about 10 years in the B2C space, and I was managing digital strategy for some global brands as well as direct mail. So I was really in the thick of things, trying to figure out how to integrate email and direct mail and social together to go to market in the integrated way, and at the time -- I guess this was probably eight years ago -- marketing automation was still in its infancy. Salesforce was still trying to figure out how do we really support B2C brands. So I was struggling being in the middle doing everything manually, in terms of handing over files and walking them over for direct mail, to the digital team, or the taking the files for digital and handing them off to the direct marketing agency. And so I thought, "Hey, you know, after so many years of being in the middle, it would be kind of fun to pivot as well and go into a more product development, product marketing role, and figure out a way how to integrate a printing type environment with an email service. And so ExactTarget -- I was a user at the time -- was in our backyard, and so I went work for a printing company here locally in Ohio and just convinced the executive to give me some play money. And, so we decided to do the very first light integration into ExactTargets' Hub Exchange. So at the time they didn't have Journey Builder, they still had Automation Studio at the time. And so we did this light integration, it was really just a test. And so I'm really excited, the engineering team is really excited. Again, working for this other printing company and ExactTarget is super excited and this is 2012 and we go to this user conference. We have our first showcase, we go to the user conference again the following year and I meet PFL. So PFL is that the exhibit hall, the Expo Hall. And I walk up to them like, "You know what, you did a great job swag bombing our entire executive team with your tactile marketing automation concept." And I absolutely love you for doing that because you know, here I am advocating for this integration because as a marketer I feel like it's a problem that we need to solve in the marketplace, and I would love to see your app. And so it all happened in their booth. Their CMO and founder, Andrew, showed me what they had built and I absolutely fell in love with it because obviously, it was like, here's my light version, MVP if you will, and here is their full-on product stack of what I wish I would have built. Brian Walsh: 07:30 What it could be. Yeva Roberts: 07:31 Exactly. And I was like, "Is this working?" You know, the usual kind of customer question you get, "Is this for real? Did you actually build this or is this still POC concept," right? Proof of concept. They're like, "No, this is working. This is how it looks." So anyway, fast forward, we stayed in touch and I eventually moved over to the team. I think I was in a product marketing role managing ExactTarget reseller professional service, and I thought, "You know what? I would love to do this 100% and just evangelize what PFL team has built." And since I understood the marketplace, had been in the Salesforce ecosystem for so long, both as a customer and as a partner, that it just made sense and they needed somebody that knew how to navigate it, that had a passion for it and could talk peer to peer. I think that's so important in the Strategic Alliances role that you truly understand the problem that you're trying to solve with your apps. And so we didn't know, I think the two of us didn't really know what it was going to end up looking like and we've been figuring it out ever since. Brian Walsh: 08:41 That's wonderful. So it's like six years ago, they're already using the term of tactile marketing automation. Now they're saying, "Hey, here's the physical representation of what we've been doing on digital, around ads and email and all of the other piece. When that happened, when everyone started talking about ABM, there must've been fireworks going off at PFL. Yeva Roberts: 09:04 Oh yeah, absolutely. What you just said is perfect. Brian Walsh: 09:07 It was like, it was converging because everywhere I go, it's about the sort of Omnichannel of hitting from all the different angles around your target account list and is there a more impactful way of doing it with them with some printed item that shows up and you provide a way to automate that? Yeva Roberts: 09:22 Yeah, absolutely. We always talk about like, everything is cyclical, so you had direct mail has been around, print, direct mail, it's been around for 50 some years if not longer, and then you have this new shiny thing come out, email, and everybody just swarms to using email and direct mail is no longer sexy, and you used to worry about junk mail in your mailbox, now you worry about your junk mail in your inbox, right? And so, as they de-invested and marketers de-invested into direct mail, they're not coming back around and saying, "Oh my gosh, we have so much digital clutter. How do we break through that? Oh, I know. Why don't we talk to our friends in the direct marketing space and figure out a way how to integrate that as part of an overall customer journey." And I think that's what's happening. And it's nothing new, I think we've just gotten a lot smarter and now we have tools, like marketing automation tools, to make that happen for us that us marketers 10 years ago didn't have. Brian Walsh: 10:18 So I agree with you, it's not new. But, having worked with Salesforce for so long in digital space, the idea of combining what we're doing in the digital world and all of the language that we use, our lexicon around that, and then this idea of there's a print shop and people behind it pushing items, and they're getting printed and then shipped and mailed. We'll go back to this translation idea, how do you bridge those two worlds together to make sure everybody understands the value, importance, and opportunity?" Yeva Roberts: 10:47 So that's hard, right? On one hand, it's much easier to introduce a new concept to somebody in maybe the B2B space and high tech who has not traditionally used direct mail, they're digital natives. And it's much harder to pivot somebody who is a traditional brand, been using direct mail for a long time, going through this digital transformation and trying to get them to break their old habits of how to think about it in a completely different way. Meaning that their digital email subscriber data is stored in one place, their tools for email execution are also in a different place, and their direct mail, physical mailing address, also live in a completely different place. And for traditional brands, it's much harder sell because you're having to re-educate them on breaking this habit. Whereas ABM and the high tech B2B space, it's so much easier. They get it because they believe in the concept and it's a new channel for them to add and the integration is so much easier for that. Brian Walsh: 11:56 So how much of your time is spent relationship building across Salesforce and the partners and that side of the ecosystem, and how much is like business development where you're actually working the deal. Actually creating a new business opportunity, trying to maybe create a new business line at PFL. How would you break down your job between those sort of responsibilities? Yeva Roberts: 12:18 I would say education is number one. And so, I think of it like three different degrees of separation from revenue. So the first degree is, like you said, helping the sales team, both sales teams, you know PFL sales team and the Salesforce sales team work together on opportunities, and that's really the deal conversations. Second degree would be activities that I probably spend the most of my time, which is relationship building, whether it's lunch and learns or customer shadows, where I go on site with the Salesforce team and conduct a training for their customer. And that's really where a lot of the magic happens and the relationships are built because for an AE at Salesforce or a solution engineer, they're looking to us as Strategic Alliance evangelists to be that trusted advisor or the subject matter expert in our space and they want to learn from you so that they could look like a rockstar in front of their customer. So long-term relationships I think is the key in this role. I don't care about the one and done referral as much as I care about educating my peers within Salesforce to speak our language, understand what tactile marketing automation is all about, understand our value and be able to be comfortable and know that they can always reach out to us, no pressure, and provide thought leadership. So I think relationships is number one and that's more like a second degree of separation from revenue. And then finally the third stage in degrees of separation is really around executive bridging, which is another relationship layer. I do spend quite a bit of time making sure our executive team is aligned with Salesforces' executive team whenever those opportunities present themselves. Brian Walsh: 14:11 Got it. And do those tend to be at events or throughout the year? Yeva Roberts: 14:16 Oh, every single day, every single day. I think the number one differentiator I hear about all the time for perhaps our competition is that the feedback I get is we are so incredibly responsive. So if there's a call going on tomorrow and the solution engineer and account executive at Salesforce are prepping for the call, they know that they can reach out to me today and I pick up the phone and answer their questions. Being at their beckon call and being 100% responsive is probably the biggest feedback I get all the time that we do. And I think that's what builds a really strong relationship as well, as well as coming up with new ideas to enable those teams. New demo environments, keeping those demo environments up and running. We have over a 100 marketing cloud solution engineers actually using our demo. I never even know what kind of meetings PFL has being demoed at every single day. But in good faith, I know that those teams are trained and they're representing us really well and we're happy with that. And I think, going back to your original question, I think relationships to us is just part of our long-term strategy. Brian Walsh: 15:33 Alright, solution engineers, this is like one of my favorite topics because they're the hidden secret to this whole ball of wax, right? Yeva Roberts: 15:38 I totally agree. Brian Walsh: 15:40 They make it happen. Alright, so explain what a solution engineer is. Yeva Roberts: 15:43 So solution engineers, sometimes referred to sales engineers too I think, they quarterback the AEs. So they're tasked with understanding what the business requirements are. So existing customers or future customers will come to Salesforce and, especially in the enterprise space, they'll get assigned to a solution engineer who goes under the hood, understands what their business objectives are, and understands what some of those business requirements they're looking for to transform their business. They have to be an expert in, imagine 4,000 Apps, which is like obviously impossible. So, I think from an unsung hero perspective, I think they quarterback the customer and the sales team pretty well from that perspective. Brian Walsh: 16:32 So it's identifying who these SEs are that are working your target market, it's building a relationship with them, and then it's providing them with solutions and education. Yeva Roberts: 16:43 Yep. And I think that the biggest misconception I hear about a lot is, the executive teams will set a goal, "Hey, you need to kind of get the word out about your app to every single social engineer within the Salesforce ecosystem." Well we know and you made a great point that being niche and being super specific on which verticals you're playing in, especially when you're first starting out, is so critical. These solution engineers, imagine they're being reached out to by what, 2000 ISVs every single day, either through LinkedIn or emails and they're bombarded. So, obviously, they're only going to pay attention to those ISVs that are being strategic in the way they approach them. They have a sharp elevator pitch, they understand the value they provide, and then you can provide them the support and solution engineers while we sleep, prioritize those relationships and really understanding those products more than somebody that boils the ocean and spams them, for lack of better word. Brian Walsh: 17:43 And their goal is to close this deal for licenses. Not just your product, but really to expand the Salesforce side of the relationship. So, if your product is on target to actually help them do that, then awesome; but if it doesn't actually help in that process, then they're not going to talk to you again, right? Yeva Roberts: 17:59 Absolutely. I think it's knowing who to reach out to. Like which solution engineers are aligned to your market, the market that you support, and then knowing what value you provide at the moment that they need it so that you're not constantly in their face but enable them in such a way that they know how to reach out to you. And then when they do, be super gracious and treat them like family. Brian Walsh: 18:23 Now, you know you're providing solutions for them to demo and in your case, you've got physical printed items. How do you bridge that gap so that it's actually impactful? I can imagine in your sales process they can mail you something, but now you've got like this third party that's demoing, like how do you pull that together to make sure that their demos are impactful? Yeva Roberts: 18:43 So, I think that it's part of our secret weapon in which is we drink our own champagne. What I mean by that, when we onboard a new solution engineer to PFL, part of the onboarding process is me actually using Salesforce to send them a welcome kit. So they actually have a welcome kit that they receive, so they go through the experience. Not only do they have access to the demo, but they receive a kit that spells out exactly what our value is and when we can help them and because they have now gone through the process, they're a better advocate for us on the call with the customer. Brian Walsh: 19:22 That's so cool. Like if you're doing just digital stuff, it's like what could I send you? I'll send you an email. In your case, it's like a printed box with their name on it and all of the materials inside. What's inside the box. Yeva Roberts: 19:32 Oh, okay. Hold on. Brian Walsh: 19:34 For those of you who can't see -- in fact that's all of you -- she's got the box. She's pulling it open, it's just full, It's chockablock full of customized content. Yeva Roberts: 19:43 Yep. It will have an invitation, an idea book, a note card with my headshot, basically just spelling out for them everything they need to know and because it's tangible, obviously it has a higher chance of being remembered than maybe some of our counterparts on the AppExchange. So, that's definitely part of our little hat trick. Brian Walsh: 20:05 That's great. All right, so let's move back to this first step. How do you identify the SEs that you think are going to help you the most to get established? Yeva Roberts: 20:16 I think it definitely goes back to being really critical on your target market. So what I mean is just from an internal alignment with your marketing team, your sales team, you as the Strategic Alliances manager really needs to be super clear with all the other teams internally on who's part of your go-to-market. Is it financial services, is it health and life sciences, is it retail? And so on and so on. If you have one or two key markets that you're going after, then it's really an opportunity for you to reach out to your partner account team at Salesforce and work with them and their leadership team to say, "Hey, who are the RVPs, the AVPs that I need to be aligned with?" And then hop on the sales team call for those teams, do a training, and understand what their focus is that year. And then from that conversation, ask them for the introduction to the solution engineers that support that team. And then it's a rinse and repeat and by the time you're done, like we're three years into it, I now know probably 200 to 300 account executive and the solution engineers that know them. It helps to have an elephant memory, which sometimes it's to my detriment, but I love people so much that I will remember things about them that maybe they said two years ago and they're like, "How did you know that, that's creepy." But, I think it goes back to Strategic Alliance, it's all about relationships. Brian Walsh: 21:46 Right. It's a people job that you're doing on there. And I think you've raised a great point, as part of the ISV program at Salesforce, you start with your partner account team. And so that partner account manager will help actually put together a go to market strategy for you to say how are we actually selling with Salesforce and make the initial introductions and get that ball rolling for you. Yeva Roberts: 22:06 Yep. Absolutely. Brian Walsh: 22:08 And I find that unique within as we look at, if you compared infrastructure, if I'm going to go to an Amazon or decided to do this on my own, walking into these ecosystems, that's one of the things that a great ecosystem is provided for you. Yeva Roberts: 22:20 Yeah. And there's a nuance to also working with your PAMs, partner account managers, because imagine they also have like 40 some ISVs that they're managing. So you have to be super helpful with them as well in terms of getting to your point very quickly. Brian Walsh: 22:40 All right. So what are some tips of managing that partner account relationship now? Yeva Roberts: 22:43 Wow, we're jumping around. So with the partner account managers, I think being organized for those 30-minute cadence calls that you have with them is always helpful. I think that's my number one tip is, you can rely on your partner account manager to do that for you. But it's actually easier if you do that because you know you're fighting for mindshare against all the 20 to 40 ISVs that they're working with. And on that call, be super clear on what your number one, just pick one thing that's important to you for the next two weeks before your next opportunity to speak to them and get support from them. I think being super organized and just having a bit of humility and patience, understanding what their situation is also helps. And then just follow up. I think following up with them is always super helpful and then celebrate those wins. So every single time we close a deal and the partner account manager helps us manage our Chatter community, and they'll send up "cha-ching" emails on our behalf, that helps them also get more visibility into the community of AEs and solution engineers we support. So you want to celebrate those wins together because it makes it super real for them and they appreciate like, "Why are you asking me for all these introductions and I never get to see the results?" But when you celebrate those wins, they get to see it from, "Oh wow. That account team introduction that I just made for Yeva four months ago actually resulted in a deal." And that's how they get incentivized, obviously, as we help them retire their quota. Brian Walsh: 24:25 So leveraging that Chatter group is actually what's pushing them to help encourage them to keep doing those introductions and bringing them out back top of mind for them. Yeva Roberts: 24:41 Yeah, our Chatter group has over, gosh, 350 AEs and solution engineers now, and I think growing a community is really important to us because it's really that resource for them for content. Trying to get teams to adopt other portals if you will. We've tried that, doesn't work. So keeping everything in the Chatter group is definitely worth it to us and something I don't see a lot of ISVs using. Brian Walsh: 25:02 Now, when you first built and you're using it, I mean it wasn't part of Salesforce yet, it was a standalone ExactTarget company. Or had it been acquired already by Salesforce? Yeva Roberts: 25:14 So the Chatter? Brian Walsh: 25:14 No, PFL, was first ExactTarget and then it was acquired by Salesforce later, right? Yeva Roberts: 25:21 Exactly. So yeah, by the time I joined the team, I think it was already part of the Salesforce family or was going through the acquisition actually. Brian Walsh: 25:32 Got it. Okay. How important has Chatter then grown because, at that point, the ExactTarget side wasn't using Chatter at all, like how did that grow? How does Chatter drive sort of your day to day use? Yeva Roberts: 25:45 Yeah, so that's funny you're making me think back. So when we first started we actually had to host two separate Chatter groups, one for org 62, which is where all the core team members were on Salesforce, and then one on NA7, I think it was called. So it was a different platform, but still Chatter. So two different communities and about probably two years into the acquisition they merged the two Chatter groups and so we ended up with one. But yeah, I think they still asked the ExactTarget marketing cloud team to start using Chatter. Brian Walsh: 26:21 Got it. And now, does your product work across the multiple clouds at Salesforce or is it still just marketing cloud? Yeva Roberts: 26:27 No, it's force.com. So we have four different apps. So because of that, it is extensible. I joke around, we just got back from connections and because it was the first time they brought service, commerce, and marketing cloud together, we had a lot of questions about, "Well I see your app working with sales cloud and marketing cloud, but what if we wanted service cloud?" And I'm like, "Well, it's extensible through the entire-" Brian Walsh: 26:53 It's just force.com. Yeva Roberts: 26:55 Yeah, exactly. So it was just like, "Of course," but I realize that not many people know that. And not that we even push that, we're trying to be super focused and not, like I said, boil the ocean, but if somebody asks us to, we could. That's the beauty of it. Yeah, that's the beauty of it. Brian Walsh: 27:15 We do an annual report, the State of the AppExchange Report and it was one of the most surprising to me findings in it is, how many of the ISVs are actually working across three, four, five different clouds and supporting it and actually leveraging that for all their growth. Yeva Roberts: 27:32 Yeah, I think coming up connections, it was super clear to me that, that's part of the growth strategy is cross-cloud. So the ISVs that can go cross-cloud, they're going to be the ones that are going to stand out from the pack. I think I heard that Salesforce wants to go from what, some close to 4,000 apps to 10,000 by 2020 or something. Did I read that in your report? I read it somewhere, and I was like, well, obviously going to your existing AppExchange partner base and encouraging them to create additional apps that can extend cross-cloud, as part of that strategy in terms of how they are going to grow from three and a half to 10,000 in a year and a half. I think that's part of it. Brian Walsh: 28:17 It is. There's actually a team on the ISV team whose only job is to help bring on partners onto all the new products that they're acquiring and launching. So as CloudCraze comes into the mix and as marketing cloud, and like each of these pieces gets built in, they want to bring that entire ISV ecosystem with them. So big focus on Quip, big focus on CloudCraze, all of these pieces. Data.com is starting to go away, and so they have lightning data service. So there's all of these opportunities and you have a team just focused on trying to get you onto a multi-cloud strategy. Yeva Roberts: 28:51 I didn't know that. I love that. Brian Walsh: 28:53 All right. So if you were to give people an idea, they're out, they're an ISV, and they're wanting to start building out an alliances team. They need an alliance manager. What do they look for? What's the type of role? What's the type of person that they're looking for to be a great alliance manager? Is it someone who's worked at Salesforce? Is it someone who's done that before? Or is there just an innate attribute about them that would make them great at this job? Yeva Roberts: 29:20 I think it goes just to DNA, because case in point is I had no background in Strategic Alliances. My background is all product marketing or in digital marketing, and so I'm proof that as long as you value relationships and you have a good strong business acumen and, you know, you can be passionate about whatever the problem the ISV is solving, you can succeed in this role for sure. Brian Walsh: 29:46 And it looks like you've been successful because PFL just announced some big news recently, right? Yeva Roberts: 29:54 Yes! We just got our funding round from Goldman Sachs for $25 million, I think it was announced in April, and now we're ramping up and hiring, building out an evangelist team. So if you're interested, definitely look me up. I'd give you some referrals. I'd love to build out a great team. Brian Walsh: 30:11 That's awesome. I might quit my job and join you then. Yeva Roberts: 30:14 I would love it. Brian Walsh: 30:16 If somebody wanted to get in touch with you, had questions, or maybe even wanted an opportunity to work with you, what would be the way to reach out to you? Yeva Roberts: 30:23 I think LinkedIn is probably my favorite platform. Definitely just message me, I'm pretty responsive there. Brian Walsh: 30:28 Fantastic. Well Yeva, thank you so much. I really appreciate this, and best of luck as you look forward. Yeva Roberts: 30:35 Thanks for having me on. Outro: 30:37 Thanks for listening to this episode of the AppChat. Don't miss an episode. Visit appchatpodcast.com or subscribe on iTunes. Until next time, don't make success an accident.

Jay Abraham, founder of the Abraham Group (and departing COO of CloudCraze, acquired by Salesforce in March), joins the AppChat to discuss his fascinating journey from nuclear physicist and submariner to highly-sought-after startup consultant, as well as what goes into a great (read: productive) relationship between a COO and CEO. Also addressed is: defining scale and how an organization prepares for it; how to know your organization needs a COO; and mistakes Abraham learned from in the trenches at CloudCraze and in his career. Here are the key topics, with timestamps, as well as the full interview transcript: Key Topics 00:00-1:56 Introducing the AppChat and our guest, Jay Abraham (formerly of CloudCraze) 1:57-4:35 Abraham's early career as a nuclear physicist and submariner before he held multiple COO positions 4:36-7:40 Experienced gained from handling the outsourcing of American Express' IT infrastructure 7:41-9:53 Transition to becoming COO of CloudCraze 9:54-16:42 The relationship between COO and CEO, and creating processes to delegate responsibilities 16:43-18:42 Defining scale and how an organization prepares for it 18:43-22:46 The cultural shift that happens when processes are defined and put into place 22:47-25:44 At what point does your organization need a COO? 25:45-31:02 How a CEO begins a great partnership with a newly hired COO 31:03-33:56 Giving power to employees to help identify and solve problems cross-functionally 33:57-36:37 Mistakes that Abraham has learned from 36:38-37:31 Closing out and how to get in touch Full Transcript Intro: 00:01 You're listening to the AppChat. A podcast focused on SasS growth strategies, plus successes in the Salesforce ecosystem and beyond. Here's your host, CodeScience CEO, Brian Walsh. Brian Walsh: 00:13 Alright everybody, welcome back to the AppChat podcast. And thrilled to have with us today, Jay Abraham, who is coming to us most recently from CloudCraze, and they're fresh off of their acquisition by Salesforce, which actually just closed last week. Welcome, Jay. Jay Abraham: 00:28 Welcome Brian, thank you very much. Brian Walsh: 00:32 Yeah, absolutely. Jay, before we get into you, give us a little bit of background, who was CloudCraze, talk about the acquisition, just what happened there? Jay Abraham: 00:41 CloudCraze is, I'd say, one of the foremost B2B e-commerce platforms. It's built natively on Salesforce, so it's tremendously helped our growth and scale, and obviously that was recognized by Salesforce by their recent acquisition of us; and I congratulate them on our acquisition and I think they're gonna have a wonderful future in the years ahead. Brian Walsh: 01:02 Fantastic. I think another statement of how amazing the Force.com platform is to be able to support an application this complex, as CloudCraze across so many large enterprise companies. Jay Abraham: 01:14 That's true, I think one of my team members on the product management side, was very appreciative. She came from one of the competitors, and she said that the biggest thing she recognized is that she didn't have to worry about the backend. But she had to worry about customer facing issues, giving them the capabilities they wanted, and that relying upon the Force.com platform allowed them to leverage everything they could -- and there's a whole team at Salesforce, obviously, building upon the Force.com platform. Brian Walsh: 01:47 Yeah it's such an efficient capital spend to not have to worry about that part of your infrastructure, the pager, all of those headcount just to manage what servers are up. Jay Abraham: 01:56 It is. Brian Walsh: 01:57 Awesome, so let's actually back into you, in your role getting there. So I mean you've done the COO role dozens of times in your life? Jay Abraham: 02:07 Officially as a COO, this is probably the first time. But I think I actively fulfilled the role as a Chief Operating Officer in many projects, both working at company's directly as well as being brought in as an executive troubleshooter. When people think about a COO, it's somebody you can give the mess to. The stuff that nobody wants to deal with, that's the COO. Brian Walsh: 02:34 I love that tagline on your LinkedIn profile, executive troubleshooter, because that's always been my experience of "Yeah, yeah, I got that. I'll take over." Jay Abraham: 02:43 Right. Brian Walsh: 02:44 But let's go way back in time. You actually were a nuclear physicist. Jay Abraham: 02:49 I was. That's what started off my career. I went to MIT. To think I built fusion power plants at the time. It was a really long time ago, 1983. When my professors convinced me to build one. Assuming all the technical details were completed and I figured out it would cost two billion dollars in 1983 dollars to do it and we'd have all the problems that we had with fission. The length of time that I would have to teach and do research before I could actually build the power plant would be 40 years and I'd be retired by that time. So I decided I'd do something else. Brian Walsh: 03:26 But it didn't end there. You actually became a submariner to practice at first, like hands on. Jay Abraham: 03:32 I did. It was kind of interesting to me. It started off at undergraduate school as a theoretical physicist and now to become a submariner you have to become a practical engineer. It was probably the genesis of my experiences being a Chief Operating Officer, because being on a submarine, you're responsible for everything that happens. And you need to, as Officer of the Deck or Engineering Officer of the Watch, you basically need to know how everything works. Even though you may not be the expert, you've got a lot of enlisted people who are -- the reactor operator, the electrical officer -- you need to be able to synthesize all that information and say, "This is what's important." And I think that's helped me a lot in my career going forward. Brian Walsh: 04:14 I can imagine. Does it also give you a whole background of jokes to say of "Hey guys, this is not nuclear physics." Jay Abraham: 04:22 I try not to say, because it was silence service in the submarine service. Everybody talks to me about telling all the stories and I can't really talk to them about it. Brian Walsh: 04:36 And I think when I was first starting to get to know you, the story that really broadened me of just the scale of things that you've done, was handling the outsourcing for American Express of their IT infrastructure. Jay Abraham: 04:48 That's true. It was an interesting project. We came in and the CFO for the technology group needed somebody to kind of lead point on financial evaluation. You go in and the technology team really wanted to outsource, which is very different in most companies. Most companies, the technology team would actually like to keep everything in-house. In this case, American Express had aggressive goals on reducing technology costs. I think the technology team felt like they wanted to step out of the way and give it to someone else to do and we said "Before we do that, let's figure out actually how the economics work." We can't just ask somebody to come in and give us a cost and say, "It's lower than what we're paying today, that's great." We build a model to kind of predict what we could actually, as American Express, reduce costs to. Then, each of these vendors bid against those costs, so we could compare, you know. These were, in the old days, we're talking about main frames, mid-ranges, desktops. We came up with unit pricing on each of those in MPS or server units or PCs and said based on various categories and scenarios of how things might play, here's how the cost would look for every vendor, as well as the internal vendor, and that's how we compare them. Brian Walsh: 06:10 Now did you have a big IT background at that point? To understand all of those individual units and how that built up? Jay Abraham: 06:18 No, I didn't have that IT background at the time. I had some technology background with my prior career with Mitchell Madison, I was a partner there. We did a lot of strategic sourcing and this is somewhat similar to strategic sourcing -- you need to understand base economics of both the vendor and yourself to see what lever needs to be pulled. My team had that background. I gave that direction on how to build it. We talked to technology people within American Express to say, "What are your parameters and what can't you do? What can you do?" And we helped them think through it. I think, a lot of this, people talk about technology being too complex to understand. My general impression has been that people think too much about what they don't have information from as opposed to what they do. Brian Walsh: 07:11 Yeah. Jay Abraham: 07:11 I mean, you can take whatever you have information on, make assumptions, simplifying the other type of things that you do have -- or you don't have -- and use that to be able to create a model or create a hypothesis that you can test against. Brian Walsh: 07:25 That's amazing. So my take away is you're a savant. Jay Abraham: 07:31 I think most consultants have got an ability to be able to synthesize and take useful data from a mess of information. Brian Walsh: 07:41 Yeah, that's exactly right. I know that it worked well for you as you transitioned to CloudCraze, because you had known Chris beforehand, right? And he was bringing you on just to sort of manage a couple of the pieces outstanding? Jay Abraham: 07:56 Right. Chris and I had known each other from marchFirst days, which is about the tail end of the time I was a partner in Mitchell Madison, which was a consulting firm. They got acquired by a company that Chris was part of and he and I knew each other. He was on the technology side. He'd always come by and borrow my people to help sell some of his engagements because we had this strategic mindset. Chris had always wanted to get me involved in some of the companies he'd done. His prior company, Acquity, which didn't work out because I had some projects going on at the time and was just too busy to get involved with it. At this point, with CloudCraze, he asked me to get involved and I started off helping him with certain areas in pricing. Went to contracts and poked into different areas until they said, "Well, you've been doing a lot of stuff. Why don't you come on as the Chief Operating Officer." Brian Walsh: 08:47 Yeah. And at that point it truly was just 20 hours a week. Jay Abraham: 08:55 Right, yes. It was just an ethic. They didn't have a clear role for me. I kind of defined my role as helping them set up the parameters so they can scale. You talked about what a Chief Operating Officer would do -- I think the most important ability for Chief Operating Officer is to help set you up to scale. A lot of people don't think about that until they start running into problems, and if you get a Chief Operating Officer early, then they'll start thinking about those things. The other thing I think is kind of risk management, which when you're growing a startup and are an entrepreneur, you're not really thinking about downside risk. But think about why you hire lawyers. Brian Walsh: 09:36 It's never for the great moments. Jay Abraham: 09:40 Right. It's to protect you from those moments you didn't really think about. That's the other thing the Chief Operating Officer should be helping you with, is to think about -- what are the things to scale and what are the things that can come bite you and to stop that from happening. Brian Walsh: 09:54 Yep. So Jason Lemkin, who founded EchoSign which Adobe bought and that's their Adobe sound product now. Sasstr fund, he runs the Sasstr conference. He tweeted recently, "A COO's job is to make the CEO's life easier." Jay Abraham: 10:16 I'll agree, that's probably true. If you think about a COO or Chief of Staff for President, et cetera, that's pretty much effectively the same role. You are to make everything easier for the president or the CEO, and get rid of all of those details. COO's should think about strategy division. COO should be thinking about, "Well, how do I make that vision a reality?" Brian Walsh: 10:35 Yeah. So how much of that is the chemistry between the CEO and the COO? How much of that is strengths and weaknesses? Because I can imagine that COOs play a different role depending on the strengths of the CEO then. Jay Abraham: 10:50 I think that's probably indicative more about what a CEO specifically focuses on, as opposed to what they do. I've talked with many CEOs, in my role as COO at CloudCraze, I had responsibility for all the back office functions, all the technology areas, etc. What it didn't have was kind of a front customer facing, but I've talked with a lot of COOs in other companies where they spent most of the time on the front in the sales end. I think that's just a matter of what role is needed in that company at that time. It could be, in our case, Chris focusing on strategy. We had Ray, who was our Pricing and Chief Customer Officer. They all worked closely together with each other from Acquity days, so they all knew how to work. Chris trusted me, so basically brought me in, said "Run with it. Decide what you want to do. Let me know if you have any issues or what you need." Brian Walsh: 11:59 Got it. I know that in my case I hired my COO back last summer. It was the very first time in my professional career where a new hire made my life better in two days. Like I turned around and said, "Oh my gosh, it's gotten that much better." And what I realized is that it freed me to actually think about two things. One, where I applied best. What was my skill set? And two, allowed me to truly focus, because up until that point, I was doing 300 different things and it can peel down. And you're right, stepped in and said, "Hey, I'm going to help you troubleshoot these areas and start to fix them, prepare for scale." Jay Abraham: 12:38 Right. You have to have that chemistry between the CEO and the CFO, and Chief Operating Officer and the rest of the executives. They have to be able to trust you to be able to go in and say, "These are the areas that are critical to fix right now and here are things we can defer." But also don't be defensive about a Chief Operating Officer coming in and saying to people in your areas, "Oh you need to change your human metrics. You need to start tracking and collecting this type of data." Brian Walsh: 13:10 Right. Jay Abraham: 13:12 Because you're not going in there to try to rip apart their organization, you're trying to come in there and say -- even in the sales area, which wasn't my responsibility -- I'd come in and say, "I want you to start collecting this type of data because that will help us tell what our conversion rates are. What's the cost per lead in various forms." And those are things that are important and will help the entire organization. Brian Walsh: 13:34 Yeah, and I found it is essential to have that second set of eyes, to really look in and say "Hey, you're already successful, but I think we can do a little bit more and let me collect data to help prove that." Jay Abraham: 13:48 Right. That's one of the things, but I think the other thing, it's real good, it goes back to scaling. In a small organization, everybody's working intuitively, in a lot of respects. For example, when we're making decisions on a contract and how much we're willing to give off of our list price, or what risk we're willing to take, those are done by the Chief Executives and they're making that as sort of, "Can I take that level of risk?" You're not quantifying it because it's a small organization and you can figure that out as you go through. Brian Walsh: 14:27 And you also think in your mind, you're thinking, "Hey, I'll be there to fix it if it goes wrong." Jay Abraham: 14:31 Right. Exactly. What goes on later is, as you bring more people into the organization and start to delegate some of those responsibilities, they don't have that same intuitive feel in business that you may have had. They may be doing things the same way you would have done them, but not doing the same exact thing. That starts to become a problem when you start scaling because you really want people to follow consistent processes at that point in time. Right? Because especially if you go to a funding event or a liquidity event, the lawyers and other teams are going to say that, "Well, what's your standard processes? How do you do this? What are all the exceptions?" And if you don't have a systematic way of doing that, it's going to be very hard. Jay Abraham: 15:19 Simple one for me was setting up processes say, well if you want to give a discount off of the price, up to certain level, it can be done by VP of sales. At a certain level it's got to go to the president. If you're taking on levels of risk that haven't really been defined yet, it needs to go to the board or certain other people to figure out how that should be done. It could be things like, what's important to you? Is it margin? Is it revenue? Is it risk? Brian Walsh: 15:54 Do you find yourself putting in that process, or do you find yourself asking the questions to assist other people in putting together that process? Jay Abraham: 16:02 Well, in most of my stuff, I think I've had to put in the process. I actually drive that to have other people think through it, and then we actually have to put in the process, say, "Ok, well this is how it's going to work when the contract comes in." I will come up with a table that says, "Here's various permutations of this." I'll give this to my legal counsel and say, "Hey, now when you talk contract to a salesperson, if their negotiation points on these five areas, then you know how to handle those five negotiation points." And there are exceptions and you can go to various people to get approval for those exceptions. Brian Walsh: 16:43 Got it. You've said the word "scale" five or six times now and I agree completely and that's one of the things we're embracing right now is we're growing so rapidly. How do you define scale? Why is it different than other parts of the business? You were truly on escape velocity for scale. Like, how do you define scale and how does an organization prepare for that? Jay Abraham: 17:05 I think I define scale as both velocity -- which is how rapidly you're growing -- and the size -- how big you are. My experience has generally been, the more you can think about standard processes and procedures -- and this goes back to my Navy nuclear submarine background, which is we would practice every single drill, possible, everything that could go wrong, so we would be prepared for it if it actually did -- that's what really helps a company out. When you're young and you're five people, it's hard to think about those things; then, you're 20 people and you're still going rapidly. Again, it's very hard to think about it. If you think about it then, and start making some standard processes, even if it's white boarded out -- take a little picture, say "This is our process." It will start progressively getting more difficult and then you'll get to a point where you're racing along and you're a race car, and now you're having to rebuild the chassis and the wheels while you're going 200 miles per hour. The earlier you start the processes of setting up standard processes, the easier it is. Obviously, if you wait until you get a Chief Operating Officer to do that, then it's usually too late to help out immediately. So it becomes harder. Brian Walsh: 18:43 I would imagine there's a huge cultural shift that happens. When we're a small startup, it's truly just art. There is no size to it. Right? It's just art, we're making it up as we go. We're making up these rules, we're just disrupting the market -- in your case it was B2B commerce, and all of a sudden we're going to put process in, we're going to define things. Did you find that there was this real pull with the organization for people who had been there a long time of, "Oh my gosh, we've never done it this way. Why do we have to define it all?" Jay Abraham: 19:10 I think that there are always people who object to that, but I think in general, my experience has been, putting the processes in actually made people feel like they knew where to go. Especially the new people. Some of the people that had been there and had all that intellectual knowledge in their head about how the organization works and could do it; they were very few and far between. There were a lot of people who were just, "I don't know where I can get that information. What can I discount the price to? How do I solve this issue with Salesforce?" Part of the steps of the process is, you have in that document of knowledge, so that anybody can go access it, as opposed to you always having to go to the one individual and they talk to you and that individual is doing a thousand things and they don't have time to talk to you. Brian Walsh: 19:10 Right. Jay Abraham: 20:11 And so I think, you do have people who say, "I don't want to be that rigid Fortune 100 company that takes forever to get things done." And I don't think putting processes from scale necessarily will lead to that. You still need to be flexible, you still need to be entrepreneurial, you still need to be able to make decisions in a collaborative environment without having to have 20 committees. You can still provide the processes and the tools that allow people to say, "Oh I know exactly where to get that information." Or "I know exactly who I need to go to get something approved by." Brian Walsh: 20:51 Eric Ries who wrote The Link Startup who has such great writings was recently on the First Round blog with an article around gatekeepers. And I think he's addressing some of those things of, those areas where they become gatekeepers, whether it be legal counsel or finance or admin, to actually bring them to the table to collaborate, rather than leaving them to the last minute. Because that just creates roadblocks and delays, so actually bringing them into the process so they become part of that decision-making process and everybody gets informed through it. Jay Abraham: 21:25 No, I think that's very important. A perfect example I can give with our teams is the sales team would not necessarily bring my engineering team into a sales pitch until well after they promised certain capabilities and certain things we were going to deliver. And then the engineering team would come in and say, "Well, how did you promise that? That's a very risky environment, right?" And I don't think they understood that they could do that. But on the converse, I kept telling my engineering team, "What have you provided the sales team to come say, 'Here's the sweet spot.'" This is kind of the like the boundary areas of what we should be playing in and to go outside, I call them green sweet spot, but yellow, you should be cautionary about doing anything like this. At the time, if you go into the yellow framework, that's a good time to call product management engineer and say, "Let me hear your thoughts on whether this works or not works." And then there's the red area, where things we shouldn't be playing in because that's not our core competencies. Brian Walsh: 22:34 I can't believe that sales would ever sell something that doesn't exist yet. Jay Abraham: 22:43 Right, when you're doing enterprise sales, you can always promise to do that. Selling a product? People expect it to work. Brian Walsh: 22:47 That's right. So if you're a CEO or you're on a board, when do you know your organization needs a COO? At what point? I mean, is it ARR? Is it number of employees? At what point is it like, "Holy crap, we need to have a COO in here to start helping." Jay Abraham: 23:02 Well, it depends on how you define your COO. So if the COO is just a responsibility that one of the other members of the executive team has, then I think you should start it pretty early in that mix. That responsibility is to set you up for growth, right? Brian Walsh: 23:19 Yep. Jay Abraham: 23:19 Okay, the President, Chief Customer Officer, the Head of Sales, it could be engineering. But somebody's got that role to go over and above their normal role and to set up processes and standards, right? Brian Walsh: 23:33 Yep. Jay Abraham: 23:35 You can do that. The other area is, you know you'll have a COO if you do. You haven't set up those standards and processes, and things start breaking or your growth stumbles or your people start leaving or your technology is always behind schedule, right? Some issue is going to come up and say to you, "Hey, I need somebody to get a handle on this." And that's when you know you've got a COO. But I'd say that's probably the wrong time to bring in the COO because it's going to be expensive and it's going to be hard and it's going to be culturally difficult. But the easier time is to bring them in well before you need it. Brian Walsh: 24:11 Yeah, I mean it's always easier to see it after the fact. Jay Abraham: 24:17 Yes. Brian Walsh: 24:17 It's hard to have that foresight to say, "Hey, we're about to run into these problems in there." Did you participate in fundraising? I mean, were you just running the business while Chris was out fundraising? How did you help the organization during that process? Because you raised some incredibly large rounds there as CloudCraze grew. Jay Abraham: 24:38 I wasn't very involved in the fundraising aspect. Chris, Paul our CFO, and Matt our CMO, were the primary investors, they were the ones who were primarily focused on the fundraising. What I was able to help with was, the very fact that we set up quarterly business reviews and gave key metrics to every department we were supposed to track -- that allowed them to provide that information to investors in a much easier format without actually having to scramble about. Then this latest round, when Salesforce acquired us and went through the due diligence process, we had prepared most of the material they were looking for. So it's easy for me to just pull it around and go and say, "Okay, we already have this." As opposed to going and creating this. Brian Walsh: 25:26 Got it. That must have made that process go much, much faster than for everybody involved. Jay Abraham: 25:32 I don't know if it made it go faster. At least easier to pull the information from our side, and we didn't have to have much disruption to our normal business. Brian Walsh: 25:45 That's good because in the end, they're acquiring a fast growing business and they want that to continue. If you're a new CEO, and you have a COO that you've just hired, what would be some guidelines that you would offer both parties? Like how do you begin working together? How do you begin that great partnership? Jay Abraham: 26:08 I think the CEO has to be honest about what's worrying him. What are the things, that if he had time, he would be doing? Brian Walsh: 26:21 Yeah. Jay Abraham: 26:23 And then what are the areas he says, "I just trust the people to do this and never checked on this." But it's probably worth somebody checking on it. I think we even consider trust. Trust but verify. And I think that goes for a lot of things. I see executives getting into trouble when they trust but don't verify. Or they may say something at a high level and their direct reports may tell them things are working at a very high level, but nobody asks the detailed questions I think. Something that a Chief Operational Officer has to be able to do very well is to helicopter -- go from seeing the big picture strategy to going down to the levels of detail to say, "Does it actually work the way that I think it's going to work?" Brian Walsh: 27:11 Got it. I know you definitely got down to the details. At one point, you were actually answering all the customer success e-mails, right? Jay Abraham: 27:19 I wised up when my product support team manager quit and we lost several people. I was helping out by going through and helping my team to be able to look through things and help them fix some of the issues. It was actually a good thing for me because I got to see a lot more of the problems that customers were raising about the product. Things from documentation, from implementation, installing the application, uninstalling the application. And I was able to say, "Okay, well, let's start a project to fix the documentation. Let's create an installer. Let's start collecting data that allows the customer success team give the engineer product management team to say, 'Here are the problems that the customers are raising. Here are various areas of the product it's impacting. Let's put more resources on those areas to fix those issues so we reduce the number of product calls or reduce the issues that our system integrators were having.'" Brian Walsh: 28:25 It's always amazing that you never actually get those insights until you experience it first hand. Jay Abraham: 28:30 That is very true. Previously in my career, I used to run a consent order for one of the independent foreclosure reviews. I came into this project very late in the game. By the time I went down to the real core issue, which was how they ran and did the actual reviews of these projects, I started saying, "Let me try to answer the questions that we're asking all of these mortgage underwriters to do -- myself." And seeing what questions that come up in my mind. Then you can start saying that people write processes, but they never try to run it through themselves. Until you run it through yourselves, you don't really know what gaps there are. One of the things I would tell my teams is, "After you've run it through yourself many times and you've figured out all the answers and you've actually put in the answers and filled it out, just like someone else you're asking to do would do it, then find somebody else who's brand new, who doesn't know anything, and make them go through it and every time they come and ask you a question, you know that's an area where you actually didn't put enough thought. Brian Walsh: 29:48 Right. Recently our Senior Director of Delivery, Kim, was out for spring break. One of her direct reports, Jake was out as well. And so our COO, both report up that way, basically had to fill both of those shoes. He came back every single day with "Oh my gosh, I had no idea everything they did." And it was this uncovering process of "I now know what we can fix over the next two months." Like, if we knock these things off, we become so much more efficient. Jay Abraham: 30:18 It is. It's very helpful for senior leadership to experience that. Because what you typically find is middle managers, they know what the problems are, but they're so used to it happening that way. Brian Walsh: 30:32 They don't need to solve them. Jay Abraham: 30:34 They don't need to solve them. And they also figure out that's the way it goes. They don't have the authority to fix it. And it's only when somebody in executive management goes and says, "Why are we doing it that way?" And they're like "I thought that's what you wanted." And you realize that "Well I don't need that information or I don't need it done that way." You're the only one that's going to be able to get that perspective and saying, "Operating across multiple departments or multiple silos, here's how we can think about it." Brian Walsh: 31:03 Do you think it's possible to create a culture where middle managers do feel empowered to make changes like that? To look inside? Or is that a skill set you develop over time? Jay Abraham: 31:13 I think you can empower middle managers to raise questions and to challenge, but it's also a skill set. But it's also time and perspective. When you are a middle manager, you're working in a functional area, so it could be sales, right? Brian Walsh: 31:34 Yep. Jay Abraham: 31:35 And you're the account executive doing things. You go and say, "I'll need this information. I need this." You may be able to say, "I got problems getting that information." You don't know why you don't have that information or why you might have limits on things. You may be saying "This is what I've gotta do," but you don't have the perspective of what the sales team is doing. And so part of it is, you need to be higher up in the organization and have a perspective over multiple areas. Brian Walsh: 32:04 Right. Jay Abraham: 32:04 That breadth of experience is what helps you say, "I can solve things that middle managers can't because they don't see the whole picture." Brian Walsh: 32:11 It's that tee in leadership or tee in management where the more senior you become the wider breadth that tee has to become. So you see more and more groups and how they interact. Jay Abraham: 32:24 Right. And that's very important. That's why I think when people get afraid about going into big companies, because that tee is so high level, they start worrying about how long it takes to fix things. And because they go up in silos, until very senior level, you don't get that perspective to be able to say, "You really, actually, don't need to have those silos." And that's a cultural thing, because as you go from a small company to a medium size company to a really large enterprise, you have to be able to give people that authority. Not just even just the authority, but I think you want them to have the willingness to be able to challenge those things and go across silo boundaries and say, "Think about it." And talk to people in other organizations that, even if you might not have the authority to fix it, as long as you guys talk you'll be able to identify the issue. Brian Walsh: 33:24 I find especially in large organizations, working with some of our gigantic clients, that cross functional ability can be so rare. To actually think, "Hey, I'm only in the product group. I don't know what's going on in sales, or enablement, or finance." But those that do, are the rising stars. They work so quickly and assemble teams that actually get stuff done. Jay Abraham: 33:44 Yep. The very fact that many people don't do it well is really why I've had a very successful consulting career, because of that ability. People hire me just for that. Brian Walsh: 33:57 That's awesome. So any mistakes that you made over your time at CloudCraze that you're going to learn from and not make again. Something that you can share with everybody. Jay Abraham: 34:08 I think the biggest mistake I made with CloudCraze initially was, I didn't dive deep enough into the engineering team and the way they work. It took me three to five months until I figured out that the amount of resources we were putting against engineering was insufficient to do what we really needed to do. Because there were a lot of things core to the product that actually needed to be fixed, and I only heard that after my Product Support Manager quit and I had to start hearing those calls. I started saying, "Why are we focusing on creating all these new features when we have all these fundamental features that were broken that it wasn't sexy to sell?" Understanding that was a paradigm shift to say, "We need to stop creating all these new features. Fix the foundations, then we can set it up to scale and say, 'Here's the new feature we want to focus on.'" Brian Walsh: 35:16 I was always blown away by just how small your product and development teams were. Jay Abraham: 35:23 They're a great team and they were stretched immensely to do a huge job. I mean B2B e-commerce is a very complex system to be able to do, and building different capabilities into the platform -- which is what sales was doing -- those teams, my teams, were actually aggressive about saying, "Okay, sales says we need this and we're going to go do it." One of the things I had to coach them on was, "But you knew all these things were broken, why didn't you say something?" They say, "Well I did." And I said, "You gotta say it in a much louder voice or jump on the table and say, 'No, you gotta fix this.'" The security's important, scales important. We can't do this without doing that. And so getting down to culturally field it, it was also their job to decide what was important. It was a big part of what I worked with them over the last year. Brian Walsh: 36:21 Awesome. Well, I am absolutely positive that wherever you end up next will be the luckiest company on the planet to get your skill set. Now, if somebody wanted to get ahold of you, what's the way to get ahold of you? Because you're not another Jay Abraham online, are you? Jay Abraham: 36:38 No I'm not. I'm not the multi-level marketer, a lot of people recognize me as that. LinkedIn is obviously the best way to do it, but I have my own consulting firm. It's j.a@abrahamgroup.biz. So that's the easiest way to get ahold of me. Brian Walsh: 36:59 That's awesome. So abrahamgroup.biz to find you and obviously LinkedIn, you're not the one with the beard. Jay Abraham: 37:05 I'm not the one with the beard. Brian Walsh: 37:08 Fantastic. Well Jay, congratulations on the exit at CloudCraze. I know you played such a significant role to prepare them for scale and accomplish the hurdles, and I look forward to keeping up with you and see what you do next. Jay Abraham: 37:21 Thank you, Brian. Brian Walsh: 37:25 Alright, thanks everybody. Again, Appchatpodcast.com or you can find us on iTunes. Have a great day. Outro: 37:31 Thanks for listening to this episode of the AppChat. Don't miss an episode. Visit Appchatpodcast.com or subscribe on iTunes. Until next time, don't make success an accident.

Dory Weiss, VP of Engineering at nCino, joins the AppChat to talk about embracing the Large Scale Scrum (LeSS) methodology in developing cloud banking products on the Salesforce platform. Other subjects include her unusual start as a writer of code, maintaining company values amid growth, “pollinating” ideas across teams, and a way to show off sprint work while having fun in the process. Here are the key topics, with timestamps, as well as the full interview transcript: Key Topics 0:00-2:25: Introducing the AppChat and our guest, nCino VP of Engineering Dory Weiss 2:26-9:23: Weiss’ early career as a graduate student in English, her transition to coding, and the similarities between the two languages and ways of thinking 9:24-15:00: Scaling personally and professionally by sticking with nCino’s culture and core values 15:01-19:02: Giving out football helmet stickers in recognition of core values, and the tight alignment between nCino and CodeScience that stems from culture 19:03-24:29: How to hire, onboard and train a good culture fit -- making it “emotionally safe” for development and growth, and weighing technical and culture qualifications 24:30-30:20: Moving from agile to large scale scrum (LeSS methodologies) and dividing teams while prioritizing the right work to get done for clients 31:21-38:56: Managing scrum relationships and integrating work responsibilities to balance speed needs while reducing silos and “pollinating” across teams 38:57-42:01: The “review bazaar” process for presenting and evaluating sprints like a science fair 42:02-42:50: Closing out and how to get in touch  Full Transcript: Brian Walsh: 00:13 Okay, everybody, welcome back to the AppChat podcast, and this week, as our promise is, we're gonna have colorful people in amazing SaaS companies. We have with us Dory Weiss from nCino, who's VP of engineering. Dory, introduce yourself and nCino. Dory Weiss: 00:28 Hey Brian, yeah, hey. Great to join you. I am Dory Weiss, as you said. I'm the VP of engineering at nCino. I joined nCino in 2013, which is one whole year after nCino started in 2012. I started in 2013 as a developer. I was the fifth developer when I joined and I think I was employee number 38. Now a mere five years later we are just over 450 folks. We've gotten really big. We are spanning a couple of buildings now at this point, which is exciting, and we've gone international, so it has been a crazy ride over the last couple of years. Dory Weiss: 01:11 nCIno, for folks, who are not familiar with us, we are the worldwide leader in cloud banking. What we do is we make it possible for banks to originate financial products more easily and with more transparency into what they're doing. Brian Walsh: 01:27 You're built entirely on the Salesforce platform? Dory Weiss: 01:31 We like to say we're built 99 percent on the Salesforce platform. Brian Walsh: 01:35 There's always some little piece that you have to do outside? Dory Weiss: 01:37 There is a little bit of magic that we can't make work on platform and that makes us a little bit sad, but those things that we need to do off platform, we do. Brian Walsh: 01:47 That's pretty amazing, though, that these large banks ... Because your customers are the who's who of the banking industry, right? Dory Weiss: 01:54 Yeah, I think at this point we have 10 of the top 30 banks in America as our customers in terms of asset size, so yeah, but also not just the largest enterprise banks are customers. We have 180 customers spanning institutions of all sizes. Brian Walsh: 02:16 That's amazing. Alright, so, you're the fifth developer at nCino. How did you get there? You had a very different course to get into becoming the fifth developer and working your way to VPE. Dory Weiss: 02:26 Yeah, frankly I never quite know how I ended up where I ended up. I learned a couple of years ago to stop trying to guess what was gonna come next, because every time I thought I knew where my life was going, something would happen to prove me really desperately wrong, but I started out actually ... I was working on being an English professor. That had always been my dream. My undergrad was in English literature. I went to grad school at the University of Iowa in a PhD program for English Literature. Brian Walsh: 03:02 Wow. Dory Weiss: 03:03 Yeah, I was so excited about teaching. That was my dream, and I loved teaching. I always really loved being in the college classroom, but as I got towards the end of my comprehensive exams and towards the beginning of my dissertation, that whole process ... I started to feel really disillusioned and the things that I was most interested in, teaching, were not the things that seemed to be what was most important to my professors and to some of my peers. Academia didn't seem grounded in thinking about, "Hey, there's a group of people who I want to introduce to really incredible ideas and have the sort of meeting of the mind sort of exchange about how do we make the world better and how do we come to understand the world more deeply?" That wasn't the focus of being in academia. Brian Walsh: 03:55 Right, almost like the values that you held for why it was pushing you there were different than those values that were already existing within the educational environment. Dory Weiss: 04:02 Exactly, exactly, and not that academic research isn't incredibly important, but it's not where my heart was leading me, and so there was the sort of moment of, "Oh, wait, this isn't what I thought it was and I don't think I want to do this other thing, so, crap." Brian Walsh: 04:24 How many years in were you at this point? Like 10 years in? Dory Weiss: 04:26 I was five years in. I was five years in. It had been a big investment and I had just always ... My self-concept had been built around this idea that I was gonna be an English professor someday, so that was a really destabilizing moment. I ended up leaving grad school and just had no idea what I was gonna do next. I ended up in Austin, Texas and found out through a friend of a friend that the University of Texas had a software developer training program. What they did was they looked for folks who had strong aptitude, technical aptitude and really strong people skills. Ideally folks who had graduate degrees in something, anything. Brian Walsh: 05:12 You mean like non-technical background people. Dory Weiss: 05:14 Yeah, like no requirement for a technical background at all. The folks that I went through the training program with, they were folks who had PhDs in mathematics and biology and chemistry and music and painting. It was just like ... I used to call us the island of misfit grad students, because it was a whole bunch of us that, I think, had similar experiences, that had found something lacking in academia and just didn't know what they wanted to do next. Anyway, the training program was really incredible. It was a six month long training program. You got paid to do it which was just incredible, and if you made it through the training program, then you were guaranteed a job on campus at the University of Texas. The university is a state institution, so once you've been there for six months, you're tenured as a state employee, so if you could get into the program and make it through those six months, it would- Brian Walsh: 06:16 Then you've got a job. Dory Weiss: 06:17 It was an incredibly sweet gig. Brian Walsh: 06:19 Wow. Dory Weiss: 06:19 I had no idea what being a developer meant when I applied. I remember ... Brian Walsh: 06:19 Had you ever written any code at all? Dory Weiss: 06:28 I knew HTML and CSS. Brian Walsh: 06:30 Okay. Dory Weiss: 06:32 I knew that that wasn't like really what coding was, but I didn't know what coding really was. I had the sense that I was missing something, but I didn't know what. Yeah, I remember the hiring manager for the training program called me one evening. It was actually on a Friday evening. It was probably like 6:30 or 7 and I had already had a whiskey on that Friday night. The hiring manager called and he said, "You know, we all really liked getting to know you, and the one question that we had that we're just not sure about is if you're gonna like the work." I said, "You know, I don't know if I'm gonna like the work either. I don't know what this is gonna be, but I want to give it a try." Luckily they hired me and gave me a chance, because it turned out that I just absolutely loved it. Brian Walsh: 07:25 That is such a cool story. I was at the women in enterprise tech conference and it was amazing how many of those speakers, and it was a fantastic conference, how many of the speakers had no technical background and yet ran global companies in technology. Leyla Seka from Salesforce, and Hilarie Koplow-McAdams from New Relic. She's a VC now, and Meredith Finn who's a VC, Jessica Lynn, all of them, same exact background, like, "Hey, I'm just gonna somehow get into this," and then they excel and become amazing leaders of these organizations. Dory Weiss: 07:56 Yeah. Well, I think for myself at least, on one hand a language is a language is a language. The things that made me a good writer of the English language are the same things that made me a good writer of code. It's a matter of trying to communicate an idea as simply as possible, as directly as possible as you can to an audience, and I think that that sort of focus on how to organize and present ideas really helped me understand the beauty of writing simple code, which I think is a real strength. Dory Weiss: 08:34 I think that's part of it and I think the other part is, for me at least, was this idea that a lot of the skills that attracted me to the classroom are the same things that I think make you a good teammate, make you a good member of a scrum team, let you be thoughtful in terms of thinking empathetically about your customers and what their needs are and how to best serve them. The combination of analytical thinking and empathetic thinking. For me, I got a lot of that from the same axis as reading books and doing the imaginative work of looking at a character and trying to understand what motivated them and why they made the choices that they did. Brian Walsh: 09:23 You know, when I look back at your background, less than a year, for every year that you've been in nCino, you've gotten a promotion. Is that driven by moving that language and being able to move from being a hands on individual contributor to now running those teams and the communication and now having a team of managers under you? What has driven that unbelievable rise for a company that's growing so fast? Dory Weiss: 09:51 That's a really good question. I think that it's about ... I think obviously that I bring some degree of technical understanding and technical ability, but I do really think that part of what allowed me to move out of management and part of what I've really enjoyed about moving into management, part of what I've really enjoyed about that, is thinking about the group of people that are around me and thinking deeply about how to make sure that they all understand what we need of them, to make sure that I understand what they need of us. In some ways it's sort of classroom management, in terms of looking around at a group of people and thinking, "Okay, how do we make sure that everybody is starting from the same place in terms of understanding what it is that we're trying to accomplish," and we can all see that goal really clearly and then work together to articulate what we need to do in order to achieve that end. Brian Walsh: 11:00 Got it. I think that pivots beautifully into the topics you're touching on and one of the things that has always attracted me to nCino, which is you live and die by your culture and values. Everything about the way you communicate, the way you engage when you walk in your office, it's tangible. How did you transform the organization to have that? Was it always there? At what point did that become this cornerstone for you? Dory Weiss: 11:24 Yeah, it was always there. It was certainly there when I joined in 2013, and it's something that I've always found just really exceptional that Pierre, our CEO, and the other members of the executive team had such foresight in terms of really making that the cornerstone of the company. Pierre loves to talk about the Peter Drucker quote, "Culture eats strategy for breakfast." He loves that. It shows up in all of his culture decks, but I think that that has really been a cornerstone, and for us it's all about the fact that if we make sure that every person at nCino is empowered to do their best work, and that's both having the resources and the tools that they need, having the support and the encouragement that they need, that they understand clearly what our goals are and how we want to treat our customers. Dory Weiss: 12:28 If everyone has that sort of foundation, then you've got ... If we've got 450 employees, then you have 450 agents of change who can go out and make the right decisions for our customers who can have great ideas that move the product forward and in ways that we couldn't anticipate. If we tried, as a leadership team, to just hold on to ... Brian Walsh: 12:55 Hierarchy, straight downs ... Dory Weiss: 12:57 Exactly, exactly, and so from the very beginning, Pierre used to talk about things ... Like for instance our answer to any question is supposed to be "yes, if ..." Brian Walsh: 13:10 Oh, that's an awesome one. Dory Weiss: 13:12 I mean, and it's just such a small, simple thing, but if you take that thought exercise seriously, it opens up all sorts of thinking, so rather than, "No, because," it's "yes, if." Brian Walsh: 13:27 That's fantastic, so you're looking for almost the noble intent of, "Of course we can meet that, if we hit this criteria, if these things fall in line." Dory Weiss: 13:35 Exactly. Exactly, and so, for me, that's a lot of what I understand our culture to be. There's obviously the kegs and the paddleboard lessons on Friday mornings and those sorts of very superficially obvious elements of culture,  and I'm glad that we have them, but when I think about our culture, it is exemplified by things like "yes, if." Brian Walsh: 14:01 Do you separate, then, culture and values? Dory Weiss: 14:05 No. Brian Walsh: 14:06 Is there a separation that's one thing altogether? Dory Weiss: 14:09 Yeah, I mean, for me, they are the same thing, and if they are not in concert with each other, then everything's gonna fall apart. Brian Walsh: 14:20 Right. How do you define it? How do you communicate it? Like you're bringing on, you're growing so rapidly. Your development team's doubling, right? Dory Weiss: 14:27 Yep. Brian Walsh: 14:28 How do you bring people on and explain that culture without just having to experience it? Dory Weiss: 14:32 Yeah, so, the company at large has six core values that we talk about in all sorts of contexts. They're on the website, they're a big part of our recruiting materials, they're part of the onboarding experience for all new employees, so you get those as soon as you walk in the door, and when I walked in the door in 2013, there was artwork on the walls that had ... Brian Walsh: 14:32 Had that. Dory Weiss: 15:01 Had the six values on them, and then in PDE, we have layered on top of that our own manifesto. We call it the PDE manifesto. Product development and engineering is what we call our department, so, PDE, the shorthand. That manifesto circles around four additional values that sort of compliment the six core nCino values. That manifesto, we show it to people when they're interviewing with us. It's also part of the onboarding experience. It is posted all over the office. We give out stickers during all of our sprint retros, so for the core ... The four values of the PDE manifesto are courage, craftsmanship, community and fun, and for each of those values, we have a little image that goes along with them, and then we made stickers of each of those images. I had been thinking about the helmet stickers that football, college ... Brian Walsh: 15:01 For football? Dory Weiss: 16:09 Give out ... Exactly. Brian Walsh: 16:10 Ohio State whatever? Yeah. Dory Weiss: 16:11 That's exactly it, so we decided that we were gonna do helmet stickers, and so at the end of every sprint, each team has the opportunity to give a helmet sticker for each of the values to somebody in the department, or wouldn't even have to be in the department. Somebody at nCino or CodeScience. Some of you guys have won those. Brian Walsh: 16:33 It's been a fantastic thing, actually. They talk about that. Our team brings back like how much our organizations are so aligned and how we recognize each other as one team, and it's just so natural. Dory Weiss: 16:45 Yeah, I mean that's one of the reasons why we love working with you guys so much is that it does just feel like we're one team, but I try to make sure that we're really intentional about going back to those core values all the time in the way that we talk about things, because they need to seem truly like the center of something and not just this incidental, like, "Oh yeah, values are cool. We've got some." It really has to be a drumbeat. Brian Walsh: 17:14 Driving that culture and that value, does that become almost monotone? Does it hold back diversity at all? How do you ensure you're getting diverse viewpoints or diverse attitudes? Gender, races, like how do you ensure you don't become just the way you always were? Dory Weiss: 17:29 Yeah, I think that that is an incredibly important conversation to make sure that we're having. That first value is courage and for us, what courage means ... One of the things that courage means is honest introspection, so I'm just gonna read what this sort of description of courage is, if you don't mind. Brian Walsh: 17:58 Yeah. Dory Weiss: 17:58 We say what we think even when it is unpopular. We share all that we know. We ask for help as soon as we need it. We own our weaknesses and our strengths. We question the status quo and our product, our process and our software development practices. We take smart risks and implement new ideas. We are always open to change and are quick to adapt. We own our mistakes and we don't hold others' mistakes against them. We accept failure, learn from it, and we do not give up. If we are doing courage right, we should be ... Brian Walsh: 18:32 Questioning why not. Dory Weiss: 18:34 We should be continually being like, "Alright, are we becoming too insular? Are we not questioning if the right voices are in the room and if we're being critical enough of what we're doing?" Brian Walsh: 18:49 Well, I have to say, the organization has a huge advantage to have someone with such great English skills help write that out. Dory Weiss: 18:58 Thank you, thank you. It was actually one of the other dev managers who wrote that draft, so ... Brian Walsh: 19:03 Now, taking from your background, do you hire for people who don't perhaps have deep technical experience? Do you hire based off of sort of culture and curiosity and train them up? How have you applied your background to that? Dory Weiss: 19:15 Yeah, so, we definitely don't require a CS background, and one of the things that we know that we want to do as we get bigger, as we get more mature, as we have more resources ... As a young company, you spend so much time in the early years being so focused on just getting product out the door that it's difficult sometimes to do much more than that, and it's been over the past two or three years that we've been able to slow down a little bit and be able to say, "Hey, we will intentionally not go as fast as we possibly could because we need to slow down and invest in dev ops. We need to invest in whatever, making our scrum practice more thorough," whatever that is. Dory Weiss: 20:09 One of the ways that we want to continue doing that is we want to be able to take on people that we are hiring just for aptitude, just for mindset, and really provide more training for them. We're not as far along there as we would like to be, so right now we need ... We are looking to hire folks that have at least a basic understanding of object oriented programming, for instance, or at least some experience with thinking about code in the sort of structural ways ... Brian Walsh: 20:56 They just understand the logic of code and how to put together an application.   Dory Weiss: 21:01 Exactly, that understands sort of fundamentally why reuse is important and how you design for that, so that is a mindset, I think, and you don't have to have ... I don't need everybody to be able to produce a perfect class diagram to prove their ... Brian Walsh: 21:20 Here, come co-program with me and I will watch you. Dory Weiss: 21:23 Exactly, exactly, but there needs to be that sort of facility for that way of thinking. Brian Walsh: 21:30 How do you make a safe environment for those new people to come on, then, right? Like, you have high performers. You're a high performing organization. There's tons of stress on, the board's pushing, closed an amazing D round, and I'm not talking like physical safety, but you make it emotionally safe for them to learn and to become efficient and proficient. Dory Weiss: 21:50 Yeah, I think we try to do a couple of things there. The first is, is that during the interview process, one of the things that we're really up front about is that we're hiring folks who have incredible technical ability, but that's only half of what we're hiring for. The other half is that we're hiring good human beings who want to be part of a team and want to work collaboratively and understand that that work is gonna be challenging and wonderful and hard and all of that stuff sort of all at once, so we try from the very beginning to say, "Okay, what you're signing up for is this wonderful ride that is going to be uncomfortable sometimes, and that's a good thing, because uncomfortable is not the same thing as unsafe." Dory Weiss: 22:42 So, we try to set that expectation, that that's part of the job, is you're gonna be stretched. You're gonna be on the edge of what it is that you already know how to do, and we know that. We understand that. You're not alone in that. We're all gonna be here doing that together, so we try to just say that. I think sometimes people forget to just say clearly what it is that they mean or what it is that they anticipate happening, so we try to say that up front. Dory Weiss: 23:18 Then I think we try internally to really make sure that we all remember that we feel those ways too, and that we need to create space and empathize with other people who are also going to feel those ways. I think we have realistic expectations of what to expect from someone for the first six months that they're with us and they're getting up to speed. Brian Walsh: 23:45 Right. What do you think is the harder one to hire for, the technical or the emotional quotient, the EQ, that curiosity, their natural values? Dory Weiss: 23:58 I think it's the person stuff that's harder to find, and it's more important. Honestly, looking back to my own experience in the training program, that's why somebody hired me. I didn't know anything, technically, but somebody saw in me a good person that was capable of learning, and I think that was the right decision. It was certainly the right decision for me, and so that's the decision that as much as possible I want to pay forward. Brian Walsh: 24:30 Well, whoever that was had genius insight, because they saw sort of into the future. I want to actually pivot a little bit to talk about a change that happened, I think it was almost 18 months ago, 24 months ago, where you've always been an agile shop, but you moved into actually taking on large scale scrum or LeSS], as I think some people call it. What is that? How do you define that? What prompted your change there? Dory Weiss: 24:53 Yeah, so LeSS is a framework, a large scale scrum framework. What prompted it, really, was that as we were growing, we got to a place where we ... I'm trying to think of ... I think we maybe had 10 scrum teams when we decided to first try LeSS, and of those teams, they were divided into what we called portfolios. A portfolio for us is just a collection of teams that are all working on a major feature set of our product. Really, those feature sets for us tend to align with types of organizations in a bank, so commercial banking versus retail banking, for instance. Brian Walsh: 25:42 So everybody's separated off into those different groups, working on sort of their problem set. Dory Weiss: 25:48 Exactly, exactly, so we had already divided ourselves up by portfolios, but then within each of those portfolios, every team would have their own backlog, and often times what would happen is we'd be doing release planning and we'd be looking at the types of new features that we wanted to develop. We'd sort of just divide them out across teams and then each team would have their own backlog, which worked fine in isolation, but what would happen pretty much every release is that at some point a team would get in trouble. Something was more complex than they expected or someone got ill unexpectedly or ... Brian Walsh: 26:31 They're slipping farther and farther behind. Dory Weiss: 26:33 They're slipping farther, farther behind.  Exactly. So, awesome -- agile accounts for that. Everything is in active re-prioritization, but what we found is when we needed to do that re-prioritization, we would have to then take 10 separate backlogs and try to then get a unified picture of what is most important across those backlogs. That act of trying to get the holistic view of our priorities when the work is divided across 10 teams, that took a lot of time. What I realized sort of as an aftereffect of that was when you have 10 teams and each team has their own backlog, what you're implicitly saying is that each of those teams is working on something of equal value. Brian Walsh: 27:29 Right. Dory Weiss: 27:31 That's probably not explicitly true. If you were going to actually rank things, you probably wouldn't say these 10 things are all equally valuable. There probably is relative merit to those things. Brian Walsh: 27:43 Yet, that's rarely something you would say to those 10 scrum teams because now that devalues them and their work. Dory Weiss: 27:49 Exactly, or it can feel like it does ... Brian Walsh: 27:56 There you go. Dory Weiss: 27:59 ... If you don't then try to frame the conversation in terms of what is most important for all of us is providing the highest value to our customers. That's why we're here, that's why we do agile, that's what we believe in as a product organization, so no one should feel threatened by that because there is enough work for all of us. Brian Walsh: 28:25 Right. Dory Weiss: 28:27 Let's make sure that the work we're doing is the highest value for our customers right now. Brian Walsh: 28:30 Yeah, I mean, at the end, agile is not just stand up and sprints, right?   Those ceremonies ... Dory Weiss: 28:36 Those are organizational ... That's like a tactic that we layer on top, right? Brian Walsh: 28:41 Yeah, that's the organization that first comes in and says, "We're agile because we do sprints and we do stand ups every morning." Dory Weiss: 28:46 Yes. Brian Walsh: 28:47 No, that's not agile. How do you take, then ... You're in these separate pods. Your whole team doesn't have holistic knowledge across the product, right? You don't have the engineers working on one module. Very different, don't have the domain expertise of another one. How do you switch? You're in flight. You guys are venture funded. You're flying through. You're moving up market. How all of a sudden do you pull that one out? Dory Weiss: 29:13 Yeah, so then you have this concept in LeSS of these LeSS teams, and that corresponds really well to the portfolios that we already had in place. What you're not doing, actually ... You're not actually sharing the backlog for the entirety of the nCino product across, now, 13 teams with a single backlog. What we're actually doing is we're saying, "Okay, we're going to have a single backlog for the retail product or the retail feature. We're going to have a single backlog for our commercial features. We're going to have a single backlog for our customer engagement platform." Dory Weiss: 29:59 There are still large domain units that hang together and sort of function as a single entity, but within that, all of the scrum teams are all then gonna focus on whatever is highest priority in that little mini-realm. It's sort of this in between scale. Brian Walsh: 30:21 Got it. Does that shift a lot of the work that you had to do, then, really, to the product owners and the management there -- of how they're prioritizing and using the different resources that are available? Dory Weiss: 30:33 Yeah, and I think that that's the hardest part of the transition to less, is particularly for product owners and product managers, because you're asking them to no longer ... I think there's a tendency, at least there has been for us, a tendency, for product owners to think of their scrum team as their scrum team. Brian Walsh: 30:56 Theirs. Right, these are mine. I'm protective. Dory Weiss: 31:00 Exactly, exactly. It becomes a shift from thinking about a group of developers and QA folks as their own to thinking about features and epics in the backlog as their own. They become the expert. I mean, they already were the expert, but we sort of refocus how we conceptualize what they do as being the expert on some number of features that they own, and they drive that deep expertise. They build out the requirements and the functionality for what that's gonna be, and then they sort of carry that knowledge with them as they work across multiple scrum teams, and so I think that that definitely required a shift in terms of the way that they conceived of their work, and it also ... It took everyone by surprise how quickly, when you put three scrum teams all working on the same epic, for instance, that work's gonna get done real quick. So in the past- Brian Walsh: 32:02 Right, so all of a sudden you don't have enough runway ahead of you. Dory Weiss: 32:05 Yep. Exactly. There was some panic early on in terms of, "Oh my gosh, we cannot keep these teams fed with stories." Brian Walsh: 32:15 Wow. Dory Weiss: 32:17 We definitely, the product organization definitely had to relearn how to best feed their teams in the LeSS world. The flip side of that is that devs, there was to a certain extent, a bit of that with devs as well. Making sure that they were comfortable with domain shifting a little more often than they may have before, or maybe not domain shifting but being asked to work on different things than their teams had traditionally in the past. Brian Walsh: 32:17 Right. Dory Weiss: 32:56 So one of the things that defines LeSS, for instance, is that you have this idea of two sprint planning meetings, so in sprint planning one, you've got all of your scrum teams in that LeSS group all together. So, so you've got three scrum teams and they're all in that meeting together. The product owners come in and say, "Okay, this is the top of the backlog. Does everybody ..." Brian Walsh: 33:21 Send us the criteria, here's the stories, boom. Dory Weiss: 33:22 Exactly, and at that point we've already done backlog grooming, so everybody is at least somewhat familiar with the stories, but it's a, "Hey, make sure everybody understand what's going on here, this is the goal, this is what we're trying to build," and then the three scrum teams among themselves have the conversation about of the tickets in the backlog, what team is going to work what. What is nice there is that then you could have conversations with teams about the fact that sometimes there is value in intentionally taking on work that is new to you so that you can break down silos, so that you can have sort of an educational sprint where you're learning new patterns and new parts of the business domain and all that good sort of stuff. Sometimes that's the right choice to make and sometimes it's sprint nine and the release is almost over and ... Brian Walsh: 33:22 "Gotta go." Dory Weiss: 34:21 Exactly. We're gonna take the stories that we are most familiar with because we're the ones who can just churn on these, so we're gonna organize ourselves for efficiency. I think it's nice to actively engage teams in thinking in those ways so that they're starting to sort of take responsibility or start to think in the same way that leadership does in terms of what are the trade offs between going as fast we can or ... Brian Walsh: 34:51 There's organizational theories around ... You know, you want a team size where a single extra large pizza can feed everybody. Dory Weiss: 34:59 Yep. Brian Walsh: 34:59 As I hear it and have slightly experienced it with you, we're asking our teams, even though they're separate, you have three separate scrum teams, to really be integrated. How do you manage all of those relationships without that becoming the overhead for you? Dory Weiss: 35:16 You know, I think it takes strong scrum masters. There are concepts in LeSS that we've taken some advantage of, but I hope we take more advantage of as we go forward. There's the idea of a scout and a traveler. A traveler is a member of a LeSS team that might attend stand ups or sprint plannings or whatever meetings of another team just to get insight into what that group is talking about and learning about, and sending that information back. Brian Walsh: 35:54 Is that just technical pollination or also sort of process pollination? Dory Weiss: 36:00 Either both. Brian Walsh: 36:04 Yeah, everything. Hopefully pollinating at everything. Dory Weiss: 36:04 Exactly, just suck it all in. Just take it all in and share it. Be a pollinator. Exactly, and then there's the idea of the scout, which is when essentially a team can say, "Oh, I see that the team B over there is working on something that I'm gonna need. Either they're establishing a pattern that we're gonna need to implement or they're building some framework piece that we're gonna need to consume, or ..." Brian Walsh: 36:34 Here's your design system that everybody's gonna have to implement. Dory Weiss: 36:37 Exactly, so what team A can do is say, "Alright, it will make us faster later if we really understand this thing that team B is gonna produce for us, so we're gonna give a member of our team to team B. We're gonna, for this sprint or for however many sprints, we're gonna send somebody there to be a scout and to work as a member of that team and get that embedded knowledge, and so then in a couple of sprints when we're ready to use that, scout comes back and has all of that sort of experience with her and then can help sort of ..." Brian Walsh: 37:20 Spread that along as they get the ... Dory Weiss: 37:20 Body of experience. Brian Walsh: 37:24 Alright, so, increase of velocity. You saw that almost immediately, right? Dory Weiss: 37:24 Yep. Brian Walsh: 37:28 You're starting to crush it. Any other major wins for you? Dory Weiss: 37:33 I do think that the quality of what we've been producing, I think quality has improved. That one's a little bit difficult because our QA team has also grown in size. Our QA automation team has been building out incredible tools, so that's one of those things that's never a single ... Brian Walsh: 37:57 Single thing actually affected it. Dory Weiss: 38:01 I do think that you've got a lot of eyes on something in LeSS, and ideally there's sort of an active reconciliation across multiple teams where you don't end up with isolated teams that might be developing their own sort of sub patterns. Brian Walsh: 38:27 Getting into a hole, or doing their own process that nobody else is gonna follow? Dory Weiss: 38:30 Exactly. Ideally everybody keeps pulling them back, pulling each other back into a really sort of shared way of doing things, so I think that that has been really helpful. One of the other things, and this is sort of not a side effect ... One of the smaller elements of LeSS that has been incredibly popular here, and that's what they call the review bazaar. Brian Walsh: 38:57 Alright, I love the name. Let's get in. Dory Weiss: 38:59 Yep, yep, so instead of doing sprint reviews, or in addition ... Let me put it that way. In addition to doing sprint reviews in the traditional scrum sense, what the review bazaar ads is essentially like a science fair. Every couple of sprints, what we do now is each of the LeSS areas essentially creates a display. It's a hands on station where somebody will demo what they've built over the last sprint or two but also anyone can come and start playing around with what they've built. We invite the entire company. We do it on Friday afternoon. We open the kegs, and everyone will come and we'll just mill around and go from station to station and just see what teams have been building and interact with it and ask questions. The atmosphere is so much fun. It's highly interactive. People ... Brian Walsh: 40:04 It sounds almost like the Google 20 percent time, like here's the extra things we've been working on, and everybody can share and look at that. Dory Weiss: 40:12 Except that it's not extra, it is the sprint work, but it's the sprint work sort of shown off in this very public science fair sort of environment. Brian Walsh: 40:26 Do you get the foam core backing and make it stand up there? Dory Weiss: 40:29 Teams make huge signs and try to outdo each other with who will have the best sign and who can get the most people to come to their displays. People get really excited about it. Brian Walsh: 40:43 It seems like that actually pulls on one of your core values of fun as well. Dory Weiss: 40:47 Yeah. Brian Walsh: 40:48 Of making sure that not only are we solving and having empathy for our customers, we're doing it in a fun way and showing off even. Dory Weiss: 40:55 Yeah, you know, I think sometimes we get so focused on the work that we're doing that we forget to give ourselves time to just be joyful and feel proud of what we've done. I think it's easy sometimes to forget how incredible our product is and how successful we are, because we're just focused on building, and I think for engineers, I think engineers in general tend to spend so much time in the space of, " Well, this could be better and this could be better and this could be better and this could be better," and that sort of constructively critical sort of mindset  really good to wrench someone out of that from time to time and just say, "No, you go show off for an hour. I'm gonna make you show off and people are gonna be really impressed by what you did, so you're just gonna have to sit there and listen to people say nice things about you." Brian Walsh: 41:55 Take the applause, take the applause. Dory Weiss: 42:00 I think that's powerful. I think it's powerful. Brian Walsh: 42:02 That's fantastic. Well, Dory, I want to thank you very much for being on with us today. If people wanted to get in touch with you or look at careers at nCino, what's the best way to get ahold of you? Dory Weiss: 42:12 Well, I would say always check out our website, nCino.com. That's N-C-I-N-O. NCino is also on Twitter and on LinkedIn and we might even be on Facebook. Then you can find me on Twitter as well at Dory Weiss. Brian Walsh: 42:33 Fabulous, and that's D-O-R-Y W-E-I-S-S. Alright, well, Dory, thank you very much. I truly appreciate this and our partnership has been spectacular. Dory Weiss: 42:42 Likewise, likewise. We love working with you guys and it has been a real pleasure. Brian Walsh: 42:48 Thank you very much, Dory. Dory Weiss: 42:48 Thank you, Brian. Outro: 42:50 Thanks for listening to this episode of the AppChat. Don't miss an episode. Visit AppChatPodcast.com or subscribe on iTunes. Until next time, don't make success an accident.  

Tom Martin of Glance Networks joins the AppChat to discuss his experience bootstrapping his business for 16+ years and how debt financing and venture-capital funding changed Glance Networks’ approach to scaling. Also addressed is keeping company values intact through rapid hiring and business growth.

Ian Gotts of Elements.cloud shares lessons learned from his previous experience founding a startup (and joining a rock band) in growing Elements.cloud. Topics discussed include: how to identify product-market fit, the advantages and challenges of a freemium model, providing value at all product levels, important updates on GDPR and how to prepare, and key metrics to define SaaS success.

Andy Swanson of Nintex joins the AppChat to share his journey from Salesforce account executive to VP of Enterprise Sales at Nintex. Swanson shares his experience transitioning to a startup, how his acting background influenced his consultative approach to selling, and why failure and vulnerability is useful in the sales process.

A short introduction to the AppChat, by host Brian Walsh. CodeScience's CEO Walsh explains why the AppChat was created, what listeners can expect from the show, why he's excited to get started and what comes next. The AppChat podcast features B2B SaaS leaders sharing insights on how to supercharge growth. Learn real-life strategies, wins, opportunities and how to best leverage the Salesforce ecosystem and beyond to take your organization to the next level.