SEASON 2 - EPISODE 145 - MARCH 12, 2025

Roles at the company, staying involved as a founder & other listener questions

Jason Fried and David Heinemeier Hansson answer listener questions in this episode of The REWORK Podcast. They discuss the roles 37signals hires for (and the ones they don’t), the importance of staying accessible as a founder, and the thought process behind choosing a business structure.

Watch the full video episode on YouTube

Key Takeaways

00:16 - Employee roles at 37signals
04:33 - How non-programmers contribute to programming
16:44 - Techniques for writing job descriptions
18:47 - Tips for being an accessible founder
25:22 - Deciding on a business structure

Links & Resources

Transcript

Kimberly (00:00): Welcome to REWORK, a podcast by 37signals about the better way to work and run your business. I’m Kimberly Rhodes, joined by the co-founders of 37signals, Jason Fried and David Heinemeier Hansson. This week we are going to knock out some listener questions that we’ve gotten over the last couple of months, so I’m going to start with an email from Mariana who says, “I’m interested to know what are all the non programming roles inside 37signals. Like what are some roles that common companies have that you don’t and how do you manage to survive without them?” So this is kind of like a two part, what roles do we have and also what roles do we not have?

Jason (00:36): Well, I’ll start with the things we don’t have that you would notice probably if you were working somewhere else. So we don’t have any dedicated managers who just do management work, so we don’t have project managers, which would probably be a surprise to many people, especially since we make project management software. But the software we make is made so people can run their own projects. So it doesn’t require project managers necessarily. We do have people who oversee things at a high level, but there’s not a project manager dedicated to each project, for example. There’s no middle management. We’ve tried some of these things in the past. We’ve had some of these positions in the past, but we don’t have any right now. So I think that would be probably what you mostly would notice that everybody here is actually doing the thing that they’re hired to do and there’s not this extra layer. You would also not see a lot of meetings, which of course are not roles, but they in many ways sort of are roles in most companies. We don’t have a lot of those hanging around. We don’t have a data scientist or a data person. We have in the past, we don’t now. Actually, we have a head of finance who does some of that work, so he’s able to do a few different things versus just have someone dedicated to that role.

(01:42): I was going to say we don’t have a recruiter, but we kind of do, although not really because we don’t hire that much anymore. She’s moved over into more people ops stuff.

Kimberly (01:50): One of the ones I was going to say that we don’t have that I think people might be surprised, I know you guys have talked about a lot, but we don’t have any sales people. There’s not a sales team.

Jason (01:58): Right, of course. Yeah, I forgot about that. We don’t have sales. We do have one person who runs marketing, but we don’t have any sales at all. Our products are self-service, self-purchase, self cancel, all that stuff. Customer service sort of functions to some degree as a pre-sales, pre-purchase group that can help people through with questions or give demos, that sort of thing. But we don’t have dedicated people who are selling. There’s no commission. Our pricing isn’t really set up in a way where it would even make sense to have salespeople here. So that’s true. We don’t have those either.

David (02:33): We also don’t have any in-house legal. We don’t have any lawyers on staff. We also tried one of those roles at one point and

(02:41): Realized we just didn’t have enough of that work to make sense. We also no longer have any other executives besides Jason or I. That’s also something we experimented with in the past with a COO role. We don’t have that anymore. There’s no business development. That’s another common role at companies. We don’t do any of that. We don’t do a bunch of deals with other companies about things. I am always like business development. What exactly is that again? I keep encountering companies who have these and I can’t necessarily always recognize it. Of course, there’s always work for everyone to do, and this is the same thing we found when we hired in these roles we no longer have. It’s not that these people would sit around twiddling their thumbs. In fact, a lot of the times that’s the problem. The problem is when you don’t have 40 hours a week of legal work, that person who’s in that role is going to find a way to conjure up 40 hours of work and what occasionally happens, what sometimes happens, what kind of was happening a little bit at our company as well was that you then start pursuing things that not only do they not add value, if it was just spinning your wheels, you would go like, okay, whatever.

