Startup to Last

This episode ended up being much more about how to increase workforce diversity than how to hire interns. Here’s a quick rundown: 

• Tyler and his team at Less Annoying CRM want to increase diversity
• They primarily source candidates via their summer internship program
• Tyler and his team have had great success at WashU with this model
• However, this has led to a lack of diversity across his 17 employees (~50% went to WashU)
• Tyler wants more internships to come from schools other than WashU
• Despite effort, Tyler has not been able to replicate the internship funnel at other schools in Missouri
  • E.g. He’s tried recruiting via career fairs, by connecting with professors, and by partnering with student groups
• Tyler pointed out that WashU is successful is due to the numerous former WashU graduate success stories that currently work or formerly worked at Less Annoying CRM
  • I.e. They have product-market fit at WashU for their internship offering
• However, at other schools, they can’t even get students to apply
  • I.e. They don’t know if they have the right internship offering yet
• Rick recommended Tyler focus on customer development to learn more about what the students at these other colleges are looking for
• Tyler realized that creating diversity is really hard, and focusing on small wins initially is key

Takeaways include: 

• Internships provide a safe way to hire because they allow you to work with someone temporarily before you extend a full-time offer
• Summer internships, by their nature, discriminate in favor of privilege
• Private schools have a culture that encourages summer internships; Public schools don’t seem to have this same focus.
• One challenge is that college students, privileged or not, are not very responsive
• When working to increase diversity, focusing on small wins up front is key. Once you get your foot in the door with a new segment, it gets much easier from there.

The problem

Tyler: All right, let's dive into the topic for today. So this one is mine. So basically we're going to talk about how to recruit interns. And I can give a little background on where I'm coming from with this topic. Basically at Less Annoying CRM, so we have 17 employees, but we've hired significantly more than that in total because every summer we have about 10-ish interns, or coding fellows, which coding fellows and interns are about the same thing here. 

Tyler: Basically college students who come for the summer. We've had a lot of success with this. It makes hiring really easy because you get to take risks on people kind of and bring in a bunch of people. And then if someone's really a perfect fit, give them a full-time offer to work here after they graduate. So have had a lot of success with that. Really enjoy it. And I kind of have a system worked out, which maybe one thing we should talk about today is just what's currently working. Like Rick, you went to Duke, I went to WashU. That type of place has an intern culture. Students are planning on applying for these, it's expected. Other universities in the area don't have that culture. And we've struggled to get students interested in it, which is kind of counter intuitive because they're schools where the fact that they're paid internships and it's a really great opportunity. You'd think it'd be even more appealing to someone who's not going to as top tier of a school. But the reality is we really struggle to get anyone from those other schools even to apply. So the results-

Rick: Sorry, what are they doing instead?

Tyler: Yeah, it's a combination of things. Part of it is a lot of these schools, people aren't full-time students as much and so they're not off for the summer in the same way. So that's one challenge. And then the other thing is, I think if you're going to a $60,000 a year private university, probably you come from wealth and probably you kind of have options. And you're like, "I'm going to dabble and try different things and see where my life takes me." If you're going to, for example, the local public university, UMSL, University of Missouri-St. Louis, still a good school. But if you go there probably you're like, "I need a job out of this." And you're majoring in whatever you're majoring in and you're not looking for random other opportunities that aren't specifically in your field.

Rick: Sorry, I interrupted you when you were describing the problem. I'll let you finish that.

A lack of diversity, starting with interns

Tyler: Yeah. Okay. Sorry, I'm rambling here. I'm basically done. But basically we have a model that works for hiring interns at WashU. We don't have a model that works elsewhere and the result of this is our employee base lacks diversity in any number of ways. First of all, there's kind of socioeconomic diversity of only rich kids go to WashU. And then also WashU has its own diversity problems in terms of race, in terms of gender, at least on the technical side. So we're not getting a very diverse applicant pool because of the way we're recruiting interns. So I'm interested in discussing how can we go out and attract interns from other universities that maybe don't have that strong of an intern culture.

Rick: Got it. So diversify your interns?

Tyler: Yes. Exactly.

Rick: The problem is you lack diversity with your interns, you've been trying to increase that, you haven't been able to for a number of different reasons, which we'll probably go into later. I'm very interested in what you're... I think you're right. I think it should start with how you do interns. What the intern period is, what you're paying, what you're offering and what's going well so far with those.

How Less Annoying CRM does internships

Tyler: Cool. Okay. So the history here, so a lot of people probably haven't heard of WashU, but in terms of price and difficulty to get into, it's kind of like a top 15 top 20 university. Lots of rich kids, people with high test scores, right?

Rick: It's the best school that no one knows about.

Tyler: Yeah, it's probably there. It's on par with the Northwestern. Except you've heard of Northwestern and you haven't heard it WashU.

Rick: Exactly. I remember when one of my buddies in high school got into WashU and he was so excited. He was running around. This is a Charlotte private high school. He's running running around the halls going, "I got into WashU, I got in WashU." Everybody's like, "What is WashU? The University of Washington? You're going to go the West Coast?"

Tyler: Or George Washington.

Rick: "What are you talking about?"

Tyler: Yeah, so no one's heard of it, but it's a pretty good school, which comes with all the downsides of good schools. So I did what every first time entrepreneur does, which is the first time I had to hire people, I was like, "I don't know. I'm going to go back to the school I went to. And I already know people there and I'm going to start recruiting." And it was pretty easy. Basically we posted on there, every university has a free job board and any employer can sign up and post there. We went to the career fair. People walk by, we g...

