Monetizing SaaS: Episode 36 with Scott Mitchell, Former CTO of Salesloft

Scott Mitchell, former CTO of Salesloft, discusses scaling engineering from $8M to a multi-billion-dollar acquisition. He shares how vulnerability-driven trust among executives enabled rapid growth, and details Salesloft's evolution from simple seat-based pricing to a metadata-driven provisioning system that migrated 6,000 customers while treating CPQ as the source of truth.
Chapters
Scott, um, I've gotten to know you over the last year and a half, and I've, I've really learned a lot from you, and I'm so excited for today's conversation. You know, most people who know you know that for the last 8 years you were the CTO of Salesloft, which is obviously one of the great software companies of the last decade. Um, prior to that, you were a principal architect for Silverpop, which was also a great success story in Atlanta, uh, before its acquisition by IBM. And when IBM acquired the company, you continued to lead architecture there and you did a 2.5-year tour of duty, I think. But in your own words, tell us your career story. How'd we get to now?
Sure. Thanks for having me. First off, this is going to be fun. Yeah, my career kind of bounces around. I've covered a lot of different spaces in IT. And so, you know, starting off my career at Southern Company, just in IT support, you you know, good old mainframes, and was very fortunate to join right as they were rolling out Unix across the company. And I kind of attached myself to the guy who was in charge of that, because I was playing with a really early version of Linux on my own. And that was a super kind of fortunate timing that led to a lot of interesting things. I went into consulting for many years, implementing Oracle Financials for customers. Where my job was, generally speaking, all the integrations, right? You're putting in these major packaged applications that have to attach back to all the homegrown order management systems, et cetera. And enjoyed that a lot. But looking back on it, the thing I missed was we used to joke our least favorite phrase was, well, that'll be phase 2. In other words, all the fun stuff went into phase 2 that we never got to go see, right? And so we couldn't get deep in any of those engagements. And that was something I, I grew to kind of long for. But the, the big kind of moment for me personally was our consulting company went bankrupt, uh, post.com. For example, one of our customers was Enron. And so there were a lot of unpaid bills and shattered dreams along the way. And I actually joined the IT department of one of my customers. And my, the CIO there was looking for somebody to help them implement financials for the 14 subsidiaries they had acquired over the last several years. And I was looking to make a pivot. And so we made an agreement that I would help him through that if he would help me move into the custom development space. And so I built a lot of web applications for them at the same time as, as rolling out this financial package. And that kind of made all the difference. I was able to then go get a job at Servidine, which is the first SaaS software company I worked for, which is an order management— I'm sorry, work order management system that was a hybrid web and mobile in 2005, I guess. And mobile then was BlackBerry, where SMTP was the communication protocol. You had maintenance guys walking around hotel buildings and office buildings that just didn't cellular connections at that point. So, but that was the big change for me is then that, that, that got me into the commercial software space, got me really introduced to SaaS architecture. And then from there on to Silverpop that you already mentioned, which was a huge learning experience, really, really getting to see scale for the first time. Billions of recipient records that we were managing, hundreds of millions of emails a day. It was, it was the real thing, right? And it was fun to watch that, you know, as we journeyed through that and grew it. And learned a ton from a whole bunch of really great people. And yep, the IBM portion of that was fascinating and interesting and soul-crushing, and it had all the range of emotions, right? And so grateful for that experience. I'm super happy that I made that move back to something small and agile again and got very fortunate to run into Rob and Kyle, the founders of Salesloft. It was truly unique. Journey for me personally and professionally. It was really just so much learning and so much that we accomplished that it was, it was really cool.
That's an understatement. I mean, you were there for 8 years, during which time you helped grow the company from $8 million in ARR, I think roughly, multi-billion dollar acquisition by Vista, and I think you built an engineering team to 150 people across several continents and so much more.
Lots of interesting learnings there. It is an interesting pattern that I sort of accidentally fallen into, Fynn Glover, which was all 3 of those companies, Servodyne, Silverpop, and Salesloft, which all start with S's. I didn't think about it till just now, but more importantly, we're all companies that had 80 to 90 employees and had a product that had reached product market fit. And I kind of fell into this niche of being the guy that helps come in and scale.
Yeah.
And so that was something I really enjoyed, kind of the challenges of scale and seeing how, what, what breaks when you press on it. How do you deal with that? How do you stay ahead of that?
Well, it's such a fascinating, it's a really fascinating moment in a company's life cycle because I mean, it's really hard to find product market fit. It is really, really hard to actually seize on the opportunity of product market fit. Not make mistakes, scale. I mean, there's so much that can go wrong for a company during that period.
Absolutely. And it was interesting because all three of those companies had very different paths. Successful, each one of them, which is good. And that's obviously largely dependent on the circumstances and environments those companies lived in. But I think I also learned a few things along the way and avoided some of our own little hiccups as well. Yeah. As always, business is fascinating and how they, how they evolve and what challenges they see.
It's like the greatest game there is. We're going to talk a lot about pricing and packaging and monetization, what you've learned about, um, that, you know, from the engineering lens and from the CTO lens. But before we go there, I'm just curious if, you know, if there's a moment that stands out at Salesloft for what it taught you about building and managing teams at that type of scale. And, and in the context of, you know, scaling, right? Because you got there when it was relatively small and you left when it was relatively big.
Yeah, I think we had 3, 3 Scrum teams when I joined. I don't think of a moment particularly, but I think of a couple of guiding lights that came out of it. I had been fortunate to work in companies that had a decent culture before then, but they weren't intentional. And the way Rob and Kyle approached building the culture of Salesloft was super interesting. One, that they thought it was important. Right? And they invested a ton of time. We spent so many conversations over the years, Fynn, trying to figure out how do we do this at scale in particular, right? They had this magic thing when there was, you know, 60, 70, 80, 100 people. How do you do that with 800? And it worked, right? And so what did it do for us? It drove alignment. It kind of let you cut past some of the distrust and jockeying when we all had a few things we knew we held in common., right? And that let us move fast. That let us engage with trust. And when something didn't go right, we kind of all knew we had that to fall back on and kind of work past or work through that issue, whatever it was. And then the second thing was that true belief that all of this comes down to trust, right? That everything we do, you know, in human relationships works better when it's built on top of a foundation of trust. And so I think about all the time we spent just on the executive team and offsites and daily rituals that were to share kind of the human side of who we were so that when we had those hard moments, when there was a disagreement, you weren't questioning whether your, whether your peer had a second agenda. You weren't surprised how they reacted because they've shared childhood trauma stories with you and you understand some of their baggage and how they might react to things. And it, uh, it was a huge accelerator, I think, and let us move quickly.
I wanted to ask you if there was like a single thing you have taken away around how to deepen trust across an executive team, like literally the tactical, how did that trust get developed? Was it many things or was it like a single thing?
I think it was many things built on a common kind of foundational idea, and that's vulnerability. And so if people are willing to be vulnerable and to share and share uncomfortable things, right, that we could get to a level of trust that you couldn't get to otherwise. And so that manifested in lots of different ways, right? It manifested in the simplest way before our operational meeting every week, we shared personal and professional highlights, right? And so we got to talk about our families. And we got to talk about the things that were going well. And in fact, we could talk about the set-asides that, you know, things that weren't going well at home right now, a child who was struggling or, you know, a parent who had been sick and acknowledging that was real and happening and that that might impact how I perform today, right? And sharing that openly. And then through offsites where we would do all sorts of exercises where we intentionally shared our own journeys, our own stories. It's a great lifeline exercise that we can get into at some point where quick, take 10 minutes, identify the 5 most crucial moments of your life, walk through them in first person, right? I am 8 years old. I'm in third grade. And blah, blah, blah, blah. You know, it's a a mind-numbing thought, but in the end, it doesn't matter that they're the 5 most important. It's that they're 5 formative experiences, those things that jump out to you and being open and willing to share those. I think because of the way we hired, right, you also brought people in who were ready to do that, or at least open to trying. And then it wound up in some really neat sharing and kind of realizing that when you share something that feels super uncomfortable, And there's somebody else in the room who has a similar experience and can relate to it and can kind of have your back as you share that thing.
And maybe it's super exceptional. I mean, maybe to that idea that companies, there's so many ways companies can really hurt themselves even after achieving product market fit. Sounds one of those examples where the classic adage of culture kills strategy or eats strategy for breakfast is really true, like an exceptional culture. Guided a business through new executive team members, through a lot of change, you know, with a really consistent steel thread.
Major pivots in strategy, right? And through a super competitive landscape. Yeah.
What was the most— what was the biggest surprise to you when you look back on the Salesloft journey?
I think we already touched on it really, was that revelation for me that culture that culture could be created, right? And that maybe secondarily that there's a difference between culture and core values. I stressed a long time about we're growing, everything's changing. And frankly, the culture is changing, right? The core values were the constant, right? And so he was the founder of TikTok, one of our customer practices. He said, core values are the lens you look through. To see if your culture is evolving in the way you want it to. It unlocked me personally, right? I was super stressed because I could see it changing. Yeah. And I didn't know if it was okay. It was changing. Yeah. But that separation of those two concepts was super helpful.
That's so, so cool. Um, well, shifting a little bit into pricing, packaging, monetization, you You know, I think maybe it's just a, a kickstarter here. You saw a lot of evolution from a pricing and packaging perspective, given the scale that the business achieved. And I think what is often true is that as a business scales and evolves from like a single simple product to a multi-product offering, from maybe smaller startup customers to enterprise customers, from maybe an original price metric to maybe kind of multiple price metrics or hybrid billing models, poorly managed pricing and packaging can be a very significant, a very expensive challenge for companies. And not just in the strategic sense, like maybe we're underpriced or something, but from a systems and architectural point of view. Because once a pricing model is in place, it's often very tightly woven into effectively an entire organization. And that includes really important business systems, billing systems, CRMs, quoting tools, et cetera. And also the application itself. Um, and changes as the business responds to the market can often end up creating a lot of instability for engineering, maybe, as well as sort of work for engineering where there has to be this considered trade-off between do we allocate engineering resources to the latest pricing and packaging initiative, or do we just go focus on core product? And so with that as maybe sort of a backdrop, can you tell us a little bit about the journey that you witnessed related to pricing and packaging and monetization? Tell us a little bit about that journey, that story. What were the chapters?
I'm sure I don't have it well broken up in the chapters, but we can get some, some kind of top of mind thoughts. I think the first thing to know is that Salesloft was fortunate in a way that the pricing model is pretty simple, right? It's, you know, charge based on the number of sellers you have using the platform, right? And in the early days, it was super simple, right? There was the Cadence product. That's all there was. You know, would you like it? Would you not like it? Right? There wasn't any— there were some subtle add-ons, right? Were you using the dialer? Um, were you paying for, you know, phone numbers, international phone numbers? So some of those things were very transactional, right? You buy a phone number. But it's not a subscription per se. And so the subscription side was relatively straightforward. That meant we didn't have to invest a lot in the early days in terms of billing, building those integrations. The platform was relatively unaware, right? Because you had an order, it came in through Salesforce, that was the official record and getting that translated into the billing system, the platform was okay to be out of the loop. Right. And provisioning was manual. We had an admin console, very simple. To your point, you know, it's hard to invest a whole lot of time in making that sexy and super functional when you've got a dogfight going on in the market and you've got to keep, you know, getting moved forward in terms of that actual user functionality. So for a long time, the platform was largely unaware and we just had a success team. Configured things as needed. To your point, we acquired Node Ninja, which was a meeting platform recording capability. And so super interesting and valuable to us in that we also have all these transcripts of recorded conversations that we wanted to derive value from. But we now have the first packaging conversation, right? Sorry about meetings. Sorry about meetings. And then not too long after, we bought Costello, which was a deal management software. And so now you had that sort of full lifecycle, right? From prospecting through deal closing, which was great. And it was a very strategic move, super valuable for the company. Um, and also opened the door to good, better, best type pricing, right? And bought multiple packages. And there was nothing. To make that smooth or easy. And so Salesforce was updated so sellers had the right SKUs to sell and prices on said SKUs, et cetera. But again, there was nothing there from the platform perspective. And so interestingly, we had actually done a lot of kind of the legwork early, early days of building a metadata-based platform features concept and then roles and responsibilities that were tied to those platform features. So the manual provisioning was turning these flags for platform features and that just cascaded into the role you were assigned and then you showed what you could have access to or not. Right. So that metadata was there. What wasn't there was the ability to seamlessly go from a one to opportunity through a provisioned tenant in the platform properly configured. And so, not too long before you and I met, as I recall, probably about 9 months before, we finally really bit the bullet and invested in a team within our SalesOps group that maintained Salesforce, really then engaged with the engineering team and built a metadata-driven I guess I need to step back. There was an iteration of the integration that existed for probably a couple years before this, but it was very hardwired, right? It was very basic, very scripted, not fully capable, and couldn't actually do the full provisioning piece. But it was entirely unable to adapt to any new pricing at all. I think that's the way. And so this new system we built finally took a metadata-based approach and we got some more APIs built by engineering into that sort of admin console so that we could say, you know, SKU X maps to, you know, these product and packaging features that had already existed within the platform. And that took 6 months, I guess, probably to build, probably another Gosh, I don't know. The worst thing, the most painful piece about that was all the research that then went into migrating existing customers to be compatible with this new approach. And there are 6,000 customers or something like that where some of them matched between Salesforce and the platform, but so many didn't. Right? Because we took an approach for a long time in this concept of soft limits, where the idea was that a CSM could go in and add a user or two for a customer who needed one. The idea was that on a quarterly basis, they would go in and reconcile, or at least at a minimum before renewal, reconcile and get upgraded to the proper number of seats. A lot of that happened and a lot of it was reconciled, but a bunch wasn't. So you had this awful multiple-month investigation of trying to figure out what was the source of truth, what was the proper state, and getting it all reconciled so that this automated system could even do the right thing. So it was pretty painful, and it would be really interesting to, to loop back with some of those guys since leaving. That was about a year before I left, the way that system went live, and see how well has it adapted. I think we got the model right, but you never know until you really, you know, go through your first major change of the company. So definitely it was hard for us to do.
What did, um, one thing I'm really interested in is sort of the components of monetization and, you know, it sounds like to some extent you built an admin panel, you built flags, you eventually built provisioning. I'd be interested to kind of get your point of view on like architecturally, what are the components of monetization and B2B SaaS that CTOs should be aware of, you know, as they— especially if they're in a scaling business where they should expect that one thing that's very true is pricing and packaging will change, right? Even if it's simple in the beginning, it will change.
Yeah. And I guess first off, my first reaction— I know this isn't a direct answer to your question, but there's also that interesting balance of in the early days you probably don't want to build too much, right? Or buy too much. You're going to be experimenting. You're you're in this phase where you, you don't have the weight of a large number of customers, a large amount of data, and you can pivot more quickly and sort of figure out what's working, what isn't working. The components, and I'll broaden it past quote unquote monetization, right? But ultimately there's the question is a customer has signed a contract all the way through to they are using the system and using it, getting the right things, access to the right things., and then beyond that, paying for what they have used either upfront or in arrears, right? And so for us, that meant, you know, Salesforce CPQ. So Salesforce opportunity management, CPQ for the actual deal details, right? Through to, on the other end, go all the way to the other end, users who have a role, which is many responsibilities. Which are constrained by the feature package features that are enabled for that tenant, which then need to bridge. And that's the bridging point, right? And so that the user information, the tenant information, the feature package configuration is all part of that admin console, right? And then you got CPQ with a bunch of SKUs, right? In and of themselves don't have any meaning, right? They, They are a textual description with some sort of pricing information hanging off of it somewhere, right? And then a unit of quantity. And so then the exercise there was that provisioning system that sat in the middle that did a bunch of things, but most importantly for this conversation, had that metadata to understand that when you, when you put these three things on order, you know, these other corresponding things need to happen in the provisioning tenant so that when that user logs in, the right, the right managing is present so that the menus render the right things, the backend allows and prevents calls based on all the way back to what was on the end. Sure, there's components missing in that as well, but that was the basic flow. And interestingly, we had to build a bunch of reconciliation stuff because still end users, CSMs, could go into the admin console and manipulate the tenant manually. And so building in reconciliation capability, building in alerting so that you could know that the tenant no longer matched.
Yeah, makes a ton of sense. And I think what's also interesting about what you were describing is you first started with CPQ. So kind of through the, in some ways, the lens of the customer funnel, which is through from purchase to invoicing and billing to actual like feature delivery, feature consumption. And it reminds me that, you know, tell me if this feels true of Salesloft, you had multiple stacks that were governing or operating on pricing and packaging. You know, you had the sales stack where you had Salesforce for managing the opportunity, CPQ for managing the quote. You had the finance stack, which I assume you had some billing system that— I'd love to learn more about billing, but I assumed the billing system was managing subscriptions. Managing invoicing, managing collection of payments. And then you have the product stack where you're like fulfilling or provisioning that contract and maybe where applicable metering usage.
Correct. Yeah. And interestingly, billing was stable enough that I never had to get my fingers into it. That's fair.
And that's awesome.
I know. Well, and interestingly, I think go back to, well, how did we price? How did we sell? And the model was pretty simple. Right? So there wasn't— CPQ was the source of truth, right? That was the order. And so I think the good news is while, while we had lots of systems in play, and while we had a total lack of integration for a number of years and different levels of integration going forward, I think we were always pretty clear on what actual source of truth was.
Yeah.
Right? And so we didn't have that sort of multi-master challenge to deal with. Other than what I mentioned, that you just flat out had the world where CPQ and the platform that didn't match. But in that case, CPQ was treated as the master. That was what was billed, right? And so that integration was, like I said, straightforward enough, stable enough that I was very happy that I never had to get my, my fingers into that piece of it. Yeah.
Can you share a little bit of like when, when it, when the business decided that it made sense? To build this provisioning system. Why? Why was that decision made?
Yep.
Who was a part of making it? Did it just land on your desk? Tell us a little bit about how that all unfolded.
Sure. Why is because we knew we couldn't do the thing we needed to do next, which was we had a major project to reconsider how we were pricing ourselves in the market.
Okay. So that was like a major, a major kind of rework to pricing and packaging effectively.
Yeah. Yeah, which both were long projects to get done and ran concurrently and mostly worked out in terms of timelines. Right. But it became clear that we just couldn't continue to operate the way we were operating. Right. And we needed, we were investing all this money working with consultants to figure out what the right way to go to market was, what an improved way to go to market would be. And yet we knew we really couldn't. Survive the answer, whatever the answer was, without investing. And so that's how it finally got pushed to the forefront. How it wound up on my plate, I had shifted my role, I guess that previous February, where I had actually picked up our internal IT. And so I've kind of moved into a blended CTO-CIO role. And so it was, it was very, at that point became very clear that that was my project to sponsor, right? Because we needed to get into both sides, including sales ops, which sales ops wasn't formally a part of IT, but they were very close partners. And so I became the exec sponsor for it, but it was really largely run by another Scott at Salesloft, interestingly, who was the head of the sales ops systems team. Yeah. He kind of did all the day-to-day and I was a sounding board and a guy to help push whenever things were still getting stuck. And then I also got to chime in on design stuff, which was great because I didn't get to do a whole lot of that at that point as Salesloft had grown.
So back into some of the systems architecture.
Mm-hmm. So fun.
Make sure I understand. So effectively, the business, I mean, at this point it's surpassed $100 million in ARR. It's looking to really reconsider next-generation pricing and packaging. It brings in a consultant. I imagine at that scale, it's a relatively meaty contract with a consultant. And the reality is that whatever the consultant comes back with from a recommendation perspective, the business may not be able to operationalize it.
Yeah. At least not efficiently, right?
And is it fair to say that the answer is this provisioning system because now the business can sell different bundles with different add-ons with different configurations to support a bunch of enterprise customers, or is that sort of a bad, a bad way to frame it?
So, so yes, that was absolutely the reason to do it and the goal to do it. In turn, the goal was to turn pricing changes into a metadata exercise, right? You shouldn't be You know, running an engineering project for 6 months, pricing changes. You want to be able to say, these are SKUs, these are how they map into the capabilities of the platform, and be done. And so the why behind the pricing changes, you mentioned enterprise and yes, we were moving into enterprise and finding a lot of traction there, which is great. I don't really feel like that was the change. It was really the strategy change. And a positioning change of the product, right? We started off as a prospecting tool. We started off as building the category of sales engagement, right? That had not been a branded thing. And we spent months of evangelism making that true. And yet, as the business evolved, we had to kind of step away from that. And so now we have this capability that was much broader than prospecting, right? It was full sales pipeline all the way through closing the opportunity. Company and managing the customer relationship. Really, even we had CSMs as customers, which is great. Yeah, but we had to reposition how we talk to the market. Yeah. And as we're repositioning how we talk to the market, well, that means we have to package it and price it differently as well.
We're no longer a prospecting tool, we're now a full platform.
And yeah, yeah, we've been the term revenue workspace for a while. For example, we thought that was going to be the thing and, and that didn't wind up sticking either. Um, so there was still some, some iteration and pivoting even at that, you know, $120, $130 million ARR sort of point in our lives. But it was really driven by that product strategy change.
If you had a bunch of, um, product and engineering leaders listening to this conversation and they were in front of you right now and they'd all just joined companies at $8 million in ARR or $10 million in ARR. And their businesses had very good metrics. I mean, these were 100% year-over-year growing companies. What might you say to them around key things you've learned about supporting the business's evolution with pricing and packaging? What would you want them to take away?
I guess the first thought is at some point you're going to, you can't be the whole cobbler's children have no shoes, right? You're going to have to invest in things to allow the company to scale. That don't feel like they're generating revenue, right? It's so easy to get tied up in everything we're working on has to be a feature that's going to generate more revenue. And yet you got to find the right time for that, right? And I don't think there's a boilerplate answer to that. It's all dependent on your market, kind of your current state and where do you stand, you know. And so being flexible but also being vocal, right? It is rare that the business will step forward and say, you know what, you need to slow down feature delivery and invest in this backend thing. Right? That's not likely. Just like they're not going to talk about tech debt. Right? That's another, not pricing related, but a real challenge for a growing company. Right? And so finding the right way to make sure everybody knows the gaps you're seeing, that they exist, and brings them forward in a way that you can have a real trade-off conversation. Right? And it might be the right thing, both with tech debt and with things like pricing and packaging and other internal tooling sort of setups. To make a conscious decision to not invest right now. That's legit. That's fine. But it should be a conscious decision and not one that just sort of, we just keep sweeping this thing under the rug. And then—
Because conscious implies, you know, there's a debt to pay off at some point.
Exactly. Rob Foreman, one of the co-founders, used the word intentional all over the place. And this is another example where you want to be intentional, right? You don't want, you want everybody to be making decisions with all the right information., and the fact that you are swimming in debt, whether that's tech debt or kind of internal IT debt, should be something that people know and make conscious, intentional decisions.
What extent do you think companies broadly, SaaS companies, you're beginning to do some consulting as well as Salesloft, do a good job of overlapping the core product roadmap and the engineering roadmap with a monetization roadmap. And maybe the question behind the question is software companies are always shipping new value. There's always more and more value coming out, but given pricing and packaging often changes at a slower rate, companies are often not capturing that value in a really consistent way. So I'm curious what you've learned about the extent to which companies do a good or bad or neutral job of aligning those roadmaps.
That's a hard one. I don't know that I have a great kind of cross-cutting example or answer to that. I will say, in my experience, companies don't invest enough time finding the right levers for pricing, right? And I think some of that is because it's hard, systems-wise, not just business-wise. It is so challenging to— I think about this: in the software industry, we've gotten really good at A/B testing software, right? We can deploy the software with flags. We can choose for 10% of the customers to see it this way, and then 90% haven't seen a change, and we can learn from the feedback and very quickly pivot, right? That type of flexibility really needs to exist in the pricing world, right? You need to be able to experiment. You need to be able to put different offerings out there. You need to be able to get feedback about what's working and not working and make changes quickly. And so the other bit of advice is Guess what? Building something like that's really hard, right? And not generally speaking your core business. You wouldn't, you wouldn't build your own CRM. You're going to go buy Salesforce or Dynamics or something. And yet I think engineering leaders to a fault have a tendency to have, or engineers in particular, have this bias to be the first thing their reaction is to, well, I know how to build that. Right. And yet pricing is super complicated and you need to do it in a way that you're allowing for a ton of flexibility. So I do think just generally speaking, companies don't, don't spend enough time to get enough value of finding the optimal way to go.
In pursuit of that flexibility is one of the essential, like if you were to sort of think through the shape of a solution, is one of the essential bodies of work, decoupling pricing and packaging and sort of business logic from application code.
Absolutely. Exactly. What should the— what should your application worry about? Your application should worry about delivering the right— a ton of high-quality features, delivering the right ones to the right users based on what they've purchased.
I see.
And then probably some sort of opportunity for the platform to engage in cross-sell, upsell, right? Some teasers. Oh, hey, you don't have this. So, you know, click here for a free demo or something. Yeah. It does not have it, generally speaking, in its domain, at least in my experience. What should the user pay for that feature? And so decoupling those, it's just good application design, right? If you go think about, we were very microservices-based, right? You want a well-bounded context for each thing you're building and pricing and packaging is a domain that should be in its own, its own context, well integrated. Yeah. That makes sense.
Yeah, totally. So the application should care to provide great functionality and correct access. It shouldn't care about the price.
That's my belief. And I'm going to caveat all this for a second, Fynn. I have grown up in companies with a direct sales team with significant sales cycles, right? So where you're you're operating in a very specific way that is fairly traditional, but there's also a whole different world of product-led growth and, you know, free trials and self-service signup. And there, the world's probably blurrier, but also easier to make the investment in automating all the things, right? Yeah.
Scott, thank you for this time and for sharing all of, all of these experiences and insights. Um, tell us a little bit about what you're working on now. You're, I think, what are we, 6 months removed for longer, maybe a little bit longer?
Yeah, it'll be 7 months next week. Yeah.
So where, where are you starting to spend your time?
Yeah, so for the first time in my career, I just took some downtime. My wife's a teacher, we took the summer together, uh, and, uh, just played. It was a ton of fun. And so as she started back to work That was my cue to kind of pick my head up and go, gee, I ought to, I ought to figure out what I'm doing next. And so I've been doing a lot of exploration before I've done this sort of pattern 3 times, and I don't think I'm going to do it a 4th. And so that all of a sudden means, huh, I don't know what I should do next. And so where I've kind of landed in the last couple weeks through a lot of conversations is kind of entering into the fractional CTO space, looking for the opportunities to kind of help companies with kind of their next steps in that growth stage in particular, I think would be a really good sweet spot to help them maybe dodge a couple of issues that I may have stumbled across before. And that can be lots of really different structures to it, right? Some of them are just straight advisory roles. Some are coaching type of roles. Some are, you know, interim sitting in the seat where either the company is going through a transition or a company that just isn't large enough to have a full-time CTO yet. And so I've been talking with a lot of companies around the Atlanta area and a couple, uh, I have so many companies that are fully remote now to see how I might be of assistance. It's going to be very unstructured working, figuring it out.
Really, really exciting next chapter. When you zoom out, you start working with some of these earlier stage companies. And when you zoom out and think about the next 5 years and what, what the next 5 years mean for CTOs at early and growth stage software companies. I'm curious, maybe some of the inflections or trends that have attracted a lot of your curiosity and a lot of your energy.
Yeah, I think it's really, really— everybody is really focused on what the impact of generative AI is. That was just me on a bunch of Atlanta CTOs a couple weeks ago. And it was a really interesting conversation. We're all trying to figure out what does it mean to build software 3, 4, 5 years from now. And I think it's going to be radically different. And so lots of early experimentation on kind of what is that kind of human coding assistant model and how far will it go. But it's— I heard somebody say, well, oh, just there are going to be all these engineers that don't have jobs. I'm like, no, I don't think that's it at all. I think yet again, this is another example of accelerating delivery. There is, in my experience, immeasurable demand for new capabilities, right? And so if what we can do is move faster, that means there are, there are more companies innovating, there are more companies building things, possibly with smaller teams, but just more efficiently. And so I don't think software engineering is dead. I do think there are, there is a need and will be a need for technical people, technically minded people to collaborate, guide, validate, confirm, and innovate with generative AI solutions. And so it's going to be, it's going to be super interesting to experiment with and see where things land. But that's certainly the central thing I think everybody's trying to get their head around right now.
Me too. And one of the things that I'm most curious about is, um, what's the second order of effect related to cost structure? I mean, historically, building software, this is like a non-zero marginal cost business. That's why it's been such a great place to invest capital and be an operator for so many years. But generative AI is like the opposite of non-zero marginal costs. So what happens is a question I certainly do not have an answer to, but one I'm fascinated by.
Yeah. Yeah. And it's super interesting. As I was kind of wrapping up at Salesloft, our data science team had built several features over the years that were language-based, right? I mentioned all those transcripts, right? We have so much textual data at Salesloft and how do you derive value from it? And obviously that had changed through things like OpenAI and such. But I think there is an interesting pivot that's going to happen as well where the massive models aren't always the answer, right? Large language models are valuable. It's the question of how large and to your point, what the cost of those models are to maintain and operate. And so I think you're finding now some people picking smaller, more purpose-built models to deliver certain capabilities. And then you can have a federation of models as well to where, depends on what domain you're building for, right? And so we were looking at things like how do you have a sales assistant, right, that can help do so many things and, and sort of there you can get a case where you're routing across smaller models that do more purpose-built things, but still with the capabilities of understanding language and organizing. It's going to be—
we, we live, we live in interesting times.
Yeah, exactly. You can use, you can use a bad English.
You, you've already slightly touched on this, but the closing question I like to ask, I'm curious if your answer changes a little bit here, is Is there a moment that you view as truly the most formative in your professional career?
I think the most pivotal moment was that conversation with the CIO at my customer, my consulting customer, where we made that deal, right? Give me a couple years. He got something and I got something. I managed to change my career, right? Going from, and the motivation was going from a place where I felt like I was always viewed as my work was part of a cost center. And the, the view generally was how in the business can we reduce what we're investing here to instead moving into part of the revenue of the business, right? How do I build the thing that makes the business? So that was very pivotal. But in terms of like growth and kind of expanding my own personal horizons, I think the day that when Kyle actually asked, I wasn't hired in as CTO at Salesloft. That was about 5 months after I joined. I very distinctly remember the call, and Kyle called and asked me to take that role. I 100% did not fully understand the implications of taking that role. Of course they wanted to be CTO. What technologist doesn't see that as the pinnacle of what they're doing, right? But the journey that sent me on in terms of personal growth was amazing, mind-blowing, terrifying. Julie.
This has been such a pleasure. Um, and I'm so grateful to you for doing it. Where can, where can CTOs who want to learn more from you and talk to you reach out to you or find you on the internet?
I imagine the easiest answer is LinkedIn and the general answer is all the socials. And I'm on the same, same handle everywhere, which is, uh, smitchellus. It's a long story. We won't get into that, but it's S Mitchell with one L and US on the end. Uh, it goes back to, uh, my first Yahoo email address. So, smitchellis, you can find me anywhere with that, that handle.
Thank you again, Scott. So much fun.
Thank you, Fynn Glover. It's been fun. Talk soon.
More from Fynn

Schematic at Operators Guild Demo Day 2026: How to bill for AI credits without a surprise bill

Should you move to usage-based pricing because AI is compressing your margins?

Why raising prices every year backfires (a pricing leader on the Mastercard quota model)







