Came up with these rules at MetaOlin tonight to make our group run smoother with fewer collisions and meetings needed.
When in doubt, email. Get information out to the entire group as quickly and easily as possible. Don't worry about polishing it, or even about it being terribly useful; sometimes it's not so much about edifying everyone else as it is expressing yourself in a way that enables you to move forward. Also note that this is about getting information out, not waiting for a reply back; it's a "tell, don't ask" philosophy. Email is mentioned here because it's a medium guaranteed to reach all members of the group with equal clarity and roughly equal latency, and also creates a record of the transmission; other media may be used as well.
If you have something to say, say it. We're all smart and thick-skinned, and we trust each other to have everyone's best interests in mind. We need to be honest, we need to be blunt, and we need to be able to say things right away and fast and trust that our teammates will take it in context and handle it in stride. If you spend more time publicly agonizing in front of your team over whether to communicate something than it would actually take for you to communicate it, then just say it already; sometimes pushing words out there just takes less time.
Ask forgiveness, not permission. All actions have to start with someone, so they might as well start with you. Unless your actions will directly harm someone or prevent them from getting their work done, go ahead and do what you're thinking of doing (and as per precept #1, email everyone and let them know). If someone has an issue with what you've done, they'll let you know, as per precept #2. It's also easier to modify and critique an existing artifact than it is to start one from scratch.
Six to freeze. This refers to the the agreement we have that all actions/features/etc are subject to debate, revision, and criticism unless it's gotten a thumbs-up by all six teammates in some way. If you decide not to ask permission (#3), do something, then let the group know (#1), recognize that some teammates may disagree and be blunt about it (#2) and that you'll have to react constructively and nondefensively to their feedback. This is intended to develop the strategy "hack early and hack often." Make quick releases, send them out for feedback, and release again; don't sink 100 solo hours into a deliverable without somehow making sure you're on the right track, or knowing that you're willing to risk not being on the right track.
Point trumps. Every project or subcomponent of a project has a point person who is responsible for making sure the task gets done whether that's through doing it themselves or getting others to do it. For matters related to a given task, the point person has the power to override all other comments, including the previous 4 precepts. We trust each other to exercise this power wisely.
- When in doubt, email.
- If you have something to say, say it.
- Ask forgiveness, not permission.
- Six to freeze.
- Point trumps.
When in doubt, email. Get information out to the entire group as quickly and easily as possible. Don't worry about polishing it, or even about it being terribly useful; sometimes it's not so much about edifying everyone else as it is expressing yourself in a way that enables you to move forward. Also note that this is about getting information out, not waiting for a reply back; it's a "tell, don't ask" philosophy. Email is mentioned here because it's a medium guaranteed to reach all members of the group with equal clarity and roughly equal latency, and also creates a record of the transmission; other media may be used as well.
If you have something to say, say it. We're all smart and thick-skinned, and we trust each other to have everyone's best interests in mind. We need to be honest, we need to be blunt, and we need to be able to say things right away and fast and trust that our teammates will take it in context and handle it in stride. If you spend more time publicly agonizing in front of your team over whether to communicate something than it would actually take for you to communicate it, then just say it already; sometimes pushing words out there just takes less time.
Ask forgiveness, not permission. All actions have to start with someone, so they might as well start with you. Unless your actions will directly harm someone or prevent them from getting their work done, go ahead and do what you're thinking of doing (and as per precept #1, email everyone and let them know). If someone has an issue with what you've done, they'll let you know, as per precept #2. It's also easier to modify and critique an existing artifact than it is to start one from scratch.
Six to freeze. This refers to the the agreement we have that all actions/features/etc are subject to debate, revision, and criticism unless it's gotten a thumbs-up by all six teammates in some way. If you decide not to ask permission (#3), do something, then let the group know (#1), recognize that some teammates may disagree and be blunt about it (#2) and that you'll have to react constructively and nondefensively to their feedback. This is intended to develop the strategy "hack early and hack often." Make quick releases, send them out for feedback, and release again; don't sink 100 solo hours into a deliverable without somehow making sure you're on the right track, or knowing that you're willing to risk not being on the right track.
Point trumps. Every project or subcomponent of a project has a point person who is responsible for making sure the task gets done whether that's through doing it themselves or getting others to do it. For matters related to a given task, the point person has the power to override all other comments, including the previous 4 precepts. We trust each other to exercise this power wisely.
No comments:
Post a Comment