What Happens When Engineers Think Like CEOs? — with Ryan Debenham

Hey, what's going on everyone? Welcome back to Mastering Tech Growth. Every week we chat with industry leaders to bring you big ideas on how to grow. I'm Mike Sirius, and today we are diving into why it's not enough for software engineers to stay in their lane and what happens when they bring go-to-market thinking into how they Joining me is Ryan Debenham. Ryan's career has taken him from building enterprise tech at Qualtrics to scaling Routr as a CTO, and now leading Rin as a CEO. He's lived through the journey of crossing lanes, from technologist to president to CEO. And today he's sharing what that shift taught him about building products people actually adopt. Ryan, great to have you on.

Thank you, Mike. Good to be here.

So we'd love to kick off with this one. When I say mastering tech growth, what comes to mind?

That's a great question. You know, I think you could think about that in a variety of ways. As you mentioned, I started my career as an engineer. And so the first thing that, that I go to is technology growth as an engineer, the skill set that you have, um, the, the evolution of, of different ways that we can build products, different technologies that we can use. You know, it's, it's so hot on my mind right now because AI as a new foundational building block is— it feels like such a growth moment for technology people right now thinking about How do we take this new fundamental building block and, and create new types of products? Yeah. So that's, that's the first thing that comes to mind. You know, another thing that comes to mind is professional growth. You know, how do you navigate a career? In fact, I actually felt lost early in, in my career trying to think about, will I always be a software engineer? And if, if I'm not a software engineer, where do I go? And, you know, to be very transparent, my first internship was with a big enterprise mining company.

Mm-hmm.

And my intuition at that time was, well, I get my boss's job and then if I'm successful, I get their boss's job. And then if I'm successful, I get their boss's job. And, you know, at that company, it, the, the leader of the technology division was a, a CIO and That looks like such a boring job.

Yeah.

So I, I had kind of this crisis, like, what is my, where is my career going or growing? Um, so I'm, I'd be happy to talk more about that, but growth professionally and then your business growth is, is just such a fun topic. How do you really grow a business? How do you create something that customers love? Um, and, you know, using technology as, as the, the primary driver.

I love that. You put almost like the three pillars around how you think about growth. So I want to rephrase this question and make it, I want to say more difficult, but let's see. So from all the things that drive a tech venture growth, so we're talking about any business that is technology-driven. If you can choose from all the things that influence growth directly or indirectly, could be sales, marketing, hiring great talent, go-to-market strategies and a lot of, you know, things. If you would choose one, what do you think is the most important from your point of view when it comes to growth?

That one's easy for me. It's a good product.

Okay.

It's a good product that customers love. I think that, I think there's two primary drivers of growth in a business. I think customers can pull you forward because they love what you're building so much that they need and want more of it. Or I think that you can brute force push a company forward. I think that you can push what you've built onto people. And that doesn't mean that it's not valuable, but it's not being pulled for, it's, it's being pushed. And so I do think the right product that customers truly love. And it truly solves their problems is the best driver of growth ultimately.

Excellent. That's such an excellent answer, right? I love that. So it's like a pull and push mechanics, right? You can be behind your product just pushing through sales and marketing that forward, or you could just enjoy getting pulled by your customers forward. You just want to be in that pull, isn't it? Because it's just so much easier, right?

Yes, it is. That's where we want to get.

Yeah. And then if you add the push behind it, oh, you're running, right? That's a great product. So we basically saying it's a product-market fit. But like if we put in the fancy keywords, it would be have a good product market fit, right?

You know, and I think people will, that's an interesting way to phrase it because that's a common way for investors to talk about it. Do you have PMF? Do you have product market fit? And we talk about product market fit as something that's quite uncommon, right? It's most businesses don't achieve great product market fit. Um, you know, and I would even go as far as saying businesses that I have worked for that have been quite successful, I think that you could challenge the product market fit and say, you know, do you really have this dialed? Because I think that true product market fit will be pulled for, whereas if it's not quite the right fit, you're going to be pushing it and it's going to be more brute force.

So the litmus test is effectively, can you say that you're getting pulled? Hence you have product-market fit, otherwise it's debatable. You've really nailed it.

Yeah, I mean, it's a spectrum, right? But I would say you've really nailed it if the customers are pulling for it.

I love that. That's such a simple way to explain it, but I think you landed that very well. I'm enjoying this. Thanks for that, Ryan. Thank you. So let's take a step back into your career. So I got this one. When you think back on your career, Qualtrics route or even early green, Was there a moment when you realized that staying in your, in your lane just wasn't working for you?

Yeah. Yeah. I would go to the first time I really experienced that was at Qualtrics and I got very uncomfortable. And the reason for that is I was working directly with our co-founder at Qualtrics. And he was putting a tremendous amount of pressure on myself, who was an engineering manager at the time, uh, and my product manager. And the problem that we had was that our customers were essentially not, not pulling for a particular product. We were building text analytics at the time. This is back in 2014. At the time. Text analytics was very basic natural language process, nothing like what we have today, right? Like the ability to talk to a comp— a computer in AI today is mind-blowing compared to where we were just a decade ago.

Yeah.

Um, but we were building text analytics features and we were particularly focusing on sentiment analysis. So what was the sentiment of the person that wrote this particular text? Were they happy or mad or You feeling some emotion?

Mm-hmm.

And then we were doing topic analysis. What are they talking about? And then the, the best was when we could tie the two together. How do they feel about what they're talking about? That's ultimately what we were trying to achieve. And the reason for that is our customers often had millions of people writing these freeform comments into their surveys, and they wanted to know what are they talking about and how do they feel about it. Well, we built a feature to do topic analysis. And sentiment analysis. And it didn't land right. It was too technically focused. It was too complicated. It was exposing these complicated models, bag-of-word models, and, you know, sophisticated, like, algorithms to the customer that we were quite impressed with. We're like, this is the latest and greatest. This is the best thing that you can get. And the customer, yeah, I remember, I remember being on the phone at one point with, with one of our customers and they said, this is really cool.

Mm-hmm.

But I don't know how I'm going to use this to drive actual, like, decisions and value in my company. And that was like kind of a little bit of a gut punch, to be honest, because we had spent tremendous amount of time building it. We were very proud of it as an engineering and product team of, of what we had built. And I remember my, my co-founder at that time came back to me and put a tremendous amount of pressure on me and said, basically, you are building a poor product and you're not understanding what our customers' needs or problems are. And honestly, my immediate reaction to that was, I'm building what the product manager asked me to build. Yeah. And, you know, I'm building— and he said, you know, the design is crap. And I said, I'm building what the designers spec'd in the design. I'm, you know, I'm building what I've been asked to build. And not only that, but I'm building it with like the latest and greatest tech. So I felt quite shocked and confused by the feedback. And uncomfortable with the feedback because he was pushing me to step outside of the box that I sat in, which was as an engineer, you get product requirements from a product manager, you get design requirements from a designer, and you build those things. And he was challenging me to say, go build something that your customers actually want.

