Mastering The Game Of Tech Stack Jenga With Sonar's Brad Smith

Media Thumbnail
  • 0.5
  • 1
  • 1.25
  • 1.5
  • 1.75
  • 2
This is a podcast episode titled, Mastering The Game Of Tech Stack Jenga With Sonar's Brad Smith. The summary for this episode is: Managing tech stacks inside of hypergrowth companies can often feel like a precarious game of Jenga, hoping you can pull out the next block carefully enough so that the whole tower doesn’t come tumbling down on top of you. On today’s episode, we’re talking to someone who has mastered the Operator’s game of tech stack Jenga: Brad Smith. Brad is the co-founder and CEO of Sonar, a tool that enables teams to manage your tech stacks from a single source of truth. In our conversation, we talk about avoiding tech stack bloat, what Operations Teams can learn from Product teams about managing change, and we get to learn about the time Brad accidentally wiped out $18M in revenue from his previous company’s Salesforce. Like this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️⭐️ review and share the pod with your friends! You can connect with Sean on Twitter @Seany_Biz @HYPERGROWTH_pod

Sean Lane: Hey, everyone. Welcome to Operations, the show where we look under the hood of companies in hypergrowth. My name is Sean Lane. Have you ever made a change in one of your systems or one of your tools only to realize that whatever you just changed, broke something else? And then you go to try to fix the thing that you broke and yet another thing breaks? Whether it's because of poor planning, or lack of context, or things are just moving too damn fast, ops teams can often find themselves in these precarious games of tech stack Jenga, hoping that we can pull out the next block carefully enough so that the whole tower doesn't come tumbling down upon us. On today's episode, we're talking to someone who has mastered the operator's game of tech stack Jenga, Brad Smith. Brad is the co- founder and CEO of Sonar, a tool that helps enable teams to manage their tech stacks from a single source of truth. Who better to talk to about this than someone who spends every day thinking about not only his own tech stack, but those of his customers and the operators who run them. Prior to founding Sonar, Brad was in ops himself, leading operations teams at companies like Terminus and Gather. In our conversation we talk about avoiding tech stack bloat, what ops teams can learn from product teams about managing changes like these, and we're going to get to learn about the time that Brad accidentally wiped out$ 18 million in revenue from his previous company's Salesforce instance. But first I wanted to learn more about the challenges Brad experienced as an operator himself, and what prompted him to start Sonar in the first place.

