SEASON 2 - EPISODE 0057 - MAR 29, 2023

Listener Questions / AMA

In this episode of REWORK, Jason Fried and David Heinemeier Hansson, co-founders of 37signals, join host Kimberly Rhodes to answer questions posed by REWORK listeners.

Listen in as they share their insights and experiences in running a successful software company by answering questions from podcast listeners on topics such as 37signals’ approach to design, decision-making processes, product management, and balancing managerial roles and responsibilities.

Tune in to hear their unique perspectives on these key aspects of building a successful software company.

Show Notes

00:23 - Noel asks David and Jason about their philosophy on design systems and using components instead of reinventing the wheel every time.
01:01 - Jason explains that 37signals’ website is a collection of ideas. The product itself is their design system.
03:07 - As with Basecamp and HEY, design consistency can emerge naturally.
03:30 - David shares that large organizations typically use design systems to standardize processes.
05:34 - Why it makes sense for individual designers to have ownership over the design process for small teams like 37signals.
06:52 - Listener Paul asks how David and Jason resolve conflicts and make difficult decisions.
07:02 - Jason explains conflicts are rare among the team and shares how they handle the things they don’t agree on (without keeping score).
08:18 - Why it’s important to remember most decisions are temporary.
08:59 - Jason shares an example of the rare occurrences when they might battle.
09:49 - Setting the standards for a smooth workflow.
11:30 - David’s philosophy: “A willingness to try anything as long as there’s an expiration on the experiment and a way to tell whether it went one way or the other.”
12:55 - Jason explains why they don’t need to consult each other for every decision—even the BIG ones, like leaving the cloud.
14:28 - Prioritizing independence, competency, and TRUST.
16:50 - Podcast listener Tim asks Jason and David to discuss 37signals’ approach to product management and some of their methods over the years.
17:20 - David shares how using software to gather and distribute information, allowing teams to make decisions, leads to everyone rowing in the same boat.
20:19 - Jason adds that with two-person teams, there is a direct relationship between the programmer and designer, and management would get in the way.
22:21 - Fighting hard against traditional managerial responsibilities because having managers invent work for other people can wreck a good thing (David and Jason only wear the hats of CTO and CEO occasionally).
23:25 - Do you have questions for David and Jason about a better way to work and run your business? Leave your voicemails at 708-628-7850 or email.

Links & Resources

Transcript

Kimberly (00:00): Welcome to REWORK, a podcast by 37signals about the better way to work and run your business. Yay. I’m your host, Kimberly Rhodes. This week we’re changing things up a bit and answering some listener questions. I’m joined by the co-founders of 37signals, Jason Fried and David Heinemeier Hansson. You guys, people have written us, they’ve voice mailed us. Let’s dive right in. First question is from Noel.

Noel (00:23): Hello David, Jason and Kimberly. Some months ago you revamped the website with 37 ideas and one that got my attention was number 36, context over consistency. While I agree with the general idea, I also think there has to be some consistency. Looking at Hey and Basecamp, not every page is completely different. So I was wondering what you think about design systems and if you use them in your products. If you don’t, I’m curious to know what your philosophy on reusing components instead of reinventing the wheel every time. And that’s it. Thank you

Kimberly (00:56): Jason. I’m gonna direct that at you, but I think we should first tell people about this website that Noel is talking about.

Jason (01:01): Yeah, so 37signals.com is is our, is our new site, which is actually a remake of our original site back in '99. It’s just a series of 37 different ideas. There’s some other links on it now as well. But, uh, our points of view on a variety of different topics about the industry, about ourselves, about design, about engineering and writing and, and hiring and, and marketing and all those things. We always wanna try to lead with ideas and that’s sort of what this site’s all about. So you can check that out 37signals.com. Um, yeah, to the point of context over consistency, uh, we, so getting specific, we don’t have, uh, design systems, uh, internally. Um, we don’t spend time building that. Our design system is the product itself. So, uh, when we build Hey or Basecamp, it looks a certain way. How does it end up that way?

(01:48): It just, that’s how it ends up. And because there’s basically, you know, only a few teams that work on these things, we can see the whole thing. We have a pretty good sense of how it looks. And so when you make a new screen, you kind of make it based on the other screens. And so it’s this constant moving target, which is nice because you can refer to context, like what do the other screens do? How do we auto complete over here, if we’re building an auto complete over there? Let’s kind of use the same thing. But occasionally you come up with a new idea that that’s better, a new design that’s better, a new layout that’s better. And because we don’t use a design system, we’re not locked into the way it was, we’re locked into the way or we’re not locked in at all.