So let's dig into that, Ryan. Let's just go in that, like, why a solid, as you describe it, a solid engineering work doesn't mean adoption. Like, in so many cases, it just doesn't mean that. And I had the same, I had the same, Ryan. I remember being head of engineering in a startup. I literally thought good engineering solutions, you know, good cloud, you know, clean code and fast deployments and everything, like, somehow gonna translate into adoption. And it doesn't. Like, the customer at the end of the day, I mean, they don't give a shit. Something in their hands, if it works, if it solves my problem, that's what I'm paying for. What's behind it, right? Like, they don't care. And but engineers seem to be like not really not registering that. Like your point of view, like why is that? It's like, why we have that?

Honestly, I think it's a lack of empathy. Like It's like everyone is busy, everyone feels pressure, everyone's trying to meet a certain expectation.

Yeah.

And drive, you know, the best outcomes for themselves personally, their family. They all have their own personal motivations. I think people naturally gravitate towards doing the things that they believe will deliver the best outcome to themselves. But okay, I think that it's a lot of work. So as an engineer, I know when I— because I'm still actively coding, I know that when I'm actually, when I'm actually, you know, actively building something, it is hard to put the problem down and go and ask questions. In fact, it's like, there's like an ego attached to what I'm building. Don't tell me this is wrong. I'm really proud about what I just built. I don't want to hear that this is wrong because I just put— I just, you know, dumped a ton of time and energy into this thing. I don't want to hear that it's wrong.

Yeah.

But not only do I not want to hear that it's wrong, I don't want to be told to do something different because maybe I don't have time to do something different. Maybe I'm already behind on the task that I'm building. Maybe there's expectations that I get this done, you know, for my, my team, my sprint, whatever I'm working on. Yeah, I just think it's hard to get your head outside of the, the sea of expectations that, that you have and go focus on something else. Because in order to truly understand your customer, you have to understand their world. You have to understand what are— what, what, what pressure do they feel? What, what are their expectations? What are they trying to, to solve for? And am I actually helping them do it? Is, am I actually solving a problem that they have? Or am I just, you know, making assumptions that I know what they're feeling and building to those assumptions, but those assumptions are wrong. Mm-hmm. And, and that's, that's what happened with me, you know, when I was building this, this text analytics feature was I was making assumptions that I understood their problem and that I understood what they wanted because we had talked about it and intuitively, oh yeah, I know what text analytics is. I know what sentiment analysis is. And, you know, the, um, working closely with this founder, like I said, he kept coming back to me. I'd run a proof of concept by him or a prototype and he would say, no, this is wrong. This is wrong. This is wrong. And I would go back. Here's another version. Here's another version. Here's another version. And it was just wrong, wrong, wrong, wrong, wrong. And I, you know, at one point I changed the talk track with him. I said, hey, I clearly am missing the point here. I want to— in fact, the reason I said that was because he said, I'm losing confidence that you and this team is capable of building this product, I'm going to have to go acquire a company to meet the customer's need.

Damn, that's not a good feedback, right? Like that's, that hits your heart, right? Yeah.

Well, and he made it personal too, because he's like, you know, that's going to be 10% of my equity or something. Like 10% of my equity is of the business and your equity is going to go to acquiring another business so that we can do this problem right. And so that's where I followed up and said, look, I've lost your confidence. I want to earn your confidence. I want to understand here. I want to step outside of, you know, what we've been doing and try this from a different approach. And that's where he pushed me to basically change the altitude, level up and get outside the box.

Okay. So I have two ones here, right? So I'm putting myself in your position and I just don't, I just feel like I'm becoming this defensive defensive and almost like evasive in that feedback, I would probably be like, whoa, whoa, whoa. I'm being told, right? Like, is that not a product situation, right? Like, if you're not happy what I'm building, go have a chat with the product because I'm just realizing their vision. And I instantly would go like, why do I need to do that, right? And I have this, I did basically, you know, research on that and I found a great thread on Reddit really going after that, right? And if you summarize basically all what guys were saying, they basically go like this. It's not our job, okay? So the product and go-to-market belongs to product and sales. Leave us alone. We'll give you a product which is scalable, maintainable, it runs. Don't force us to cross these lanes, right? But what we saying, hey, this is going to limit your growth, isn't it? That's going to limit your growth. It's going to have impact on your credibility, how you seen in the business if you don't talk that language, right?

Yeah.

Yeah. Okay.

Yeah. You know, it, I'd say the best way to describe it for a company that produces software as its product, it is very hard to get a like ideal to achieve like an ideal outcome when the people actually building it don't understand what they're building or why, if it's, if it's to a spec. And the reason is the people designing the spec aren't the builders usually. They don't, and, and they don't know necessarily what's even possible to build. Like the, the reality, and this is one of the reasons I would say that as engineers grow into, you know, larger, having larger impact, you know, through management roles or ideally cross-functional roles, never stop coding, never stay, never fully exit, because the only way to really build the best product is to be very in touch with what's possible. And if you're not in touch with what's possible, then how do you achieve an ideal outcome? And when you're just taking a spec from somebody who's probably not in touch with what's possible and you don't, and the engineers don't think about what they're actually trying to accomplish, then there's this chasm between like, there's just, I'd say, let's just call it a missed opportunity of if the person building the product knew what they were trying to actually accomplish, not to a spec, but to a customer problem, then they would likely build something better than— they would solve the problem better than they would if they just took, you know, the requirements and stayed in their lane. Yeah. So, you know, I look at companies where the leader of the company is a builder and very technical. And I think you get better outcomes. I think you get better outcomes when the person who is setting direction or when the people who are setting direction understand in detail what they're asking their teams to do and can sit down next to them and participate, you know, at the end of the day if they need to.

I love that. And I fully agree. What I'm thinking is, Ryan, as well as like how did that translate like in enterprises? Does it matter which environment you are in? Does it matter if you're like in a startup or like scale-up or like a proper enterprise? Or we're saying it's really environment independent. If you are engineer, you will have product people in your team and then you will have product coming down to the team or programs and enterprises. You still want to develop that skill of being able to talk with product around go-to-market and really understand the customer, what you're building, why you're building, and not only that, actually go and build it.