Brad Smith: It's interesting that if I were to rewind the clock and tell you the first time I started to see some of the problems we're solving for now, it might have been six, seven years ago, I joined a fast growing startup here in Atlanta called Cloud Sherpas. Was there for about three years and they ended up successfully exiting to Accenture. But when I started, I was brought on to run operations, mainly on the professional services operations side. Funny enough, I think this is so true for so many operations folks. They start on day one. They get done with some HR paperwork and maybe go to lunch with some folks and get back in that afternoon and they're like," All right, Brad, here's your admin license for Salesforce. Good luck. Hope it goes well. Let me know if you have any questions." Fantastic. What's Salesforce? I don't even know what this is and I think all the folks that I talk to now from a Sonar perspective, a lot of our prospects and customers, I ask them their origin story. Like," How'd you get to where you are right now?" And it's a very, very similar path, but I noticed some of these problems that we're solving for there, which has a big zoom out for this. There's so many moving parts to your CRM. And now we have so many different integrations that connect to it. There's just inevitably so many blind spots. So I remember making changes. Of course, didn't know what I was doing for the most part. So it was very much putting my cowboy hat on and just configuring things and seeing what happened. And I remember things breaking. I remember sales reps coming over to my desk. Some of my consultants coming over, marketing and finance. I mean, there has to be a better way to manage how we deliver changed to our organization and really make sure that we can see all these impacts that are happening, so. Fast forward from... so, I spent a little bit of time doing just direct Salesforce consulting, helping companies get Salesforce up and off the ground or optimizing their approach to it. I really enjoyed the consulting space, especially when I was doing this with Coastal Cloud, which is another platinum partner in the Salesforce ecosystem. But I really knew my spot in life was in the ops side. So I moved back into operations and started at a company called Gather Technologies, which, another local Atlanta company, fast up and coming company at the time. And same thing happened. Congratulations, Brad, here's your new inaudible Here's your admin license. I was like," Fantastic." But fortunately there were some folks there that had some documentation behind what they built and why they built it. But at the end of the day, the same problem was occurring. I was making some new changes to things like validation rules and process builders and I've joked around. There was times that I would look at Salesforce and sneeze the wrong way and something would break. And it's really just because again, we don't have this level of visibility that we really need. And that was one of those catalyst moments for me mainly because I ended up meeting my co- founder Jack at Gather and we'll get into a little bit more of how we progressed with Sonar, but he and I had a couple of aha moments as to how this gets solved. I think the biggest story that I go with most of the time I'm telling folks, where was my catalyst moment for why we built Sonar? The way we did was when I moved from Gather to Terminus and I was a director of rev ops over there, my first project I got into to Sonar or sorry, I got to Terminus was all right, it's really about products and price books, standard functionality for Salesforce, but they weren't using it at the time. I was like,"Man, I got this. Perfect. Done this a hundred times. This is fantastic. Great first project really get my feet wet in here." And I put my old consulting hat back on. I spin up a sandbox. I build my solution and get the thumbs up from all the executives and all the VPs and all the end users and I go to hit deploy all my change set, really just pushed my solution to production. Did that at 12:01 AM on a Tuesday night. So I guess really Wednesday morning and did about an hours worth of testing, like a good Salesforce admin does. Felt great about it. And I could sleep. I'd wake up the next morning at 6: 00 AM to text messages, voicemails, phone calls, emails, Slack notifications," Brad, what is going on with Salesforce? What is happening?" And because of one small blind spot that I didn't see, because I didn't know how all these systems were interconnected, I wiped out our revenue, which is not a fun thing to happen. At that the time we were roughly like an$ 18 million run rate company. And nobody is happy with you when you take something for$ 18 million to zero million dollars. So, weird. Yeah. It's funny how that works. Right?

Sean Lane: But I think, Brad, one of the things that is very admirable about you and what you've done is that there are plenty of people who see a problem, right? There's plenty of people who will say," Oh, this part of ops is tough or this part of ops could be better. But then their knee jerk reaction is to either, some people just complain about it and go about their day. Some people will go and try and Google options to solve this problem or a software that they could potentially buy to help solve this problem. What was it about running into this problem over and over again that you said to yourself," You know what, like I am actually uniquely qualified to be the one who solves this problem along with Jack."

