The #1 Mistake Every Technical Founder Makes

Sean Weisbrot: Welcome back to another episode of the We Live to Build podcast. Many people praise technical founders for being the lone hacker who puts together the product, and then magically launches and gains fame. The reality is, a technical founders are just like non-technical founders, but with a different skill set they bring to the table. Being a technical founder can be an advantage, but it can also be a disadvantage in this episode about how to succeed as a technical founder.

Sean Weisbrot: Our guest is Dave Shanley, the founder and CEO of Content Camel, a sales enablement tool for sales content management. He's a serial entrepreneur with experience in bootstrapping, raising venture capital acquisitions, and growing product lines to $25 million a year in revenue for B2B SaaS. He was previously the founder and CEO of Notion, which was acquired by Jama Software, the founder and CTO of Crowd Compass, acquired by Savant, and before that, he ran a global team at Ciclo acquired by SAP. More specifically, we touched upon what is the hardest lesson you learned becoming a technical founder of a company.

Sean Weisbrot: What did you wish someone had told you before you started? What's the most important soft skill you have developed through all this? Why you should set expectations early. What are the most common pitfalls the technical founder experiences? How should a technical founder decide whether to be a CEO or be the CTO and hire a CEO? How to deal with legal issues when you're not the CEO and much more. So, thank you to Dave and I hope you enjoy this episode.

Sean Weisbrot: What is it that makes you the right person to talk about this topic?

Dave Shanley: I have a background in computer engineering, so I have like a very, very formal background. I did a bunch of startups in San Francisco and Chicago before starting my own companies based out of Portland, Oregon. My first company that I started here a while back was a team of three of us, and I was the CTO. We built that up and sold it, and then later went public with the acquiring company. And I ran a tech team of like, I don't know, about 150. And then I basically moved on from there.

Dave Shanley: I mean, I saw up close and personal what it meant to like, grow at a really quick pace and like, what sort of growth, you know, the growth mindset like growth thinking, sales and marketing applied to the business, what that could do. And so that has really informed my opinion, um, in building the follow-on company from that, which was a data analytics company which exited, and then I ran growth at a mid-sized like 40 million RR company that had acquired me. And then I then left that and started a new company that's bootstrapped. It's in the sales enablement space, sales and marketing software.

Sean Weisbrot: All right. Thanks for the breakdown of your background. It definitely sounds like you have some experience in this regard. Let's start with what is the hardest lesson you learned becoming a technical founder of a company.

Dave Shanley: The thing that you learn right away is the whole over-optimization, right? Or spending too much time in a certain area and product and not seeing that used. That crops up a lot for a lot of teams, you know, because whether it's 1 or 2 technical folks on the team or an entire team, five, ten, 15, 20 we're like, however big it is, like you're going to build stuff, right? Like that's you're in the mode of building things. And if, you don't take on board whatever, like go to market like who's getting your product to market. Like if it's not you because it's probably not you if you're the technical founder, right? If you're not taking on board their feedback, you're missing that opportunity to connect. And I'd just like to frame it as like engineers really want to see their stuff used.

Dave Shanley: Obviously success comes from people using it and loving it and things like that, but it's like you don't just want to build stuff, to build stuff. But in the absence of that feedback of like connecting with the team that's out selling it or, or the marketing team that's, you know, driving organic growth or whatever that is, you're just going to like, build stuff in a vacuum, and it's not going to be the right stuff. Like, for sure, it's not going to be the right stuff. Some of it's not going to be right, or maybe even most of it's not right. So that's what is like the most painful and hardest lesson is getting on board with trying to focus on building the stuff that people will use and that drives the business forward versus just building stuff.

Sean Weisbrot: So, what's something you wish someone had told you about entrepreneurship before you started?

Dave Shanley: I wish that I had read the Steve Blank-like customer discovery stuff earlier. I wish that someone really made it clear to me that you can, whatever way you're thinking about it today in testing your idea. Like say you are doing customer discovery, say you are trying to explore the opportunities around your solution space. You can probably do it like faster and cheaper than the way you've come up with. People fixate on solutions and they don't fixate on kind of like they don't bubble up to the next level.

Dave Shanley: That is the problem and that problem space of like what they're trying to solve. They get really like in love with a specific solution, and they are looking for reinforcement from people they talk to about that solution, that it's like the one to pursue. But I bet if we all sat down and brainstormed, we could come up with 10 or 15 ways to do it faster and cheaper.