Yeah. Yeah. You know what, the, um, the way I describe the relationship between product and engineering to my teams is as these like circles that, that overlap. Um, you know, where it's, and every organization's gonna be a little bit different and the relationship between any two people will be a little bit different. But I would say that the degree of overlap of those circles of responsibilities may be a little, but should be, it should potentially be a lot. And so if I, if I look back to one of the best product manager relationships and partnerships I ever had, it was this, this woman, Jamie, and, you know, Jamie at Qualtrics and I really, um, overlapped heavily in, in what we did. There were times where I was getting on the phone with the customer and learning in, you know, in place of her. There was times where she was working closely with my team and, and often doing things that you would consider an engineering manager should do. And, you know, I would say the two of us were a partnership, and as a partnership, we were trying to achieve an outcome. Qualtrics actually, um, developed this concept of, of the team of four, and they took a product manager, an engineering leader, a marketing leader, and a sales leader, and basically partnered them up as like a mini executive team for a product or business line. And that team of 4 was, you know, responsible for the ultimate outcome of, of, of that particular business line. And, and that was, that was quite successful. You know, it really pushed every member of that team who were, were typically manager to director level people. To think about more than just their function, to partner as an executive team trying to accomplish a particular outcome. I love that.

Yeah, I can see that working very well. I mean, when I think about startups and when I think about founding members, I usually think about that 4. I go like, I would not join any startup if you don't have that 4 nailed. That's such a fundamental function to get anything off the ground into successful mode. I want to read this quote, Ryan, to just land the point, right? So according to research from the OKR Institute and Gartner, in companies with silo teams— so effectively we're saying teams which don't cross the lanes— productivity drops nearly 29%, job satisfaction slips 37%, and entire departments usually duplicate effort, sometimes wasting around 10% of the operational budget. So it's a very costly mistake to sort of assume that staying in your lane is a great choice for yourself and for the business overall.

I would actually, I would, you know, through my own experiences, I would argue that that's quite conservative.

Oh, you would just go bigger, bigger numbers, bigger numbers.

Okay. Probably much more because You know, I've just seen over and over and over again businesses that I've been a, that I've been a leader of where departments, you know, or groups within departments are their daily operating rhythms are, are built around deficiencies of other departments, like deficiencies in the product, deficiencies in, you know, support material, deficiencies in You know, lack of functionality or like bugs or whatever it ends up being. It's like whole teams, processes get built around these things. And sometimes you take a step back and you question, why are we doing this? And nobody really knows. Well, we, it's what we've always done.

Yep.

You know, and like what I've found is, you know, Grin as an example is a company that at one point was, was quite a bit larger than it is today. And, you know, we ran into some, what I would call product market fit challenges where, you know, originally we had great product market fit over time as we expanded the product market fit we had with that expanded customer base was not as strong. And, you know, the, the reality is like as a large team, trying to push through that. And I would say we were in a moment early for Grin, we were getting pulled. Later in Grin, we were trying to push.

Okay.

And, you know, teams were just building all sorts of band-aids. You know, I would say many departments were kind of a house of cards. And yeah, you had to look under the covers and ask, what is going on here? And you realize just how much inefficiency is happening on a daily basis and how much like bad process upon bad process upon bad process is layering on top of, you know, something more fundamental down below that nobody's paying attention to. And so, you know, anyways, it's, that kind of goes back to the point of one, like Oftentimes the root cause may exist in a different department, but if you don't care about that department and that department's not your job, then nobody will ever solve it.

Exactly.

And it just propagates and, you know, becomes something that the business adapts to.

It just becomes a norm, and that norm is just, it's really not healthy, but because it becomes a norm, you don't really realize that you have that Exposure somewhere deep. Yeah, I get you. So, well, take us through the moment when you, this engineering manager in Qualtrics, or maybe different situation, but you realize like you have to cross the lane, right? And so how does that crossing the lane actually happen to you? Like, did you learn about go-to-market? Did you start spending more time with sales or marketing? How did you actually improve yourself and you crossed that lane?

Yeah, I'll tell you. So the first time I can remember that happening was back at Qualtrics when the founder was pressuring me to figure out how to build the right product, not just build the product I was being asked to build. So that was like Hey, I'm being pushed to do something that isn't like my job spec. My job spec as an engineer is to build, you know, to build software. Now you're asking me to build the right software and it made me uncomfortable, but it was, it was good. It was a good, you know, it was a good feeling of, of uncomfort. I would say I don't feel like I actually really understood it until my paycheck depended on it, um, to be honest.

And I get you, I get you.

And so, like I said, I think that human nature, to some degree, we— that we all have so much going on in our life that we end up filtering the things that don't feel necessary. And, and so if it's not necessary for me to learn this thing, I've got a million other things to learn And so I'm not going to learn it. But if it's necessary, then suddenly that changes. And, you know, in terms of just living everyday life, it's necessary when my paycheck depends on it. It's necessary when my job depends on it, when I'm bonused on it. Right. And so as a, as even as a CTO at Rout, I had a very strong go-to-market partner. And, and so it wasn't my job. Not, you know, not that I didn't care about it. I was an executive at the company, so I cared about the, you know, the team's performance, but when the company was feeling go-to-market pressure, that was my partner's problem, you know, more so than mine. And, and, you know, he, he took it on and he, and he solved it. Um, but he would've solved it better had I been a better partner of his, you know, to, in, in truth. And so when, when I joined Grin as the CTO, You know, we also had go-to-market challenges. Now, before I really got to spend much time at the company and, and try to understand what they were, we ended up making a pretty big shift and I became the company's president. And as the president, suddenly net revenue retention, our net ARR, our, you know, monthly and quarterly sales numbers, those were mine. Those were my numbers. And in fact, I remember sitting in a board meeting once where we announced that my role was changing and one of the board observers looked at me and said, have you ever run go-to-market before? Have you ever been responsible for the sales number? And I said no. And he just, you know, he's like, it's a lot of pressure. It's a lot of pressure. Um, you know, and, and the, the, what I thought in that moment was, you know, this partner, um, Charlie, that I had, had spent, uh, years working with. I, I remember Charlie, who was, who was Chief Revenue Officer at, uh, at Rout and then later at Grin. Um, I remember Charlie saying, I constantly have a target on my back every single month, every single quarter. Nobody in the company feels the stress that I feel.

Mhm.

And I sympathized, but I didn't empathize with that. I said, yeah, you do, you know, that, that's got to be tough. Well, once I, once I was in charge, then I could truly empathize.

Mhm.

Now, now that's my responsibility. Now, now I'm thinking about product, not from the sense of, do I build, how do I build this, like really cool thing that I'm interested in, but like, if I don't build the right product, then I will fail to deliver on this company's core objectives. And then I personally fail in my role. And so that shifted everything for me.

Okay. And, you know, it, um, let me ask you, Ryan, about credibility. So I'm, I'm, I'm I'll take it a little bit maybe down to like an engineering manager type of roles, maybe even like engineers themselves. I feel like if you bring, you know, ability to talk around go-to-market with other departments or other teams like sales and marketing, I feel like people will look at you in a much better and more credible sort of light. So you become not just a doer, an executor of tasks, but you become in a way a partner for them to get answers to and, you know, make decisions and you make them better, right? Because you can just explain what's possible. So I think like if you're thinking about your career growth, that should be something you should be interested in because that's just going to grow your credibility within any organization. Am I right over here or your point of view is a little bit different?