Here’s what you should know about Tyler:

• Grew up in St. Louis, Missouri
• Went to college at Washington University in St. Louis (“Wash U.”)
• Majored in Computer Science
• Became a web developer through side projects and internships
• Played guitar in a heavy metal band called Embers Rise (listen here)
• Left his Masters program early to join a startup called Zane Benefits (which is now part of PeopleKeep) in Park City, Utah  
• Met Rick at Zane Benefits in 2007
• Survived a lay-off with Rick in October 2008 and became head of product
• Worked with Rick to pivot the business model to get to cash flow positive
  • Zane Benefits provided a software-enabled service to small businesses that allowed a company to reimburse its employees for individual health insurance tax-free
• Had no interest at all in entrepreneurship prior to Zane Benefits
• Got frustrated having the responsibility to lead Zane Benefits without the power to make key decisions (i.e. “board decisions”)
• Founded what is now Less Annoying CRM in 2009 with his brother Bracken King
• Less Annoying CRM is a simple customer relationship (CRM) tool for small business people
• Got the idea from working with insurance agents and Salesforce at Zane Benefits
• Less Annoying CRM is 100% self-funded and bootstrapped
  • Launched the product at the beginning of 2010
  • At the beginning of 2011, hit  50 users / $6,000 in annual recurring revenue (ARR)
  • At the beginning of 2012, hit 500 users / $60,000 in ARR
  • As of the recording of this episode, at 22,000 users /  $2.6 million ARR growing at ~20% per year. 
• Wants to run Less Annoying CRM for the rest of his life
• Unique perspectives
  • Fan of bootstrapping
  • Thinks raising venture capital is limiting for a company
  • Thinks more founders should look to run companies for life versus selling

Where were you born?

Tyler: Cool. So, Rick, you are interviewing me today. Where would you like to start?

Rick: I'd like to start at your birth.

Tyler: Ah. Tucson, Arizona is a hot, dry-

Rick: Were you really?

Tyler: Yes.

Rick: Oh, I didn't know that.

Tyler: Yeah. I was there for like a year.

Rick: Yeah. Tell me your personal story.

Tyler: My personal story. So yeah. I grew up in St. Louis, moved there when I was one, and basically, I'll focus specifically on how I got to the startup world, right?

Rick: Mm-hmm (affirmative).

College and major

Tyler: I had no interest in it at all. I think everyone wants to have that, "Oh, I was selling lemonade when I was a kid. I was a hustler." I didn't have anything like that. 

Rick: What year?

Tyler: Well, they forced me to take a computer science class my freshman year just to meet the requirements for electrical engineering. I went to my advisor and I was like, "I promise you I will never code. I hate computers. Don't make me take this class. It's a complete waste of time." My advisor was like, "No, you have to take it." I took it and I just loved it. So I didn't switch freshman year, but that was really the start right away. And then I worked as a student web developer for the business school that summer and then did internships and stuff. I didn't particularly love classes, but I loved the process outside of school, like building personal websites. I was in bands and I made a message board for a heavy metal band, Embers Rise, just fun projects.

Rick: Where can I find a copy or a streaming song of Embers Rise?

Tyler: Embers Rise. I think there's another band called Embers Rise now, so if you Google it, you'll find a band. But it's not mine. My Dropbox is the only place to find recordings.

Rick: I'm going to have to find one of those and publish it on StartupToLast.com.

Tyler: We'll see if that happens or not. But yeah. So I was more of a hobbyist. Even though I was majoring in computer science, I was never good at the academic side of it. But I was kind of a hobbyist, and that's where I really developed a passion for building software.

Working at Startup in 2007

Rick: So what happened after college?

Tyler: This is when I met you, as you know. So I was actually supposed to do a fifth year. I was in a bachelor's/master's program, and during the fifth year, a friend from high school, Tom Elgin, reached out to me and was like, "Hey, I live in this place called Park City, Utah," which I'd never heard of before. It's a ski town in Utah. "And there's this startup here that's like about to go... It's about to explode. It's about to be hugely successful." I actually at the time, because I wasn't good at school... I mean, I wasn't terrible, but I was a B-minus student. I didn't have a lot of confidence in my professional capabilities, and I thought, "This might be the only chance I have in my whole life to just ride other people's coattails success." So I wouldn't say exactly dropped out. I ended up getting my bachelor's because I had finished the requirements for it, but I left school in the middle of the semester, drove to Utah, and started working at this tech startup called Zane Benefits.

Rick: What year is this?

Tyler: This was 2007, which, for people who were around back then, was an interesting year to enter the workforce because for that first year things were pretty normal. You joined at the same time. For the first year at this company, it was a normal venture-backed startup. They just raised... What is it? A series A or a seed or something.

Rick: They call it a series A. Three million dollars.

Leading a startup from 2008 to 2009

Tyler: Yeah. So I was just like an entry-level programmer. I had bosses, and I was just learning the normal corporate world. And then I assume we'll talk about this when I interview you as well, but 2008 hit and global recession and all that. I don't know the whole... You know the whole story a lot better than I do, but basically, 20 out of 25 people or something like that got laid off at the company. Both of us were lucky enough to be survivors of those layoffs. I tell every person we hire, everyone who wants to really know my story on entrepreneurship, this was the defining moment because we showed up the next day to work and there was... Our bosses had been fired, right? The CEO fired himself. So we just showed up and we're like, "Well, I guess we're in charge of the company now." I don't know if... Did we realize that at the time?