(03:56): It’s a hobby. No, no, no. The problem is, and this is true of middle management in particular as well, that these roles end up pulling everyone else in. So all the people who were busy doing their normal job are suddenly pulled into projects that a middle manager or a lawyer or a business development person or any of these other roles that we don’t have, they require someone to actually do the thing. And I think this is where we certainly realized and learned by not having these roles, you actually make the rest of the company more capable.

Kimberly (04:33): Let’s go back to the first part of Mariana’s question because she’s asking what non programmer roles we have and when she sent this in, I thought it was interesting because there’s a lot of people who are not programmers who…

Jason (04:44): Most people are not programmers.

Kimberly (04:46): …who also are taking some of that programming tasks. Our designers are also coding. I’ve done a GitHub pull request or two, never thought in a million years that I do that. So I think there is something about everyone kind of being involved that we do that I think probably a lot of other companies don’t do.

Jason (05:06): We’re currently hiring a product designer, web app product designer, and one of the things that people reach out to me about, they’re sort of incredulous about this. They’re like, wait, what do you mean designers write their own HTML? They kind of, sort of dabble. They can fix some things, right? I’m like, no, no. They write all of their own HTML and CSS and a little bit of JavaScript and some of them get in there and do some Rails work and it shocks people and they’re like, well, that’s actually called a design engineer role. It’s called the designer. And it blows me away because 20 years ago, this is what all designers did. Web designers design stuff and did the HTML and CSS. And to think that we’ve gone backwards, we’ve actually gone backwards that fewer people can do that nowadays and that there needs to be new roles that are spun up to handle that part of it.

(05:55): It’s very odd to go backwards, especially in such a short period of time. I can understand how we have fewer, let’s say, blacksmiths around who know how to work with iron and whatever perhaps, but in 20 years, in some ways the skills have atrophied and people are less able to build things that they built 20 years ago. So don’t give me the shit that it can’t be done. Of course it can be done. It has been done in very recent memory. It’s been done and it’s done better when the same person can do the whole thing. So yeah, in some ways don’t have roles by process of elimination and then other people, like David said, get better and they’re more capable and then we can move faster and do more things with fewer people because of that. But other roles, obviously Kimberly, you’re an example. Chad does video, Mark’s on marketing. We have two people in People Ops and not everyone else, we have a number of designers, so you wouldn’t consider to be programmers, but they do their front end work and customer service of course, which is still I think the biggest group in the company. Maybe it depends. Programmers might actually have the edge there now if we count everyone in Ops and SIP as well. But yeah.

Kimberly (07:04): Jason, do you think that it’s changed with designers who used to do more programming than they are now because tools have changed, because now there is a Figma that you just make it pretty and then someone else codes it.

Jason (07:17): But that’s always sort of been the case. Before it was Figma, it was Photoshop and before that people would use Illustrator way back. There’s always been a tool to make visual designs and these can be useful tools, but I do think people have just stopped there and they’ve start handing it over the wall to someone else now to implement. And also I think mobile development is different obviously, and so that’s a little bit different. More people are being brought up on that now and that’s sort of a place where designers do tend to do less of that work for implementation, let’s just say. So that’s true, but I dunno, I think it’s a proliferation. I think what ends up happening is that large companies typically have many, many people doing many different things, many different specialized roles and maybe in those cases it makes more sense for whatever reason, and then small companies look to these big companies and go, how should we structure our teams?

(08:05): What we should structure our teams like the way Facebook does it? Well, Facebook might do it their way because it makes sense at that scale, but it doesn’t make sense if you have four designers to have four designers who can’t implement their designs and have to hire three more people who can just do that part of it and then hire programmers to do the backend before you know it, you’ve got this big team that’s expensive and then you have to go raise money, you got to have more salaries. It’s like you should be looking for people who can do more of the work themselves, I think is sort of ultimately the key and maybe it’s harder to find those people these days. I mean it probably is, but the nice thing is you just don’t need that many of them.