No, you're very right. You know, I do think that, I think that as an engineering leader, you should, you should design how the team works in a way where, where that's a requirement. If, if you're not within an organization where that's a requirement, then I think you should take the opportunity to as much as you can. Now, you know, today, in, in, within Grin, We actually, um, we actually don't have product managers today. You know what, what I, I, I do think that we're evolving and, and AI is changing things. I, I think we're seeing a convergence of these. It's like you go back not that long ago and you kind of take some of the, the like agile best practices and the, the role descriptions and it's like you've got You've got product managers, project managers, product owners, Scrum Masters. Like, it's this very, like, um, very detailed explanation of the different roles and responsibilities that, that, you know, that play a part in an organization. And I, I just look at that today as, like, it is not the right way to do it. Anymore, right? And like, that's very much where you get a spec as an engineer and you build to the spec. And then you've got a product owner who is responsible for like the backlog and, you know, prioritization. And you've got a product manager who's responsible for talking to the customers. And it's like playing the game of telephone. Every person that's involved in their own isolated way, there's a loss of fidelity in the transfer of knowledge between one person to the next. And ultimately what ends up getting created is some less than ideal product that misses on like the true intent of the person who actually understood what the customer needed. And so I would say today, I, you know, I recently talked to my, in fact, some of my engineers, they were like, hey, we don't have a designer. We're not designers. What do we do? And I said, why are you not a designer? Like, you know, and they, you know, what should we build? Well, what does the customer need? And it's, I mean, it's uncomfortable. I'll be honest. It's uncomfortable for an engineer. To be asked the question of, well, what does the customer need? Uh, yeah, I don't know, right?

You tell me. So yeah, yeah, what, what is the—

what, what design is going to be the best? Yeah, I don't know. Well, go use the damn product. Does it work well? Is it, you know, like, if you use it— in fact, you know, how many engineers— this is actually funny because, you know, some of some of what I think are one of the first mature AI products, in my opinion, besides chat that has come out is code editors.

Mm-hmm.

Soft, you know, code like Cursor or Cloud Code or some of these, you know, different coding tools. And, you know, in my opinion, haven't been told this, but my intuition here is that because software engineers are like, oh, I could use this to like be quicker at my job. And so they build it for themselves. They are the end user. And so they, they build a great product for themselves. And when they're using it and they say, I don't like this, they fix it. Yeah. Well, if this doesn't feel right, then let's just change it. Let's make it better. Well, when a software engineer is building for somebody who they don't understand, then they, they lack the ability to say, ah, this is, this isn't a good design because they don't understand actually what the customer's trying to accomplish. And, and they lack the ability to, to know whether or not they've really nailed, you know, the, the requirements. Mm-hmm. Because they're, they're not the user. Um, and this is where empathy plays in. You know, you may not suddenly become, you know, Grin, Grin builds marketing software. Engineers may, may not suddenly become marketing experts. However, there's a lot that engineers can do to understand what do our customer— what are our customers trying to accomplish? What are they accountable to? And if I use the product with that mindset, is it easy to use? Is it hard to use? Is it accomplishing the goal? And if it's not, how can we fix it? And it's been amazing to see, honestly, back— backend engineers, people that say, I build APIs, I create distributed systems, I design architectures. It has been amazing to watch these people build user interfaces. In fact, one of them recently posted a comment at some— somewhere on LinkedIn, I think on one of my posts, and said, made some comment about how he was essentially a newbie at building React code, but kind of said it in a lighthearted way of like, hey, I'm a— I typically write software, you know, server side with Golang and I'm using JavaScript and building React user interfaces right now. And like, To, to me, that is an engineer that is stepping outside of their comfort zone.

Yeah.

Is thinking, is like taking on the, the true goal in mind versus just what they're being told to do and saying, okay, I, I've got to like, I've got to, I've got to go build a product that, that our customers are going to use, and it, and that has to push me outside of what I'm accustomed to doing.

So in tactical way, then what we're saying is use the product, that will help you to understand if the product works, which most likely gonna make better decisions on whatever you're building right now. Is there any other way of how engineers willing to step outside their siloed ways can get that, uh, you know, that language, that go-to-market understanding, their customer feelings understood? Or is it that's like the only way? Or are we saying, you know, go Yep.

Go, go, go use it. Absolutely. I think that's one of the best ways. But if you're not gonna use it, well, you, you should find a way to definitely use it. Everybody should find a way to use their product. But in addition to using the product, watch people use it. You know, we, we use some, some tools internally so we can record customer, right? Okay. Customer demos.

Yep.

You know, we, we can record customer use, watch people use it. Mm-hmm. That is like very eye-opening to see people struggle to, to find the, the button that you put in the upper right-hand corner or struggle to like realize that you have to click that pencil and then you can edit this thing that's over here.

Hmm.

It's like, oh yeah, okay, I guess that's not as intuitive as I thought. right? So watch it and then talk to customers. You know, I don't believe there's a way to develop empathy for your customer if you don't meet them. If you don't meet them, talk to them, watch them use the product.

But how do you set this up, Ryan? It's like, how do you get your engineers, if you have, you know, I don't know, 50 of them or 100 of them talking with the customers, is there some type of like meet the customer day where something gets slotted in their diaries? Can we trust them that they will you know, present a good vision of a business and they're not gonna, you know, join with, I don't know, some poor language and talk with the customer in a bad way or something like that. It's like, is that like okay? Like, do you guys have a process of how you get engineers into like talking with the customers?

I've seen it in a variety of ways, but you know, the simplest way is let's say, you know, maybe the product manager owns the relationship, or maybe, maybe it's an account manager that owns the relationship. And hey, we're going to meet this customer, we're going to give them a demo, we're going to get some feedback, whatever it ends up being, right?

Okay, so they just shadow the session, right? Yeah.

Hey, we're going to invite a couple of engineers to join this call. Um, I've only ever seen customers react positively to that. Cool. Sounds good. Like, you know, it— and if the engineers aren't comfortable talking, then they don't have to. They can just observe. They can just be a fly on the wall. I've seen a lot of engineers actually really enjoy those customer calls. And, you know, I think starting to get to know people is how you start to build empathy for them and how you start to think about things in a different way. So I get engineers on the call 100%, you know, and as, as to as much degree as they are comfortable. But in addition to that, get, you know, get recorded demos, having, you know, require that engineers watch people try to use the product. So it's everywhere from one, meet the customer, like get to know them by name, see, you know, how impactful what you're building for is for them or not. Two, observe, you know, outside of a direct conversation, observe just use patterns. Make sure you're recording this stuff, make sure you're watching it. And then probably three, go use it yourself. Find a reason to use it. You know, I've met many executives, um, which honestly is a bit People might find this surprising, not surprising, or, you know, somewhere in between. But I have met many executives that do not know how to use the product that they sell.

