Subscribe
Share
Share
Embed
If you've been following along with the podcast, you've heard the mention of two-person teams and how 37signals makes the most of its software features and productivity with just two people working together—one programmer and one designer.
In this episode of the Rework podcast, 37signals co-founders Jason Fried and David Heinemeier Hansson sit down with Kimberly Rhodes to dive deeper into the concept of two-person teams and share valuable insights on the benefits, challenges, and strategies behind their unique approach.
Listen in as Jason and David share the importance of short-term cycles, the significance of building their own tools for maximum efficiency, and how these principles shape their company's operations. They also discuss the expansion of two-person teams into other areas of the organization and the limitations of working as a team of one.
Tune in to discover how the power of two can revolutionize teamwork and productivity.
Show Notes:
[00:00] - Today, Jason Fried and David Heinemeier Hansson are here to discuss the concept of smaller teams and how two-person teams are effective at 37signals.
[00:48] - Jason shares that initially, teams at 37signals had three people, including two programmers and one designer, and why they changed to two people on each six-week cycle project.
[01:33] - The constraint of having two people is not a resource issue but rather an opportunity to tighten project scopes and prioritize ideas. Direct communication between the programmer and designer eliminates translation layers and allows for efficient progress.
[02:14] - How the direct collaboration of two-person teams sharing the same workspace enables rapid progress.
[02:53] - David shares how working with web technologies improves two-person teams' efficiency and helps avoid delays caused by platform approvals or updates.
[03:49] - The significant advantage for 37signals is that it eliminates the need for conversions.
[04:44] - Enhancing the bandwidth between the two team members by removing obstacles and maximizing direct communication—how 37signals realized that having five programmers for Basecamp was too many.
[05:40] - Blowing the minds of startups who think they need an army of programmers—the secrets of 37signals' productivity.
[06:31] - New members easily integrate into the productive system, proving that anyone can embrace this approach.
[06:45] - Two-person team pairings at 37signals are flexible—some stay together, some don't.
[09:06] - Embracing the freedom of the two-person team approach by setting aside daily stand-ups and rigid check-ins in favor of a balance of oversight and support without unnecessary bureaucracy.
[10:19] - The secret behind 37signals' unique management approach—how management, driven by processes rather than people, creates a more efficient work environment.
[11:10] - How a simple set of questions and a six-week feature cycle can provide clarity while evaluating progress and fostering trust within the team.
[12:48] - A drop of product management is all you need to drive success.
[14:31] - How traditional software development approaches and large teams lead to excessive long-term planning, misguided processes, and massive hirings and firings.
[16:02] - Challenging the status quo with smaller, nimble projects for greater success.
[17:07] - Unlike industry giants, 37signals is focused on speed and efficiency.
[19:05] - David shares the difference between producing something final instead of “a long conveyor belt of partial feature implementations that get put behind feature flags, and you have the proliferation of half-done work that has never moved off the plate.”
[21:07] - Jason shares one of the biggest mistakes in business—what promises really get you (hint: it’s not to your targets).
[22:59] - Unlike traditional growth models, 37signals embraces the philosophy of "hire when it hurts."
[24:32] - The delicate balance between efficiency and redundancy! The crucial factors to consider when building sustainable teams
[27:09] - We love doing the “Ask Me Anything” shows. If you have a question for David and Jason about running a business, leave a voicemail at 708-628-7850 or email us with questions to have it answered on an upcoming episode.
Links and Resources:
Do you have a question for Jason and David? Leave us a voicemail at 708-628-7850 or email us
Sign up for a 30-day free trial at Basecamp.com
Creators & Guests
Guest
What is Rework?
A podcast by 37signals about the better way to work and run your business. Hosted by Kimberly Rhodes, the Rework podcast features the co-founders of 37signals (the makers of Basecamp and Hey), Jason Fried and David Heinemeier Hansson sharing their unique perspective on business and entrepreneurship.
Kimberly (00:00):
Welcome to Rework, a podcast by 37signals about the better way to work and run your business. I'm your host, Kimberly Rhodes. If you've been following along with a podcast, you've heard the mention of two-person teams and how 37 Signals makes most of its software features with just two people working together, one programmer and one designer. But these programmer and designer teams aren't the only small teams of two at the company. The people team, finance, and QA departments also run with these small teams of two here to talk about getting more work done with smaller teams are the co-founders of 37signals, Jason Fried and David Heinermeier Hansson. Let's, guys, start with the program or designer combo, 'cause I feel like we get a lot of questions about that, how we put out so many features with just two people working on it. Jason, you wanna jump into that?
Jason (00:48):
Sure. We used to, well we started out with three-person teams, kind of, but also kind of two really. I guess David and I were working together on a lot of things early, early, early days. We had another designer at the time too. We ran with three for a while and three by the way was, was two programmers, one designer. But that's when we were doing work that was, I think multiple months. We didn't really have this idea of cycles yet. It was still like, you know, kind of as long as it takes sort of thing and things were more complicated. And I think when we went down to doing six-week cycles, we realized that two people is all you need anyway. We first of all scoped the projects down so they were smaller and tighter and simpler to begin with. And the two-person, uh, constraint forces us into making good decisions about what to do and what not to do and that, so it's a benefit.
(01:33):
We don't feel resource constrained, you know, it's all about like, we actually have plenty of resources. We have a designer and a programmer, both talented people who can build a lot in six weeks maximum. So we don't feel resource constrained. What we do is we, we feel idea constrained, we feel scope constrained. We have to tighten things up to make sure that we can get this done in a certain amount of time. And one of the beautiful things about two people is that, um, communication is direct. There's no one translating, there's no translation layer between a manager talking to people or PM talking to different people. Two people who work together, work together directly. They work in the same code base, they work in the same place. They work in Basecamp, they work off the same lists or the same kanban board, we call it card table.
(02:14):
They work on the same chat and whatever it is, it's just them two working together. And it's so direct that you can make a lot of progress very, very quickly. I think that's one of the real secrets to this is that when you don't have a middle person, when you don't have a translation layer, you just move fast. You just, it just happens by default essentially. So, um, it'd be hard to actually see us going in a different direction. It'd be hard to ever see us going back up to three or more instead of what we do. We would have more parallel teams running, so we'd have more two-person teams running. If we wanna get more capacity, that's how we do it. We wouldn't throw more people at a project, we'd just build more product teams and do more projects together.
David (02:53):
I think part of the reason this works is the materials we're working with and how we work with those materials. First of all, all feature development, generally speaking starts on the web. The web is one of the cheapest forms of software materials you can have in contrast to things like native development that while really important in many cases and necessary, it's just a lot slower. If you work with modern tools for the web, it's incredibly quick to iterate. You're not waiting for sort of updates to put out, um, getting things approved by Apple or Google or whatever. You can iterate on things really quickly. And the oddity here, I think for us, the thing that perhaps stands out more than than anything else in that regard is that the programmer and the designer are working in the same materials, at the same time, in the same code base.
(03:49):
We do not have sort of a, we used to call it the, the Photoshop wall now, I guess it's the Figma wall where you throw Figma files around and then someone has to cut that up and turn it into the actual code. No, the designers at 37signals go, if not straight to HTML, then very quickly to HTML and not just to HTML, but to JavaScript and even a bit of Ruby. You're working in the same code base. There's not a translation layer. Not only is there not, um, sort of a human translation layer, there's not a technical translation layer either cutting all those translation layers out and getting the most direct bandwidth between two people. I don't think people realize how big of a difference it makes. In fact, um, we had a funny incident a few months ago, I think it was where we were, was it five programmers on Basecamp?
(04:44):
And we were like, it's too many. It's too many. We can't actually do product management for Basecamp with five teams at the same time. We cut that down to three teams. So we'd have three programmers at that time working on Basecamp at any one time with three other, uh, programmers. And that was it. That was all we needed. I talked to startups all the time who think they need 5, 7, 10 programmers to do anything at all. And when I tell 'em, Hey, do you know what Basecamp, the thing that's like paying for 37 signals has been pushing this whole company forward for 20 years. It consists of like three teams of two. Like they blow their minds. And this is what is odd to me, is we have shared everything about how we built. We share our tools, we share Ruby on Rails, we share our process, we share Shape Up, we share every single approach how we run this company.
(05:40):
Yet it's still somehow a huge secret. There are very few companies who are taking us up on the order of like, if you work with these tools, in this way, running your company like this, do you know what, you can get similar levels of productivity. So my mind is just never baffled that that is the case. But um, I guess that's why we keep doing these shows. This is why we keep writing blog posts. This is why we keep releasing open source code because this is entirely possible, and it's not because we somehow gathered a completely unique group of people who you couldn't find anywhere else in the world. We've had a bunch of people over the past two years, all new to it. They slot right into this system and are productive in, in much the same way. So the secret is out there, it's just for people to pick up on it and go.
Kimberly (06:31):
Okay. So I'm gonna give our audience a little more clarity on these teams of two – programmer, designer. Are they always the same programmer designer duo? I know the answer's no, but kind of tell me a little bit more about that and how they're partnered up.
Jason (06:45):
We kind of have some duos that stick together over multiple cycles, but it's not written in stone. It's just sort of, people work together because the product teams are small. Like David said, we have three, three teams on Basecamp. Like there's not a lot of room to move between people anyway, but it can happen. So it's not, it's not, this is not a requirement. You could change up every cycle. We used to do that. Now we don't as much anymore. A lot of it has to do with the projects as well, or historically it had to do with the project. So for example, if there was a part of the product or part of our infrastructure that really required a specific person, that person might get shuffled into that because they really know that world well. Although that's not really typically a good thing because then other people don't get exposure to it. But for the most part, if they wanna stick together, they do. If they don't, they don't. It doesn't matter. And I think that's the thing. Just we don't need to layer on policies and requirements to make this work. It just works naturally. And I think that's the idea.
David (07:43):
And I think this is also part of like the not magic. Clearly there's some magic here. I still actually haven't figured it out, like why more companies and teams haven't taken us up on doing the full thing. But sometimes I think it is because they imagine that this only works if you have folks working together for five years or 10 years or whatever, that you get into some very magic groove and that's what makes the whole thing possible. So not to say that that doesn't help, um, when you work with someone you've worked with for a long time, it does go faster, but it's not a requirement for this. The, the two person team works without this idea that they are each other's sort of soulmates of development. Um, it's not a prerequisite for, um, for doing it.
Kimberly (08:29):
And okay, then also tell me this about managers because I know we're not a manager heavy organization, but I assume that these teams of two have some sort of reporting structure. I think that's what gets people confused as well.
Jason (08:42):
Yeah, on the product side, essentially there's one primary product manager happens to be Brian. It also happens to kind of be me and David ultimately also. But really it's Brian is is the primary people report to, but it's not really reporting. This is another subtlety I think that we've never really quite captured in terms of how to explain this, but there's just a lot of floating going on. There's just like this very organic thing. Like people, you know, no one's poking their head in every day to see how's it going, how's it going, how's it going? How every once in a while you do that or people pull someone else in to get them to look at something or review something together. It could be a peer, it could be a manager. It, it's just, it just works. People know when they need help. They know when they haven't shown someone something for long enough.
(09:27):
When someone hasn't seen something for long enough, they'll ask. There aren't rules here, it's just what do you need? When do you need it? Who's around to help? And let's make sure the quality bar is still high. So that's a fundamental piece of this too, but it's not, we don't do daily standups. There's not regular check-ins necessarily. There are enough check-ins. There's enough oversight, but not too much. I know this is not satisfying because people wonder out how do you do it? Exactly. The answer is you do what you need to do and you just feel it out. And some projects don't need anything. Some other projects are really involved and need a lot more. Some, some things are, you know, very uncharted territory and there's a lot more involvement from someone more senior or someone with a broader perspective. Other things like just figure it out, like it's gonna be fine. Again, I know this is not satisfying, but that's the truth. And hopefully people can find satisfaction on that.
David (10:19):
Well, I think the deeper truth, at least for us is that there's just not a lot of management at this company. You talked about reporting and that's typically how companies are set up. You have a manager and you're reporting to that manager and the manager's job is essentially to sort of nag and follow up with you. Are you on track? Are you on task? Are you going where you should go? And we just don't do that. Um, so it ends up with, they're still management, but it's management more by process than by people – that instead of having a person that's following up with you all the time and like checking in on you and making sure that you're on track, we have processes. One of the processes we've talked about in the past is this notion of the automated questions. This is perhaps one of the favorite features of Basecamp for me as a quote, unquote manager.
(11:10):
Or I'd rather almost say as a manager of the processes rather than as a manager of people, I like to put effort into managing processes. And those processes should be automatic, unobtrusive and kind of just there. So these questions we ask is on Monday we ask in the beginning of the day, what are you gonna work on this week? And then at the end of every day we ask, what did you work on today? And not everyone answers the daily question every day, but they answered enough that you get this sense, are we moving forward? And then we have this cycle clock frequency where you have six weeks to work on a feature. Like we only really get to do that six times a year, but that provides us six opportunities to evaluate the quality of the work and help steer someone in the right direction.
(11:59):
You knew you're joining the company, your first cycle is not gonna be a slam dunk. You're going to find the autonomy confusing and weird. I think, uh, that's at least what I've heard from a fair number of people who've joined this company is that like it's odd that you just get this brief, the product or the feature brief, which is like a single pager with squiggly lines. It's not in precision and everything is not spelled out, but the broad outline is there. And then you put together with a partner, one other person, and he is told like, all right, go make something great in three weeks, four weeks, six weeks, whatever the appetite we have for that specific feature is. And I find that works the majority of the time. The majority of the time people will live up to the challenge. They will live up to the trust that you're placing in them.
(12:48):
It's in a kind of, again, unusual amount of trust for a lot of people. They're used to being checked up upon every few days, perhaps in some cases every day. And here you could find yourself in a situation where you're not checked up at all that you might hear from someone like two weeks from now and you're just there with your partner to figure it out. And it works. And not only does it work, it works better, at least for us that the removing the managerial interventions and checkup and regime is a turbocharger. And this is one of the things as, as Jason mentioned, is odd compared to a lot of other companies who think of like product managers as something you need to insert into everything, right? Where we have one, one product manager for like two major products that each have, what, what do you kind of like six active teams maybe across the two products, HEY and Basecamp.
(13:45):
That's enough. Each single team need just one sixth. And it's not even one sixth because Brian is also thinking about the next cycle and so on. They get one 10th of Brian in a given cycle. That's enough. That drop of product management is all you need. It's, it's like the food coloring, right? You have this beautiful clear glass, one drop of red boom, the whole glass is red, you don't need to mix in a gallon to turn it red. So realizing that it's not that this is no management, it's not that this is a flat organization. It's not that there's no hierarchy, it's not that there's no one thinking about where the product needs to go, it's that those things can be done at much, much smaller doses than almost everyone realizes.
Kimberly (14:31):
Okay, so you guys might not know the answer to this, but I'm just curious about your opinion because we've seen in tech, huge numbers of hirings, but then also huge numbers of firings. Like where are companies getting it wrong? Clearly we operate with very small teams. Other software companies have triple, quadruple the size but aren't necessarily making updates as often. Like where did it go wrong?
Jason (14:56):
And there's probably a lot to say here. Most of it's upstream where the ambition is so large and the projects balloon and there's too much planning central long-term planning. Like, here's our roadmap for two years. Here's all the things we promised our customers that we're going to do. Here's what we promised our investors how much we're gonna grow? Like there's all these promises that are pushed out into the future and there's nothing easier than making a promise far down the road because you don't have to deliver on anything until later. And so with all these promises, you have to start backing it up and you choose too much work too early. Uh, you, you hire a bunch of people to do all this work. To David's point, you have the wrong process in place where there's just a lot of daily standups and scrum and all these things that the velocity and the pace is different and the duration of projects goes on as long as it needs to go there.
(15:53):
There's not time boxing other than like, well in two years we're gonna get all this stuff done. There's just, it's too big, too broad, too undefined and too long term, frankly. Um, we're very short term. We think about things every six weeks, like every six weeks we've figured out, figure out what we're gonna do over the next six weeks. And that's basically it. We have an idea roughly where we're headed directionally, but truly, I don't know what we're doing eight weeks from now. I don't know, I I don't know yet. We haven't decided. And so with that, you can make decisions as you go. The projects are gonna be smaller. Again, we're maxing out at six weeks and the closer you are to now, the smaller you need to be. I think the further out you think and the bigger you think, the more ambitious you think and the more promises you make and promises actually is probably the key word here. The more promises you make, the bigger and clunkier and slower and more frustrating it actually becomes. Now why and Kimberly's good question. Like why? Well, I I don't really know why, but this is just how it is in most places. It's anathema to us. I mean, it's just not how we would ever wanna run things. Um, but this is sort of traditionally how it's been. So I dunno that that's my quick take. Maybe David has a different perspective on it, but that's my feeling. It's promise driven.
David (17:07):
That's all spot on. And I then also come back to, to saying like our secrets, like the why is, is there. We're putting out our tools, like how we work. There are a million different ways you can make a web app and some of them just take a lot longer than others. They're, the reason we build our own tools is that we see that inefficiency and go like, you know what? That's not gonna work. We can't use the kind of tools that are not suitable for a team of two with one programmer to deliver a major feature in six weeks. So that automatically just shrinks our appetite for complexity, which is sort of, uh, um, factor in this that rapidly just makes something that appears to be simple, very complicated because you're working with poor materials really, or not poor as it, it's not necessarily that the outcome is poor, but the ergonomics are poor, that they have the wrong grips.
(18:03):
They don't work for single programmers, they work well for large teams. That's where a lot of tooling comes from. It comes from huge companies like Meta or Google or, or whatever where cost just doesn't matter, at least not on the same scale. They, they would think nothing of having 10 people on a team or 20 people or 50 people, our entire company size on a single push. Right? And we care, uh, quite deeply about those economics and those advantages compound. Those really compound in, in a way that when you remove a layer of complexity, you're moving like logarithmically down the chart in terms of how quickly you can operate. The other thing I'd say is this curious thing where as Jason say, on the one hand you have all these long-term promises to investors and roadmaps and customers and whatever, and then you somehow swallow those long-term plans with the cough syrup of unreasonably, short cycles, durations.
(19:05):
Scrum, for example, talks about a two-week cycle where what you're producing is completely artificial. In most cases. Those two week sprints, they're also called sprints, which there's a whole discussion there. They don't produce something final. They produce an artificial piece, bite of a real thing. When we talk about six weeks, we're talking about like the thing. That's the feature. We're shipping it and then we're moving on to something new. When you look at, um, at these two-week sprints, it's nothing. Nothing's fucking finished. It's just a long conveyor belt of partial feature implementations that get put behind feature flags. And you have the proliferation of half done work that has never moved off the plate. And that in itself is just a massive complicating factor. If you could just focus on one thing, this is what we're doing, we're two people, let's work on this together.
(20:00):
Three weeks, four weeks, six weeks, whatever. This has our undivided attention, our attention's not being atomized by all these other things going on and all this half done work and all these feature flags and all this other shit that comes up. We're just gonna do one thing at a time and we're gonna get it off the plate. It's, it's kind of one of those, um, deceiving things where it looks like we're going slow. Sometimes when we look at, um, a cycle's worth of work, we'll look at like three features or something like that, and you go like, that doesn't, I don't know, feel like it's, it's a lot. But then you go like, we do that six times a year. You look at Basecamp at the start of the year and you look at it at the end of the year and you go like, wow, it's so much better. We made so many real meaningful, worthwhile improvements, even though it was like 15, 18, 20 things of major note. It's enough.
Kimberly (20:50):
I will say for your customer facing teams, it's nice to be able to say, I don't know what we're gonna work on in two years. You know, people ask for feature requests and it's an easy answer. Like, we only work six weeks in advance. So I can't tell you the answer to that, but you know, it's, it's kind of a nice out.
Jason (21:07):
And tied to that. Can I just add one more thing about promises? Every time we've made a promise, we've regretted it, like truly, and some of them we've delivered on, but like, just, just to, to have this thing dangling out there 11 months, like, it's like, well yeah, by, by the end of the year, this is the best promise, I mean the worst, best promise, like, yeah, we'll do that by the end of the year. There's always these like, you just keep pushing things and it's like, well, it's easy to say that. It's the same thing when, when you ask people like, would you pay? How much would you pay for this product if we released it?Would, you know, like, ooh, I don't know if a hundred bucks, 50 bucks, 20. It doesn't cost 'em anything to say anything right now. So whatever they're telling you doesn't, you can't put any weight into it. And the same thing is true with like these, yeah, by the end of the year or by early next year. I mean, we do have targets sometimes for like a new product release, but it doesn't drive. I mean it's, as we get closer, we then it really does drive us. But to make promises to the outside world, uh, about timeframes down the road is, is one of the biggest mistakes in business. And it happens all the time and people are constantly late.
David (22:12):
And it's completely unnecessary, self-imposed, hurt and harm. We used to do it more. We used to make more of these promises and this Jason says we've regretted every single one. And then when we switched over to essentially not committing to things, you know, what the cost of that was minuscule compared to the cost and the aggravation. When you're late on a promise, that is one of the worst things out there. Um, you've set up that expectation yourself. You said it was gonna be there and now you've broken a promise. There are very few things worse in business than breaking a promise to a customer. Um, so rather take that like minuscule maybe annoyance, slight annoyance, like, uh, can't you, like can't you work for this for me? Yeah, yeah. Maybe we will, we'll consider it in six weeks.
Kimberly (22:59):
Okay. Before we wrap up, tell me a little bit more about our other two-person teams. We've talked about the designer programmers, but we have a couple others in the organization. I'm assuming that those started as just one person teams and then expanded?
Jason (23:11):
Yeah, essentially on the product side, we, we assemble two-person teams and most of the company, well, in other, not most in other areas, it starts with one person, like Andrea for example, solo and now Bethany's on her team or perhaps you and Chad, although you guys came on at the same time essentially. And then yeah, on, on finance. You know, we've, we kind of start with one person. That person needed someone else. So that's kind of how it grows. It rarely grows to three. I mean sometimes people are collected together, like marketing is a good example. There's different people from different skills that are under a certain umbrella, but in, in our case, there's two people internally who do video work. You know, you and Chad. So like I kind of think of you as a team of two even though you're doing different things in a sense.
(23:55):
But that's typically how it goes. Um, so, so this is about, this is about not about anticipation of what we're going to need. It's actual need. So we, we've had this this term since the beginning. Higher when it hurts. I think this might have been in getting real if it wasn't in getting reals in rework, but higher when it hurts. Point being don't hire in anticipation of pain hire when there is some pain. Uh, and not a tremendous amount of pain. You don't wanna be like strung out where you're really, really resource depleted and can't do anything, but you should feel it first before you go, we really need to have someone else come in and help or, or, or build something up. So that, that's been our, our process since the beginning.
David (24:32):
And some of that pain as we've had it on QA, which is one of the teams we've most recently hired for comes up in the moment that, uh, Michael, the person we've had on QA flying solo for a long time with external help, but flying solo internally was like, hey, I'd like to be off for six weeks. I have a sabbatical coming up. I want to take some prolonged breaks. And we were like, oh yeah, actually do you know what? We've been flying too long with like just one person on that team and some things would've ground a little bit to a halt if he was to to leave for six weeks. You know what, we should have someone else there too. So I think that at least instinct for us now at this stage of the business is also a little bit about redundancy, about do you know what, um, we have, uh, Nick and Ron managing our books and our accounts, you know, what if we're large enough business that like if Ron or Nick, um, was unable to get to work for a while, like we still need to get people paid.
(25:30):
Like we still need to pay our bills and our vendors and manage the funds coming in and so on. Like, just having one layer of redundancy, um, is prudent. Now, I would not advise for this at all when you're starting out and even quite late in the starting out, having the single bus factor in the beginning is just fine. Until you are solidly established, you should not be thinking about redundancies. Um, but once you are, as we are now 20 plus years into this, having some redundancy around critical functions like, hey, are we ? Are we still making money? Uh, are we still paying people? Good prudent thing to do. But you gotta be quite vigilant about that too. Like once that redundancy is there, like that's the pain. Like so many departments, as soon as they get a little bit of um, sort of momentum in growth, that'll just continue on unless it is stopped, unless it's arrested quite early on.
(26:27):
So that part. And then finally I'd say on that, I think particularly for someone who'd been at the company for a very long time, what we've seen time and again is if you are the only one doing the kind of work you're doing on a team of one, that has an expiration date. You can't do that for too long. I mean, at most a couple of years, anything longer than that, you're gonna go a little stir crazy. Um, you just are, you need someone else to share your trials and tribulations with who actually understand the work itself, not just the manager, not someone else. And we've had I think a couple of cases like that where didn't quite work out over the long term because we only had one person in that role. So that's some of the considerations to, to think about.
Kimberly (27:09):
I love that. Well, with that, we're gonna wrap. It's been a little while since we've been here and last time that we were on the podcast, we did an ask me anything. We wanna keep doing those. So if you have any questions that you wanna have Jason and David answer about a better way to work and run your business, leave us a voicemail at 708-628-7850. Rework is a production of 37 Signals. You can find show notes and transcripts on our website at 37 signals.com/podcast.