David (08:40): I think another thing that’s key about this is there’s a fundamental satisfaction that comes out of a job that you can do almost entirely by yourself or with maybe one other person. Our standard team size for building new features in any of our applications, new or existing is two people. One designer, one programmer, that’s it. That team of just two people can take an idea all the way from pitch to we’re shipping it, we’re following up on it, it’s live, it’s in production. There’s not necessarily anyone else involved and I think there’s a huge degree of job satisfaction. You get so much closer to the work when you have essentially two people being able to take something from concept to deploy. In a lot of companies there are just so many phases. You have to go through so many things where it has to get handed over from one to another.

(09:35): So much larger teams, there’s just an inherent alienation from the work when you’re doing this little subpar… This was the problem with mass production back in the day where we were replacing artisans who someone would put together a whole saddle and they would do the sewing and they’d do the lines, they’d do all the things that they go from nothing to, I made a saddle and then we got mass production and yeah, I bolted in this one screw on the side of a model T. It’s a little abstract to take that work and go like I’m responsible for the model T. You have to do many more steps in your head to justify the kind of work that you’re doing amounts to something that it’s real of any kind. I mean we’ve talked about this idea of bullshit jobs many times in the past, and those certainly sneak in when there are more moving parts in the process.

(10:24): The process gets longer, it has more layers, it has more sub-specializations that Jason said. It’s not just a designer, it’s a front end design system engineer that’s drilled it down five different ways and then you end up with all these people like that’s what I do. So that’s the function I provide. Whereas when you have more generalists, those generalists can decide, well, we don’t do design system in general, but let’s just imagine that we’re doing some of that you needed, let’s say to develop something on your design system for two weeks and then you needed nothing more on it for the next six months. That’s possible when you’re dealing with generalists. It’s even the same thing for Jason or I. So we don’t have a in-house lawyer anymore, which means that a lot of the things that at least if they’re contentious in the legal department, they flow to Jason I and do you know how much easier it is for us to say, fuck it, let’s not do anything about it?

(11:23): When it’s Jason or I just dealing with it, it is much easier because we have so many other things we could be spending our time on. So it gets weighed in that equation. It gets weighed against like, well, I could spend my time on this issue with sort of dicey outcomes or I could spend some time on product development. What would I like rather do what’s more beneficial to the company versus if you have a full-time lawyer on staff, of course they’re going to dive into this and maybe they’re going to aggravate the situation and they’re going to escalate and now we’re in court and what? What happened?

Jason (11:55): I’ll give you another real concrete example. We’re spending a lot of time on this question, but it’s a good one. So over the last two days, Jason Zimdars is one of our designers and I got together in person, which we don’t do very often, and sat down and worked out some new design ideas for this new product we’re working on. And in an afternoon and a morning, we were able to really riff fast on a variety of different things and get those designs into production with real data so we could look at these designs for real and tweak things for real without having to say we’re going to do these designs and then he’s going to go back, then we’re going to hand them off to someone else and then the feedback loop is going to be too slow because it’ll take two or three days to implement that and then every little change we want to make, we have to send back over the wall.

(12:44): It’s like, it’s so nice when Jason can sit there and—the other Jason, I’m not talking to myself here, that’d be weird—and we can get in the HTML and the CSS and tweak things and play with things and play with the data and move things around and see things in real time this way. You have so much more leverage when you can do that, and we made progress in about six total hours of work that probably would’ve taken another team a few more days because they’d have to go back and forth and the feedback loop just gets slower and slower and slower and slower, almost as if you’re working across different time zones, even though people might be next to you but they’re doing something else so they can’t implement your change right now. It’s just very slow way to work. So anyway, I think it’s really a good idea to ultimately slim down the different roles you have and allow people to expand their abilities and cover more ground individually.