(02:27): We instead we’re, we’re loose, we’re, we’re allowed to do it the way we think it should be. And then over time, maybe the rest of the app catches up to that new style. Maybe it doesn’t, maybe there’s some inconsistencies. It doesn’t matter that much. So I think the point is is that if you wanna know how to design something in Haer base camp, you look at Hey or Basecamp. Have we done something like this before? Yes, someone similar, some something adjacent. Use that style, use that concept, use that general layout principle and bring it forward. But also if there’s a way to improve it, do that as well. And um, that’s, that’s kind of our, it’s always been our approach. I just feel like making artifacts like design systems, it’s very time consuming. It, it locks you into past decisions. Um, and then there’s these religious battles about, well, can we change it? Can we not change it? Well this thing says we can’t, we have to do it this way. It’s like, it’s all unnecessary. Um, the other thing I would just say is if you look at Basecamp or Hey, essentially they look, each product looks different, but within the products things do feel pretty consistent even though there’s no rule to make them consistent. So I think it naturally shakes itself out that way.

David (03:30): I think also when you look at design systems, they are typically for organizations that are so large that they no longer trust individual designers who make good choices. This is something you see over and over again on the programming side as well. Once an organization gets to a certain size, there’s a different group of people who are now architects. And the architects tell you how things are supposed to work and be laid out and which tools you use in what order. And, and that is a function of bureaucracy in its most pure form. Bureaucracy is about standardizing processes such that you can slot in people you don’t have direct relationships or trust with. Now, there might be other people who like the sign systems for other reasons, but this general pattern of setting things up in a rigorous way, that’s the consistency part, right? Like that’s the essence of consistency is rigor that you follow the same process every time.

(04:28): To get similar style outcomes is something that, um, is probably very appropriate at a company of 2,000. And we revolve around this question over and over again. The industry is so chock full of methods, principles, and processes extracted from big tech companies and they make total sense at 50,000 employees, a hundred thousand employees, 2,000 employees. These are the things like, uh, microservices or or service oriented architectures. This is something I’ve been ranting and raving on about, uh, 15 years. But then when you scale it down to our size, we have a product team of less than, I think it’s less than 40 people. Um, and on individual teams we have two people, one developer, one designer, very small teams. They just, not only do they not need these things, it would be actively harmful to introduce them. And this is the misconception I think is so often brought in when you say like, well this works really well for Facebook, it has worked really well for Apple.

(05:34): I’m sure Apple has a design system for how apple.com looks such that the subcontractors or even employees they have in Denmark don’t have to think about the overall layout. They can just slot into a system and do their translations and move things around as they see fit and it’ll look pretty good. But if we were trying to do that at our scale, it would be inflicting harm, not just harm in terms of productivity, although that would be a key part, but also harm in terms of the ownership that individual designers at 37signals have over this process. When you set someone free to make the right choice in a given situation, rather than follow the bureaucracy, I tend to find that they are happier people. They feel more creative, they feel more expressed in what it is. On the technical side with the programming thing, there’s so many tales of how, well, I don’t like how we have to do this, but we have to because bureaucracy, reason A, B, C, and D, you know, why, why do you have to do it like that? So embrace your size I think is the key part of this. It’s not design systems bad, design systems good. It’s design systems inappropriate for a team of four expert designers at a company like 37signals.

Kimberly (06:52): I love it. Okay, question number two, it’s from Paul. It says you must have made many difficult decisions together. How do you guys resolve serious conflicts?

Jason (07:02): We don’t have that many serious conflicts, so I don’t, we’re not that practiced in it frankly. Um, I think we mostly see eye to eye on most big things and there’s probably 10% of the things we don’t. And I think then we just debate and discuss and sometimes we yell a little bit, but like for the most part it’s, you know, you, you lay it all on the table, you have a good relationship, a good, a good trust, you trust each other’s intuitions. You trust each other’s point of view and you just kind of figure it out. I don’t know the, there’s not like this thing where it’s like, well, I’m going home and you’re going home. We’re never talking about this again. It’s just we don’t have that kind of relationship, but we will battle occasionally over things. Um, one, one of the things we’ve done over the years is, um, kind of trade.