Brad Smith: Yeah. I think the unique side of it was just, I think that I've stubbed my toe through it for so long, for so many years and I still have some of the scar tissue to prove some of those mistakes. But I think where Jack and I looked at each other in this unique capacity was that I kept running into the same issue where I just... I knew what I was doing. I've got a handful of Salesforce certifications, have to configure this stuff now for years, but there's really no playbook for how to implement change within your organization. We talk about effective project management all the time and how do we make sure that we communicate directly to our go- to- market teams, why we're making the changes we make? Well, tactically, I know how to make those changes, most of the time, asterisk, because sometimes I clear out a lot of revenue, but I think the bigger parts of that is, we were finding so many blind spots that the easy examples... How can I answer a question very effectively and easily. Where is opportunity stage being used across my entire tech stack for my go to market technology? Like, you know what, anecdotally, I know the answer to that. I know that I've got that mapped to my marketing automation system. I know I've got it mapped to my sales engagement, my customer success platform and my finance platform, I think. But then you start to realize that, well, those are also overlapping and potentially colliding with internal automations in Salesforce. And so going back to when one of those first catalyst moments when I met Jack I was talking with him about this. And we were both, I think about a month in to our time at Gather. I was like," Man, you're a smart guy. You're over in the products and engineering world. I've got a problem. Can you help me fix it?" And he's like,"Yeah, man, shoot. Tell me what's going on." I was like,"I presented that same thing." I was like,"I just can't wrap my head around how to visualize how all this technology is being orchestrated together." And he kind of laughed at me, Sean. He was like," That's a problem for you?" I was like," Yeah, man, it's a big problem for me. I can't make change very quickly and efficiently and safely. There's so many times that I make this change and I don't realize it's attached to something else. And now my marketing team's mad at me because I made a change with a sales team and then inaudible is mad because I made that marketing update." And when I presented that to him, he's like," Wow, I can't believe that's a problem for you. We, as in the engineering and product world, we've solved for this." I was like," Well, let me put a little asterisk beside that, Jack. You inaudible properly educated about this. You all have engineers who have computer science degrees and been doing this forever and the software industry in general has been around for so much longer that truly the go- to- market technology side of things." And he came back. He said," Man, I've got a great tool belt to make sure the problems that you're facing don't hit us. And we get to use great things like get inaudible and Datadog, PagerDuty, things like that to make sure we know how our integrations are working. We can propose change and really make sure that we know the up and downstream impact." And I don't remember like word for word out of my mouth. And I was like," Jack, that's cute. We don't have that." And I think that was one of those, again, catalyst moments where a light bulb went off in both of our heads. We can go and solve a really big problem for go- to- market operations teams who are by hook or crook or most of the time voluntold, here's your tech stack. Go and optimize it or go and manage it.

Sean Lane: Here's your tech stack. Go and manage it. Raise your hand if you've heard or experienced some version of that before. Brad found that these well known, understood and solved problems in product and engineering worlds could be solved in similar ways for operations teams, and yet no one had done it. It sounds simple, but we've all made a change in Salesforce or some other system that has had unintended consequences. Now, hopefully not$ 18 million consequences like Brad's, but you get my point. And so I wanted to figure out why we as operators are behind and where we might be able to avoid these errors to begin with. Does it have to do with the way we shape our teams, where one person pulls at one thread, one person pulls at another, or are we careless or does it just come down to slowing things down in order to speed up later?

Brad Smith: If you think just even holistically of the impact that I made to my organization at Terminus, where I was at the time and I wiped out revenue, think about the downstream, almost catastrophic impact that made by wiping out essentially all opportunities and all the revenue associated to them. Our sales reps couldn't manage their pipeline. Our marketing team couldn't run reports on which opportunities we have in our pipeline, which ones do we should target for different advertising strategies, our CSMs. They had no renewals to manage because they all had$ 0 bills beside them. And even all the way down to finance, they were like,"Man, I can't bill anybody. I don't know which company is late on something," because essentially I wiped it all out. The impact of all that is it's catastrophic to your entire go- to- market and just overall company. But when you think of why it's so different, to your point on the product side, where they make change and they create a new feature and test it thoroughly and then push it to a developer or to the staging or to staging to production org. That's a totally different step in process and for better or for worse, sometimes on the operation side, we just get to go fast. And I think that's one of the great benefits for creating and developing solutions on the Salesforce platform and this entire tech stack ecosystem we talk about, but we don't follow the same processes. And more important to that, we can put this process side over here in one silo, but from a communication standpoint, we also don't communicate effectively, nearly as much as we should. And I think it's, again, we talk about it all the time. Here at Sonar, most of that boils down to lack of visibility and even just understanding what the impact might look like to begin with. And a great example of that... I don't want to over- index on big projects like adding products and price books, the way you operate your opportunities. Take a step back and do a small project. You get a new request from the VP of marketing that says," Hey, we're going to start tracking competitive intel. We just realized this new competitor popped up on our radar. Can you add that new competitor's name to our competitor list?"" Absolutely." And that change we know is so simple. You go into the back end of Salesforce. You add a new pick list value. You get to go. But what we don't always understand is how is customer success using that field? Because they're tracking competitive intel as well. They have internal business processes, they have reports, they run based off of this. Did they know that I just made that change? Let's talk about sales. Sales, obviously, if we're in the second half of our funnel, we're far down [ inaudible 00:13:33] very much tracking our competitors. Who else is this company talking to? Who are they evaluating? And if I don't tell the sales team," Hey, I've just added competitor number seven to this," it's out of sight, out of mind for them. They don't even know to track it because we didn't communicate it effectively. And so when we talk about how do we make these changes? Some are big and some are small, but at the end of the day, they impact all of these teams significantly. And what we're trying to do in building for our customers is the way for everyone to collaborate and see inside one place where these impacts go, all the way down to who owns that business process? How does that feel being used in other places within your tech stack to really make sure that you can effectively communicate that change up and downstream, whether it be big or small.

