AppChat
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. Brian Walsh of CodeScience hosts decision-makers and thought leaders, talking tales from the trenches with those who have experienced something great.
info_outline
[E9] Salesforce Essentials EVP Meredith Schmidt on Helping SMBs Thrive
01/07/2019
[E9] Salesforce Essentials EVP Meredith Schmidt on Helping SMBs Thrive
/episode/index/show/appchatpodcast/id/8158103
info_outline
[E8] A Conversation with AppExchange Leader Mike Wolff
12/18/2018
[E8] A Conversation with AppExchange Leader Mike Wolff
/episode/index/show/appchatpodcast/id/7965635
info_outline
[E7] The Recipe for Success: Twilio’s Ron Huddleston on Building Out Ecosystems
09/05/2018
[E7] The Recipe for Success: Twilio’s Ron Huddleston on Building Out Ecosystems
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...
/episode/index/show/appchatpodcast/id/7009438
info_outline
[E6] The Role of Strategic Alliances with Yeva Roberts of PFL.com
07/10/2018
[E6] The Role of Strategic Alliances with Yeva Roberts of PFL.com
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...
/episode/index/show/appchatpodcast/id/6794092
info_outline
[E5] It’s Not Nuclear Physics: Lessons on Hiring and Leveraging a COO with Jay Abraham of the Abraham Group
04/13/2018
[E5] It’s Not Nuclear Physics: Lessons on Hiring and Leveraging a COO with Jay Abraham of the Abraham Group
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...
/episode/index/show/appchatpodcast/id/6478510
info_outline
[E4] Adjusting Scrum Methodology to Meet Aggressive Scaling with Dory Weiss of nCino
03/29/2018
[E4] Adjusting Scrum Methodology to Meet Aggressive Scaling with Dory Weiss of nCino
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...
/episode/index/show/appchatpodcast/id/6422965
info_outline
[E3] From Bootstrapping to Booming: Lessons on Scaling Through VC Funding with Tom Martin of Glance Networks
03/16/2018
[E3] From Bootstrapping to Booming: Lessons on Scaling Through VC Funding with Tom Martin of Glance Networks
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.
/episode/index/show/appchatpodcast/id/6374027
info_outline
[E2] Freemium Rockstar: Finding Product-Market Fit and Defining Success with Ian Gotts of Elements.cloud
03/02/2018
[E2] Freemium Rockstar: Finding Product-Market Fit and Defining Success with Ian Gotts of Elements.cloud
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.
/episode/index/show/appchatpodcast/id/6322418
info_outline
[E1] From Salesforce to SaaS Startup: Andy Swanson of Nintex
02/20/2018
[E1] From Salesforce to SaaS Startup: Andy Swanson of Nintex
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.
/episode/index/show/appchatpodcast/id/6281408
info_outline
Welcome to the AppChat!
02/02/2018
Welcome to the AppChat!
Lorem ipsum
/episode/index/show/appchatpodcast/id/6206619