How to Think Deeply About Problems with Bloomreach's Ian Mesey

Sean Lane: Hey everyone, Sean here, before we get into this week's episode, I've got a special announcement for you. I mentioned on last week's episode that we have our Hypergrowth San Francisco conference coming up on November 18th in San Francisco. And I asked a bunch of you, if you were interested to reach out to me and a bunch of you did. And so we decided to do something special for listeners of the operations podcast. We have a special code for you. The code is operations 99. This will get you a discounted ticket for$ 99 into Hypergrowth San Francisco. This ticket is usually$ 599. So use this code. We want to see you there. Again, it's Hypergrowth San Francisco, November 18th. If you want more information, go to Hypergrowth. drift. com. And remember the code is operations 99. Thanks so much. Now on with the show. Welcome to another episode of operations. The show where we look under the hood of companies in Hypergrowth. My name is Sean Lane. Let's play a game. If you were to look at your calendar for saying next week, how much time would you have blocked off for actually doing real work? Actually scratch that. Not just time blocked off for doing work, but rather time blocked off or just thinking about the work you have to do, time blocks to just think. Today's guest, Ian Mesey calls these time slots on his calendar building blocks, and he protects them religiously as a part of his work as the head of revenue operations at BloomReach, the maker of a digital experience platform. My favorite part of this episode is that, in listening back, there's a clear point where I shamelessly transitioned from being the host to just an audience member, asking the questions I hope all of you would have. If you had the chance to sit down within yourselves. In addition to teaching me about how to think deeply about problems, he talks about how he recognizes the value of unsexy projects, including... Don't fall asleep on me here, governance. And it's okay to cringe a little bit when you hear that word now, but by the end of the episode, you'll hear Ian's take on why governance isn't about slowing down progress, but rather it's about not breaking things in the process of progress. Ian's career actually went in reverse on some of our previous guests. While guests like Kyle Morris, went from practitioner to consultant. Ian was the opposite, which I learned has its pros and cons. In fact, prior to joining BloomReach, he worked at Blue Wolf and he co- founded Go Nimbly with guests from our previous episode, Jason Reichl. So to start, I wanted to learn about Ian's transition from years in consulting to becoming an operator right in the middle of a company growing in Hypergrowth.

Ian Mesey: From the beginning of my career, I've been in professional services and it's been really interesting because I've seen so many different business models. I've seen so many different company sizes, company structures, all kinds of different things. I've seen the pros and cons of organizing operational structures, the different ways you can structure an operational team, all the way from large enterprise companies down to startups that were a few years in. So I think consulting is great. I think it's a great way to gain experience. And we used to joke around when we were at Blue Wolf, that it was an NBA program. I really enjoy consulting, but at a certain point I wanted to have the experience of actually owning the entire architecture, owning the entire... And I am when I use architecture, I'm not just talking about technical architecture, but process and things like that from end to end. As a consultant there, there've been quite a few times in my career where I've been able to manage large projects that were kind of all inclusive, but you still get to a certain point where you hand off the project.

Sean Lane: You don't get to stick around either the implementation or the results, right?

Ian Mesey: The impact. Yeah. A lot of times the actual impact to the organization is more conceptual for you or theoretical for you. And you don't get to see it day to day.

Sean Lane: Ian was drawn to the concept of owning something. And this reminded me of our very first episode of operations with my boss, Will Collins, who came from a banking and VC background, but he felt the same pull to working inside of a company rather than just investing in one. So when Ian did make the jump to BloomReach in December of 2018, I was curious, did he find himself assessing his new situation with the mindset of a consultant?