Rick: Oh yeah.

Tyler: Yeah. We were just like, "Nobody else here is going to care enough t...

In this episode, we talk about why we started the podcast, who we think our ideal listener is, and how we plan to grow our audience.

After going back and forth, the following framework emerged for marketing a podcast

• Why did we start the podcast?
• Who is our audience and ideal listener?
• What problem are we solving for our audience?
• What makes our podcast unique?
• How will we measure success?
• How will we achieve success?

Takeaways include: 

• Our ideal listener is someone who:
  • Wants to achieve freedom through entrepreneurship
  • Wants to build something sustainable that will last for many years
  • Does things the way they see is the right way to do them
  • Doesn't feel like they have a sufficient peer group for the hard conversations
• Control, freedom, flexibility, and doing things the right way (as we define “right”) are important to our ideal listener
  • Our hosts (Tyler and Rick) share these values
• There is a hole between the venture capital communities and serial entrepreneurs who are flipping companies
  • And that hole is build startups to last with sustainable impact and value creation for customers, employees, and owners
• We think the Startup to Last podcast is unique in the following ways:
  • We have a deep-dive topic each week
  • We do not follow the guest-interview framework
  • Our hosts (Tyler and Rick) have skill sets that cover the whole spectrum in a way that most other podcast hosts don’t
  • We cover the spectrum in terms of company size and maturity
    • Tyler is 10 years into his company while Rick is in the very early stages of his company
  • We are both comfortable with the essence of entrepreneurship: not knowing the answer and being OK with talking about it until we find it
• Startup to Last has achieved basic traction since launching in June 2019:
  • 200+ downloads across multiple platforms:
    • 33% are on Apple
    • 22% are on a web browser
    • 12% are on Spotify
    • The rest are on various other platforms.
  • 11+ subscribers (Thank you)
  • 95% of our downloads and subscribers are from the U.S
    • We've got a couple in Mexico, and then some in Europe
  • From July to August, we doubled the number of downloads month-over-month
• We will measure success going forward by making the following metrics go up:
  • Subscribers
  • Downloads per most recent episode
• We will achieve success by:
  • Talking to our existing listeners
  • Doing customer development with potential listeners
  • Experimenting with various growth channels and tactics
• We think our ideal listeners hang out in the following places:
  • Online bootstrapper communities (e.g. people engaging at Indie Hackers and attendees at MicroConf )
  • Social media sites (e.g. people who follow similar podcasts on Twitter)
  • Q&A sites (e.g. people who are asking / answering related questions on Quora)

Why did we start the podcast?

Tyler: For anyone listening, you haven't been listening for long because this is our ninth episode ever. When we started this podcast, we were planning on just focusing on how do we make the content, so recording it, having a schedule, picking topics, editing, producing, publishing it. All that stuff, and at this point, we feel like we've kind of got it down. I mean, I'm sure we'll get better over time, but we've got a system where we can get podcasts published pretty regularly, so now the next question is, how do we get anyone to actually listen to this, and so we're going to talk about that today. 

Tyler: Keep in mind that neither of us have ever done a podcast before, so this is going to be very speculative and maybe every idea we have here is going to fail, but basically, we need to have this conversation anyway, so let's record it, and maybe people will find it interesting, what we're planning here. So with that said, you're more of a marketing person than me certainly, Rick, but I was thinking one thing we could potentially do is go over some ideas we already have or maybe you could start high-level and just talk about how you think we should even approach getting listeners to a podcast like this?

Rick: I think one challenge that we have, Tyler, is that the reason we created a podcast was pretty selfish. It wasn't with a customer in mind or an audience in mind. For background, we started this podcast because we want to spend more time together. Right? You live in St. Louis. I live in Utah. Well, you came out every other quarter or every few quarters or so. I recently made a trip out to St. Louis. We had a great time, and we both said, "We'd like to spend more time together. How do we do that?" I think both of us were thinking podcast when we said that. Two reasons. One, we want to spend more time together. Two, it's kind of interesting to see if a podcast would work. Neither of us have ever done that. Let's try it. And so we did that, and now it's been, you said, nine episodes, I think?

Tyler: Yeah. We did two or three that we kind of threw out before we started actually publishing them.

Rick: Yup, yup, and so now, what is kind of weird here is we have content that is valuable to us. I'm getting value out of this every week when I talk to you. I think you're getting value out of it. But the content that we've created was made for us. It wasn't made for some market out there of potential listeners that we have a high confidence that will get value out of this.

Tyler: Yes. Although, I listen to a lot of podcasts that are, if anything, even less for an audience than this. I listen to maybe five podcasts where it's two founders talking, and some of them don't even have deep-dive topics like we do. Some of them are just, "Hey, what did you work on this week? What did you work on this week? Okay. Bye," and I think they all have thousands or tens of thousands of listeners.

Rick: In marketing, that's luck. Right?

Tyler: Yes, but there's an audience that wants to listen to founders talking to each other I guess is my point.