Sean Weisbrot: I can definitely say I've fallen victim to falling in love with the idea of features, and we started building those features. But then later I got a chance through the podcast to validate those ideas by talking to people I kind of built first and then validated, but thankfully I validated correctly. Thankfully, my ideas were correct.

Dave Shanley: Again, it's like success, and despite the choices you make, you can get lucky like you can. It can work out, but a lot of people, unfortunately, spend a lot of time on things that are not the right choice that they could have validated, and they could have explored that way faster and way, you know, less expense to monetarily or to relationships or you know what I mean?

Sean Weisbrot: As a technical founder of several companies, what is the most important soft skill that you have developed through all this?

Dave Shanley: I think it is really, truly being able to understand where people are coming from and taking that feedback and, you know, working with people to essentially like achieve their goals inside the organization. Like I think that creates a dynamic, lasting culture. I think it probably took me a while to get to the point where I, like, fundamentally understood where people come from, you know. People are coming from a lot of different perspectives and a lot of different angles. They're not all going to think like you. They're not all going to have the same expectations. And just some of the some of the skills associated with nailing that down.

Dave Shanley: A lot of it is just basic stuff like write stuff down, you know if you have a conversation and it's about expectation setting like a document that like to make sure that there's a shared understanding like there's no shared understanding unless you've written it down and it's like echoed back, I think a really powerful tool, you know, in the soft skill side is, I think I would say, like most teams skip this, this concept of authentic appreciation, where you know, you truly recognize people's contributions and you make that a habit, you know, among the team, not just from your perspective as a leader, but as a habit among the team, I think is a very powerful dynamic.

Sean Weisbrot: Do you think it's taken the most work because technical people are, I guess, generalized as being not terribly good with other people?

Dave Shanley: I think there's some truth to it, but I think it's unclear expectations, setting and not understanding where people are coming from and not, you know, having the difficulty in empathizing with that or sort of building that construct where you fundamentally understand that. I guess if that makes sense.

Sean Weisbrot: I'm sometimes surprised by my team. I feel like sometimes their communication skills should be better. I try to help them work on it, and the reason why I'm surprised is because when you're coding, the rules are very simple. Do this thing right. You're telling the machine to do this thing, and if this thing is not possible, do this other thing. So, like the communication with the computer is very simple. This is what you need to do. But when it comes to humans, it's not so clear-cut anymore because of emotions. Yeah, sometimes it's interesting for me to observe that it's not just about being a technical founder, it's also about working with technical people, and trying to relate to them is also a struggle at times.

Dave Shanley: I don't have a ton of experience running like cross-cultural teams. That is definitely a different bag because you have you have to really understand where those folks are coming from, from the cultural aspect, I think it is interesting because I think as more and more teams go remote, right? I mean, obviously everybody's remote now, but it's more companies really seek to be very dispersed. I think there's a lot of challenges to having, you know, a very, very cross-cultural team.

Sean Weisbrot: Because engineers are great at processes, and startups need to develop processes in order to scale. Do you think an engineer is the best CEO for a company?

Dave Shanley: I mean, it's not an unequivocally yes or unequivocally no. I think there's some obviously really talented, uh, technical CEOs out there. I think there's some really terrible technical CEOs out there. The skills at the executive level are all about growth system building, focusing the team around success in the market in like whatever the organization is set to achieve. Can you truly get everybody focused and rallied around the core aims of the organization? If that person, the executive role is technical, then they brings a certain set of skills like ideally like. Systems building and decomposing problems. Right? That approach to problem-solving analytical abilities, it's obviously much more broad skill set than just that.

Sean Weisbrot: So, what I'm hearing is an engineer could be a good CEO if they also understand the people side.

Dave Shanley: Yes. I mean, maybe it's also it's like who's on the team, and like are they leveraging that team? If you have an organization where the executive empowers and takes full advantage of the other folks in leadership, that is probably going to be a successful company or certainly has a greater chance of success if it's the person that's trying to go to lone and trying to solve every problem and think that they are, like, uniquely positioned to solve every problem, that probably will not be quite as successful.

Sean Weisbrot: In the beginning, I tried to solve a lot of problems, and I realized very quickly, I'm not really good at most of those things. So, I was like, okay, I've just got to find people to do them because if I try to do it, I will crash and burn hard. Is there a technical founder of a company that inspired you in any way?