Ian Mesey: Oh yeah, for sure. I think the biggest struggle for me as normally I'd go into an engagement or a new engagement at a client and I'd get that, we did what we call business process review where we'd go end to end from lead sources all the way through to billing and customer success. I did that at BloomReach, what I didn't have the ability to do and what I think looking back on it, I wish I would have pushed back on this more is, you don't have the time that you would as a consultant or even the team to build out the documentation and do the presentations with the C- suite and things that you would normally do as a consultant. You would want to think about how you communicate this out to the organization. And I think I made a mistake of taking that for granted like," oh, they'll understand the value of what I'm providing or they'll understand when I talk about the need for X, Y, or Z project. It'll be evident and I won't need to do all this documentation that I did as a consultant, nice presentations and things like that." As a consultant, I felt the need to sell projects. I went away from that when I first joined BloomReach, but I think that was a misstep in hindsight, I think I should have definitely not taken for granted the communication side of selling projects and things like that.

Sean Lane: This is such an important lesson for operators. We can get sucked into the work we're doing so easily, or we can know the value and the intricacies of what we're working on, but we can forget to communicate or sell that value elsewhere, and Ian, he realized that. The time he had to make slide decks and present his findings as a consultant was no longer built into the job. And in my mind, it's not just about selling the project you've decided to work on, it's about justifying it against all the other things you could be working on. Ian told me he struggled with this at first with competing responsibilities for the CRO, the CMO, the CFO, you get it. Ian came to BloomReach when it was over 400 employees already and had raised just shy of a hundred million dollars in funding. So I was curious at a company like that, what challenges did he find when he first arrived?

Ian Mesey: I was not surprised by the types of problems that they had. Coming into organizations, one of the things that you realize as a consultant is you come in and everyone's got problems. Even seeing my own clients up on stage at Dreamforce or up on stage at Saster or something like that, where they're presenting these glorious visions where the skeletons lie. They're like," ah, yeah, that sounds nice. But it actually", I think I was prepared mentally for what I experienced at BloomReach, the ops resources that they've had. Well in sales ops, they didn't have a sales ops resource for I think nine months or so before I joined and the resource that they've had before, very, very smart guy and very, very talented. I actually worked with him a bit when I was at Go Nimbly, but he was the loan operation resource. So you can only do so much. And then the guy who took over that role also very, very smart, very talented guy, but he was also the head of marketing and also led the SDR teams. So operations was his sixth job. So I was prepared for that. My boss, the CRO is a straight shooter and he told me he did not pull his punches in the interview process. So I was prepared for it. And on top of BloomReach did an acquisition a couple years before I joined the CMS platform based in Amsterdam. So, and I've done org merges, I've done lots of them. I've been a part of a lot of acquisitions from both sides. I know how much work in org merges. I know that the operations team at that time was not resourced for it. So I was prepared for data quality issues and things like that, that I've experienced.

Sean Lane: So here's the thing. If you're at a company that's smaller than BloomReach or smaller than Drift, and you have maybe less funding, take solace in the fact that everyone has problems. Everyone has some form of operational debt. So Ian, he set out to fill in some of the gaps that he saw. And he told me that he always starts by looking at the handoffs in the customer journey and more specifically points that he could find friction. Now, Ian may not have had the experience as a practitioner inside of a company at that point yet, but what he did have with his years of consulting experience, and if there's one thing you learn as a consultant is how to approach problem solving. Ian not only taught me about his approach to problem solving, but also how he sets aside time to think deeply about those problems.

Ian Mesey: This is something that is super challenging in any role, really, but actually thinking building time in your day to think deeply about problems. I do a time blocks on my calendar that I call building blocks, but usually that's me thinking about problems and putting them to paper, trying to formulate solutions. And that's a challenging thing is especially when you're... Both as a consultant and in house, your calendar fills up so quickly and you can easily spend your whole day in meetings talking about problems, but never thinking that.

Sean Lane: You like religious about protecting those blocks, those building blocks on your calendar. I did get in theory, everyone says," yeah, great. I block off these times in my day", but all of a sudden, those things can get overrun. Are you really strict about those building block periods?

Ian Mesey: Yeah. And I'm fortunate enough that my colleagues are behind me on it. They're very supportive of these deep think periods. And at Go Nimbly there, what we call cave days where people walk off almost entire day is to make sure they're thinking deeply about problems.

Sean Lane: That's amazing. So can you give me an example or take me through a recent session you've had of a deep think?