Rick: I can't disagree with that. We're coming at this from a product-first standpoint or not even a product-first. We're coming at it from a, "Hey, we want to spend more time together, and then see what happens," which is a little different than, "Hey, there's a problem out there," like a normal business venture or something that you're designing to actually be sustainable and make money. You go, "Hey, there's a problem out here that I know about, or that I heard about, or I've witnessed, or I've felt myself, and there's a market for people who had this problem. I've talked to them, and they're... They don't tell me what the solution is, but based on their symptoms, what's out there currently from a current solution standpoint, what they are looking to achieve, what their ultimate outcome or job-to-be-done is. You go, "Okay. Well, this person is trying to get from A to B. There's a problem getting in the way. I'm going to solve that problem, and then we're going to create a solution for that." We really didn't go through that process. So, we're in our ninth episode. We've got some traction, and we could talk about that, but I don...

In this episode, Tyler helps Rick create a plan to teach himself how to code a web-based application. Rick isn’t sure where to start and asks Tyler for help. Tyler shares best practices he’s learned from teaching more than 15 people how to code from scratch. 

After going back and forth, the following framework emerged for teaching yourself how to code a web-based application:

• Clarify why you want to learn how to code.
• Get a macro understanding of the skills, languages, and technologies you need to know in order to build an application. 
• Pick a simple CRUD (Create Read Update Delete) application to build from scratch (e.g. a blog).
• Set up some basic infrastructure and pick a server-side (or back-end) language (e.g. PHP, Python, Ruby, etc.)
• Start by building a static version of your web application with HTML and CSS
• Then work through the C-R-U-D of CRUD. Create, read, update, delete one at a time.
• Add Javascript to freshen up the UI or UX.
• And add APIs to add third party functionality (e.g. Stripe for billing). 

Takeaways include: 

• Start macro. There's a bird’s-eye view that requires some generalist research to help you visualize the macro components required to build a CRUD app. 
• Picking your server-side technology and languages are going to be one of the hardest things to do. What is your server-side language going to be? How are you going to set up your database? Where will you host your servers? Take some time to get this right.
• Set up a local server on your computer to start. This simplifies the initial infrastructure setup.
• Use GitHub. When you're writing code, get in the habit of checking all your code into GitHub so that it's backed up. This helps with version control and code review.
• Find a mentor. Find someone who will do regular code reviews with you and give you feedback.
• Keep the front-end simple to start.

Why learn to code?

Rick: Now that we've got PandoLabs steady and GroupCurrent on a good trajectory, I'm starting to turn my attention to how I can finance the development of a minimally viable product, specifically in the business-to-business software application space. One of my constraints at LegUp Ventures is I don't want to give up control of the company as I scale it, so I have to be very cautious about giving up equity early in the company because I need to be able to give up equity later without losing control. In our episode about technical co-founders, I realized the person I need is a full stack developer, and basically that's a unicorn that is going to cost me an arm and a leg in terms of cash and/or equity. So I reflected on that. I talked to some people. I talked to you offline. What I came to was I was a computer science major at Duke, so I'm not some person who doesn't know anything about how a web application works. But from what I learned, the Duke computer science program when I was there, we were doing assembly classes. My eyes were glazed over. The best classes were the programming classes where we actually built something that resulted in something that worked. Facebook was just getting started at the time. The whole idea of building a web application and building a business around it was no part of the curriculum.

Tyler: Well, if I can interject for a second, I think a lot of people who didn't major in computer science don't appreciate the fact that most computer science classes, you don't code at all. You write your answers down on a piece of paper and turn it in. You really don't learn much about software engineering, which is a whole different discipline from computer science.

Rick: Exactly. And the reason I majored in computer science was to learn how to code, but I ended up not learning much about how to code. But I learned a lot of theory and I learned the history of the internet, and some valuable things. And plus I can say I majored in computer science and people think that's cool. But I did learn some things about coding through that major. But there's been 12 years, 13 years since I've coded past HTML and CSS. So there's a huge gap between how I think in my head based on what I learned about how building a web application works, and what the truth is today. There's been significant evolution in the no-code space for example, which allows people who have no ability to code to logically and visually design applications. There are also significant infrastructure automation tools that massively reduce the knowledge you have to have about setting up and running servers, and worrying about security, and all these things that you really had to know back in our day, my day, 2007. So I've decided that I need to learn these things and I don't know where to start. So I think there are a couple of approaches. So why do I want to do this? I want to start there. I am terrified of making a mistake hiring someone to do this and wasting a ton of money. I'm also terrified of bringing the wrong co-founder on because I don't know enough about what I truly need. When you say I need to hire a full stack developer, that's good. That's like a unicorn to me and I feel that's very risky. So through this effort, my main goal is to reduce risk. I don't actually expect my myself to actually learn how to code a full application. I do expect to de-risk bringing on support to build the application.

Tyler: If I can add one other reason to do this, I think it'll make you a better executive overseeing future technical hiring. There's no business in the world that doesn't have some technical component to it anymore. And if you want to run businesses, knowing how to code will help you even if you never write a line of code ever again.

Rick: Totally agree.

Tyler: Cool.

Rick: My problem is not necessarily to learn how to build an application. It's to address my fear of really wasting money in early stage product development. Where do I start?

Tyler: Yeah. Well I think it's good that you have that constraint here because for anyone listening to this episode, it's like how to learn how to code is such a broad topic. We need a constraint. And the constraint here is you're not trying to go get a job as a professional developer. If you were, I'd say you'd probably need a much better theoretical background first of all. And second of all, the technology you use would need to be really focused on what's sexy and trendy right now because that's how you get hired. You don't care about any of that. So it's really how do you build an MVP as quickly as possible, ignoring your learning, and the sustainability of the software long term because someone else is going to come along and rebuild it probably.

