Without both these types of trust, an organization is going to be inherently unpleasant: - trust that your coworkers are competent code-wise - without this, yo

Without both these types of trust, an organization is going to be inherently unpleasant: - trust that your coworkers are competent code-wise - without this, you're gonna get frustrated that you're constantly having to clean up after them and catch problems they've created (whether in a PR gated process or later when you find the problem they already committed - note that this isn't solved by PR gating because someone else less competent might have approved the PR anyway) - trust that your coworkers aren't going to be annoying with their reviews - you cover this one, you'll be constantly blocked if you can't trust that When people complain about very large organizations and teams being too bureaucratic and annoying it's because their organization hasn't figured out a way of scaling that trust. There are coordination problems that become very hard: hiring quality bars for interviews; alignment on what to focus on in reviews; even just "my opinion on what code I can be trusted with" vs "the domain expert's opinion on how much I can be trusted with that code". So process is created because "trust" doesn't scale to huge networks of people. The author mentions TDD, that's just an automated form of process because honestly, you shouldn't even trust yourself with some things when it comes to code. ;) But in a huge org you can't even trust everyone else to be on the same page, and that causes friction if you want to go fast.