Sean Lane: Brad and I spent a lot of time talking about Salesforce and Salesforce specific examples, but these problems of communicating changes, understanding the ripple effects of your decisions, looking around corners to anticipate where things might break, these problems extend far beyond Salesforce, to all of the other tools in your tech stack. Many of which talk back and forth with Salesforce as well. What you end up with is this vast network of plumbing running behind the scenes of these hyper- growth companies. And if you take a piecemeal approach to that plumbing, forgive me, but you're going to spring some leaks. My dad is a plumber by the way. So all these plumbing puns are completely fair game. But with someone like Brad available to us and he's someone who thinks about this stuff all day, my question to him was," Have we gone too far? Have we reached this extreme tech stack bloat that is just too much to manage?"

Brad Smith: Obviously in the space we're in Sean, so many people come to me, especially as we're showing our product off. We're talking to our customers and prospects like," Hey Brad, I know you've looked at this space for so long. You know almost every system and every tool out there. Is this the better one? Should I use this?" And I tell folks all the time, as politely as I can," If your first strategy is to throw technology at something, you're not on the right track of your strategy at all. Let's rethink your strategy because to your point, there's so much technology out there and I can't throw that much shade." We're one of those new pieces of technology that are coming out. And so what I tell folks all the time is understand what your problem is first. Do yourself some diligence and see what it takes for you to truly understand how you want to solve this for your company. Begin with the end in mind. These are all goofy cliches, but really think about what you're solving for. What does success look like? Work backwards from that, try and understand, is this a process thing that we'd optimize for internally? Do I need to make sure our company knows what step one plus step two plus step three looks like? And honestly, if there's 18 steps, how do I get those down to 10? That's the genesis of what we're trying to do with operations, right? It's trying to be efficient and give our entire go- to- market teams so much power to go and do their job better. There is a tipping point when you are spot on. Was saying this, there's times that we throw too much technology at this. And the tech stack gets bloated and we see the downstream impact of that. You throw nine different tools over to an SDR or an AE team. Do you think they know how to manage every one of those, be efficient with every one of those all the way down to the process of,"Hey, I just sent a new demo." Great. I got to go check four boxes here. I got to change something here. I need to go high five the person across the room. What does that process look like and are we actually being efficient inaudible it at all? I pushed back often to our customers, all the folks that we talked to in the ecosystem. So understand what your problem is first. By all means please don't just try to toss technology at it. We're all already spending a ton of money on the go- to- market technology that we have. And all of it is fantastic and they all serve different points for solving very big problems for our company, but you don't know what you don't know. And if you don't understand what your problem is to begin with, you're probably going to make a mistake and spend a lot of money that you might not inaudible.