Rick: Yup, exactly.

Where to start?

Tyler: Okay, so my background here, I majored in computer science at the exact same time you did and got sounds like the exact same education you did. But then became a professional software engineer after that. And I don't code a ton anymore. I probably maybe put in 10 hours a week at this point, but I think I'm relatively up to speed on how things go. My attitude is that it was much, much easier to ship a working software product 10 years ago than it is now. Let me clarify. You can s...

In this episode, Rick helps Tyler think through how to roll out a major product redesign for his 20,000 users. Tyler has a plan, but he’s concerned about losing customers through the transition. His biggest roadblock is figuring out how to roll this out without causing his customers to get angry and leave.

After going back and forth, the following framework emerged for communicating major product changes to existing users:

• Why you are making the product changes in the first place?
• How will you measure success (i.e. the desired outcome)? 
• What are the key messages you need users to understand?
• What proof points (e.g. screenshots, quotes, stats, etc.) can you provide that your key messages are true?
• How can you segment users and prioritize them?
• What mediums should you use to communicate?
• How often and over what time period can you communicate these key messages and proof points to each segment?

Takeaways include: 

• Start with why. Identify why you are doing this. Is it for customer acquisition, customer retention, or something else?
• Recognize that some users will go through change cycles, and help them through it. This starts with clear messaging.
• Don’t surprise your users. Give them plenty of notice and time to get through the change cycle.
• Treat this like a marketing funnel or sales pipeline. It’s a conversion.
• Segment customers by risk and value so you can prioritize outreach. This might be based on revenue, net promoter score (NPS), product usage or a new survey.
• Choose mediums and frequencies that support your annual contract value (ACV). If you are a low-ACV product, you probably can’t afford 1:1 phone calls for every customer. 

The change cycle concept

Source: changecycle.com

What’s the product change?

Tyler: The topic for this week is how to communicate major product changes to your users. This could go any number of directions, but the reason I'm bringing this up is, I've referenced the last few episodes where we're working on this big redesign of Less Annoying CRM. It's both a redesign and two major new features. It’s the biggest update we've had in at least five plus years, if not ever.

Rick: Did you say two new features?

Tyler: Two new features. Yeah, outlook, calendar sync. And we're completely redoing custom fields. Pretty big features, but the thing people will notice most is the redesign. And so I've been kind of thinking, "how do we communicate this to people?" The traditional way to think of this is, "how do you build hype and use it as a marketing event?", which we can talk about. But the theme of the podcast is "how do you build a business to last?" And I think a lot of companies change and eventually it leads to their downfall if they do this wrong. They forget their core audience and all that. They get too excited about the upside. Our audience is not one that loves change. And so most of the communication side that I'm thinking of is not, "how do we market this?", but instead, "how do we reveal this to people in a way that will minimize their likelihood of flipping out and leaving." Basically.

Rick: In other words, a lot of companies might see this as an opportunity to wow users. You don't see that. You see this as a threat to users.

Why you are making the product changes in the first place?

Tyler: I think it's good for them, but if I'm being totally honest, the reason we have to do this, is to keep getting new users. The two new features will be helpful to our existing users. The redesign won't. They already know how it works. It'll look nicer, but that doesn't provide any value to them and they're not going to be excited about the fact that we redesigned.

Rick: Is this true in most cases? When companies do redesigns, is it always usually for new users?

Tyler: Yeah, I think so. I was just kind of thinking of this case, but if your audience is really into design or something like that, maybe they get excited about it. But for the most part, if you think of software as a tool, which CRM software certainly is. I think most B2B software is a tool. Once you know how the tool works, I can't imagine much benefit to saying, "okay, now you have to learn a new way for it to work."

Rick: If it works currently?

Tyler: Yeah. Yeah, true.

Rick: Got it. Yeah. Okay. Man, I guess, if the redesign is valuable to new users, there's got to be some benefit to switching to the new design for old users.

Tyler: Yes. And so a couple things on that. First of all, this is one reason why we're bundling it with two new features. We've done this throughout our history. You know how anytime Facebook changes anything? Everyone on Facebook's like, "oh, I hate it, I'm quitting." And then they forget about it a couple of weeks later. One way we try to minimize that reaction is saying, "there's an actual new feature for you here that you care about." And probably it doesn't have to come with the redesign, but to a user, it seems like they're a package deal.

Rick: Yeah. I'm also realizing that your users are probably highly sensitive to this because this is a CRM product. They use it every minute of every hour of every workday.

Tyler: And there's also a history here, which is a lot of our users are older, 40 plus years old and they've been through multiple cycles of CRM companies screwing them over. And so part of this is a lot of them, their natural reaction is, "oh, you're getting ready for an acquisition. You're getting ready to raise prices." They see the writing on the wall anytime anything changes. So I have to kind of reassure them like, "no, no, no. We hadn't redesigned the software in seven years. We need a new design here."

Rick: I think we should dive into why you're doing this. Just because you need to do it for seven years doesn't resonate with me. It probably won't resonate with your users. So why do a redesign? Let's actually exclude the two new features from this conversation.

Tyler: Yeah, I agree.

Rick: Why are you prioritizing a redesign and what does it mean for the company?