Dave Shanley: Not really. I mean, I mean, there's been some great technical CEOs. I mean, like Lucerne from New Relic is obviously a great example, has been successful in building up a lasting company. I mean, they're maybe losing ground to Datadog these days, but that's those are like product decisions. And so maybe, you know, there's a point at which the, you know, the organization didn't scale well.

Dave Shanley: But in my personal career, I have there's not like a specific person or other folks on in the technical run them. And like, I want to be like that person, like the CEO, the codes sort of thing. It's mostly been about just learning, just learning what worked for other folks, whether they were technical or not. I mean, it's other business leaders, Benioff and folks that built that had like a systems approach to think, to thinking and effectively built teams.

Sean Weisbrot: I don't blame you. One of my close friends is the technical founder of a software as a service company for hotels in the US, and he was the only person for the first like three years. So, he was coding and doing business development and sales and customer service and all that and eventually started to hire like customer relations managers and salespeople and all that. And it wasn't until I think like a year or two ago.

Sean Weisbrot: So, he's been doing it for like eight and eight years or eight, nine years now. So, it wasn't until like recently that they started to hire developers. And even still, he's still coding alongside the other people because, like, he really loves his product. Um, and his twin brother also works with him more on the tech side as well. But yeah, like, he just can't seem to take his hands away from the code.

Dave Shanley: I think that's also an interesting point. Like as a founder, I think, I mean, from my personal perspective, like, I think it's interesting to be real and acknowledge, like, are you doing the things that you enjoy, right, like you started this company or are you in this role just by default because like you were this person and the rest of the other founders that you wanted to work with had a certain set of skills and like they took these roles and then you wake up and you look around in three years time or five years time or whatever, and you're like, what the hell? Am I doing? This isn't what I like. I think it's okay. Like from a permission standpoint, like to change that up. You don't have to do that. Like find another role in the organization or like or move on. Unfortunately, some people stay in roles too long and it's not good for them and it's not good for the organization.

Sean Weisbrot: He loves what he does, and that's why he's continued to play the CEO role. At the same time, him and his brother are both highly technical people, and so they kind of share the technical responsibility. But he also like manages the sales people and the marketing people and customer service people as well.

Dave Shanley: So, I mean, it's hard to do all that like the I you definitely get to the point where you become a liability. At my one of my first companies, I wrote the code base one, definitely one of the most active like committers on our project. And then, you know, I don't know, three years in and you're responsible for the entire team and have a lot of, like, diffuse responsibilities inside the organization and like a bunch of responsibilities on the growth side, like you are not the best technical contributor.

Dave Shanley: You know, it's the specialist versus general generalist kind of play, right? Early days, everybody is a generalist. Then you filled that in with like very specialized people, people that are very good at like very specific things. If you try to just like jump in to all these different areas, you're just you're become a liability. Like it's the it's the sort of joke where people will humor you, but not but you're actually not being effective.

Sean Weisbrot: Yeah, I can definitely see how there be a problem, because if you don't build the organization from the ground up in a way that one thing flows to the next. So, for example, in our organization, my COO wants me to focus on the user story level and build a lot a long-term roadmap based on that. And if the tech team knows what the roadmap is, they can do it. If the marketing team knows what the roadmap is, they can market it. If the sales team understands what the roadmap is, they can sell it and it starts from the user story and it starts from communicating with your clients.

Sean Weisbrot: It starts with having systems like Canny and promoting Canny for customers to tell you the features that they want. It's having phone calls with the users and saying, you know, what are your problems and things like that. And then going back to this high level and building something that can flow through everything and building a data pipeline that connects to all of it so that, you know, data is built in tech flows to marketing. So, marketing understands what's happening, and then they can inform sales and customer service, and it flows back to the executive team so they can see what we're building is resonating with users. We see them using it more. We see them paying more or we see them leaving. We see them, you know, not paying anymore.

Sean Weisbrot: And that's really the mindset that my CEO and I have. And that's what we're trying to institute now. We're trying to build it as we grow the company, so that it's not like in five years we go, Holy crap, none of our teams are talking to each other. Nobody knows what's going on. And there's a mess everywhere, and there's fires all over the place. So, we hope that with this strategy. It'll solve the it'll prevent these problems of these conflicts from happening, especially because I've heard of organizations where, like the tech team thinks they're the, the best or like, or they're treated the best or the inverse.