Ian Mesey: Another one is our loss analysis. When we're thinking through why we lose a deal, everyone's got the close, last reason. And I was on a call with Forrester. I was on a call with some Forrester folks and they had this tool that was used to find problems in the top of the marketing funnel. I have this up on my screen, this tool because I was going to apply it to the top of the marketing funnel. And then as I was in one of my building blocks thinking about loss analysis and how nuanced it actually is. You can't boil it down into one loss reason in a complex enterprise level sale. So I was thinking about this problem and I just happened to stare off into space and realize that I was staring at this sheet. It's got... They call it the diagnostic hypothesis map. It's basically a heat map for where problems are in any process. And I was like," oh, let's apply this to our loss analysis." I've this series of questions organized by the customer life cycle that basically give us insight into where the problems were in the deal when we applied this tool, if I wouldn't have had that time set aside to think deeply about that, I would have probably just been like," okay, what are our last reasons?" Because that's typically what one dots. And just put them into Salesforce. But because I set aside this time and we were able to come up with a creative solution that has offered insights that we wouldn't have otherwise had.

Sean Lane: And this is obviously from the way you're describing it, it sounds to me like a pretty solitary activity. How do you then translate that? Is there a process where you have someone on your team that you then," Hey, can I whiteboard this for you? Can I bounce this off of you?" What's your sanity checks so you don't come out of one of those thinking sessions and you think you're off on the amazing track and all of a sudden you realize that you're solving a completely different problem?

Ian Mesey: Yeah. That is a great question. I've found that it has been more of a solitary exercise coming in- house at BloomReach, but in the past, I have calling that I bounce ideas off of, of course that I trust in our really smart people. But in the past that when I was at Blue Wolf, we had this problem. People weren't thinking through there, the entire solution. They weren't thinking through the downstream effects of their solution, blew off the way back then, the way they hired for the team that I was on. They were hiring people, young people who did not have ops experience necessarily, which turned out to be an advantage. But at first they weren't used to solving these ops problems. And so this was Jason Reichl who you spoke about earlier. When I worked on this team at Blue Wolf and together, we tried to solve this problem and what we came up with this solution review. So, the project teams were typically a project manager, an analyst that did most of the configuration, Salesforce configuration and a developer. Those were a typical project team. So they would ingest a problem that they heard from one of their clients. They would put together a solution and we templatize the solution documentation. And then they would come into twice a week, we add a meetings called solution reviews. So they would come and they would present their solution to the broader team. And it was a way to get everybody's brain on one particular problem and to poke holes in each other solutions and to learn from the solutions that were presented. And I think that's one of the most successful things that we implemented while we were at Blue Wolf.

Sean Lane: I think the sum of Ian's two different practices here is much more powerful than each practice on its own. If you combined his deep think sessions on a particular problem with his solution review idea that you have with your peers. I think the end results will be much more thorough and impactful. On our operations team here at Drift, we run many ops show entails. Once a month at our team meetings where one member of the team gets up and presents to the rest of the team on a specific topic that is important to them or something that they've been working on. This not only allows them to show off their work, but it also gives the rest of the team the chance to learn something about what else is going on inside of ops. Lets them ask questions, poke holes, everyone on the team gets better as a result. And Ian's been through a lot of these cycles, both as a consultant and now at BloomReach. And he told me that a theme that he has noticed is that you really oftentimes can forget about the unsexy projects, the ones that are harder to articulate the short- term value.

Ian Mesey: As a consultant, you go in and especially organizations that have organically structured their ops environments over time. There's a lot of structural issues that are not the value of fixing those structural problems are not apparent right away to someone who is not... Usually, if you're dealing with an IT resource they'll inherently know that the value of let's say code quality. It's not as inherently valuable to the CMO or the head of sales or a VP of sales.

Sean Lane: Especially because a lot of those things aren't necessarily short- term wins. So if your company is going through high growth, it's not something that they can feel or experience, that day, that week, that month.