Hmm. Not good.

And there's, you know, it's like, well, these are the reasons that these, like, ways of working that are inefficient or broken never get identified. Is because there's just a, you know, somebody who's thinking about the problem at the right level has a lack of detail of how things actually work to understand that the way things are working aren't actually working very well. Okay.

So I love that, by the way, those three things. And if I'm engineer, if I'm, you know, listening to this chat, I want to cross the lanes. I want to increase my credibility. I'm just going right now to product people and going like, 'Where is the recordings? I want to watch it. If there's no recordings, put me in those demo calls, put me in those sales calls. I want to shadow this. I want to understand our customers because I want to bring that knowledge and make better solutions.' That's a very good move to make to any engineers looking to cross these lanes. So I have this question. Let's say that you have some type of old school— I don't know why I'm saying old school, not necessarily old school, don't care about customers, but you have a certain team or a certain mindset, right? Where the belief is that their values are good code, clean code, good technical solutions. How do we actually go changing that mindset? So they start thinking about adoption and revenue and stuff. Do we do, I don't know, coaching or some type of presentations? But we want to shift their mindset. So we want to sort of enable them and gently push towards, hey guys, we really want you to sort of start talking, you know, more business values and outcomes than just thinking about code. Like, how do you get that done in practice?

I, so I think the ideal way to do it is to invite, to invite that to happen and to make opportunities for that to happen. I think the ultimate way to do it is with you know, not a carrot but a stick. So it's like, let's start with a carrot, right? Like, hey, we'd really love to start getting engineers onto our sales calls or on, you know, passively, like either like observing or, um, or, or watching recordings. Or we'd love to get engineers into customer demos. We'd love to get engineers into customer feedback sessions and You know, just, just invite it at first. Hey, we're doing this demo. Who wants to be a part of it? I think that you can see that a lot of this can happen culturally. So as the culture of the company and the engineering processes evolve, it becomes a common practice. It becomes something that ultimately what you'd like to, you'd like to see people understand is that by doing that, they will be able to do a better job. And again, like I said, ultimately, we're all intrinsically motivated in some way. People have to believe that it's going to be better for them if they do it, or they won't do it, especially if it makes them uncomfortable, right? There's some quote, I don't know where it comes from, but people basically resist pain until the, you know, resist change until the pain of not changing is greater than the pain of changing. And that's like, well, if I'm not— if I'm an engineer that has not frequently interacted with customers, and that— and if that makes me uncomfortable, then it is painful to start meeting them. It's uncomfortable, and we resist uncomfort unless there is some benefit of that comfort, you know, uncomfortability that ultimately is better for us. And so I would say start culturally. At the end of the day, you can make it a requirement. Hey, you have to.

So that's a stick, right? So the carrot is like, hey, you know, that first part, that's going to help you grow career and all that stuff. But, you know, if people are not listening, they're not joining the calls, we whip up the stick and we go like, that's now part of your job, basically. Yeah.

And you can just establish like, hey, at this, in this organization, at this company, it is part of the job expectation that you, that engineers meet with our customers, that you use our product, that you whatever. And, you know, if people aren't aligned with those expectations, that's okay too. Um, you know, in fact, I'll just, this is a different example, but it's, it's similar. Grin recently, we made the shift to a heavier adoption of, of AI tooling for coding. Mm-hmm. And, and we started with a carrot. So for a while we said, hey, everyone now has a license to use Cursor and we encourage you to try it. And once a week we're gonna do these like engineering, you know, brown bag sessions where we, everyone comes and talks about what they learned, you know, how, how they're using AI more effectively now in their daily process. And I think we did that for 3 to 4 months or so. And over that period of time, we actually, you know, leadership, myself and other of the engineering, not just managers, other of the senior engineers said, this is great. Like, this should be something that we are all using. And it started to become more of an expectation. Okay, now you have to do this. And I remember a great engineer on my team. Said, Ryan, I want to talk with you. And I had no, I actually recruited him from another company. So I know him quite well. And he said, I'm quitting Grin because I'm not comfortable with the expectations of that we have, the pressure that I have to use AI in coding. I don't want to. And I don't, I don't, like feeling the pressure that I have to. And, you know, I was like, hey, as your CEO, you know, best of luck. And, you know, as a friend of yours, which I am a friend of his, I said, you know, and as a fellow engineer, I think you're making the wrong choice.

I would agree.

And, you know, I think that I would encourage you to kind of understand why you're resisting it so much. Maybe you feel vulnerable to it. Maybe you have something that— something. But I'd encourage you to understand that because I believe that in a handful of years, it may be even less. It's happening rapidly. Engineers that do not have developed a proficiency for using AI tools will have a hard time getting jobs because it is you will be able to be so much more effective. Well, so, you know, the interesting part of that story is that he came knocking back on the door 2 weeks later and said, I made a mistake, and I hired him back. And he's, you know, so it's— he's like, hey, you're right, I made a mistake.

Um, and he probably just tried it first for 2 weeks. Maybe he never tried it, then she gave a proper go. He's like, damn, that's good, that's good, that's good stuff.

Yeah. Um, you know, I, I mean, I I remember my first handful of weeks using AI code editors was like, it's like dumping, you know, a 5-gallon bucket on you. It's like, at first it's like, holy, wow, I can be so effective. And then all of a sudden, oh my God, it made so many mistakes. And then it's kind of back to, okay, now I know how to use it effectively.

Yeah, it takes time to learn it. Yeah, but it's awesome, Ryan. I think, yeah, you're definitely right when you say that in a couple of years, the market will expect that to be a skill.

It'll demand it, yeah.

Yeah, I mean, it's very evident. I fell back in love with building stuff because of AI. I mean, I didn't code, you know, for probably like 7 years now, and it's all, you know, it's all managerial type of roles. But then AI came out, you know, and, you know, I bought into these tools and I was like, damn, that's fine, right? You just talk with it, you just build stuff, things are happening. You're like, ooh, I'm back in love with just producing stuff.

Yeah, it's, uh, same story. I, you know, I, and I think there's probably a period of, of 3 or 4 years where I didn't write code. Um, I, I, I wrote code a lot. So I, I wrote code. I was managing 100 engineers at, at Qualtrics and I was still writing code at, you know, at Rout for the first couple of years. I wrote a lot of code. Um, but then, you know, my, my kind of the demands on me as a CTO got large and, and I, and I just ended up stopping and then you stop for very long and then it's like, it's a lot of work to get back into it. Now it's like, you know, I, I used to use Angular and, and like these front end, you know, develop like development, um, like patterns and things that have evolved. Nobody uses Angular anymore. Like everybody's using React and, and it's like, I don't even, now I gotta go learn React and that, you know, it's just like the, the barrier to entry felt large where, where AI has just no barrier to entry is not large. No. You actually don't need to be a pro at React to, to use AI and write good React code. You can actually just learn how React works and, and you can work in partnership with, with AI and do it really effectively.