Sean Lane: I feel like too, you just harped on what the end user experience is, which is huge, right? Because they're feeling complete tool fatigue, but you also have these ops teams who are then left holding the bag for the ongoing maintenance and management of these tools. Right? This has happened to me so many times where somebody from one of the internal teams will say," Oh, we're looking at this tool, but don't worry. We've already asked them about the Salesforce implementation. And it's super easy." A lot of times that might be true, but it's not about the first week, right? It's not about the initial implementation. It's about the ongoing use cases and maintenance and administration of a particular tool like that and how it's going to be used both in relation to the other tools you have, but really in relation to how your company goes to market. If you have this one video tool or something like that, that is going to be used for training on your website, but then you have a different tool that is for how people are going to consume written training on your website. Okay, how do those things talk to each other? Are we going to know when someone completes one course in this tool and a different course in this tool? That to me is also really interesting is the ongoing maintenance that you then end up with. And so you end up with a team that is spending all their time, exclusively on maintaining tools and very little on actually creating value for the business.

Brad Smith: Yeah, you're spot on. And I think this is, Sean, one of the coolest parts of my job and some of the conversations I get to have because our sales team is obviously working very closely and hands- on with the folks that are using our product and they're loving that. But a lot of my job responsibilities make sure that I have that executive connection with the company that we're talking to. Make sure that the leadership side of the house knows why this is important as well. One of the questions I ask every single executive, every time I get on the phone with them is," Tell me," however long this person's been there. Let's say it's Sean at Drift. You've hired Sean to do what? Tell me exactly what value he's bringing to the organization and most of the answers I get back from the VP of sales, the CRO, the CEO, CFO," Hey," it's like," Oh man, Sean brings so much strategic knowledge to our organization. The fact that he has his finger on the pulse and he gets to help me understand what does our pipeline look like? Where are our bottlenecks in our processes here? Which industries are we excelling in? Which ones are we performing low in?" And a lot of that really boils down to strategy and being very strategic in what we do. Of course, every executive knows that there's some tactical ownership of how do I orchestrate this system? Oh yeah. He also gives a Salesforce licenses out and sets people up on other sales engagement tools and make sure the marketing automation platform looks right. And they'd know that what responsibility... But the first thing I asked, what value they bring in like,"Oh my gosh, this strategic business intelligence, like fantastic." Love that answer. Completely agree. That is actually epicenter of what operations should be providing to a company. Do me one favor. Go ask that same person we're talking about. Go ask Sean that same question, but in a little bit of a different manner. Just go ask him, on a daily basis, on a weekly basis, how much of your time is spent being strategic versus tactical? And every time they usually come back, like," Oh my gosh, it's the inverse. Our folks are spending way more time orchestrating in this crazy complex tech stack, putting out fires everywhere, helping sales reps troubleshoot. I can't create a quote the right way," things like that. And I think it's this aha moment for a lot of the executive side of the house too, because they know in principle the value that operations brings. But unless you're sitting right beside them day in day out and seeing all the different hoops we jump through and all the different roadblocks we run into, it's hard to understand what split of tactical versus strategic that we really run into, so. It's always that aha moment that I get. And of course, I'm smiling ear to ear because we can help solve for a lot of that. But it's so true. This split of tactical and strategic, and to your point, how much time does one really spend just managing the technology that helps our go- to- market teams thrive, is a lot. It can be burdensome sometimes.

Sean Lane: I encourage you to try out Brad's experiment for yourself. Ask yourself what percentage of your time are you spending on the proactive, strategic work that's hopefully creating value and driving new insights for your business. And then what percentage of your time is spent on the more tactical tool- based administration and upkeep? Then in your next one-on- one ask your boss or your CRO or your VP of marketing, whoever, what their expectation is for this split on your time. Just like Brad said, I bet that this prompt will trigger some really interesting and revealing conversations. But having the conversation is only the first part, right? On this show we've always tried to arm you with tactical ways you can better work as operators within your hyper- growth companies. So I asked Brad after this conversation, if I find myself on the wrong side of that split, what do I do? How do I, along with my teammates, fix that problem? How do I meaningfully move the needle towards the more strategic end of the spectrum?