Ian Mesey: Exactly. And we touched on earlier in this conversation, we touched on selling the value of projects to your stakeholders. And that is difficult to do when the value is down the road. This will make it so that we can go public without spending a million dollars on data cleanup or something like that. It's really hard to communicate the value of that and even tie it to revenue, even though it is. It's hard to tie those things to revenue and that's really what it takes to sell the value of a project to a CEO or CMO or a CRO.

Sean Lane: Is there something on that list of unsexy projects that you have tackled since you got to BloomReach and you feel like you were able to tie some type of value too?

Ian Mesey: I wish I could say that everything is PG, but it's not it. It's a constant struggle and that's one of the things that is also hard to communicate when people are like, when is this X, Y or Z project going to be done? And the answer is, it's never done. You always have to care about data quality. You always have to care about code quality, but I think coming in, I did put together a governance program. I did put together. I applied the code quality structures that we developed at Go Nimbly to BloomReach. So for example, we had some contractors building out our support portal. They adhere to the code quality standards that we put together. So those types of things are important because let's say, well, for example, on that support portal project, they eventually hired a firm that was legitimately concerned about code quality and very, very talented solution architect. The initial firm that they were working with went live with a trigger. I think I was three months in when live with a trigger that completely shut off any ability to update opportunities. It's basically lock down the opportunities for us. And it took me several hours to figure out what had gone on? What had happened? Because I didn't know that they were doing a deployment.

Sean Lane: So, you're actually.... You're making me realize that there's this whole other side to this super power that you have now, which is you are probably a little bit of a pain to consultants at this point, but you were probably the most well- informed, well- prepared client of consultants at this point in time, which I think is incredible. So the code quality thing, can you... For someone who's about to maybe outsource our project to someone for their instance of Salesforce or for whatever, what's an example of something that you absolutely make sure that they have to adhere to.

Ian Mesey: It's an entire governance process, right? And you say governance and a lot of people in startups cringe when you say governance because crosstalk of bureaucracy and slowing down progress and things like that. That's not the intent of governance. The intent on governance process is to make sure that you're not breaking things in the process of progress.

Sean Lane: Can you define for you then? Okay, you came into BloomReach, you wrote a governance program. Can you define for us, what do you think of when you think of governance? What is the purpose of its serving?

Ian Mesey: If we're talking about the MVP of governance is a deployment process. Making sure that these folks are working in the sandbox, that no one is making changes in production, that they're promoting from a developer sandbox to a full sandbox, that you're running test scripts, that they have well- written test scripts, that they have well- written unit tests if it involves code and that the deployments go smoothly and making sure that if you're in charge of operations, you've got to make sure that you're on top of deployments because if you've got a lot of contractors or as I've seen at lots of organizations I've worked with, you've got 12 people with admin access to Salesforce, or every market area is an admin to Marketo or Eloqua. You got to make sure that those people are not making changes directly in Salesforce or directly in production I mean.

Sean Lane: And for everyone that you're talking about, because I completely can identify with the cringe, like, oh man, governance, all these rules. We have to slow down, it's going to hinder us. There's a long play there, that investment that you're making now both in terms of what it will yield you later, but also the work it'll save you later, right?

Ian Mesey: Absolutely. And it makes it so that you don't run into problems in future deployments. You hire a contractor to do one project. Let's say you hire a developer, let's say to write a trigger for you. And the trigger is pretty simple, but you could be accidentally laying traps for yourself in the future when you go to deploy and that you don't have code coverage. That's something that we're struggling with that BloomReach right now is, we have terrible code coverage because we've been in business for 10 years and people didn't prioritize unit tests in the past. So that's something that now I have to go and sell to my bosses, hey, I'm going to spend X amount of dollars basically in hours to fix all these unit tests and make sure that we have it solid foundation on which to build. And that runs... That causes problems with every deployment I do. I never know what I'm going to get when I hit the deploy button. I never know what to expect.

Sean Lane: You're coming into a mature organization, right? People have been building on top of building on top of a building all in the previous years before you got there.