(07:42): Basically it’s, it’s like, it’s like two friends going out to lunch over the course of five years. Like, I got this one, you get that one, I got this. You know, you don’t really tally, you don’t keep track, but it kind of evens out in the end. So one of the techniques is when we’re really just stuck, which is, again, I don’t really remember a time when we were truly stuck, but if we were, and there’d probably been smaller decisions where we were kind of like, whatever. Um, you just kind of can tell who wants it more and in many case like, you know what? You fine, let’s just try that. And, and the other, the other thing, and then like I got the next one, I mean you don’t really like call that back at one point, but it just evens out in the end.

(08:18): The other thing to recognize is that I think it’s a little bit about making sure the decisions aren’t so sacred that um, someone needs to be absolutely right and someone else is absolutely wrong. And if we don’t do it exactly this way, we’re screwed. Like you really don’t wanna get to that point to begin with. So, you know, most decisions we make are are temporary to begin with. Even if they’re really big ones, you can always change. Um, and so, you know, we don’t, we don’t get too, I would say too attached ultimately to, to a decision because we can, we can make a different one if we have to. I think one things that, the most recent one, there wasn’t like a heavy disagreement, but there was a lot of discussion was was some pricing changes we were gonna make on Basecamp, like switching to per-seat pricing.

(08:59): And we’re still working that out. We don’t actually, if you actually go right, although when this podcast airs it might be different cuz there’s tests going on. But right now, as of right this second, um, we don’t have per seat pricing as an option for I think, I don’t know if it’s 50% of the people or everyone, I’m not sure what the test is cause it started when I was gone. But we have a different test, different pricing setup up and we might go back to per seat and try that again. We’re just exploring some things, but I think that’s when of the most contentious things happen when there’s a lot of work that would need to happen to enact a particular decision. That’s when you want to be like as careful I think as you can about the decisions you make because it sets off a chain reaction where lots of other people have to get involved. So that’s I think the only time when maybe we really, really battle. But I don’t know, maybe David has a different point of view on it, but that, that’s sort of my take. It’s not that often. And then when, when it happens you trade.

David (09:49): I think another tactic that we often use is recognizing the boundaries of each other’s expertise. So when it comes to for example, picking what to work on for an the next cycle, um, I view my role as informing Jason about the technical trade-offs and then I accept and not just accept, but expect that Jason’s role is to be the key product manager. And in fact it becomes easier that way even on my end when I have a preference that then does not turn out to be Jason’s preference and he picks another thing, I can feel so at ease with it because I accept that in that specific situation, my primary role is to give the technical input on where we can judo, where we can um, save something on the technical side about doing things and then Jason will pick whichever one it is. Usually we’re on the same page with that anyway.

(10:44): But I do think it helps going into some situations with a bit of a tilt of who has this domain more. Now we have some domains we share more equally, uh, about writing for example. But in fact I don’t recall ever having a disagreement about which essay goes into REWORK or, or doesn’t go into REWORK. We usually see incredibly eye to eye on that. And then in the other areas where we might do have some disagreements, just letting that finger on the scale play in that, do you know what, Jason’s the key product manager here. Like that’s literally his role as the CEO is to pick what, what we do and what we work on. And then I have other stuff that I focus on on the technical side where Jason’s not gonna come in and say like, actually no, we’re, we’re fucking staying on the cloud.

(11:30): I promise Jeff that we would stay on AWS until the end of time. That’s just not a situation we have. So I think that’s easier for us than some other founder pairs because we have our own areas of expertise. If you do exactly the same as the person you’re sharing the business with, I do think that becomes a bit more difficult and you have to lean on sort of the tit for tat situation, um, a little bit more. And then as Jason says, one of the things and one of my fundamental philosophies here, I’m kind of willing to try anything as long as there’s an exploration on the experiment and there’s a way to tell whether it went one way or the other. I think the pricing experience we’re doing right now, I had a bunch of opinions about some of the pricing tests that we did and not all of that got expressed and I was like, it doesn’t matter. We’re gonna let this hit reality, the wall of reality and reality’s gonna settle the score. What is it gonna serve that we argue in the abstract back and forth, no it should be this. No, it should be this. We’re in the realm of, of magical thinking. The magical thinking only gets dispelled when we actually put stuff in front of customers. You can’t argue your way to the correct price. All you can do is present reality with a set of choices and reality will be your referee. And then what is there to argue about?