It's so lovely.

The whole point of that, just, you know, the whole point of, of saying that was that It is going to be uncomfortable and it, I think an organization should start by encouraging, but ultimately I think organizations need to adopt a culture of expectation that your engineers are developing these skills. I think it should be a requirement.

I 100% agree. I mean, I, So I don't need to code, to be honest. It's all just hobbies and things like that. But I really enjoy the feeling of just, you know, almost like, you know, being Tony Stark in Iron Man because, you know, I just have a microphone. I just enable voice. I go like, you know, build me this and that, you know, I want to do this and it just spits out the code. You see things working and then You know, you start just sort of talking with AI and you see product coming, you know, together. Of course, there's limitation of this, of how far you can push it. Like you can't really build, you know, a full big SaaS platforms, but micro SaaS platforms, which is right now on the rise, you know, it's all called vibe coding or, you know, or vibe sprints. So it's, I mean, it's as real as it gets, man. If you just give it a go, you will very quickly realize that if you add another couple of years on this new wave of building things, it's just gonna be something else. And then yeah, if you just say no to it, you're just gonna be left behind, man. It's just like, it's gonna be your loss effectively.

It'd be like an engineer today saying, I only code in assembly language and trying to get a job.

Yeah.

It's like, well, look, there are some jobs. There are maybe some niche jobs. But the reality is that 99.9% of jobs will not hire you if you only code in assembly language. And you know, that, that, that will happen here too. It's, there may be some niche applications, maybe, but the vast majority of jobs will expect that you are using AI. You'll have to, because it, it just like, you know, going from assembly to a modern programming language, there's orders of magnitude of efficiency improvements. You'll see the same with AI. There will be orders of magnitude of efficiency improvements.

100%. We drifted a little bit into AI from the go-to-market, but I think it's very important as well, crossing the lanes. And to your point, which you made in the very beginning when I asked about mastering Tech Growth, you said professional growth. And that would be something where engineers listening should just not ignore. And if you're using AI, well, good for you, continue learning that skill. As many talks I had as well, you know, in the show, we have close to 100 episodes, last 20 or so, a lot of AI. We actually had businesses who do professional services with Vibe Coding and they, you know, developing new processes where they just iterate so quickly on the product features and with the AI that it takes like a week or two and they have dedicated, you know, Vibe sprinting as they call where they just get like 4 people coming together, very skilled with the AI, it's UX and and UI, and then it's a frontend and backend, and they just build small products and small features and they just ship it. They get very quick feedback loops and that just allows, you know, to build it, find that market fit and build better products much, much, much faster. And I mean, if you are a business owner, you sitting, you go like, damn, like I'm just gonna launch 2 new verticals next year. So yeah, it's definitely gonna have that. I wanna ask this, Ryan, so, If I'm this engineer which is crossing lane, I'm now part of these demos. How can we help engineers to think through this process in such a way that they ask the right questions or, you know, or ask something of like product people where they go like, look, you know, I'm asking these questions, so I'm getting the right answers and that helps me to build the right things. Is there like a framework you would use or just some tips around that area?

Um, I, I don't have a, like, a preferred framework. What I would, I would always start, and, and if the engineers aren't comfortable, have the product manager or somebody who's on the phone start by making sure that the customer explains their job and what they're responsible for. Like, I think if you don't really understand why somebody's using your product, then it's hard to ask smart questions. Because you may be observing their use, but you lack the full picture to know ultimately what they're trying to do. And therefore it's hard to be smart about it. But, you know, lay the foundation. Hey, I'm such and such person. I'm responsible for these things. I use this product for this reason. And, you know, and then I think it depends on It depends on the point of the call, if it's a demo or a, you know, feedback session or what it is. But I would say that the true goal at the end of the day is to understand how can this software better solve the problems that they have. So how, you know, and I like to, so actually I do have a framework. I like to use this kind of value framework. Where it, you think about the true value of any product or service that we sell is the combination of a handful of things. One of those is the perceived likelihood that using this thing will accomplish the outcome. So, you know, does the customer believe that this tool is going to achieve what you're trying to, what they're trying to achieve. And if it, even if it does, but they don't believe it, that matters. And so how can you help them to be more confident that using this software, you know, or using your product is going to help them? Another is like, to what degree does the product actually help them achieve You, what is their ideal outcome? So if you're building, let's say, you know, Grynn builds, we build marketing software to help companies work with influencer marketers. Let's say the ideal outcome is, is GMV, like the total amount of sales that an influencer is able to drive. So the ideal outcome is to, is to make GMV as high as possible. Okay, well then How, how likely does the customer believe that that will happen? So, you know, it's kind of those two. One, what is their ideal outcome? What is their confidence level that you can do it? And then the other two things are, what is the, um, time delay? How long does it take to do it? And then what is the effort that has to be applied in order to, to do it? So all these things come together because If the time delay, it's like, oh, I can do it. It'll just take a year. Well, then the value's less, right? Well, I can do it, but I have to put 100 hours into operating, clicking buttons. Well, then, then the value's less, right? Or, you know, I can't actually get you to your number, but I can get you to 10% of your number. Okay, well, then the value's less. And, you know, I can get you there, but the customer doesn't believe it. Again, the value is less. And so, you know, ultimately we're trying to help the customer. We're trying to increase the value of the product in your customer's mind. And I think you can approach it from all of those angles. If the customer's concerned about how much effort it is, why is it so much effort? How long does it take you? How, how, like, you know, every day, what's your process? You know, what are you doing? You might observe that your customer is doing things that you're like, oh, I never realized it would be used that way. I've seen that numerous times where it's like, oh my God, this is way inefficient for what they're trying to do. I could probably make that way better. I didn't realize they were going to use it that way. Right? Or hey, did this thing, you know, I have to wait 3 weeks for this thing to be done. I have to have it, you know, it's got to be done in 2 days.

Okay.

Well, then we've got to rethink this if it has to be done faster. Then how do we do that? If the customer just says, I don't, you know, take text analytics, we were observing sentiment and back in the day, you know, today you ask ChatGPT, what is the sentiment of this sentence? It will almost always like it's, I think most people would say, I have confidence it will be right.

Yeah.

