Show Notes
In this episode, Tyler helps Rick evaluate how to build a new software application from scratch. Since Rick is a nontechnical founder, his biggest roadblock is figuring out how to build the application without raising money.
After going back and forth, the following framework emerged for nontechnical founders trying to hire a first employee:
- What is the idea (i.e. problem and solution)?
- What type of application needs to be built to deliver on the idea (i.e. requirements)?
- What technical skills are required to build the application?
- How much are these skills going to cost?
- How are you going to finance these costs?
Some of the takeaways include:
- If you're a non-technical founder, it’s very hard to bootstrap early product development without giving up equity.
- CRUD (Create. Read. Update. Delete) software applications require a generalist “full stack” developer while more sophisticated software applications may require a specific specialty.
- There are two big buckets of skills for product development: design and technical.
- The design bucket is made up of two categories: 1) user interface (UI) design and/or user experience (UX) design; and 2) graphic and/or visual design.
- The technical bucket is made up of three categories: front-end development, back-end development, and infrastructure.
- There are a number of ways to staff these skills ranging from finding an experienced generalist co-founder, which is most expensive, to outsourcing, to hiring entry level talent at the low-end. Each approach comes with it’s pros and cons.
- One downside of going with less experienced talent is “technical debt”, which can increase costs down the road. Another downside is slower progress due to the learning curve.
- To attract top talent, you either have to: a) have a compelling idea and be willing to give up significant equity, or 2) already have some traction and be able to pay a competitive salary and bonus.
What is the idea?
Tyler: In this episode, we’re going to talk about the ideal technical co-founder or first employee for a software company, and how to find them.
Rick: I’m excited about the topic today because I’m not technical. For purposes of this conversation, let's assume it's a software application in the business-to-business (B2B) realm. Obviously, [what type of software you want to build] is going to be a determining factor. But for the purposes of this conversation, let's condense it to, “what's the right technical co-founder for a B2B software company.” This is on my mind because I just ran into a [technical] problem with
Group Current. But, it's also on my mind because as I think about
LegUp Ventures, which is my parent company that owns and operates [my startups], I'm starting to think about other types of software applications that I might want to build. For example, I'm still very interested in the employee benefits space outside of health insurance. I have an idea about education benefits where a company could give money to employees, tax-free, and let them go into a marketplace similar to the health insurance marketplace and peruse courses from all types of vendors [ranging] from
Coursera to
SaaStr to, even in-person events or books on
Amazon, buy them, and then get reimbursed tax-free by their company. I've thrown this around with a lot of people, especially millennials who are interested in going to take advantage of these new tools, and there seems to be a solid demand for it. I cannot find anyone who's delivering on this. I know exactly how this is going to work and all the technical specs. The big roadblock for me is knowing how to go about building the application in a way that I can prove [product market fit] before I raise money.
Tyler: Yeah. So it seems like there's at least two parts of this. One is what skills would the ideal technical co-founder have and all that? The other one is how do you find that person?
Rick: Yeah, and I would say there's a third element. So one is, yes, skillset. Two is how do you find them, and then the third is what do you call them and how do you pay them? Is it a co-founder? Is it a contractor? Is it an [outsourced] shop? Is it an employee? And what's their title? Is it engineer? Is it co-founder? Is it CTO?
Tyler: Right. Okay, so where do you want to start here?
Rick: Skills.
What type of software application are you building?
Tyler: So you're talking about a web-based application, right? And this is something that absolutely doesn't require genius-level technical knowledge to build. Do you know the term CRUD? This is a CRUD app.
Rick: CRUD sounds bad. Is CRUD bad?
Tyler: No. It's Create, Read, Update, Delete. It's basically the four main database functions, and a lot of software out there is nothing more than putting stuff into a database, taking stuff out of a database, and then putting a [user interface] (UI) on top of it.
Rick: Yes, and I would say that the UI for this is critical, because it's going to be a low ACV (or annual contract value) product and self service is really key.
Tyler: Yeah, so the UI design might be more important than the actual technical implementation here because, with most CRUD apps, and I consider a CRM to be one as well, you don't need a
Google-level genius computer science PHD to build it. Maybe you need someone who has more empathy for customers and stuff like that. Do you think the person you're talking about is going to design it, or do you think someone else is going to?
What skills do you need to build the application?
Rick: So, maybe I could talk about what my skills are. It sounds like this is going to be variable based on what compliments I need. I am a terrible designer from a “look and feel” standpoint. I can wireframe a usable product. I can wireframe a vision for something, but in terms of making it an exciting experience for a user, from colors to a style, to even specific placement of elements, that's not me. But in terms of writing requirements, describing the high level technical requirements, describing the user persona, the strategy around marketing this, that's all I'm really strong at. I would love someone that is as passionate about the user experience as me, but I can't do the design, I can't code the design.
Tyler: So you either need a designer and a programmer, or a jack-of-all-trades who's going to be able to do both of those? A lot of companies would have two different people for these two different roles.
Rick: Well, let's assume for this conversation that I'm looking for one person to fill this void, and I'm open to calling them a co-founder. I'm also open to calling them whatever is appropriate to call them. Employee. Contractor. Outsource shop. If this is going to be one person, what are all the skills that they would need to be able to design, code, and, I guess, launch?
Tyler: Yeah. So where you leave off is basically a requirement doc. Maybe you could do the wireframe, but it sounds like where does stuff go on the page is not something you think someone else would be better off doing. So, you give a requirement doc and they take everything from there.
Rick: I'm very opinionated when it comes to the final product, and I can tell you, “that's not right”. I can point out a problem, but coming up with a solution specifically that's going to be implemented? Not me.
Tyler: Okay. So you need someone who has everything from wireframing, mocking up, and then also full stack development. So, pretty much a generalist here, unless you wanted to outsource parts of that. So you could bring on someone who's just got the product side of that, and then outsource development, or vice-versa. If that's the skillset, you're talking about someone who has built an entire thing themselves before. Really what I mean is you're talking about someone who does not have a background working at big companies, I think, right? No one who works at a big company is doing all of those things.
Rick: Why is that?
Tyler: Because big companies specialize. They have a design team and they have a front-end team and a back-end team, and maybe the person does it on the side as a hobby, but my limited experience working at big companies, you don't get exposed to all those different pieces versus at a really small business, or a startup, or something like that, maybe one person is touching all these different pieces.
Rick: Okay. Got it.
Tyler: Do you buy that?
Rick: I buy it. I think we're getting into how to find the person.
Tyler: Yeah, okay. The highest level skills are UI design, graphic design, front-end engineering, back-end engineering, and maybe a little infrastructure stuff.
Rick: Can you go through each of those and just translate it to non-technical speak?
Tyler: Sure. I should say the design nerds of the world quibble quite a bit about this terminology. So everyone might not necessarily agree with the way I'm defining these terms.
Rick: What are the big buckets of skills, and what do they mean? Let's go through those.
Tyler: Okay. Let's start with the design. The two big buckets are design and technical. Let's start with design. Within that you've got UI, which means User Interface, or UX, which means User Experience. Once again, technical nerds will say there's a difference, but often they're used interchangeably. What that is, I think, is basically understanding how the software should work. So, where do the things go on the page? How does it walk a user through the typical workflow? It involves design and thinking visually about the product, but it's not super specific, it's not what are the colors or the corners of the buttons around it, what picture should we use? It's much more abstract like writing the copy, and thinking like, "if we have this set of pages, the user will be able to accomplish their goal.'' I'd say that's UI design to me. Then, there's graphic or visual design, which is more about the aesthetics of it, just making it look okay. I would argue you probably could get away with being a little bit weaker on that, because even though it's going to be a self service product, the individuals are not going to be buying it. You're going to be selling it to a company, and then the employees of that company, they have to understand how it works, but they don't have to like it, right?
This video does a decent job of explaining the design requirements for building a software application.
It also quickly explains the differences between UX and UI.
Rick: What do you mean by, "like it"?
Tyler: A lot of consumer products like
Snapchat and
Instagram need to just have lots of cool animations and everything needs to be super polished and beautiful, the colors need to be good, the logo needs to be good, because people are using it because it's cool and pretty and sexy. You're building B2B SaaS (software-as-a-service). It doesn't need to be sexy. It doesn't need to be beautiful.
Rick: I don't know if I agree with that for this specific application because I think the target market for this particular example is going to be a smaller business, and they're going to be buying it on a self-serve basis sometimes. So I guess I'm a little hesitant to just throw away the importance of that for this, but I hear you.
Tyler: Okay. I'll give my own experience here. Like Less Annoying CRM. I consider myself someone who's much better at UI design than visual design. Less Annoying CRM is a product that we get a lot of praise from our customers about the design, but what they mean is UI design. It's not attractive. Nobody would look at it and say it's attractive. That's why we're doing a redesign right now.
Rick: Okay, then I think we're saying the same thing. I care much more about UI design than visual design at the stage that we're talking about.
Tyler: That sounds right to me. So to me those are the two big buckets of design, and I think that covers pretty much everything on the design side. Then, you've got the technical side. I broke it into three categories. Once again, people might quibble with this, but I said front-end, back-end, and then infrastructure. So let me start at the end there. Infrastructure is like, you have to be able to host a website somewhere. This is something I'm terrible at. My co-founder is more technical than me. He's on the infrastructure side. But getting a server up and running, making sure your database has backup so that if something bad happens, you're not screwed. That type of thing.
Rick: Ok.
Tyler: Back-end coding would be a programming language that runs on a server, so PHP, Ruby, Python, something like that, that interacts with the database to basically save the right data in the database and get the right data out. If you have algorithms, like let's say you want a recommendation engine or something like that, that's normally going to be back-end. It's often considered more technical and less “user experiencey,” because no one ever sees it. The back-end is the code no one ever sees, right? Then, the third bucket is front-end, which is, take all the data and the algorithms and all that that's generated on the back-end and visualize it for the user. So actually implementing the user interface that the designer designs.
Rick: It sounds like the front-end person overlaps with the UI designer.
Tyler: Yeah, a visual designer can write the HTML sometimes. A lot of designers can do basic front-end coding. If you think about really sophisticated apps like
Google Docs or something, the front-end coding on that is really extremely technical and probably a designer would not being that type of thing. In your case, I think the back-end is simple. Once again, it's a CRUD app. You're going to have a list of education tools and you're going to be able to pull up that list and show it to people. It's going to be pretty straight forward. So I don't think you need deep, deep knowledge on any of these from who you're looking for, but you do need some experience with all of them, and I'd say the one you want the most deep knowledge on would be UI design from the sound of it.
Rick: Does UI design include speed of the interface? One thing that annoys me is everything looks great, and then all of a sudden you click "Sign up" and there's this toolbar that just starts spinning and you totally lose trust in the app because it does what it's supposed to do, but it takes 10 seconds.
Tyler: Yeah. That would not be the UI designer probably.
Rick: Who's that?
Tyler: Those are going to be the front-end and back-end engineer for the most part. I think it's pretty well understood that you want everything to be as fast as it can be. A designer shouldn't have to tell you that. So I think the programmer, if you consider there's five different people working on a team, the programmers, the front-end and back-end would be most responsible for the performance I think. Maybe the infrastructure person depending on the specific performance issue.
Rick: Cool.
Tyler: Yeah. So anyway, I think you're looking for a pretty even split across all of those. You're looking for a generalist, which is tough.
Rick: It sounds like I want a UI, front-end leaning generalist.
Tyler: Yeah, and there's a term I don't think I've used yet which is full stack. So front-end and back-end are different parts of the tech stack. Full stack means you can do all of it. So, if you're talking to people, I think you're saying "I want a full stack developer who can also do UI design", or something like that.
How much are these technical skills going to cost?
Rick: That is super helpful. I want that. Okay. I want to go into cost. I'm starting to realize that's actually more important to me than where to find them. I assume these people exist. How much do they cost?
Tyler: Yeah. There are many different personas for this. If you want someone who's proven, I think your best bet ... I think it's hard to separate costs from where do you find them, right? Because where they are in their journey matters.
Rick: What's the range? If we look at the less experienced, lower cost, up to the most experienced, higher cost, what's the range in let's call it salary in Utah or or St. Louis (not San Francisco) for this type of person?
Tyler: On the low-end would be somebody who probably is in college or recently graduated college and they're just a total nerd for this stuff and have self-taught. They won't have a ton of experience, but they'll have the interest and all that. You're paying them the lowest you might pay a developer basically, or just equity probably.
Rick: What's that? Assume no equity, this is just an employee. What would that cost?
Tyler: We pay our developers $70K to start. I think that's fairly in the middle of the range probably, but because this would be brand new venture, working directly with an experienced CEO, I think you could get away with paying quite a bit less to somebody. Because it's such a unique opportunity, I bet you could get away with $40K or $50K probably.
Rick: All right. Talk about the other end of the spectrum where you're getting someone proven. I'm assuming this person, if they're proven and they can do all of this, they're probably pretty valuable.
Tyler: I would say yeah, very valuable. They would expect significant equity no matter what. If they are someone with an engineering background but enough design sense and user empathy to be able to do the whole thing, that's one of the most prestigious jobs at a tech company. So I think you're talking about mid-six figures if you're paying them totally in cash.
Rick: Outside the Bay Area, or in the Bay Area?
Tyler: For the best ones in the Bay Area, you're paying them a million a year. For a normal one, you're paying them $500K in the Bay Area, so maybe in $300K. I don't know.
Tyler: Cool. So this is a pricey person.
Tyler: If you find that person though, I think they've got to be a co-founder.
Rick: Yeah, okay. So co-founder versus employee versus contractor starts getting into what experience they have and how much can you pay them.
Tyler: Yeah. And I should say by the way, let me give a disclaimer. I'm just making all this up. So, I hire mostly entry level people. I have friends who have these types of jobs, but the numbers, take a little grain of salt with them.
Rick: I take everything you say to be exactly the truth.
Tyler: Absolutely. Nobody can question my wisdom. You were just saying the equity versus compensation thing probably has to do with experience level?
How do you finance these costs?
Rick: I understand the broad situation for a full stack developer with strong UI design experience. That person's going to be really expensive. So, how do I finance this when I want to bootstrap until product-market fit? I’m willing to self-fund this to a point. How do I finance finding someone who is really good at this, or let's just call it good enough at this to start making progress, without paying $300,000?
Tyler: Right. One thing I guess I would ask, you've been through your last company, basically a total rewrite of the code base, right? One thing I think you have to ask yourself is how much do you want to invest upfront to prevent that from happening down the line? Because there are a lot of corners you can cut, you can get someone who's less experienced and all that type of stuff, but you accumulate what's called technical debt where you're constantly slowed down by bad technical decisions that were made previously. One of the benefits of hiring a more experienced person and one of the benefits of bringing on a co-founder who you can trust versus say outsourcing it is they're going to take more ownership of the code and make sure that it's good. Do you care about that?
Rick: I don't think so. Based on my experience, none of this matters unless you get to that product/market fit stage, and once you get to that product/market fit stage, if you're thoughtful about how you do this you can pretty much figure out anything. You can finance it, you can bring in talent to fix it. It's not an unsolvable problem, right? Sure, it might slow growth, but that I think is the trade off, right? So if I'm raising VC from the beginning, and speed was of the essence, then I would have a different answer, but in this particular case where I'm bootstrapping, I want to start making progress, speed is important, but what's most important is continual improvement and getting to product/market fit as quickly as possible at the lowest cost possible before we take on capital, outside capital, then that really tells me that I don't care about technical debt.
Tyler: Yeah. So if you don't care about technical debt ... one way obviously to finance this is just give a ton of equity, like a 50/50 split for an experienced person.
Rick: I'm not going to do that. Do I have to do that? I'm bringing the idea here.
Tyler: Yeah, you have to.
Rick: I have all the market knowledge. I have to do 50/50?
Tyler: You said the high-end of the spectrum? For the high-end of the spectrum, yeah. There's never been a better time to be a programmer than right now. Programmers have a million options.
Rick: Why do you say absolutely 50/50? Why can't I do 70/30 and pay the [person] something?
Tyler: Okay. Sorry. You could do that, but I guess what I mean is if you're both getting the same deal, like neither of you getting paid whatever, I have a hard time imagining an accomplished person with this skill set partnering with a non-technical person and taking less than 50%.
Rick: When they didn't come up with any of the idea and they're being fed basically a business? I don't understand. Explain this.
Tyler: I think conventional startup wisdom is that ideas are not worth very much, execution is.
Rick: Understood. Okay.
Tyler: I could be wrong. By all means, go out and try, but I think if you're going for that really experienced person you need to think of them as an equal partner, and if you don't think of them that way I don't think you're going to get them.
Rick: Well, there's equal partner in terms of ownership and say [of outcomes], and then there's who owns what of the business. I think those two things are different.
Tyler: Yeah, but one way to look at this is like what's your market rate if you're being paid cash and what's theirs? Both of you would have very high market rates, but it's not clear to me yours is higher.
Rick: I could understand that if the technical person was saying "Listen, this is my idea, I'm going to find someone to do this with me. I'm not going to give up 50% for a co-founder, but I'll give 25%, and this is a good deal, here's why. Come along.” If it was compelling, I might come along on that. So I don't understand why on the other end of the spectrum, roles reversed, that wouldn't be true.
Tyler: Yeah. It might be. You're saying the word "idea" a lot. If you're pitching me on this, I'm like "That's worth nothing. I don't care about the idea. Let's move onto the skills you bring, and you bring great skills, but so do I".
Rick: You're getting to I think another issue in attracting someone that's really good. Traction. So to get the really good person without giving up significant equity, you've got to have traction.
Tyler: Absolutely. Yes. 100%. I've always thought as a technical founder, if someone wanted to approach me that's non-technical, you either have to bring money or you have to bring customers, and if you're not bringing either of those, why am I partnering with you?
Rick: So what I'm realizing now is for me, in this business, I'm not interested in a top-tier person. Now, if I was interested in raising VC (venture capital), having a 50/50 partner on this, I'd be having a different conversation with you right now. But for this particular venture, I'm not interested in that. So, I think one takeaway for me right now is not only what type of application you're building, what problem you're trying to solve, not only does that drive the person you need, but it's also how fast you want to grow and what the trajectory is. If you're starting from scratch and you don't want to give up equity and speed is not of the essence, it's going to be very difficult to attract top talent without giving up half of the company.
Tyler: Yeah.
Rick: Which for this particular situation eliminates that option for me. So assuming that's the person I want to hire when I [have traction], who's the right person for me to hire now? Or is this an outsourced job? What's the best way to finance this skill set if it's not a co-founder and it's something to get me to the place where I could go get someone like this?
What's the best way to finance this skill set without bringing on a co-founder?
Tyler: Let me throw a few ideas out there, and admittedly I've never hired this type of person before, but here are a few things that seem like they could work to me. One is the hungry young person with no experience, but they're going to put 90 hours a week in and learn it all and all that. One is you outsource the whole thing. And a third one I would say is you find someone at a recently failed startup. That might be someone who's particularly well suited for this. We can dive into each one, but those are three groups I'd look at.
Rick: Okay. The last one you said was interesting and unique. Why did you go there?
Tyler: If you don't want total entry level, you want someone who has experience, but the problem with experience is it’s expensive. If someone's startup just failed, they are likely to be in a position where they're very, very open, like they're not comfortable right now. So if you offer them something they'll probably listen. Now, some of those people will be like "I just took a risk, it didn't go well. No way. I'm going to a safe job", but some of them might be like "I loved it, but I can't start a company by myself. I just saw how hard it was. Oh, you've run a 60 person company before? Fantastic. Let me go code stuff up for you. I know how to do that".
Rick: Interesting. Okay. So that's a good place to find someone, but they're probably going to want to get paid, they're not going to work for free. Okay. So I want to come back before we go into that. So, I want to get to the person that I need for this, and then let's talk about how to find that person. So, you said outsource development. How does that work?
Tyler: Okay. So my understanding is there's maybe three normal models here. One is there's all these agencies out there that you can outsource to. They're primarily marketing agencies, but they have technical-
Rick: I thought you said Asians for a second. You said "Agencies".
Tyler: Yes, agencies.
Rick: Okay. I thought that was not a Tyler move at all.
Tyler: Yes, agencies. You've, I assume, dealt with these before, like marketing firms that you can hire.
Rick: Yeah. Actually at
PandoLabs (a GroupCurrent client) we have a supporting partner called
Outcode and they have a team... I can't remember exactly where it is, but I think it's Eastern Europe somewhere. They have developers offshore and they have product and UI people here, and they sell a project, they have an MVP kit, that sort of thing.
Tyler: So that's one way to go. Most people I know who have done that have told me "You get what you asked for, but you pay a pretty high price for it". That's my understanding.
Rick: So, expensive?
Tyler: Yeah, expensive, but fairly reliable.
Rick: But they deliver?
Tyler: They deliver, and I've heard good and bad experiences, but I think the main thing is if you go to an agency they're going to have a person, a project manager, it's not just a programmer. So you could hire some outsourced programmer, but then you have to manage that person. If you go with an agency, there's probably less burden on you to make sure the project gets executed. I'm sure some of them are terrible and don't deliver, but it takes a lot off your plate, I think. But you pay for it. Another model I'm familiar with is basically those people in Eastern Europe that you were talking about, just going to them directly. There's all kinds of online marketplaces and stuff like that to meet them.
Rick: Like
Upwork for example?
Tyler: Yeah. A friend of mine here in St. Louis who's running a pretty successful startup at this point, he did this and then he ended up just hiring all of those people as full-time employees eventually. So that's his whole dev. team now, are these people he used to kind of freelance out to for pretty low costs, but the flip side of that, it's more affordable, but you have to be the project manager and really make sure that they're taking care of business.
Rick: With that model, one thing I start getting excited about is maybe I hire more of a product person, like a younger entrepreneur in residence kind of thing that's entry level, but gets buying behavior, understands how to ask questions, knows how to develop relationships and then solve problems. Then say "Hey, you're going to be an EIR, this is a great job for you. No equity. 40, 50K. I guarantee it for a year. Then do you have this budget?" Maybe it's another 40, 50K with this freelancer. "I'm going to work with you to build a product around this vision".
Tyler: Yeah, that sounds fairly appealing to me. It's a lot harder to find one person who can do all this than to find one person who can do half of it and manage the other half. I think.
Rick: Yeah, I don't think I'd like the outsource shop because I wouldn't have someone who I would trust with a direct relationship with me who cares as much about the solution and the problem as I do.
Tyler: You'd have to be a manager. I get the impression you don't want to be.
Rick: No!
Tyler: But you could, you could if you wanted.
Rick: I want to find someone who's like, “Rick, I know that what you have here is going to work because of your experience. I trust that. That has de-risked this for me. As long as I deliver what you're thinking and it works, this is going to turn into an opportunity.” That's the mindset I want.
What does “co-founder” actually mean?
Rick: I get why you want that. To some extent, though, it sounds like you're saying you want a co-founder, but you don't want to treat them like a co-founder.
Rick: Why do you say it that way?
Tyler: You want someone with the passion and buy-in and skills of a co-founder, right?
Rick: I don't know what means. Let me clarify what I'm saying. You keep saying "Co-founder" and I think you're assigning meaning to it that is different than what I'm assigning to it. To me, co-founder, all it represents is you are recognized with equity in the company for co-founding the business. That's what it means to me. It's functional. I was not a co-founder of
PeopleKeep, or
Zane Benefits. I guess technically you could argue I was founder of PeopleKeep, but I wasn't a founder of Zane Benefits. But I took ownership of Zane Benefits as an employee, and I had a founder mindset without equity.
Tyler: But that's partially because you came on so long after it was founded. I mean not that long, but a couple years or whatever.
Rick: I don't think so. I think it was because I was given ownership.
Tyler: Sorry, that's not what I mean. What I mean is you weren't called a founder because you came on at that point. You were a “founder”.
Rick: So what you're saying is that you have a different definition of founder than I do?
Tyler: When I'm using these terms what I'm getting at is an employee is someone you manage, you're responsible for the outcome, you need to make sure that they deliver, and a founder is someone who is a peer of yours, you may be called the CEO but you're not their boss really, and they own their area. You can say "It's not my job to make sure it happens, it's your job. If it doesn't get delivered you messed up, that's not my failure as the CEO".
Rick: So I would argue that there are people you could hire as employees and give them that same ownership and pay them a salary, and they could join at any stage of the company, now or later, and you could even not pay them anything because they're so passionate about it. But if you give them ownership and you say "This is your thing", and they're getting something in return that maybe isn't money, that they would act like a founder.
Tyler: Yeah, absolutely. So, sorry. Yeah. I'm using founder colloquially to mean that set of characteristics that founders often have, not that they literally have to found the company with you.
Rick: I'm glad we're talking about this because this is one thing that's bothering me. I think when often times I say technical co-founder or employee, there's a lot of people who have a definition in their head of what a co-founder is and they immediately go to 50/50 split, or if it's three people, 33/33/33. If it's something else, if you're not that, if you're not getting equity, you can't be a co-founder, and I disagree with that. I think if I go find a co-founder and I'm paying a million bucks a year from scratch.
Tyler: I disagree.
Rick: Why?
Tyler: Because why aren't you giving them the equity? It's a lack of trust on your part. It's saying "This is mine. This is not yours. I value you, but it's not yours", and if it's not theirs, they're not a co-founder.
Rick: I understand that's true for my definition of co-founder. I always say that your definition of founder is more about less ownership in the business, more ownership of the outcome. So I want to differentiate between those two. I think there's ownership in the business, and then there's ownership of the outcome. I do not care if the person has ownership of the business. I care if they have ownership of the outcome, and how we compensate that ownership of the outcome could be equity, it could be recognition, it could be experience, it could be cash. I'm less concerned in worrying about that. I'm more concerned about what outcomes need to be managed, who can manage those outcomes, and then once I know who those people are I can come up with a compensation strategy.
Tyler: Absolutely. I'm just saying there's a spectrum of people all the way from no experience at all and otherwise would be working at
Safeway, all the way through would be making a million dollars a year at Google, and the more you go up the spectrum of their buy-in, their passion and their skills, the more you have to treat them that way if you're going to compete, because these people have lots and lots of options right now. Maybe a year from now if the economy's different that won't be true.
Rick: I agree with you. So, for my situation in which I do not want to give up equity prior to product-market fit when the company actually is real, I have to figure out how to finance this to product-market fit without giving up equity. Which means I immediately can't hire the experienced person here without giving up equity. So that's off the table unless I want to talk about giving up equity. And even then, I've got to figure out how to make it happen for less than 50% to make it work for me and my hypotheses at LegUp Ventures. So, that's one thing. Where I'm going to now is who's my right first employee that I don't have to give equity to, that can run with this with check-ins from me at a, let's call it $40-50K salary, and then supplement them with a more experienced skillset on a fractional basis.
Tyler: Yeah, so what I'm saying is I don't think you can get that person and not be a manager yourself. I think you're shirking your own responsibility by saying "I'm paying them like an entry level employee, but I'm going to give them the level of responsible of the manager and the individual contributor in this important part of the business.” I think you need to be the manager here.
Rick: Sure. So, I guess we're getting into what's the difference between a manager and what I'm saying.
Tyler: You need to own the outcome and tell them what to do, I think.
Rick: Why?
Tyler: Because you're paying them like an entry level employee, and so you're going to get an entry level employee.
Rick: I'm going to totally disagree with you on this. You and I were paid like entry level employees, no one was managing us.
Tyler: We weren't managing other people though. What I'm addressing is when you were saying earlier "I'm going to hire this person who can do this and manage those people in Eastern Europe". I think that's too much to ask.
Rick: Ah. I'm not asking for that.
Tyler: Okay.
Rick: I agree. So, there are two employees in this case. There's one employee and a contractor in this case. Both are going to have some level of outcome ownership, but they both need to be collectively managed as a team by me.
Tyler: Yeah, okay. That sounds good to me. Okay.
Rick: That solves the problem. That solves the problem for you. Okay, good. I actually have my solution I think.
Tyler: Yeah. Well, you mentioned Zane Benefits where we both worked our first jobs out of college.
Rick: We were these two people!
Tyler: Right. And we worked under
Paul Zane Pilzer, a serial entrepreneur. He's done this a million times. What does he do? He goes and finds a bunch of young hungry college students that don't know what the hell they're doing and they figure it out. So, that model seems pretty much like what you should be looking at here.
Rick: The only thing I think that is a little bit different about what Paul did is I want the engineering talent to be more experienced.
Tyler: Why?
Rick: Well, I don't know that I do want the more experience, because today it's a whole nother level. At the time when we were there, when we were going through this, this was all new stuff. SaaS applications were just starting to conquer a lot of different business problems. So there probably wasn't an option to go find someone at the same price of entry level person on a fractional basis in India, or the Philippines, or even in the U.S., that could deliver and avoid some of the learning costs of entry level.
Tyler: Yeah. Let throw something at you that might help bridge this gap. I have not done this before, but I've heard about it on podcasts that I listen to. There are people who are experienced engineers that basically rent out very small amounts of their time to mentor entry level people remotely. So, for example you could say get someone fresh out of college to be your head developer, or CTO, or whatever, and pay $2,000 bucks a month. That would mitigate some of that risk of hiring an entry level person without the cost of getting the experienced person.
Rick: That's a great idea. It's almost like there's an ecosystem here for a bootstrap startup within itself that you have to create to avoid spending a lot of money and get the best of both worlds.
Tyler: Yeah.
Rick: I like it. Both would need mentors, but I can't provide the technical mentorship. On the business/product side, I could provide the mentorship, but I would need a partner on a fractional basis to provide technical mentorship, and that person could be the future CTO, or person that takes over at a later stage.
Tyler: Yeah. Another option here, put that person on your board or whatever and say "For one of your duties, can you mentor this person for me?" Yeah, there's all kinds of things you could do here.
Rick: This is good. I have a much better direction now. Thank you. I know we didn't talk about where to find these people, and we're kind of out of time.
Takeaways
Tyler: Well, let's just summarize. Why don't you go ahead and summarize everything and then we can call it?
Rick: So, there's this thing called CRUD, I can't remember what it stands for.
Tyler: Create, Read, Update, Delete.
Rick: It basically means that what I'm trying to build is an unsophisticated technical problem that high level technical people would scoff at and say that that's not a challenging problem. So a lot of developers would probably say "I'm not interested for that reason alone". Would you agree?
Tyler: Maybe not so much that they wouldn't be interested, but you don't need to copy Google's model and hire the PHDs of the world. Anyone who can code can do this.
Rick: Okay. Yeah, so the skill set requirements are more generalist than specialized. That's a big takeaway for me on the CRUD. Which means the skillsets I need to figure out how to provide early on in the startup is a full stack developer with UI abilities, and hopefully experience. Now, how to make that happen with the constraint of a bootstrap makes it very difficult to go hire that person, especially without giving up a majority of the company, or a significant portion of the company. So, one of my big takeaways is to find that full stack developer, which includes infrastructure, back-end, front-end, UI, and then maybe some visual design that's good enough.I'm going to have to figure out how to piecemeal that early on, and I don't know exactly how I'm going to do that yet, but it's clearly not going to be a co-founder for me. It’s clearly not even one employee. It's a group of people working together to make continuous improvement with some portion of their time. That's my biggest takeaway, honestly. If you're a non-technical founder, it’s hard to bootstrap early product development without giving up equity.
Tyler: Yeah. I think that sounds right, but there's a plan. So, excited to hear how it goes.