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.
software_developer
on 22 May 08thank you for sharing new thoughts .. we always glad to find some new ideas from you.
also I want to note that your book is very good and ideas behind it are splendid ..
qwerty
on 22 May 08Is the cool wearing off? Posts about 37s’ culture used to stress that there are no rules, everybody was encourage to think for themselves and to act accordingly. (Example: signing up for conferences and buying books.) This sounds different and at least for me it feels like 37s is moving a little close to the culture of more regular companies that acted as counter examples when emphasizing the “less is more” mantra and Getting Real. I actually believe such rules are useful but you quickly might be less special than you used to be or, at least, sounded.
Morgan Aldridge
on 22 May 08Having recently emerged from an extremely late, and thus over budget, project I greatly appreciate these “rules”. I’ll definitely be suggesting that we adopt them as well.
Regarding qwerty’s comments: these sound like simple guidelines to encourage people ask for help and let others know what’s going on, not rules that are holding people back from, “think[ing] for themselves and act[ing] accordingly.”
sunchin
on 22 May 08qwerty,
that is silly.
this is completely in line with an agile or “getting real” methodology. it’s all about making sure nobody is wasting their time.
good post.
leethal
on 22 May 08Who is the author ‘37signals’? Stuff written by.. all of you peeps? Weird.
David
on 22 May 08“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.”
What a novel idea. Next thing you know you’ll think of something realluy ground breaking like to-do lists.
Nicholas Henry
on 22 May 08[sunchin] I agree, the rules described are all about “getting real”. [qwerty] They not detailed procedures mean to hinder, they are guiding principles that keep you on the right track, moving forward. They keep you sane.
Great stuff.
Don Schenck
on 22 May 08So 37 Signals has a built-in structure whereby you help people to not get lost in the slog.
I like.
ML
on 22 May 08Who is the author ‘37signals’?
Typically, posts that show up authored by “37signals” include content from multiple authors.
Ben
on 22 May 08Sounds like 37signals is having some growing pains. Its gets harder and harder to be lightweight and agile with all those projects and employees.
JF
on 22 May 08Ben: We’re just open to change. If something isn’t working, we try something new. If that doesn’t work we try something else. We’re always looking for new and better ways to work together. We’re far from perfect — there’s lots of room for improvement.
None of the ideas we posted on have anything to do with size. If we had three people we could still be working too long without looking up. If we had 5 people we could still be almost finishing things without taking the initiative to prep it for launch.
We’ve dabbled in a variety of work methods over the years and will continue to refine through experience.
Peter Urban
on 22 May 08I think it’s great that you guys share what works for you and what doesn’t even if the cult that comes with your success sometimes bites you in the back with sarcastic comments. Keep it up, there are plenty of people that see it for what it is.
Robin Chauhan
on 22 May 08Can someone enlighten me as to what “judo” means in this context?
JF
on 22 May 08Robin: We use “Judo” when we mean “How can we chop this big problem down into a bunch of small simple problems.” The Judo solution is the simplest solution we can come up with that solves enough of the problem to move forward.
Ben
on 22 May 08Ahhhh!
I just got owned by JF.
Richard
on 22 May 08We have met the unending time line challenge by implementing a 5 week (actually 4 week read on) cycle. This works for us on an existing product we are adding to. It may not work in a pure R&D phase.
Week 1 – Planning low hanging fruit work. Plan out the two week dev cycle, support any new production issues from previous release and pick any low hanging fruit opportunities. NOTE: All planned work must fit into the two week cycle otherwise it is too big.
Week 2&3 – Develop
Week 4 – QA and Debug.
Week 5 – Beta with select customers and production launch after successful beta. This week overlaps with week one.
By having week five overlap with week one we can actually extend a week for contingencies. Our whole company has subscribed to this management, sales, support, training, etc. Even our customers are now starting to talk in this form and are comfortable knowing how things progress. This also allows us to publish the new features that will be release at the end of the dev cycle with everyone having confidence they will be there.
Steffen Hiller
on 22 May 08Nice Post. I think that “owning a feature” is an important rule. How long does someone actually own a feature in your team? Forever? I would think forever would be a good “rule”. That also would increase quality of that feature, because the one working on it will have to face user feedback and possible bug fixes and changes himself, so he better makes it right now, instead of coding quick but dirty solution. On the other hand, I’m not sure if “quality of code” is a problem in your team, since you have the privilege (which you earned yourself, of course) to have very good people. But I guess even the best people can get tempted to finish something fast with 90% instead of 100% of their effort if they don’t own the feature and therefore are not fully responsible for it’s quality.
Pavel Pichardo
on 22 May 08We have implemented that first rule you post, and it works great. I think that the best way to get things done, you need someone to worry for it and press a little the other involved in the project.
tyler
on 22 May 08“If you’re working on the feature, you own the feature. You’re responsible for involving everyone that needs involving. And do it forcefully.”
Amazon basically used the same idea and I think it’s a good rule. If you are the owner then you own it all: building, deploying, and operating. That said, if every time you want to get something done you have an uphill fight (whether that be technology or people) then it can get quite demoralizing.
Wilfried
on 22 May 08If 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!
A good idea, it works great with many designers who need to be worried to finish projects; but I think too that some of them doesn’t want to be worried…
J Lane
on 22 May 08Great post.
I love posts like this because they can apply everywhere, they’re as much true for a team as they are for an individual. Owning the launch would have helped me immensely in a past life—now as an “army of one”, I have no choice but to own the launch.
I love the 2 week concept though. I think that you had written previously that things that take longer than 2 weeks are probably too complicated and should be further broken down. Good call here.
Matt Radel
on 22 May 08I agree that the 2 week concept is swell. Very refreshing…long projects can be a friggin’ drain at times.
eric
on 22 May 08eh, yes and no. I worked at shop as the sole designer/UI guy and the 6 developers all came to me on Fridays (push day) to make their stuff ‘pretty’.
Usually I tried to get ahead of the curve by providing mockups/templates before the guys started coding (isnt’ that what 37 does?)
Brian Scates
on 22 May 08So you’ve basically adopted SCRUM without the daily meetings?
Clay Johnson
on 22 May 08There are a lot of new names in that Who are 37signals box. Who are these folks? Congratulations regardless!
Jeff
on 22 May 08Sounds like a couple of policies, to me.
Steffen Hiller
on 22 May 08Clay, that folks has been there a while, they add them one at a time,
but,
Jason, I would love to see a timeline who started when, and what they actually do, (and how I’d fit in your team). ;-)
JF
on 22 May 08Usually I tried to get ahead of the curve by providing mockups/templates before the guys started coding (isnt’ that what 37 does?)
Yup, that’s how we do it. But there are always tweaks and adjustments required prior to launch. Usually a string of little things. That’s why the designer comes back in near the end.
This discussion is closed.