Even with like sarcasm and slang, like it's right. It's almost always right. Um, at that point in time, 85% was like a pretty good benchmark of accuracy. And so then the customer would say, I don't have confidence that it's going to be correct. Well, that, that's a problem. How do we boost your confidence? How can we change the product layer more, you know, more ability for you to observe where it might not be right and maybe allow you to correct it. So, you know, all, all of these different things, I, I, I would say find the value that is gonna be the largest driver, the largest driver of value in, in that customer's mind, and then ask questions about it. How do we make it faster? How do we increase your confidence? How do we reduce the amount of effort? How do we make sure the ideal outcome is better? You know, every one of those I think could turn into a series of questions that help any software engineer, product manager, other. Really expand their mind into like, okay, I know how to make this better. I know how to increase the value.

Is this framework a value framework? Is that just something you develop from experience purely, or is it something based like on a book or like a—

No, this is actually Alex Hormozi.

Oh, Alex Hormozi. Okay.

I know that name. Yeah. So he has a, I like forget the, I forget the name of his website, but, but you could, you could search it up. He actually has quite a bit of content on that value framework. And I just think it's such a simple, like, explanation of the different ways in which you can increase value. And each one of those core variables, you know, parameters in, in that equation could be entire conversations with the customer and could just be a series of questions and And the reality is every, you know, modifying any one of those parameters increases the value. If the time, if the amount of time goes down, the value goes up. If the amount of like effort goes down, the value goes up. If the perceived confidence goes up, the value goes up. If the ideal outcome goes up, the value goes up.

Goes up.

And you know, so, so, but, but it's, it's 4 distinct, you know, really topics that could have very different conversations about. And, you know, an engineer or a product manager can now evaluate value creation from 4 very distinct points of view. And, you know, ultimately, I think that gives you a more comprehensive understanding of things that you have the, you know, the potential to create.

Excellent. Thanks for that, Ryan. We'll put it in the show notes for our listeners, the link to that. Alex Hormozi write-up of value framework is going to be a great help. I'm sure about that. So let's jump in the rapid questions, Ryan. So it's 30-60 seconds per question.

Okay.

What's one business book you think every engineer should read?

Ooh. So there's a couple that have been really impactful to me. One, I love Radical Candor.

That's a good one. Feedback, right?

It's— I was an engineer. I was just a person in general that I would say was a bit of a people pleaser and avoided conflict. And I learned through reading that book and just through some personal, you know, examples in my life that avoiding conflict was actually pretty selfish and, you know, led to less ideal outcomes both for myself and the people where there may be some conflict with. So I think that's an incredible book. And then the other one is Crucial Conversations. And obviously both of these books are related to basically human interaction, which I think is so critical. Crucial Conversations is how do you have hard conversations with people? We all have to do it in our personal lives, in our professional lives, and there is a framework for how to do it more effectively. And just one of the most profound books that I've personally read, because it is so easy to slip into emotional reactive behavior in those conversations, and it's just unproductive. And, and so that, you know, having a framework in your head allows you to, to take a big deep breath and realize, okay, follow the framework, navigate this differently. Yeah.

Okay, what's the biggest myth about engineers moving into leadership?

Um, I— so from my personal opinion, the biggest myth is that you have to be a manager to progress in your career. That's, that's what I've observed, and that, and that that's how you make the most money. Um, I've always led organizations to say You can advance in your career to the same level regardless of whether you manage people or not. But ultimately, increasing your compensation is attached to increasing your impact. And increasing your impact means you're having, you know, an impact over a broader group of people, a broader influence of the product. And so leadership is required regardless. You can't advance in your career, even as a, I would say a senior engineer is a leader of other engineers. A principal engineer is a, is a leader, a senior principal. Like it's just the, the, there is always an expectation that to advance in your career, you have to develop leadership skills. And. Whether that be directed towards people management or a technical track, that it's a requirement. So the myth, you don't have to become a manager, but, you know, the other side of that is you do have to be a leader.

Yeah. And it is a big difference between a good leader, which is capable to multiply talent around him, and a leader who either just doesn't know how to do leadership and from his or her best intents still somehow manages to diminish people around himself. That's a good book which is called Multipliers by Liz.

It is good.

And yeah, it just goes into that concept so, you know, well that when you read it, you can see yourself, you can see your colleagues, you know, previous managers, and you go like, damn, like they, they, they You know, like they did that and they were coming from good intentions, but how they deliver these things were quite diminishing to everyone around. And you can feel that in like team, you know, dynamics and how the team feels and that's nice. Yeah. All right. Which skill helped you more as a CEO? Was it coding or was it communication?

Communication. But it's communication with caveats. I think communication is one of the most critical skills that anyone can develop, period. That said, if you, you know, for me, especially this time of like the era that we're in where I view AI as a revolution of technology and I think it will change everything. I think that without a technical skill set right now, I would not know how to guide the company. Um, you know, I think that, I think that we would be behind. I do think it's just like, you know, in the late '90s, the internet became something that businesses were able to start adopting. And through the late '90s and into the early 2000s, you had a whole, you had a wave of adoption. And hype, and a lot of companies crashed. But also during that time, some of the biggest, most iconic companies in the world today came from that time. Amazon, Google.

Yeah, Microsoft.

Meta. You know, Microsoft, uh, was around a little bit earlier, but that's Microsoft, you know, kind of in its current form. So the— I would say, um, we are in a similar era. Where there is a lot of hype around AI today and there will be a lot of bad products that are built, a lot of bad AI products that are built. But I also believe that there are, you know, a decade from now, the most iconic companies of the future are being built right now.

Yeah, I do agree.

They are ahead of the curve.

Yeah. And yeah, I mean, that's a, that could be an episode on itself, Ryan, to be honest. I don't want to go to that rabbit hole. It was such a great opinion to sharing and I'm like, yeah, yeah, full resonation with that. So I want to ask this. So when it comes to go-to-market leaders, do you think they have a misunderstanding about engineers which potentially, you know, that leads to not good decisions being made?

I don't know if I would, I don't know that I would say a misunderstanding. I would say a lack of understanding. Okay. I think that honestly, I think that every department outside of engineering lacks understanding. I think engineering is often a black box and I think that's really unfortunate and I think that's on the engineering departments to change because, you know, companies that are, that are building software as their product, when the engineering team acts like a black box, it's very hard for that company to, to truly like be successful. The, it's like, well, there's this, this, we, we throw it over the fence to engineering and we may or may not ever get it back, right? Mm-hmm. Um, it may or may not ever get prioritized. It may or may not ever get fixed. The feature may or may not work. It's like, God, that's frustrating if you like, if you have no sense of control of what goes on there. And so I think there is a lack of understanding and I think that that can be greatly improved by immersing engineering more into the culture of the company. Invite engineers to do, you know, we do, in fact, we did this at Qualtrics too, but we do weekly company-wide all hands, and I love having engineers do demos, you know, and, and some engineers love it. Some engineers are kind of nervous about it because you may be talking in front of hundreds of people, but let the engineer do the demo, not the product manager. Stop insulating engineers from the company. Let the engineer get up and show what they're proud of, even if it's like a tech, you know, hey, I changed this algorithm and we made, you know, this particular part of our process much more efficient. And why does that matter? It matters because it's going to drive our costs of AWS down by 10% or whatever, right? I think you can coach an engineer on how to make it resonate, any topic resonate with the broader company, and you should let them get out and immerse themselves.