Tyler: Okay. Let's break this into two categorie...

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...

What’s an employee handbook?

Tyler: The topic this week is employee handbooks. This has been on my mind because we redid our whole employee handbook this last spring leading up to hiring some new people. So I rewrote it and put a lot of thought into it, but I wanted to talk through it with you. I'd like to cover things like what should actually go into it. And one thing that I hadn't thought of prior to now is when and how should the information in an employee handbook be communicated. What we used to do is everybody would start working here, and then we'd give them the employee handbook and say, "read this." And more and more, I'm realizing a lot of this information might be relevant earlier in the [hiring] process. I'm interested in your thoughts on how this should work. 

Rick: Yeah. When I hear employee handbook. I associate it with zero value to employees and 100 percent cover your ass (CYA) for the company. I don't think that's what you're talking about here. So what do you mean by employee handbook?

Tyler: Fair enough. Maybe there's a different term for this that at the end of this podcast we will have figured out. What I mean is that, over the years, we have amassed a lot of institutional knowledge on how we do things and our philosophy on things. Plus, there are a lot of policies and stuff like that. I've actually recently split it up into three things. One is company philosophy. One is information about how compensation and benefits work. And the third one is all of the various policies like: You want to take a vacation day? Here's how you do it. You want to use the nap room? Here's how you book it. That type of stuff.

Rick: And where does the CYA, or cover your ass stuff, fit in?

Tyler: We probably do that less than a lot of companies would. We do have random stuff people sign when they start like, "acknowledge that we're providing all of the benefits required by law" and stuff like that. So I think we're covering our ass to some extent, but probably not as much as some companies do. 

Rick: So let's call that a fourth bucket, which is different than unique policies to the company. So, one is philosophy. Second is compensation and benefits. Third, policies. And fourth, CYA. 

Tyler: I'm least interested in CYA because some lawyer writes that up, and no one reads it and no one cares. I'm probably more interested in the other three. What's the right information to include? And the thing that has really been on my mind is, "when?"  Should this information be made 100 percent public and used as a marketing tool for recruiting?

Rick: I 100 percent think so. Yes. I'll give you my experience with employee handbooks. I'm unique in that, at my last company, I was there for twelve years. I've never experienced another employer, but we went through lots of iterations of the company as you well know. At first, I was the 13th employee of the company. Then, I was one of 35 employees. Then, we went down to four people. You, of course, were one of those four people. Then, we went up to 60 something 70 employees. Then we went back down to 35. Then, we were down to 20. Now, I don't even know how many people are there. And every time there was a big switch, someone at the board would say, "we need a new employee handbook." It wasn't until probably three years ago that I really took ownership of what an employee handbook was. Before that, and I think this is what most people think, I believed employee handbooks were CYA material. My experience as an employee getting an employee handbook was: "This is unhelpful. I can't understand the language. This seems like something that you're trying to screw me with."

Tyler: Yeah. When you say CYA, it's so employees can't sue you and [claim] you didn't provide some piece of information. You'll be like, "look you signed this thing that said we gave you this document."

Rick: So, over the years we had different versions of this. One was there from before I got there. Then, you know, the board was like, "we have to have an employee handbook". I was like, "why?" And they were like, "because we have to cover our asses," you know. And, I said, "OK". So we hired some third party to come in and build an employee handbook that provided no value because they had no idea about our business. So it was, again, all these new rules that I didn't even really care about honestly. It created more problems. Every time we rolled out an employee handbook, it created more problems than it solved. The last time I let someone else do this was probably four or five years ago where we had a really really smart senior vice president who knew that employee books were important.  So, she brought a third party in. I was uninvolved in the building of the handbook because I didn't care about it. I didn't think it was a priority, but I was listening to the person who was more experienced and smarter. And she was right. But, I think that an employee handbook that doesn't have your imprint on it [as the CEO] could be a really bad thing because it can send the wrong message. But the point here is that when that handbook came out, I saw it I was like, "holy crap this could provide so much value because it did touch on the philosophy stuff and it did touch on the things that employees needed to know to be successful at the company. So, I actually wrote my own handbook after that. And now the employee handbook, to me, is the most important tool of a CEO to communicate to their employees consistently and clearly. 

Tyler: OK. So at the beginning of this you said, "you think it's a CYA tool." You used the term employee handbook and just kind of redefined what that means to you and then thought of it as a really high priority for you. 

Rick: Absolutely. It went from a high company value tool with low value to employees to a very high employee value and high company value tool. 

Tyler: Once you decided to take ownership of it and decided this is going to be really valuable for employees, what did you put in there and did you get any feedback on it? 

Rick: I don't know how helpful my iterations are gonna be because I would say I learned more about what not to do than what to do. 

Tyler: I think those are the most valuable lessons. 

Rick: Well, I think you've done this well for a long time. When I started thinking about this, and I don't know if you remember this, but I said, "hey Tyler, can you send me your employee handbook?" Do you remember sending that to me? 

Tyler: Yeah. 

Rick: [Your handbook] was actually really useful. Once I realized this employee handbook thing was a good thing and not a bad thing for employees, there were a couple of companies that I looked at it [as examples]. I looked at yours. I looked at Basecamp’s [employee handbook], who shares it publicly. 

Tyler: Yeah, there's is on GitHub, and you can just read the whole thing.