Brad Smith: Ask a ton of questions. And that sounds cliche, right? Like," Oh yeah, of course. I want to ask a ton of questions." You want to understand why people are asking for these changes, but I think one of the biggest responsibilities and one of the jobs that operations has to do, that's not always the most fun one, is to say," No," and there's a very delicate and eloquent way to do that. But I think what we're learning is that the persona of the Brad Smiths of the world, the Sean Lanes of the world, all these fantastic operations leaders, they want to satisfy their go- to-market teams. So almost our initial knee- jerk reaction to those questions, like," Absolutely we could do that. You got a big problem. Let me solve that." But I think we need to slow down sometimes, really pressure test what this new problem we're facing is or how we're trying to optimize for things because I think, the old adage, it's tough to be a yes person, or yes ma'am resides here because we get overloaded with requests and some are big, some are small, but if we don't pressure test exactly what we're about to create these solutions for and why they're important to the organization, we're going to move fast. We're going to break things and things are actually going to slow down because of it. So now, as I'm talking to other operations leaders who are like,"Oh man, I've got this project list of a hundred plus items I'm backlogged on." I'd push back a little bit. Like," Which one of those items are mission- critical or have you talked with everyone in the organization as to why that change is important?" It's almost counterintuitive because we want to be supporting our go- to- market teams. We want to provide new solutions, but if we don't truly understand that the core of what we're trying to solve for, and we move too fast, we really try to build something incredible, but don't know how it's going to impact all the other teams, we're setting ourselves up for failure.

Sean Lane: What's really interesting about that is when you talk about how we're moving really fast and we are supposedly brought in by the CEO or by leadership to play this strategic role. A lot of times moving really fast and saying yes to everything actually flies in complete contrast to that. You are literally going in the opposite direction of what it was meant to be. Our VP of sales ops at Drift, Laura Adint, she has a saying where she says," Smooth is fast, slow is smooth." And it's kind of just like, you have to really stop and think about it. Smooth is fast, slow is smooth, but it's really just... Everything has to be this orchestrated motion that when things are moving like that, all of a sudden things do seem to be slowed down and you don't have this crazy rushed feeling to it. And I'm curious, when you're talking to these different CEOs, every single time someone tries to sell us on a piece of software like this, they're talking about the ROI of one of these pieces of software. And then we, or whoever the champion is, goes back internally and makes this business case for why we should get this thing, because here's the return on investment of this tool for our business. And I'm curious how you think about the ROI of these tools and the time spent on it by off people versus what's just the pure ROI of a ops team? And does all the work we're spending on these tools hinder that ROI? Does it boost it? I have not figured that out.

Brad Smith: Yeah. I think it's a question that we obviously run into with every single customer we talk to. I challenge it a lot because I think the historical sense of ROI that we always hear, I was like,"What's the return on my investment?" And everybody's mind starts to associate dollar in, dollar out. What does my output look like from a revenue side? Because we're talking about return on monetary investment, putting money into something. How much money am I getting out? And we've never really had anybody come to us and say," Hey, Bradley, I've been using Sonar, but I don't have any new leads." Like, well, sorry. That's not exactly the world that we live in. crosstalk That's the expectation, but," Hey Brad, you didn't close any more deals this month. I don't get it." Nobody's coming up to us about... They all are asking for sometimes monetary, like" How does this actually move our revenue needle?" And I pushed back and I challenged with," Well, hang on. Before we talk about any ROI of the dollar in, dollar out on any software, let's talk about the ROI in rev ops. What are you goaling your rev ops team to do? Obviously, spoiler alert, unless somebody can prove me wrong most of the time, not too many rev ops leaders are closing deals. They don't have a quota to hit.

Sean Lane: They don't care.