Kimberly (13:32): Okay, one more follow-up question on Mariana’s, I know we say we hire when it hurts. Are there any roles that you guys are sometime in the future we should add this? I mean I know my role, Chad’s role are roles that didn’t exist until you added them. Are there things that have kind of bubbled up for you guys about things that we either need or might want to implement soon?

Jason (13:54): Well, I’d say they’re not imaginary, so there are things like you don’t really necessarily feel the pain perhaps, but you want to do something you haven’t done before and you need someone to do that work. Like with you and Chad for example. It wasn’t this pressing, pressing, pressing thing, but we really wanted to do it and we didn’t have anyone to do it and we wanted people to be dedicated to do it so they could do it well. So that was a little bit of a, you might say like a splurge and I’m super glad we did that. Right?

Kimberly (14:22): Thanks for the splurge.

Jason (14:23): Well, right, I mean I meant that in the most positive possible way. It wasn’t like we cannot ship this product and we’re stuck and we desperately need someone to come finish this. It was more of a speculative situation, but one that wasn’t imaginary. We had work lined up for you guys to do and we wanted you to do certain kinds of work and now we have a lot of that work that was done and is still being done.

Kimberly (14:47): Is there anything that’s coming up now that you’re like, Ooh, this is something new coming up for us? The answer could be no. I just was curious.

Jason (14:56): Nothing on my end, I dunno, David, any thoughts technically there?

David (15:00): No. We brought someone on in a contractor role recently to deal with some JavaScript work that we didn’t have anyone dedicated to do. Not that the programs we already have couldn’t do that, but there was a bit of, it hurts. We’ve had some issues. We’ve wanted to move our editors forward, both the new House markdown editor that we use in write book and also our tricks editor. So we were like, you know what? This has been irking us for quite some time now. Can we do something here? Let’s start with a contractor. So that’s an example actually of hiring when it hurts. I think that applies quite specifically there, but I will say we have done more of that in the past. Some of those examples we talked about with the legal stuff or with the middle management stuff, some of that was speculative and anticipatory.

(15:48): We were thinking if we get a little bigger, if we go somewhere here, if we do these other things, we should have these capacities by the time we arrived there. And I will say that that didn’t pan out very well. It was speculative and it was anticipatory in a way where unlike these roles we just talked about with you and Chad where there were concrete tasks, there were concrete videos, there were concrete onboarding flows that we wanted to revisit, this was a lot more fuzzy. This is like, I guess if we’re more people, we have someone maybe kind of overseeing something very fuzzy. And I think that’s what higher, when it hurts encapsulates. It shouldn’t be fuzzy. You should be able to spell out here’s 10 things this person will do in their first month. Very concrete points and the points aren’t like, oh, that’d be nice to have.

(16:40): They’re like, oh man, we’ve got to have this. We must have this. And it’s funny because that’s actually how we write our job openings now. Our job openings will spell out, I think the latest one you had, Jason also had like 5, 6, 7, 8 things where you went, here are specific projects that someone in this role could have been working on in the last month, and I think that’s a wonderful clarifying function. And it’s something actually I wish that more companies would copy. Jason, you just posted this new opening for the designer and I always think, why aren’t more people writing the job postings like this? Maybe they don’t want to be as blunt as we are in some of the introduction to the role. You go very explicit about we’re not hiring a decorator, we’re hiring a designer, but the part about thinking through what’s this person going to do, not fuzzily in a year but concretely on month one I think is incredibly clarifying.

Jason (17:38): Well, part of that of course is because the people who typically write the job ads aren’t the ones who are in that role.

David (17:45): Yes.

Jason (17:45): So an HR department might write the job ad and they can generalize in terms of hitting certain targets on experience or skills or whatever, but they may not be up to speed on the things specifically that that person would’ve done a month ago. Now they could ask though, but I agree job ads are some of the most poorly written descriptions of things that people really desperately want to fill and fit. It’s an odd mismatch.

Kimberly (18:10): I also think, and I’ll link to this job posting, which is open through March 24th, but I think it’s interesting how it’s written is really how we write and Jason, how you write for the website. It is in paragraph form. It’s not just a long laundry list of bullet points, which is what most job descriptions are.

