Apr 13, 2018
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.