Built on Trust

8 Oct 2025 · 28 min

Ask about this episode

Ask anything about it. ChatGPT or Claude reads this page and answers with the times it was said.

Connect VO and ask about every podcast you hear, including the moments you saved. Add to ChatGPT · Add to Claude

In short

REWORK Podcast Episode Notes: Built on Trust

Episode Overview In this episode of the REWORK podcast, co-founder and CTO of 37signals, David Heinemeier Hansson, discusses the importance of trust in building a high-trust organization with host Kimberly Rhodes. They explore how trust can enhance company culture and performance, even in remote working conditions.

Key Takeaways

  • Trust as Default:
  • Trust is the foundation at 37signals, cultivated over years through hiring practices and company culture (00:23).
  • Empowerment through Freedom:
  • Employees are given the freedom to make decisions, including financial expenditures, fostering an environment of trust (05:19).
  • Mistakes and Policies:
  • One person's error should not lead to restrictive policies that hinder the overall trust environment (11:46).
  • Remote Work Trust Dynamics:
  • Trust remains crucial in remote workplaces; managers should focus on the quality and pace of work rather than just hours logged (15:15).
  • Coexistence of Trust and Accountability:
  • Trust and accountability enhance each other; a culture of honesty and feedback is vital (22:10).

Detailed Discussion Points

The Foundation of Trust at 37signals

  • David describes how a culture of trust was built intentionally by focusing on hiring trustworthy individuals.
  • Examples of trust in practice include:
  • Employees can delete tasks and archive files without oversight.
  • Deleted items are archived for a period before permanent deletion, allowing for recovery.

Empowering Employees

  • David shares his experiences with unnecessary approval processes for minor expenses, advocating for reasonable spending freedom.
  • The organization encourages employees to spend on tools and resources that help them perform their jobs effectively.

Handling Mistakes and Policies

  • David emphasizes the significance of not overreacting to individual mistakes by implementing harsh policies.
  • Instead of blanket restrictions, the focus should be on reviewing and discussing errors to align expectations.

Cultivating Trust in Remote Work

  • Trust is essential in remote settings, where visibility of a worker's activity may be limited.
  • Managers should evaluate work quality and pace rather than simply counting hours spent at a desk.
  • Implementing regular check-ins, like weekly plans and end-of-day summaries, helps maintain transparency.

Balancing Trust and Accountability

  • Trust should not mean a lack of accountability. David suggests that organizations should celebrate good work and address underperformance directly.
  • The concept of a "trust battery" is introduced, where both employees and management contribute to maintaining a culture of trust.

Hiring for Trustworthiness

  • David admits that there's no foolproof method to guarantee that a hire will be trustworthy.
  • The hiring process at 37signals involves rigorous assessments to ensure candidates demonstrate their skills and integrity.
  • David recalls a rare instance where a candidate almost deceived the company, but highlights that such occurrences are extremely rare.

Conclusion

  • The episode concludes with a reminder of the importance of trust in the workplace. David and Kimberly express that fostering an environment of trust leads to a more engaged workforce and a more pleasant working atmosphere.