Ian Mesey: I call that untangling the Christmas lights. It's a bit exclusionary the imagery, but my grandma had 50 years of Christmas lights in our attic and every year you'd have to go and figure out which ones worked and untangle all the wires and figure it out to be able to set up the Christmas lights.

Sean Lane: So then I need your help, right? So I am just as much an audience member of this show as I am the host. So one of the things that I need help with is we're growing really fast at Drift. And when you talk about building a strong foundation, one of the things that I try to make a distinction about with my team is, sometimes in order to continue to move fast, yeah, maybe you have to put a bandaid on something, but you never want to build on top of a band- aid, right? And so, how would you recommend or advise a company that's going through Hypergrowth to make sure that they are building those strong foundations even though it's never going to be perfect. How can I avoid a year from now, two years from now, five years from now having a huge heaping nest of Christmas lights to untangle?

Ian Mesey: That's always going to be challenged. And I even struggle with it myself. I'm doing what I said my clients used to do on stage, inaudible rosy picture, I'm not good at this necessarily. It's a constant challenge. I think the way that you mitigate those types of risks you're always going to have to put on band- aids every now and then, even as a hyper mature organization. You're going to have to deal with band- aids every now and then. One of those is estimating out your projects so that you're not having to... You don't commit to something that you realize you don't actually have the time to complete. So you have to change the solution to bandaid rather than to actually solve the problem in a scalable fashion. Two is to recognize when you're using band- aids and document those and put them on your backlog so that you fix them in the future. Because often what happens, especially at SAS organizations or past organizations or technology organizations in general is an ops resource will leave. And no one will know where the skeletons lie. It's basically time bombs for the future. So if you can build into your process documentation and documenting these band- aids so that the next person that steps into your role knows where to do them. And the guy that handed over to me did an excellent job. He basically just recorded video after video, after video, when he built. And I've used those... His name's Adam and he's hilarious and brilliant. I've used those so often. I've returned to those videos to figure out what this functionality is trying to accomplish and why he built it this way. And he talked me through all those in videos.

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?

Ian Mesey: Oh man. Not related to sales ops at all, but it's a book called October, about the Russian revolution in 1917. It's a very narrative version of that and it's excellent.

Sean Lane: Amazing. I will have to check that out. All right. Favorite part about working in ops?

Ian Mesey: I think your episode with Jay Zack, Jay Zach said... What did he say? You have to be a business athlete. You have to be able to change positions. You see a lot of different parts of the business and I think that's my favorite thing. I like learning new things and tackling new problems and that's every day is new in operations?

Sean Lane: For sure. never a dull moment.

Ian Mesey: Yeah.

Sean Lane: Least favorite part about working in ops?

Ian Mesey: Spreadsheets. I hate spreadsheets.

Sean Lane: Just all of them in general?

Ian Mesey: Yes. Especially ones that are big and monstrous and businesses run off of them.

Sean Lane: I will take it. Someone who impacted you getting the job you have today?

Ian Mesey: That would be my business partner at Go Nimbly, Jason Reichl. He gave me the original opportunity. I blew off and hired me there. And I've worked with him ever since.

Sean Lane: One piece of advice for people who want to have your job someday?

Ian Mesey: Yeah. Geez. I don't know. A piece of advice that... Don't... Well, yeah. I would say don't go directly in operations. There's a principle in lean manufacturing called Go and See. And I think that's really important where you actually experienced the problems because you have to have empathy for the end users. You have to have empathy for your stakeholders. And there's no better way of doing that than actually building sympathy by doing the job for a bit. So I love that a lot of the most successful people that I've hired in the past have come... Have been previously been an SDR or previously been a marketer. And those people, because they know the process and they have sympathy for their stakeholders.

Sean Lane: Thanks so much to Ian for coming on and being our guest on this episode of operations. That's going to do it for us. Remember, if you are interested in going to Hypergrowth San Francisco, the code is operations 99. Get your tickets today. Also, if you like what you heard on today's episode, make sure you've listened to all the previous episodes and to leave us a review on apple podcasts, six star reviews only. Thanks very much. That's going to do it for me. We'll see you next time.