Jason (18:27): I mean there’s a little bit of information on some things you should be able to do, but we don’t have a bullet list of tools you need to know how to use and how many years of experience you must have in those tools and that whole traditional structured job ad, which is just silly.

Kimberly (18:44): Okay, we’re going to move on. Thank you Mariana for that question. The next is a voicemail that came from Jackson.

Jackson (18:50): Hey, just want to say great job. I’m just wondering how are you guys able to stay so involved with the community being that you guys are running a company that size? I’m just curious to how you guys are so accessible and how you guys are able to do so much.

Kimberly (19:16): When he says community, I don’t think he means our Basecamp community. I think he just means community at large, but you guys are very accessible. You answer your own emails. How are you able to do all of that?

Jason (19:27): I’m surprised when people can’t do all of that. I’m like, what are you doing that you don’t have some time to get back to people?

Kimberly (19:34): They’re in meetings all day.

Jason (19:35): I do have a backlog of emails. I do need to get back to more people. I’ve got about 20 or 30 I need to deal with that I haven’t dealt with. But chiming in, you put something on Twitter or LinkedIn and you chime in, you comment. It just takes moments. The reason I have 20 or 30 emails to deal with is because they’re all long. I feel bad with a short response even though maybe I shouldn’t, it’s not my problem that someone wrote a super long email, but those are the ones that I always have a hard time getting back to. There’s a lot of questions in here. I got to figure out what to answer or whatever, but mostly it shouldn’t take much time. It’s also part of my job. That is my job, isn’t it? What else am I supposed to be doing? I’m doing the other work, but I should be connecting with our customers and people in the industry and people who might be our customers. I mean ultimately David and I are the sales team in a sense. That is the job. And I feel like to hide from that responsibility behind, I don’t have time for that is a dereliction of duty in a lot of ways in my opinion. I think you ought to be doing more and more of that and I’d give up other things before I would give that up.

David (20:42): I couldn’t agree more. This is part of the job. Jason and I are the face of the company to a lot of people and that’s not sort of a burden. That’s a blessing. That’s a wonderful thing that we can have that direct connection, that someone, a random person on Twitter, I will admit that occasion I do get pulled in a little too much on some topics of discussion that perhaps I should not let myself get pulled into, but broadly speaking, I think it’s actually a feature. This is what’s so unique and special about developing products this way, that a customer who’s just trying out hey and has a question might catch the attention of either Jason or I and get a response from literally the person who’s running this stuff who could immediately put something into effect and I think that’s really a feature. I mean I think of, now I’m really dating myself here, but I’m thinking I buy a Walkman and it’s like 1987 and there’s something like I wish that button was the other way.

(21:45): How could I possibly reach the CEO of Sony or even the design director at Sony to give some feedback. It just didn’t exist. That was not a thing. This is in my opinion, one of the blessings of the internet most of the time and some days a little bit less of a blessing, but when it is a blessing, it really is magic. It is incredible that I can sit here right now in Copenhagen, Denmark and someone in Denver or Vancouver or Paris who are like trying out our products and immediately I can have a conversation with them about that or it’s not even about the product, it’s just about our outlook, which is by the way also our product. Our product is just a much how we think, how we have taken our ideas and our biases and our opinions and then shaped that into a physical piece of software that you could buy, but you interact with those ideas.

(22:37): Lots of people will interact with those ideas for months or years or in some cases even decades. I had people write me who said like, hey, I’ve been following you since the mid 2000s. I never bought anything. Hey, I just signed up for a Basecamp the other day. Great piece of software. Sometimes the sales cycle is literally measured in decades when you run it in this way, and I think this is where Gary V. has been the number one inspiration for me on this because whenever anyone asks this question, how can you do all this stuff? I’m like, I don’t do that much. I’ll answer, I don’t know, on a busy day, 40 tweets and 20 emails and then I remember Gary V, that motherfucker, he’s going to do 400 emails and 1500 tweets just like, and I’m like, yeah, I’m a total slacker in that game compared to Gary and also Gary runs a company I think, what does he have like 1500 employees?