Jason (12:55): I think the other thing that’s interesting would be interesting for people to, to understand is that there’s even big decisions that we don’t consult each other on at all. Like David pulling us out of the cloud. Like we never have actually even discussed that. David’s like, we’re just doing it. I’m like, yeah, okay, makes sense , I mean like what am I gonna say to that? That’s not my expertise first of all. Um, I don’t really have a strong opinion about it and he does and he’s all in. Good, go for it. Like there’s a lot of that that happens here too, which, and people I think would be surprised to hear that like decisions like that aren’t heavily debated internally. Like even like way back when, way, way, way back when, when we were building Basecamp for the first time and David selected Ruby to do it, I think we may have had a chat cause we were doing PHP before that together a little bit and he’s like, I’m gonna do this Ruby thing.

(13:40): I’m like, all right, cool. I don’t, sounds good. Like, I don’t know, whatever. Those things, they’re huge decisions ultimately, but you also just simply have to trust the person who knows best. I mean I could throw some thoughts in and, and the other thing is is that for example, the cloud thing, like I could be the one who’s like, well you know, there’s a risk here. I’m like, but that’s almost, it suggests that David hadn’t thought about that and I I try to be careful about that too. Like of course he thought about that. He knows the risks, he knows the challenges, like of course and it’s, it’s sort of dispiriting to, to throw that at somebody and and condescending almost to to throw to like just throw things in because you feel like you need to have your say. I know those things were considered and I’m sure that that that they were thought through and, and uh, I trust. So trust is a big, huge part of it.

David (14:28): And I think that trust enables us not to have a bunch of debate clubs. Like there are very few decisions, even the big ones, even the ones where we do consult each other on 'em, where we debate for like weeks on end. They are very, very rare. People would be and frequently are shocked when we have new people coming in, especially more senior people come in and they realize, they’re trying to get their lay of the land of the decision making processes we have and I’m like, what process? Like we just make decisions and we, we go with them and it enables, um, a higher goal. It enables a velocity that it is difficult for some people to sort of grapple with initially, but then they can appreciate the results of that. We can move so quickly on so many things at the same time because we don’t run all of it through like a leadership funnel where everyone has to get their say.

(15:26): And this is some of the things that we’ve struggled with in part a little bit over the years is that under some level you do want leadership, the more senior people in your company to feel involved and feel buy-in and they can be ill will if something major pops up and they hear about it through a different channel that you first having the discussion with them and so on. Absolutely recognize that that is a drawback, but it’s a drawback we’re willing to accept. Like this is, to me, this is the interesting part of designing a intentional company is to say, here’s a bunch of things that’s valuable but we cannot have them if we want these things that are more valuable and we place such a uh, high premium on pace, on velocity, on independence, on competence and on trust. Do you know what? That does mean we can’t then debate all decisions. We’re not gonna hear everyone out on everything. That would grind things to a halt. Even if that would make someone feel better in a given situation, it’s just not gonna happen. So that’s a big part of like knowing who you are. Know who you are and and what your values are. Things become a lot simpler and it becomes a lot easier to accept the byproducts of stuff that then isn’t always great. Yeah, that’s the price of admission.

Kimberly (16:42): Okay. David, you mentioned Jason as product manager, which leads in nicely to question number three from Tim.

Speaker 5 (16:50): Hey Jason, DHH, thanks for the podcast and books. I run a product team and often share your content with uh, with our teams. My question, can you talk about 37signals approach to product management While you seem to perform what I would consider the typical product function, you don’t seem to have product managers. I wonder if you would share your thinking around traditional product management and more broadly the approaches that you’ve taken over the years. Thank you so much. Cheers. Tim.

David (17:20): David, do you wanna start with this one? Sure. So I worked at a couple of companies before, 37signals that had product managers and I must say I have a bit of an ambivalent relationship with that role, um, because it kind of um, implies many of the negative aspects or tendencies of management in general that I see that it’s someone who, who just makes decisions and tells other people what to do. I am greatly skeptical of that constellation, just makes decisions and tells other people what to do. Now it has a role and a larger company, I’m sure there’s enough decisions and enough people to tell what to do, then maybe that sort of happens. I never wanted that role. I think that we are much better informed by being in the work to a large degree rather than just being like, we make decisions, which I associate with, on the technical side, of like architects

(18:20): These are people who just make the big technical decision then someone else figures out the details. You know, what can’t divorce those two things. You cannot make good decisions if you are not in the details. Those things are diametrically opposed to to being good. So I think part of it is that we saw, like the product management part is actually a relatively small part. Now we are a little bit larger and we have more teams and now, uh, Jason has uh, uh, Brian in product strategy that helps prepare some of the pitches and so forth. But even that role and that process, it’s not product management in the stereotypical way I would think about it where it’s someone who’s following up with the team like every two days. So where are we on this thing? Where did we progress? In part we built software to solve that instead.