Links and Resources

  • [Record a video question for the podcast](https://sendspark.com/request/The-REWORK-Podcast/hsj7miu9gesm8gq6jm8pr6z9izly0fc2)
  • [Books by 37signals](https://37signals.com/books)
  • [Sign up for a 30-day free trial at Basecamp.com](https://basecamp.com/pricing)
  • [HEY World | HEY](https://www.hey.com/world/)
  • [The REWORK podcast](https://www.rework.fm/)
  • [The Rework Podcast on YouTube](https://www.youtube.com/@37signals/podcasts)
  • [The 37signals Dev Blog](https://dev.37signals.com/)
  • [37signals on YouTube](https://www.youtube.com/c/basecamp/featured)
  • [@37signals on X](https://twitter.com/37signals)

Additional Notes

  • The episode illustrates how a culture of trust can facilitate better communication, stronger relationships, and ultimately a more effective organization.

Written by AI. May contain mistakes. Listen to the episode to check what was said.

Hear the part that matters, and keep it.Open this episode in VO. Double tap your headphones to save a moment as you listen.
Get VO free

Transcript

Automatic transcript. May contain errors.

0:00Welcome to Rework, a podcast by 37signals, about the better way to work and run your business. I'm Kimberly Rhodes from the 37 Signals team, joined by 37 Signals co-founder and CTO David Heinemeier Hansen. This week, we're talking about building a high-trust organization. The reason this came up is because we constantly have customers asking us how they can prevent people from doing things in Basecamp. Like anyone can delete a task or archive a file. Our answer is always like, well, we just have a very trusting organization. I don't think that is by chance. I think that's been built over the years.

0:33So, David, let's talk about that a little bit. I mean, I don't know if you've intentionally, you and Jason, have built that kind of trust within the organization, but it's what we always tell people. We just are very trusting. I think the trust, though, is partly a consequence of the kind of culture and the kind of hiring that we do. And I think we've ended up with over 20 years of having a lot of people through the company. Some have worked for us for a short amount of time. Some have worked for a long amount of time. But the kind of catastrophic antidotes that I can pull on when we have extended too much trust and it went wrong, it's a really short list.

1:14It's not zero. Like there's always the opportunity that you just you're wrong about someone. And they did not for whatever reason to serve the trust that you extended to them. But I think what's key here is to divide the calamities that could possibly occur if someone you trust prove out not to be worthy of that trust. There are certain aspects of the business where the trust really is truly critical. And that's around areas like data access. Right. So when it comes to accessing customer data, especially on something like, hey, where you're dealing with personal emails, we actually have a multi-layered step process that communicates that, you know what, we may trust you, but this is so critical and this is so important that even our most trusted employees still have to go through quite a few steps.

2:09So, for example, when someone is investigating an issue with, hey, and emails aren't being delivered or there's something else wrong, they usually have to go in and look at the database. But right from the get-go, we knew that if the staff we had had full access to the data and just through their normal course of business, their normal investigations, their normal help of customers were exposed directly to emails and the subjects and the rest of it, that wasn't going to be something we'd be comfortable telling customers. In fact, it goes further back than that when we were building Hay, I was trying to get my wife to use it because I thought like, hey, you write a lot of emails.

2:54Wouldn't you like to see what we built? And the very first question she had was, wait, can your employees read my email? And my answer at the time wasn't just like spot on, really clear. It had to be built up because I was like, you know what? Technically, you sort of kind of they could. So we build up this defense in multiple layers where the emails themselves are encrypted. When we do normal service on the application and we're on the console, on the terminal, exploring these things, the data is just encrypted. You have to basically unlock any type of encryption. And when you do, you have to put in a reason.

3:31This is why I'm unlocking access to the encrypted data. This is why I'm looking at it. And not only is there a log of that made in the system, the log is then reviewed by other people. So this is sort of the double binding of not only are we taking notes here, like there's a bit of a camera, the detailed camera recording all the sessions of exactly what happened, how the data was accessed, and then the reasoning why someone needed access to that data. And then on top of that, there is another team or another individual reviewing that. Like that's probably the most severe process we have because it's about the most severe data access that we have.

4:12Right. The rest of the business, very, very different. Our default is that we will trust people to not delete things that shouldn't be deleted. And therefore, in Basecamp, for example, there's no confirmation step per se. There's no access control where only some of the employees of 37M signals have access to creating new things, to deleting things in existing projects. We rely on the fact that we hire trustworthy people. And by the way, when something is deleted, it goes into that trash can. It's going to sit there for 30 days before it gets expunged. And that's enough. Like most of the time, this just isn't a problem.

4:53And not only is it not a problem, when you set up your organization this way, where your default is to trust the smart, capable people that you hopefully hired and you did some of that betting up front, everything just glides so much easier. There's nothing where you have to tap someone else to do something for you. There's no escalation path. There's very little asking of permission. That's not just in the software. It's also around things like expenses. I remember back in 2001, I think it was, I was working at this tech company in Copenhagen and I needed some books. I was reading up some JavaScript stuff.

5:33And at that time, we were buying paper books and I wanted to get some O 'Reilly books, I think it was. And the process I had to go through just to get approval for spending, I don't know,$50,$100 on a set of books just felt completely demeaning, actually. You're like, you're paying me a very nice salary and I have to talk to multiple people to spend money on developing my skills that I can apply to the reason why you hired me? Why? What are you trying to save here? You're trying to save just$50,$100 while you're spending thousands on me? How does that make any sense at all? And I really took that experience to heart and like, you know what?

6:17I don't want that. if and when I started running my own company, there's got to be like a pretty high ceiling or floor of what requires someone to ask for permission. And it's got to be so high up that, do you know what, for the vast majority of purchases, for the vast majority of time, it's just not something we're going to bother with. Because then everyone can just roam around on their own, get what they need to do the job that we hired them to do. And do you know what? then we can look at some expense reports and whatever else next month or next quarter will follow up. And if there's something that's grossly out of line, which, do you know what?

6:58A couple of times over those 20 years, I've looked at some expense reports for a couple of things and went, do you know what? That deserves a follow-up conversation. That wasn't money wisely spent. And so what? So what? That's the key insight, I think, here is if you start with a presumption of trust when it's not about critical customer data, but all this other stuff, the 95 % of the rest of the business that doesn't fall under that, you can just go back and revisit things after the fact. How bad could it be? How much money, for example, let's say you You set a ceiling of$5 ,000 or$10 ,000 or whatever it is that employees can purchase at their purchasing limit.

7:44And then you go back and visit it after the fact if it turns out that something isn't quite right or the general guidelines as we have them, which I think it's still in the handbook, which is, here's a company credit card. And the policy, generally speaking, is spend it wisely. Yep, that's exactly what it says. And I think it says, like, if you need something to do your job, you should buy it. Like use this credit card to buy this if this helps you do your job, which I remember when I first started and read that because I have worked for organizations where there's this whole expense approval.

8:16I want to go to this conference and you have to write up, but whatever. It is not like that here. It's you have a card. If you feel like you need it, spend it. And I honestly think that freedom has made I can't speak for anyone else, but for me, I'm actually super cautious about what I spent recently. David, you're like, get a new camera. And I'm like, I didn't really want to spend your money because I know that it is truly your money. And because there's profit sharing, it's all of our money at some level. Like as people are spending, that is reducing our profits, which then gets distributed to employees.

8:50So I think we're all super conscious about that. I do think that helps to give everyone at the company a feeling of having a stake in it. And we didn't always have that. And I will say, do you know what? It actually worked out pretty well even when we didn't have that, but it works even better now. And what I find is exactly as you say, when we had that conversation about you getting the fancy camera, the Sony FX30 that both Jason and I have been so happy using, that's very emblematic of the problems that I generally find with this policy, that I have to push employees to actually spend money on things that'll improve their daily work.

9:31And I've seen this with computers as well. We've had a number of times where folks have hung on to computers that were sort of past their due, where there was just something substantially faster available. This is something that's come up now that we switched to Linux and Linux is so much faster at running our test suite. And now we run local tests. I've had to literally push a A couple of people like, just get the framework desktop. Just get the spec'd out version. It's not that much money. A$2 ,000 computer. Do you know what? How much time does that have to save you in a month or two before it's earned its key?

10:12Not very much time at all. And then there's just even beyond the mere cost benefit analysis. There's also just the joy analysis. I have the best tools available to me and I really like working with them. I think that in and of itself is a wonderful reason to splurge sometime on some really nice equipment that just makes your job more enjoyable. And a fast computer that runs the tests or whatever else that you're doing, that's really one of those key things. That's a key material that we use to do our entire job. So I'm keen to push the employees that we have to spend money on that kind of stuff.

10:52Now, at the same time, I'm also incredibly eager to compress all the expenses that we don't need, that we don't feel contribute to that sense of satisfaction in the job. I mean, the most famous example that we've talked about on this podcast many times was exiting the cloud, that there was a bunch of expenses there that were in a completely different class, literally millions of dollars every year. It did not contribute to that sense that like, oh, my God, work here is wonderful. And when you take those$2 million a year or whatever it was that we ended up saving on the cloud exit and you then apply our profit sharing plan to it, it's actually meaningful money that sort of filters through that entire process into the pocket of individual employees here.

11:43So I do think that's a really nice kicker on top. I'm laughing because at the last meetup, I was sitting by a programmer and was doing some video editing, which, you know, video always just like drains a computer. And I'm getting the spinning beach ball. And he looked at my computer, was like, Kimberly, you need a new computer. Just go buy a new computer. So I think there is that trust. I think people do look at it very seriously. Like, I want to make sure I am not extending beyond what I should because they've given me so much trust. And that's definitely my general impression of the vast majority of people.

12:19But I just do want to caveat it by saying that occasionally you're going to have different conceptions of what's reasonable. As I said, a handful of times, if even that, over 20 years, there have been instances where I thought, like, you know what, that's not reasonable. But the key is, what's the price of cleaning that up after the fact? And by cleaning it up, it's usually just about making clear that we're on the same page about what's reasonable. It's not even about like the money that was already spent. Who cares? In most cases, it's about making sure we have the right norms going forward for how money should be spent here.

12:57And if someone needs a reminder or two about how to calibrate that, it's fine. We have those calibrations about all sorts of other stuff, like what's the quality before feature goes out the door? How's our production environment? All these things are things we talk about. But when it comes to money, I find that there are a lot of executives who are sort of overly concerned about making a mistake and then feeling like they can't undo that. And that's when bad preemptive fences are put up. This is one of the things we write about in Rework. Don't scar on the first cut about policies, because that's usually how it goes, right?

13:37Like a lot of these expense policies, the more draconian they are, the more likely that there is like this one anecdote attached to why the policy is the way it was. Because this one time Ben just went to town and just splurged on super expensive hotels and whatever room service. And now we need an expense policy. He would very clearly define things. And could it also just be that Ben needed a conversation, that you needed to have one conversation with Ben saying, you know what, this isn't reasonable. Look at this. Come on, dude. And then that was the end of it. And then everyone else did not have to carry around that policy cut for the rest of days.

14:21One of the examples I often see in physical offices is that like there'll be this sign like your mom is not here. Clean up after yourself or like don't leave dishes in the dishwasher. Again, I know why that sign is there. It's because the one person just was a bit of a slob. And policy is a way for executives Sometimes HR and other people Who have responsibility for the behavior of others To like, ah, do you know what? I don't want to have that conversation And that feels a little uncomfortable To go directly to Ben And tell Ben that that's not okay So I'll make a generic general assessment That feels less confrontational But all that has a price You're making everyone in the organization Just carry the cognitive load of one of Ben's fuck-ups until the end of days.

15:13Not a good trait. Yeah, okay, so as a remote organization, I feel like there has to be trust in general. I think people going back to the office, they feel like, oh, if I see people working, then that's gonna somehow be better. Talk me through the level of trust when we're remote. And like, how do you know? We have people ask us this all the time. Like, how do I know people are working? How do I know that they're not wasting their time? I think that's a trust thing as well. It really is. And it was the number one question Jason and I was asked during the pandemic when a lot of organizations suddenly had to switch to remote and were very uncomfortable with what that entailed in terms of trust.

15:52And my answer was first to focus on who's someone's manager or leader. That person needs to be able to gauge the quality and the pace of the work. That is literally why they're in that position, that they're there to oversee a number of individuals and gauge the quality and the pace of the work. If the quality is no good and we're pushing out bad work, you know what? That's a conversation. If the quality is all right, but the pace is way too slow, that's a conversation. Managers should always be in the loop on both of those things. Now, quality and pace are occasionally derivatives of time spent in chair.

16:35That's true. For someone to put out good quality work at a good pace, those expectations usually line up with full-time employment in a lot of cases. So that means spending, I don't know, about eight hours in front of the computer every day, a little more, a little less, depending on the task at hand. But so many managers, it seemed, especially at that time, had kind of stepped over the whole having to gauge the quality of the work and having to gauge the pace of the work and just went straight to the derivative. How much time is spent in the chair? And if I can't see the person in the chair, well, suddenly my main enforcement function and my main supervision function seem like it's lost.

17:17And then there are a lot of managers who suddenly feel like they're flying blind. Well, you're only flying blind because you're looking at the derivatives. Look at the actual stuff that's being produced. Now, I say all that. And then I also say that we have protocols and practices at 37 Singles to keep that top of mind. Is the quality and the pace proportionate to where that person should be for their level? Now, I expect very different quality and pace from a junior programmer than I do from a principal programmer, for example. But both of them have to answer our two questions that pertain to work.

17:58The Monday question, what are you going to work on this week? And the end of the day question, what did you work on today? And then finally, net sum of all the work done in the past six weeks gets summarized in the heartbeat that the entire team puts out, right? So you have these barriers to make sure that everyone is at least radiating the information of what they're working on. So that you as a manager, most of the time, just can assume that things are going well because you hired good people. And then occasionally you can just have a notch, have a look and see like, is the work product good enough?

18:35Is it coming out on pace? If it's not, let me just scroll back a little. Let me look what Ben. Poor Ben. Now we're picking on Ben. I'm picking on Ben because we don't have a Ben at 37 Signals. So I'm just going to scroll back through Ben's answers over the last six weeks or maybe sometimes even longer. What has Ben been up to? What has been working on? Does it feel right? Maybe I'll peer in and have a look at some of the pull requests or something else like that. And then you can get a really good sense of whether folks are on it. And do you know what? These things aren't so mystical. The people who put out great work at a good pace, they tend to spend the hours in front of the computer.

19:11And do you know what? If somehow the fantastical thing could happen that a principled programmer here could in 10 hours a week produce what appears to me 40 hours worth of progress. Do you know what? Good for them. I haven't ever seen it. I've never seen someone be able to perform at the level that they're at, principal or lead or senior or junior, in like a dramatically lower amount of time than anyone else. Because if they can do that, they're usually due for promotion, right? Like we're giving you tasks that are too easy or projects that doesn't require enough of your capacities and you're able to just sail through it.

19:52So it just really isn't a problem. But I do think it can be a problem in organizations where there's already a bit of an antagonistic relationship between the manager and the employees. And if the employees know that the manager doesn't just know anything, he's a fucking bozo, right? In the Steve Jobs term of it, right? doesn't know the work, doesn't know the quality of it, doesn't know where the pay should be, and is treating us perhaps not so nicely. Maybe there's not that much trust. Maybe there's a lot of bullshit red tape. I can see the temptation that someone could go like, do you know what?

20:28Yeah, I am just going to work five hours a week. Or I am just going to work 10 hours a week. They can't tell anyway. And if they can't tell anyway, I think there's just something really important loss in that connection between manager and worker that is a breeding ground for this kind of apathy or even antagonism that someone might screw pop up. So I'm not discounting that this can't happen, that you let someone work remotely and they just totally blow it off because you're kind of already at war. But my advice would then be like, fix the war, like make peace, Find some managers who know the work, who know the pace.

21:08Find a way to reset relationships. Because just forcing folks to be under your direct supervision is a really poor substitute for doing the job that a manager is supposed to do. And by the way, it usually doesn't even work. The delusion here is in part based on the notion that if someone is sitting at a desk in an office, you can rest assured that they're being highly productive. Do you know what? I've sat at more than a few desks for more than a few days early on in my career, and I totally blew them off, right? I just wasn't engaged in the work or whatever. So I know you can skirt the work at the office too.

21:49Maybe it's a little harder. Maybe there are a few more constraints on it. And maybe if the rest of the organization is dysfunctional in other ways, it can help. I'm not going to say that. but it should not be a reason to pick remote or not remote just on the basis that I don't trust my employees. Well, fix that problem. I also appreciate because it's such a high level of trust. It feels like as an employee that you're being treated as an adult. When in other organizations, you're like, I feel like I'm having to be babysat for no reason. When like I'm a competent adult, why can't I just operate like an adult?

22:24So I feel like that it's a very different vibe when there's that level of trust. And I think what happens in some organizations is that employees will live down to the low expectations you have on them. Just as much as they'll live up to your high expectations of them. In most cases, if you have low expectations and you're treating people like you have low expectations of them, there's going to be some of that. How can I game the system? Oh, they tell me I can't spend money on the essentials. Well, how can I just spend a bunch of money and book it under bullshit category in the expense report, right?

22:59Like then it can become a bit of a game of how can I evade these nonsense processes. And I think you're really off in the deep end when that's even a temptation that something like that can happen. It's just simply so much more pleasant to work both as an employee and as a manager in an environment where the default is we trust each other. And we trust each other because we have our eye on a little trust battery here. We have our radical candor. We tell people when they fuck up. We tell people if they're not keeping up either. And we pay attention. And when you do all those things together, occasionally you got to say, do you know what?

23:39This is not the right person in this role at this company. We're going to part ways with them. And when it is someone who's in exactly the right role and they're doing a phenomenal job, we're going to promote them as quickly as we can. to the level that their talents demand. And you know what? Start doing all that. You can end up with a lovely place to work. Okay, last question before we wrap it up. I think part of this, of building a trustworthy organization is having trustworthy people. How do you, and I think I know the answer, but how do you figure that out in the hiring phases? I mean, there's no background check.

24:18Like how do we know if someone is worthy of this level of trust? We don't. There's no certainties. There is always the possibility that you hire someone who is just really good at deceiving you. I try to remember, I don't think we've had a single individual I would apply that label to. Really? That someone made it through our hiring process and they came in and they were told, actually, that's not true. I just think of one instance. The person did not get hired, but they got very, very close. So we had one opening where someone did apply and I think it was like their CV. It was their CV. It had a bunch of things on them, places that they worked.

25:01And right before the confirmation hearing on the person, we're just about to hire them. I think it was Andrea just checked. just routine checks yeah and turns out the person was just a fraud oh wow like had listed companies they never worked at in positions they've never worked at and the reason it stands so much out to me is like that's literally the only time in 25 years where someone is malicious in that way now maybe the kind of candidates who otherwise would be that like out of a thousand applicants Is it entirely possible that maybe, I don't know, 10 of them or 50 of them or even 100 of them fall in that category would willfully deceive us?

25:44That's possible. But is it possible that they're willing to do that and then they're also like really good at their job? Like totally blowing us away with amazing code. They ace the interviews that we do with someone in person. They just fool us all and they exhibit extraordinary skill. Do you know what? I don't think that's very likely. It's not necessary. If you're really good at your job and you can show us amazing code or fantastic designs or any of the other tests that we apply to candidates, you don't need to be a fraud. So I do think that has a sort of filtering function where at other companies where if you're mainly hiring on, I don't know, bingo matching their buzzy keywords on their CV and the entire process is driven by HR and there's not any take-home test or whatever, and you can bullshit your way through.

26:39I do think you're probably more likely to end up with someone who is a fraud, but you do all this other work to ensure that you hire someone who's really good at their job. No one has ever made it in or at least never made it in and then we discovered it, which to me is all the same. Like if someone got in all the way and they were somehow frauding us while also doing a spectacular job, I'm almost like, you deserve it. There was a case of this in the media recently where there's one guy in Silicon Valley, I think he had like four or five jobs. Oh, yeah. And none of these companies knew that that person would know.

Read the full transcript

27:14First of all, I mean, that's not nice. You should not lie to people. But also, do you know what? Lions share the blame here, lay with the companies who just had this person on payroll for I don't know how long and never discovered that they didn't put in the work or the work wasn't at the quality or the pace that it should have been. Yeah. Well, on behalf of all employees, we appreciate the trust. With that, we're going to wrap it up. Rework is a production of 37 Signals. You can find show notes and transcripts on our website at 37signals.com slash podcast. Full video episodes are on YouTube. And if you have a question for Jason or David about a better way to work, run your business, leave us a video message.

27:53you can do that at 37signals.com slash podcast question.

From the publisher

Trust is the foundation of any strong company. In this episode of The REWORK Podcast, 37signals co-founder and CTO David Heinemeier Hansson joins host Kimberly Rhodes to explore what it really means to build a high-trust organization. David shares how trust shapes the culture and success of a team, even when working remotely.

Key Takeaways

  • 00:23 – Trust starts as the default at 37signals
  • 05:19 – Empowering employees with reasonable spending freedom
  • 11:46 – Why one person’s mistake shouldn’t lead to restrictive policies
  • 15:15 – How to cultivate trust in remote workplaces
  • 22:10 – Trust and accountability can and should coexist

Links and Resources

More from REWORK

All 44 episodes
Built on TrustREWORK · 28 min
Listen in VO