A couple of new internal rules at 37signals that we thought we’d share:

Owning the launch too
Lately we’ve had a couple of features, fixes, and tweak lately that have been sitting idly done waiting either for deployment or for input from someone else like design.

So we’re establishing a ground rule: If you’re working on the feature, you own the feature. You’re responsible for involving everyone that needs involving. And do it forcefully.

If you’re a developer and you need input from design, grab a designer and tell them that the feature won’t launch until they deliver X. That’ll get ‘em fired up to get it done!

If you need to have the feature deployed and you’re not confident doing it on your own, book a specific time with Mark to make it happen, so you both can be around.

It feels great to be done with something on the programming side and then feeling free to move on to the next thing. We all do that at times. But it’s not really real until our users are able to enjoy it.

The 2-week plan
We’re also worried that we’re keeping our heads down too long on projects. We’re not stopping, looking around, and deciding where to go next early enough. Things are lingering too long without reality checks.

So here’s the rule moving forward: If someone is working on something for two weeks, stop. Then post a message to the Basecamp project. Use one of three choices (you can also pitch multiple options):

1. Provide an ETA on completing the project and create corresponding milestones in BC for the phases/completion.
2. If you don’t see an end in sight, ask for judo help to get it done sooner. Always consider that there’s a significantly simpler solution than the one you are working on.
3. Suggest abandoning/shelving the project.

The goal here is to not let weeks and weeks and weeks pass before deciding to either judo something or kill it. We’re not using our time efficiently if we’re tangled up and not asking for help. There’s no pride in pushing through something without being able to see the end.