Dave Shanley: I mean, I've been in organizations where the executive team doesn't understand their tech team at all, right? And doesn't don't they don't want to go near them or touch them sort of thing? You can start laying the groundwork for that foundation now, no matter what size you are. You have finite resources like you have finite ability to accomplish things. Take a pie chart and then you're going to chop it up into like probably three quadrants. One, it's like new marketable features. That's what drives your business. Like everything, the existence of your company, growth, etc. is going to be driven off of like new marketable features.

Dave Shanley: Basically, you also have to do the table stakes stuff like the stuff that all your competitors have and the stuff that people expect, but it's not marketable. And then you have like tech debt, which is the technical underpinnings to keep the trains running smoothly. You've got those three quadrants. I bet in most of the people, like in the organizations, they're not setting expectations on what's our focus on those. If you have sliders for each of those, are we more on like the marketable feature side or are we more on like, man, we gotta shore up like our quality and tech debt because customers are complaining about it or whatever?

Dave Shanley: That is fundamental. Imagine going to your organization and clearly communicating where those sliders are. You can measure what the output was, but you're clearly communicating those expectations so that all of the small decisions that people make that don't get flagged up and don't involve teams getting together in a room or, you know, on a Zoom or whatever, like, and trying to hash something out, like all those small decisions are then influenced by those expectations that have been set. That's how you start to shape the culture and build it from the bottom up. But you know, with that top-down, strategic, clear expectation setting.

Sean Weisbrot: I'm glad you said that. I have an example. A friend of mine coded a platform by himself for four years, and then it was ready to start having customers. But he doesn't know anything about being a CEO, so I've been mentoring him on how he could think more like a CEO. How should a technical founder decide whether to learn how to be a CEO, or whether to hire a CEO, so they can focus on being the CTO?

Dave Shanley: If it's only you and you have built a product and you have no ability to go recruit a co-founder or CEO, pay a CEO, whatever the dynamic is, then you're stuck doing it yourself. So, it's whether you like it or not. It's like, how passionate are you about making your project successful otherwise? Like without those constraints, you should really focus on like what's going to make you happy. It is easier to divide up the responsibilities, right? And have a partner and have them participate in the business, you know? So, if you're a technical founder, like you're probably going to stick with the tech side.

Dave Shanley: I see a lot of people like they go and just try to get anybody like, oh, this person was good at some big Co, right? Like, oh, this is a Nike executive. And they'll like for sure they'll be effective in my tiny little startup is probably not the case. Just like you would do your diligence on hiring a tech candidate. Like, make sure you're doing your diligence on the business. The side, unfortunately. Like you don't know what you don't know. So therefore like, how do you systematically fill in that knowledge?

Dave Shanley: Make sure you go talk to other leaders, other peers who are some successful tech, you know, founders that are interfacing with the business side, that have worked closely with CEOs or sales leaders or whatever. What are the qualities that make that a successful relationship? I don't know if people just want to, like, wave their hands or think that it's different or, you know, they would spend a ton of time evaluating a technical candidate that they would bring on their team, but wouldn't put the time in to evaluate someone that they're going to bring in.

Sean Weisbrot: On the business side, if you are heavily technical, it could be difficult to figure out who is the right person to run my company from that side and how do I find them and how do I attract them. How do I get them to come on board? How do I retain them? Do you have any advice about that?

Dave Shanley: You're not going to be able to effectively recruit like, you know, how is a CEO who knows nothing about technology? You're going to go like hire a Python developer. They have no ability to evaluate them. So, it's ridiculous to think that suddenly, magically, you as a technical founder that hasn't been through the process before, haven't run good market, sales, marketing, business ops, like any of that stuff that you're going to be able to evaluate somebody's ability other than do you like them, which is only one piece of it? Or, you know, do you think they're going to be successful?

Dave Shanley: It's like, yeah, it's crazy. I would hit up your network, like get referrals to people, but that only goes so far. Yeah, I mean, I would do the work and try to find peers that are a little bit further along and figure out the feedback that they have on what's worked for them, what they've seen work, you know, from the relationship and characteristics and, and things like that. Then you will have some criteria. You'll basically be able to like build up this framework and rubric like where you can then go have meaningful conversations.