Brad Smith: It's one of those things that you'd have to sit back and zoom out and say," What is my ROI on rev ops?" Are we making sure that our go- to- market team is up and running and by up and running, I mean, are they educated on the technology we're already using? Are they educated on a process that we're following? And most importantly, are they maximizing the use of that efficiency to bring revenue into the company? Our support role in all this is to make sure that the lights stay on, the wheel spins fast. And so if you're goaling your rev ops leaders, your rev ops teams, to make sure that their go- to- market teams are in fact educated, enabled, and making sure that their business processes are buttoned up and airtight. Of course, that's going to have an impact on how your business performs. The quality of the day spent in the life of someone in marketing or sales or success is optimized. They aren't spending too much time troubleshooting tactical issues. So we really look back at this and say, the ROI on rev ops is really to make sure that that team is optimizing for efficiency across your entire company. And then we get to start peeling back into the art, oh, why is that important to the software that I buy, whether it be Sonar or Drift or anything else. Is that accomplishing this goal? Is it making our rev ops team more efficient to allow our go- to- market teams to be more efficient? And of course, we look back at all this, we zoom out and say," Tell me about the investment you've already made." Not only in your rev ops team, but in your technology as well, because those are really, really, really big investments. You want to make sure those investments have returns and that's where we get to come in and really help make sure that not only that technology shines but the team shines as well. But it all boils back down to, what did you set a goal for when you hired this person or this team to begin with, because that's how you really have to measure this.

Sean Lane: I think it's helpful to expand the definition of what optimizing for efficiency might mean around some of this tech stack stuff that we've been talking about. That doesn't just mean adding more stuff to the tech stack. If anything, like if you're looking and you're going through the exercise you just described, and you're hiring somebody or building out a rev ops team, and one of the bullet points you put in for responsibilities for this team is tech stack management. That means calling and refining and reducing that tech stack just as much as it means adding stuff to it. If you don't have a cadence where you're going back and revisiting different things in your stack to see how they now play with the other things that you're adding in, like that's a huge part of it as well. Don't you think?

Brad Smith: Yeah, absolutely. Like if you're not looking to see how exactly these inputs and outputs fly, what exactly are you measuring? You got to throw that back at the table and sometimes there's some awkward silence behind that, but it's okay for that because it serves as this constant reminder like," Okay, what did we set out to accomplish to begin with?" Not only do we create aha moments from a technology standpoint, but there are so many times when we just got to create foundational aha moments with our customers. What exactly did you set out to accomplish today? And let's work from there how we can help optimize for that.

Sean Lane: Before we go, at the end of each show, we're going to ask each guest the same lightning round of questions. Ready? Here we go. Best book you've read in the last six months.

Brad Smith: Great book. Can I give you two if that's okay?

Sean Lane: Yeah, of course. Yeah.

Brad Smith: Yeah. I love it. So from a business perspective, one of the funniest books, but also things I've taken away from, Quench Your Own Thirst by Jim Koch, the founder and CEO of Boston Brewery Company, Sam Adams. And do you just talk about smiling ear to ear with every page you're reading. He is hilarious and he really does bring my business value to how he'd watched the company. Obviously in the seat that I'm in, I'm trying to learn from the best. And so I'm reading tons of books like that.

Sean Lane: And you're really trying to play to the Boston crowd here too. I get it. It's very well done. Well, pandered, I appreciate it.

Brad Smith: Hey, you know what? I do a little bit of research. I know the questions. I will say this too. The other one, non- business related, The Cost Of These Dreams By Wright Thompson. So he's an ESPN writer and he really digs into what the sacrifice has been made to be at the top level. He's doing interviews with like Michael Jordan. And he's trying to understand some of the other fighters that fought Muhammad Ali a long time ago. And it's just a really, really level setting book to read, to hear what it really takes to go out and be successful.

Sean Lane: Favorite part about working in ops.

Brad Smith: Man, I'm so lucky right now, because not only do I get to work at ops back at the top, so many awesome ops leaders, especially like yourself. I will say watching other operations folks get so creative with their solutions is literally what wakes me up in the morning. It gets me excited about what we do, but also like hat tip to everybody out there in operations because when we talk to folks..." How are you solving for this issue?" And they're like," Oh man, here's my process." And they bring up a really cool workflow diagram, all this fun stuff. And it's watching the creativity of all these operations leaders shine. I mean, I learn something new every day with every column on so it has to be that.