I fully agree. We do demos with the engineers as well. We, you build it, you present it. Yeah, it's a very great practice. What's one question you now ask before you build anything new?

Why?

That's a good question. Why I'm even thinking about it. Okay.

Why are we building it? And you know, you have to, as I like, Just like you said, with AI becoming such an effective tool to help people write software, I've gotten back into writing a lot of software, which, which is, it's like the best of all worlds. I describe myself as an engineer first, then a CEO. And the fact that I can do both, which I feel like I can do now, is just, you know, I love, um, but as an engineer, it is hard to like separate the personal excitement of something you're building from the why are we building it part. Like there's just this natural tendency to like want to like build it in this certain way or see, uh, even recently I like It's like I built the, I built this feature for a new product that we're, that we're building. And the first feedback I got on it from the marketing team was like, eh, it's kind of ugly.

Well, thanks guys.

As you know, as an engineer, I'm like, are you kidding me? Like, look how like it's so elegant. It's so consistent. It like, and it's just. Why are we building this? We're building this for this particular purpose. Okay. Did we build it optimally for that purpose? No, no, we did not. And so I, you know, I ended up rebuilding it. So it's just hard. It's hard as an engineer because you get really excited about what you're building.

Okay.

Personally excited. Um, but you've always like, why are you building it? You're not building it for your own personal benefit. You are building it. For your customer's benefit, and if you're not, then you're in conflict with your company's goals.

Yep.

Okay. If you're starting with building it for your customer, then you're aligned with your company's goals and you might build something different.

So basically we're saying a simple question why, or there's a 5 Whys technique, right? Where you just go like, why? Why? Why? That's—

5 Whys is great.

That's— yeah. Ask that before you write any code. Okay, that's a great question. What's harder, unlearning old habits as an engineer or picking up new skills as a CEO or a business operator?

I think it's harder to— I think it's harder to break old habits than to develop new skills. Um, okay. I think developing new skills comes with a lot of trial and error, which can be frustrating. Mm-hmm. But I think breaking habits requires a lot of, um, uh, a, a lot of dedication, a lot of commitment, a lot of, um, yeah, a lot of personal investment. And it's painful. It's like, kind of goes back to that quote I said, which is change is painful and people, people resist change unless, unless the pain of not changing is greater. And so anyways, yeah, that I would say it's hard to break old habits.

I would agree. I have some terrible old habits. They don't leave me. The older I get, the more pronounced they get. If you could give your younger self A one tip about career growth, what that would be?

I got that one tip and it changed my career. So it is prioritize your own like professional growth based on opportunities that will challenge you over opportunities that may satisfy, like, or over opportunities that lead to like a higher title or a higher pay. And that doesn't say that you shouldn't care about your title and your pay. I've seen people comment, it's like executives love to say that because you want to hire people cheap and tell and not give them big, you know, it's that's not the point. The point is prioritize your learning as your primary driver, and then title and pay just need to be, you know, at market fair with, with what you're doing. And that will put you on the best trajectory for long-term growth.

Yeah.

And, and I got this feedback early in my career. I was managing a team of maybe 15 software engineers at this company, backcountry.com, and I got provided the opportunity to go to Qualtrics, which was a startup, and they had no managers. And at the time, I felt like the myth in my head was the progression is engineer, team lead, manager, director, VP, you know, all the way up. And that's, that's how you do it. And I had been an engineer, I had been a team lead, and then I was then a manager. So the thought of going to a startup as an, as a software engineer again felt like a career step back for me. And so that was like a title and responsibility thing kind of attached to my ego that was hard. But somebody that I trusted said, hey, if you think that you will learn more at this company than you will where you are, you should do it regardless. And I took the leap and it was the best thing I could have possibly done. And so I teach that often. I tell people, just, you know, make sure that you are properly challenged and ask your manager if you're not properly challenged in your current job, ask your manager for opportunities and see if there's ways to adapt your role or find ways to stretch yourself or other within your current organization. And ultimately, if you can't find, you know, if you can't find that opportunity where you are, then maybe you should go look for somewhere else. Yeah. You know, but that'll put you on a good trajectory and ultimately in your career, you'll see the high point, the pinnacle.

I fully agree. In general, working towards challenging situations is just how you grow. There's this— I think it was Mel Robbins' podcast where they talked about exactly that, is that if you think about a situation and you're finding yourself, you know, quite fearful of the situation and you're finding excuses of why you should not do that, that's usually a sign that you should go ahead and do that because that's what the growth will be because it's just going to push you outside of that comfort zone, and that's why you're thinking like that. So I apply that very often. I'm like, you know, if I start thinking like that, I'm like, okay, well, let's go.

This might be it. Yeah. You know, I tell people too, as I go back in my career looking for examples that I can teach to people, they are— it is— it might be every example that I can draw from was a painful example.

Mm-hmm.

Like, that was an uncomfortable time in my career, and that is why I learned so much from that, and that is why I am now able to teach that. And so in the moment, those things kind of suck. It's like, I am very uncomfortable right now. And in the moment, it's hard to always see the big picture. But the truth is, you know, those will be the moments in your life that you look, you look back to and you say, I had a ton of growth.

Yeah. Gives you a great story as well. Yeah. Like if anyone's into like public speaking or, you know, storytelling, having great stories to tell is just good, right? And then everything, a great story is always, you know, has that climbing the Everest type of challenge and you overcoming that and coming on the other side with real lessons to share, right? So, I mean, you shared just powerful things here, Ryan, today. If people listening, you know, wanna learn more from you, what is the best way to connect?

I do a pretty good job of kind of sharing my story on LinkedIn. And so that's a great place to follow me. I've started to post a little bit on X as well, but mostly on LinkedIn. You know, I now, I would say if you look back 3 or 4 weeks, I was posting almost every day. Today it's like you're lucky if you get a post of me in a week. And that's just, you know, the reality is right now I am like immersed in, we are building this new AI product at Grin and it is the most fascinating thing that I've ever personally been able to work on. And so, you know, it would just heads down. I'm very heads down. Building right now, but I will be sharing a lot of that story on LinkedIn, so it's a great place to follow me.

Excellent. So, and for everyone tuning in, guys, I appreciate your time. Drop your questions in the comments and go to Mastering Tech Growth to check our community out. And as always, guys, until the next time, stay safe and see you online.