When it comes time to write the social code we call organizational rules or team practices, make heavy use of the standard library that comes factory installed inside all of us. That standard library is Human Nature. --- Let's take a random example of an area where processes tend to be imposed in many different baroque time-wasting and unnecessary ways: Pull requests in software development. What's the right process for pull requests? We believe the right approach to these questions is to outsource the decision to human nature, or to put it more simply: Imagine asking grandma. 1: Grandma, what's the right process for pull requests? 9: What's a pull request dear? 1: It's like asking permission. 9: Permission for what? 1: Like when we're all working on a project together. 9: What sort of project? 1: A fence. Imagine we're building a fence together. 9: Oh, I see. What's a pull request? 1: It's a way of asking permission. To change the fence. 9: I thought you didn't have a fence yet. 1: We don't, we're building one. 9: Why would you have to ask permission to work on a fence you're all working on? 1: I don't know, maybe we want to add something to it, and we're not sure the others will like the idea. 9: Whose land is the fence on? 1: It's communal land, we're inside a company, so it belongs to all of us I guess. 9: Oh that never works dear. 1: What do you mean? 9: If nobody owns the land then nobody's going to take care of it. 1: Wait we've gotten off topic. Suppose we have to work this way. What's the right process for pull requests? 9: You mean when should you ask permission? 1: Yeah. 9: Well, asking permission is for when you want to change something that isn't yours, or if you want to change something you all share in a way that might make other people upset. 1: Like what? 9: Well if you want to change the direction of the fence, maybe ask permission. But if you want to wake up early and work on the fence in the direction you already agreed on, it's a bit silly to ask permission. 1: How can we tell which is which? 9: You need to know the people you're working with. 1: What if our team has 10,000 people? 9: Don't be silly, there's no such thing. Nobody knows 10,000 people. Work in smaller groups, or you'll never be able to get anything done. 1: Why not? 9: Honey the more people you have working on something, the longer it takes. --- Without knowing anything about our field, Grandma just arrived at a very important truth about software development: ask permission when you want to change someone else's house. Don't worry about asking permission to change yours. And only worry about asking permission to change shared things when the change might make other reasonable people upset. And you have to know your team, so you have an idea of what you all agree on and what you don't. Grandma didn't know anything about software development, but she knows about people. And all good practices for working with other people are true outside of software development. There's no point having a series of confluence pages on human nature. The most embarassing case of "Not Invented Here" is when a company attempts to reinvent human nature. You're not going to improve on the implementation by adding rules. All you need to do is clarify by example, as the need arises. With most people most of the time, these practices will Just Work.