Sean Lane: We didn't even talk about this but we will absolutely put a link into the show notes. You have also started an amazing ops community, Wizards of Ops, where a lot of those creative solutions are on display every single day. There's a Slack group. There's a website. I personally have leveraged it so many times. So from the people who have gotten a whole lot of value out of it, thank you very much for starting that.

Brad Smith: Of course. I get in there every day and I learned something new every day. That's my goal is to jump in and hear how some of these folks are being creative and folks like you contributing to it. And the other thousand plus wizards that we have in there, collaborating and networking, sharing ideas and-

Sean Lane: All right. Flip side for you. Least favorite part about working in ops.

Brad Smith: I'd probably have to say how other folks outside of ops interpret operations. We struggle sometimes. A lot of folks don't know exactly what's on someone in operations plate or the level of complexity that's involved. And so I think we as operators or operations professionals have a duty to educate folks. You get that request that comes over. It's like," Hey, can you just add the checkbox? It checks the guy, the thing in the place." It's like," It's not that easy. I have to understand what all of the up and downstream impacts of that are." But there's so many times that I think people underestimate how difficult it is to be in operations. And so again, we have a duty to educate that group of folks, but sometimes that can be a little frustrating, just not knowing the full complexity behind the day in and day out of the job.

Sean Lane: Someone who impacted you getting the job you have today?

Brad Smith: Ooh, that's a good one. I'm going to give a shout out to Pete inaudible I think a lot of folks know Pete for starting Modern Sales Pros. He's a longtime friend of mine, friend turned mentor, turned... actually bought his software atrium when I was back at Terminus. You get here today at Sonar, but he has just helped push and elevate me to not only strive to be a great business leader and make sure my team is operating at a high level, at a high efficiency, but from a community standpoint, what he's done with building MSP and how to run a truly successful community, I learn something different from him every day. I was catching up with him yesterday and every minute I get with them is just a wealth of knowledge. So you have to give a hat tip to Pete, for sure.

Sean Lane: Pete's great and has been on the show before as well. All right. Last one. One piece of advice for people who want to have your job someday?

Brad Smith: Ooh, ask questions and ask more questions and ask more questions. Find good mentors like Pete. Find people that want to help elevate you and pay that forward. He inaudible leave your ego at the door. We talk about that every day. We walk into his front office. We're all here to elevate each other. If we do that, we are going to be well on our way to success, but ask a ton of questions, leave your ego at the door and pay it forward.

Sean Lane: Thank you so much to Brad Smith for joining us on this week's episode of Operations. And seriously, if you haven't checked out Brad's community that he started Wizards of Ops, I highly recommend it. I go in there all the time to ask questions and it's served as a phenomenal resource for me and our team at Drift. So thank you to Brad for that as well. If you've enjoyed the show today, please make sure you're subscribed. You get a new episode in your feed every other Friday. And if you're liking what you're hearing and want to tell other folks how much you like the show, leave us a six star review on Apple Podcasts. Six star reviews only. All right, that's going to do it for me. Thanks so much for listening. We'll see you next time.


Managing tech stacks inside of hypergrowth companies can often feel like a precarious game of Jenga, hoping you can pull out the next block carefully enough so that the whole tower doesn’t come tumbling down on top of you. On today’s episode, we’re talking to someone who has mastered the Operator’s game of tech stack Jenga: Brad Smith. Brad is the co-founder and CEO of Sonar, a tool that enables teams to manage your tech stacks from a single source of truth. In our conversation, we talk about avoiding tech stack bloat, what Operations Teams can learn from Product teams about managing change, and we get to learn about the time Brad accidentally wiped out $18M in revenue from his previous company’s Salesforce. Like this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️⭐️ review and share the pod with your friends! You can connect with Sean on Twitter @Seany_Biz @HYPERGROWTH_pod