Rick: So I looked at [Basecamp's] and I thought theirs was good, but it was a little bit different than the culture I wanted to build. And then I looked at yours, and I thought yours was really useful it. It was in a Google Doc. It was twent...

Tyler: In this episode, we're gonna talk about the pros and cons of remote work, such as when does it make sense for a company to have employees altogether in an office versus fully remote or something in between.

Rick: I personally get this all of the time. I've heard of four core models that . One is “single site” which means everyone works in the same office environment. Second, is “multi-site” where you have multiple locations with everyone working within the office. And then the third is “satellite”, in which most of the team is together, but a few people are remote. In other words, it's more of a hybrid model. And then at the complete other end of the spectrum is “remote-first” meaning everyone works from a separate location by default and then comes together when necessary to meet in-person. Does that cover the gamut of options in your opinion? 

Tyler: Yeah. It's kind of a sliding scale so everything in between is fair game. But, yeah. More and more, I think people work at a company with lots of people, but they work remotely or they work in coworking spaces or whatever. So the world is trying to figure out what makes sense for which companies here.

Rick: In my most recent consulting project, I'm working remotely. It's the first time I've actually worked remotely for a company before. So, that was an interesting experience. I'm interested in what your experiences are with this. Do you feel like there's a right way to do this?

“There's not a one-size-fits-all, right solution”

Tyler: 100 percent, no. There's not a one-size-fits-all, right solution. I see a lot of arguments in favor of remote, but my experience is that, in practice, doing remote has a lot of challenges that I think get glossed over when people talk about it. So, I think there's there's pros and cons to both. Philosophically, I want remote to be the answer. But, in practice, I haven't seen that to be true so far. 

Rick: Before we go into pros and cons, tell me why you want remote to be the future. 

“Talent is global… if you limit yourself to a specific location, you’re limiting the talent pool”

Tyler: Just to name a few people [and companies] who are advocates. Basecamp is remote-first. Doist is remote-first. If you follow the founders on Twitter, they talk about this a lot. I buy the argument that talent is global. It's spread out all over the place, and your company should be trying to hire the best people possible. And if you limit yourself to a specific location, you’re limiting the talent pool. The other [argument] is that we are all adults. There’s something that seems almost like an industrial-age assembly line about having everyone commute to the same place and sit in desks next to each other in order to get work done. The internet is a thing. It doesn't seem like we should need to be next to each other. So that's why I feel like it should work. 

Rick: So one [argument] is that [remote-first] allows you to attract a better breadth of talent from different locations. More diversity and people that you would never even think of hiring at a co-located place. And then on the second argument, I understand that you don't like the industrial nine-to-five feel of an office. But, what is it that you would replace it with?

Tyler: Well I like the idea of if you get your work done, as the boss, it’s not my business how it happens. Historically, I feel like too many employers felt like they owned their employees. I mean historically they actually did and that was obviously terrible. 

Rick: Are you talking about slavery?

Tyler: Yes. We haven't broken out of that fully, we're still, I think-- plutocrats exert way too much control over the people who work for them.

Rick: Wait, what's a plutocrat?

A plutocrat is a person whose power derives from their wealth.

Tyler: Rich people who run the world, basically.

Rick: Are you a plutocrat?

Tyler: I'm working on it. [laughs]

Rick: All right. Sorry. Keep going.

Tyler: Basically, like what you and I are doing right now. You're in Utah. I'm in Missouri. This is fine. We're both adults. We're getting this thing done. Should I have to fly to you every week in order to record a podcast? Of course not. Why does everyone have to drive to the same office to get work done?

Employees gain autonomy and flexibility from remote work

Rick: There's a lot of benefits [to co-location] that we'll go through later, but what I'm trying to get to is what is it that you gain from [remote-first] as an employee?

Tyler: I think it's autonomy. You get to decide where you live, you get to decide, "Do I want a standing desk? What kind of chair do I want?" You just have total control of your work environment. 

Rick: Flexibility. Employee flexibility. Got it. Yes, it's the ultimate flexibility. Get the job done, work when you need to. I don't think that always applies. For some roles, you will need to be available whether you're remote or co-located at a certain time.

Tyler: Yes, there is time flexibility, but that's maybe orthogonal to environment flexibility.

Rick: You're killing me with these words. What's orthogonal?

In statistics, orthogonal means statistically independent

Tyler: Perpendicular. It's like an unrelated thing.

Rick: They cross over each other?

Tyler: Yes, it's just that they're pointing in different directions. These are two points. Your time flexibility is almost completely independent of your location flexibility. Support needs to be on at a certain time, they don't necessarily need to be in the office to do their job.

Rick: Location flexibility is really what you're arguing for here?

Tyler: Yes.

Rick: I like it. There's also work environment flexibility, which gives the employee choice on the desks and stuff. I get it. What's stopping us, in your opinion, from getting to where everyone's working remote?

“It's very, very lonely to work remotely”

Tyler: My company is not remote for the most part. We have a little bit of a hybrid model, but we’re mostly not remote. Obviously, despite my philosophical agreement with it, I think there are some real practical problems. I can just rattle off a few. One is, it's very, very lonely to work remotely, especially if that means you're working from home. Remote can also mean going to a co-working space and being around people, but those aren't the people you're working with, so I think there's still an opportunity for loneliness there. I don't know if you've ever done that type of thing.

Rick: I am a little bit different in this regard. I actually like to be by myself, so I can't relate to this. In fact, when I see ...

The role of a small business or startup CEO

Tyler: In this episode, we're going to talk about what the role of a CEO should be at a small business or a startup. I always hesitate to call myself a CEO, depending on who I'm talking to because it seems a little pretentious. I run a 17-person company and some days, I don't do any CEO stuff: I just write code or design something. And some days I'm in meetings and brainstorming long term product vision and I feel more like a CEO. I'm a little unclear on when's the right time for a founder, especially a bootstrapped founder, where you're not representing shareholders or anything like that, when's the right time for them to let go of the individual contributor role and just really embrace, “my role is to be the boss of the company” and all the actual work that gets done is getting done by other people?

Rick: I don't know exactly where to start with this. I'm very interested in the subject too. My immediate reaction is, I don't think that this is written in stone. It seems very circumstantial and honestly, subject to what the person has decided what their role is going to be, how they're going to play the CEO role, how they're going to spend their time. I guess, you keep saying CEO role. Maybe we can start with, what is uniquely the CEO role at all stages of companies?

Tyler: Yeah and you probably know this better than me because I think you've experienced different stages. What I have seen myself is, there's individual contributor work. If you come from sales, go to sales. If you're a marketer, do marketing. There's management, which I feel like I've stepped into. We're big enough at this point where it's, “okay, there's a programmer who needs a manager.” We don't have a manager for that person, so I'm their manager. There's a manager of managers, where I've got someone who manages the customer service team but someone needs to talk to him and then I guess there's other stuff, right? Do you agree with those three categories at least? Those kind of evolutionary steps as a business grows?

Rick: I would say that that's the different types of management but not necessarily… I know CEOs who have one report.

Tyler: Yeah, absolutely. I kind of think of all three of those as not fully CEO work but I'm not sure what ... There's some fourth category which is CEO work. What do you think that is?

Rick: I guess I would look at it a different way. I wouldn't look at it as, primarily a ... I wouldn't look at it from a people management standpoint, I would say there are three ... I'm going to butcher this but someone told me this once and I'll try to remember it as best I can. The role of the CEO is three or four things. The first is making sure that there's enough money in the bank. The second is making sure everyone is aligned on what the priorities are for the company. The third is building a cohesive team to ... and whatever that means retaining, training, managing, recruiting…

Tyler: Just making sure it happens.

Rick: … making sure you have the right people and I can't remember the fourth.

Tyler: Yeah and I actually think I coincidentally saw someone retweet this today.

Rick: I kind of look at a CEO's role as, either those three things are happening or they're not and if they're happening, the CEOs doing a good job, right? If you've got enough money in the bank, everyone is clear on what the priorities are, the team is cohesive and you've got a solid pipeline of talent to fill future needs, then the CEO is probably doing a pretty darn good job. How much time is it taking him to do that?

Tyler: Right, maybe none-

Rick: Maybe none.

Tyler: -depending on the company.

Rick: And if there's free time, maybe there's some opportunities to dabble as an individual contributor. If it's taking all of your time to do those three things, maybe some of those things you're doing as an individual contributor.

Tyler: Yeah, I can relate to the second one, having a vision or whatever. At Less Annoying CRM, we don't have a strategy aside from the product. The whole company is about execution and then the strategy is, where is the product going? And that's my individual contributor work. Product design. So I think that's an example of what you're saying.

Rick: Yup, yup and so it sounds like you do a lot of individual contributions on setting, what are the priorities for the company? And that's great. 

Tyler: And I love that stuff.

Rick: And I guess stepping back, when you say individual ... I'm interested in why you brought this up, number one, is this something that's bothering you? And two, what do you mean by individual contribution? I understand now what you mean by CEO role but what crosses into individual contributor work versus non individual contributor work?

Tyler: Yeah, so I wouldn't say this is something I'm worried about or that I have a problem or anything but what I notice in myself is, from time to time, I enjoy having periods where I'm meeting with a lot of people and having high level brainstorming and stuff like that but I really really love it when I have a day or ... I never have a full week but a good chunk of the week where I'm just not talking to anybody, on my computer, either designing or programming. When I say individual contributor work, I guess what I mean is, I'm not managing or leveraging other people's work but instead I'm saying, "The work I'm doing is directly moving the company where it's going, rather than setting a vision that other people are going to follow."

Rick: Would you consider that, setting the vision, individual contributor work?

Tyler: Yeah, I mean I guess it's on the border. It's half and half but so for me, I'm doing the design because I think it's cool. Oh, I really want to design this, versus, I can't wait for the rest of the team to follow this grand vision, you know?

Rick: It sounds like, if we agree that the role of the CEO is to do those three things, make sure there's enough money in the bank, set the vision, make sure the priorities are clear, create clarity and then build the team, then anything outside of that, that is done as an individual contributor, on your own, would be what you're talking about.

Tyler: Right, so writing code is definitely individual contributor work.

Rick: Yeah, okay.

Tyler: Design is ... If it's like, we need this feature and I'm designing it, that's IC work. If it's what is the-

Rick: IC?

Tyler: Individual contributor.

Rick: Is this the new lingo? Is this an acronym?

Tyler: I don't know. That's how they write it on the Twitters.

Rick: The Twitters?

Tyler: Yeah but if I'm designing some future project that maybe we will or won't do but it's a strategic thing, then that's probably CEO work. Okay, I buy that distinction.

Rick: Okay. What types of individual contributor work do y...