Sean Weisbrot: And how would you suggest they incentivize someone to be a CEO?

Dave Shanley: I mean, there's a lot of different ways. I mean, people get passionate about the product. Like I recruited a CEO and another technical co-founder to my first business, you know, like out of thin air. I had put myself out in the community and the people were like reaching out to me to connect. And then I was talking to them about my ideas. And you get people excited about what you're working on, and they want to be part of that. And so that's one mechanism.

Sean Weisbrot: I think the most common understanding of startup, in terms of the exec team is that the CEO is the one in charge, or at least the main founder or something like that. So, if you're a technical founder and you decide that you want to be the CTO and you bring someone on to be a CEO, maybe it's a co-founder or someone that comes in a little bit later after you've started the company. How does that dynamic work?

Sean Weisbrot: Do you, as the main founder, and as a CTO, still maintain a lot of the decision-making and control and then allow the CEO to do their job? Like, for example, if I were to hire a CTO right now, I would be like, okay, well, this is all the stuff that I want to get done, but I also want your input. So, like I understand from a non-technical point of view how I would manage the. Other executives. But how does that work? When you choose to be CTO and you're a technical founder?

Dave Shanley: I mean, it's just like a marriage or a partnership or anything else. How do you want to participate if you want to be the technical founder? That's like off in a corner building product and you want just everything else taken care of, that's what you will achieve. I don't think that's the healthiest process, but then the other founders in the business are going to be making decisions. The opposite is you can't make all the decisions together. I mean, a lot of early-stage companies do a lot of like collective decision-making. It can be slow and then it doesn't scale. I do think it is interesting.

Dave Shanley: Bezos like a two-way door analogy where it's like a door that you can go in and come out of. If you can reverse the decision, make the decision quickly. If it's a decision that you can't undo, if the outcome is painful, then spend more time upfront. Like, don't sweat the decisions that can easily be undone. Try to make them as quickly as possible. You know, with bringing someone into the business, you can set those expectations like hey, things in this realm make those decisions quickly when it's something that is harder to reverse or touches the tech team, or touches company culture or like whatever. Like, let's make sure we all get together on that and partner on those decisions.

Sean Weisbrot: It was going to say, if you're the CTO, you're the main founder, and you decide to give the CEO a lot of control, effectively, you're allowing the CEO to tell you, this is my vision, you're wrong. Go do it this way instead. Almost. And you're kind of subjugating yourself or relegating yourself to a lower position, even though it's your baby.

Dave Shanley: That is not necessarily the case. I think in every relationship, it's healthy to have an operating agreement that you're not going to do it all by consensus. Someone has to make the decision and other folks too. They can disagree, but they can commit. Is this a reversible decision? Like it's very difficult to disagree and commit to a decision that you feel is like very like one-way street that's different then that definitely needs to be hashed out. But like you're not going to achieve consensus.

Sean Weisbrot: As the CEO, I'm the one talking with the lawyer, preparing the different, you know, the employment agreements, the shareholders' agreements, the Constitution, things like that. But if you're a CTO and you don't really understand, I mean, I don't really understand legal stuff myself, but like, I try, I'm able to have those conversations about my expectations for what I want for the company with the lawyer. But I guess as a CTO if you don't have those things in place and you do have a CEO, would you be relying on the CEO to go and do those things? And then how do you know that they're not building up power and control for themselves behind your back without you realizing it through these legal documents?

Dave Shanley: I mean, you can participate in those conversations with the lawyers. The legal foundations of the company are definitely one of those one-way street types of situations, right? So, you can clearly set the expectation like, hey, I want to be involved in these conversations where we're setting up, like the legal entity and how the foundations of the team legally and like what those rights responsibilities are from that perspective, that it would be an important joint founders agreement I've always involved. In my company, It's always been the whole team in on those conversations. You don't want someone like nefarious in your business. I mean, it comes back to like vetting whoever you're bringing in and working with. Like, you have to be able to trust them.

Sean Weisbrot: What's something I haven't asked you that you wish I would ask?

Dave Shanley: It's a really interesting thing, is there's such an opportunity for technical founders to be more involved in creating this culture around successful go to market. Like, I think there's tons of opportunity there, and I think it's just a blind spot and a white space where people are not focused on creating a culture where the whole organization is focused on that success.