(23:36): Maybe it’s even more at this point, but if he can do it, I mean Jason and I doesn’t have any excuse and if Jason and I can do it, you don’t have any fucking excuse. If you’re running a company of our size or smaller, you should be available. And not just for their sake, for your sake, for your sake. Having that direct connection. I mean I’ve probably told this story by the way three times in the last month about the origin of how Jason answered every piece of customer service email for the first three years of the company ending up doing 150 emails a day at the end of it. And not only is that amazing, I mean the emails were short and sometimes they were also curt and sometimes they were not that friendly, but they were very effective and the amount of input that we were blessed with because of that, that there was such a short line someone, or not just someone, seven people that day writes Jason about this one annoying thing.

(24:33): I guarantee you by the end of that day that problem was fixed if it was fixable in the day because Jason was sick and fucking tired of answering the same damn thing for the seventh time. So it’s just as much to your benefit to be available as someone who can set direction because you need all that input. We often talk about how we said product direction and company direction on a gut feeling, well that gut needs something to work with and that’s what the feedback is. That’s what that continuous stream of interaction with customers, potential customers, haters, fans, all of it goes into that gut machine and every cycle something comes out and it is like, you know what? We should work on these things. Why exactly this feature, not that feature. Ask the gut. The gut was informed by the past six weeks of 700 emails.

Kimberly (25:25): Okay, let me do one last question for you, and this is more of a business structure question. It’s a two part, feel free to answer either one of them. This is an email from Garr. He said, “Hello, 37signals team. REWORK instilled confidence that there was another way to think about building a software company other than the VC and scale route. My co-founder and I are in the product building phase and have a growing podcast. I have another product idea to be built in the future and a potential book related to our niche, but growing industry. Currently I’m a hundred percent the founder of my LLC. What advice do you have on how to structure a company that seeks to share equity with employees and a co-founder?” And then second part of the question answer either one, “How should I think about structuring a company that may have several software products and media IP over time?” It’s a lot there to unpack, but co-founders, how should he structure his business to share equity?

Jason (26:21): If he’s set on that, an LLC is not the right format, probably want to do an S corp or something like that for equity reasons. LLCs basically you have members and members own units and once they kind of own the unit, that’s sort of how it is. I mean you could restructure the cap table a bunch of different ways probably as people leave it’s really too complicated for that probably. Maybe there’s some other ways to do it that are more sophisticated. I’m not aware of those, but I think an LC is probably not the right format if that’s how you want to run it. There are other ways to do this though. For example, we are an LLC and we have profit sharing plan, which is essentially kind of like equity, not really exactly, but we actually have the equity side of it covered by a liquidity program that if we were to ever to sell the business, we would set aside 10% of those proceeds for employees based on their tenure, which is how the profit sharing program works too.

(27:14): So you can share profits along the way, which is sort of what equity is supposed to kind of do. And then if the company ever sells down the road, you can distribute those profits or I’m sorry, those proceeds in a similar way and you can sidestep the whole equity question completely. So there are other ways to do that too. I wouldn’t be so set on what you want to necessarily do until you think it through some more, but if you do want to do equity straight up, I don’t think LLC is the right way to go, but I would probably go S corp then in that case C corp is probably more complicated than needs to be. That’s my baseline understanding of these structures. I don’t know if David has any thoughts on that?

David (27:53): I would say the main pivot point for me is what’s the level of risk and what’s the level of investment. If you’re taking on a bunch of investors and you’re doing seed rounds and you seek to do series A, you should convert to something that can do that S or C corp as quickly as possible. If you’re not going to go that path, then you should think about am I offering employees a risky position that I’m essentially going to underpay them for compared to market rates wherever I am and I need to give something to compensate for that. Equity is also a reasonable thing to do for starting in that case. In our case, neither of those two things were true. We weren’t interested in raising a bunch of series of venture capital funding or other forms of investment, so we didn’t really need the sophisticated structure for that.