(19:04): We built software like um, the automatic questions, the automatic question, the two automatic questions we have, which is the one at the start of the week that asks what are you gonna do this week? And the one at the end of every day that asks, what did you work on? Takes a huge role of the product management stuff, which is to gather information and to distribute it more broadly and let that inform the process, right? That’s not just happening automatically and I think we’re much better off for it. It hands over a degree of agency to the people actually doing the work. Do you know what? You are gonna make the decisions, you’re gonna face all sorts of problems as you dive into the particulars and those particulars are gonna reveal trade-offs and you’re gonna have to make them. Now occasionally you might summon me, you might summon Jason, you might summon Brian, like, Hey, can I get a second opinion on this? But it’s ultimately it’s on you . And I find that just to be a liberating process. When we talk about our teams, we talk about teams of two, one designer, one programmer. That’s 95% of all product work that happens at 37signals happens with that team. There’s not a third person called product manager on top of that boat just telling the other two which way to row. Nah, you gotta pick up the oars yourself. If you wanna be in the boat, you gotta row.

Jason (20:19): I don’t have much more to add except that, I mean it’s, it’s, you know, when there’s two people, it’s it’s a direct relationship between the programmer and the designer. They don’t need a lot of management to begin with. Like you just don’t, and someone would basically be getting in the way and have nothing to do most of the time. So that’s not the kind of, we don’t wanna have people here who have basically nothing to do most of the time, uh, and then get in other people’s way. That’s it basically. There, there are decisions there. So one thing that is, is people don’t usually get, when I talk about two person teams is there are other people who come in from time to time and provide feedback and, and reviews and that, but they’re typically pulled in by the team when the team is ready to have someone look at something. It’s not somebody who’s just dropping in constantly and asking these questions.

(21:04): So there’s, there’s, it’s not management, but it’s, it’s, it’s a degree of oversight. There’s some quality assurance, not QA only, but also just like quality. Like is the bar high enough? Some of that stuff that happens, but that’s not a permanent role that someone’s making decisions about every single day. That’s just a ridiculous amount of time to spend on that. But you kind of look at it occasionally. You get with the team, you talk with the team and then you go away. So you kind of float between different teams and different projects. There’s nothing and nobody dedicated to an individual project to manage it. So that’s just some more detail there to add.

David (21:35): And this is actually the key fear I always have about management is that the best way to wreck a good thing is to introduce a manager who have more hours than there is work to do because they will absolutely positively invent work and the kind of work that they will invent is work for other people, not for themselves. So I think this is one of the reasons why we’re so hyperallergic to, uh, management. Maybe we are even a little too allergic. I mean we do have some management and now at 80 people, we have some people who do management a fair amount of the time. But if you looked at the product organization coming from a traditional background, you would absolutely go, where are all the product managers? Where are all the team managers. And we’d go like, yeah, we don’t have them. The teams will make the majority of the decisions themselves.

(22:21): And we fight so hard, including in my role and in Jason’s role. I’m not a full-time CTO. Jason’s not a full-time CEO. These are hats we wear occasionally. Some weeks we wear that hat for 10 hours. Some weeks we wear the hat for two hours. Some weeks we might wear it for 40. But those are rare. It is very rare for us to have a full week’s worth of managerial responsibilities. So this is why I’m so big on like having a hobby. My hobby happens to be programming, so I get to absorb like all my excess time is absorbed by programming. And for Jason being in the product itself, being part of working on the individual features and individual designs and all that stuff absorbs all of that. Because wouldn’t it be weird if there just so happened to be exactly 40 hours every week, 48 weeks a year, 40 hours every week on managerial decisions? Absolutely not. There’s no way, know how. It just adds up to that. Um, and when it doesn’t, all hell breaks loose.

Kimberly (23:25): Okay, we have more questions but I’m gonna wrap for now and we’ll pick back up next week with some additional questions. But thank you guys for answering those. And again, if you wanna be a part of the REWORK podcast and ask one of your questions to David or Jason, leave us a voicemail at 708-628-7850. Or if it’s easier, you can send us an email at rework 37 signals.com. REWORK is a production of 37signals. You can find show notes and transcripts on our website at 37signals.com/podcast. You can also find us on Twitter at @reworkpodcast.