(28:43): And on the other hand, there wasn’t a lot of risk. At no point in the history of 37signals have we hired someone on the pretense, do you know what? We’re going to give you vastly below market rates, but here’s a golden ticket that we might become a moon ship or something like that. That just was not the proposition. And I think as you analyze what you want to do, you should look at what kind of company do I have and what kind of company do I want? If you want a company that you own, you set the direction for and you’re going to be in it for the long term, that leans more towards what we did, the LLC route, the profit sharing route, the sort of proceeds route. And if you’re in the other hand like, no, I want to grow real fast.

(29:24): I want to attract a bunch of talent that I can’t really afford. I got to give them something else, then you should go to equity and different kinds of corps. What’s so nice about the LLC is it’s the most tax efficient pass through structure you can get in the US. So if you actually produce profits. I know this sounds weird when we talk about start, what profits? What there’s money left over? But if you happen to be interested in that actually making more money than you spend, there will be money left over and the most tax efficient way of getting that money out is for you to have an LLC. And then the second thing is LLCs have a very low overhead in terms of accounting, in terms of legal, all those mechanics of operating the business, it doesn’t get simpler than an LLC, so that’s how to think about it, I think.

Jason (30:15): Yeah, I would also just in general, don’t make things more complicated than they need to be. You can always add complicated stuff later. If you start out too complicated, it’s quite hard to go backwards.

David (30:26): That’s the other thing, this isn’t a one way door. So if you stick with the LLC structure for now, you can decide to convert it later. If you have an S corp and you’ve handed out a bunch of equity and the cap table is muddy as hell, you don’t get to go back. You don’t get to go back to the simple days. That basically never happens unless you go through bankruptcy or something else like that first.

Kimberly (30:49): In regard to Garr question about having multiple products and how to structure his company for multiple products, have you guys ever considered spinning off anything separate or it’s always been this one umbrella, one LLC with multiple products underneath?

Jason (31:04): We’ve thought about a variety of things. I would tell him just to think about any of that shit right now, make one thing, make it work. Make sure you’re even around in three years to make your next product or two years, whatever it is, don’t worry about that stuff. I appreciate the thoughtfulness that he’s going through here, but don’t need to think about it. Just make one thing, make it work. From my understanding, he doesn’t have the one thing yet. He’s in the middle. He’s in the process of making the one thing. See if you’re even going to be around in two years, then make another thing and then feel it out and you can figure it out. But don’t create all this structure and complexity just in case because maybe. That’s how you end up just getting tied up in knots and spending more time and more money with lawyers and it’s just all unnecessary. Just get there later if you need to. You can. And the key is of course, keep it as simple as you can initially. That gives you all the flexibility and optionality you need down the road. So that’s what I would suggest.

David (32:01): And I’d also say for us, the LLC setup worked when we were four people. It worked when we were 80 people. It still working when we’re 60 people and we’re 25 years into this thing. So it’s not like the LLC sort of fizzles out at some point and expires just by default, that it kind of dies of old age. That’s not what happens. You only need a different structure when things get more complicated, but that complication is a choice at every step of the way, and you can choose to say no. We’re going to choose to keep it simple. We’re going to choose to have low overhead. We’re going to choose not to have a cap table full of bolts of other stuff in it.

Kimberly (32:41): Okay, well that is a good place to wrap up. Thank you for those questions. In fact, Mariana Jackson and Garr, I’m going to send you a piece of REWORK swag for sending in a question to us, so thank you for that. REWORK is a production of 37signals. You can find show notes in transcripts on our website at 37 signals.com/podcasts. Full video episodes are on YouTube and if you have a question for Jason or David about a better way to work than run your business, leave us a voicemail at 7 0 8 6 2 8 7 8 5 0. You can text that number or email us at rework@37signals.com. I just might send you a piece of swag.