Thanks. I'm one of the founders @ Rethink, and project/engineering management is my job. The dev team here is simply amazing. It's not false modesty -- I've been busy with some administrative aspects of the company for the past month and haven't been able to put any time at all into project management. The guys just took the issue tracker and ran with it -- I woke up this morning to discover that we've got a new release.
So, my hat is off to all the DB Rethinkers. It's an honor to lead such an amazing team.
EDIT: I do hire people and occasionally set the tone, so I deserve some credit :)
I wrote the multi-index code and got this release shipped so I guess my opinion might be worth something on it. The answers I read to questions like this normally strike me as very tautological. Things like "you need your team to be well oiled and to have very specific goals". It's not that that's false, it's just that we normally judge a team's well oiledness by how quickly it releases nice things. So I'm going to jump over that, our team is plenty well oiled and getting better all the time but let me tell you how I think we got there.
For us the secret was getting in repetitions. We started by building and releasing one thing we were really proud of, our process for doing it was adhoc and broke down in a million places but we slogged through. Then it came time to build the next version, this time we did some things better and a lot of things we didn't do better. This was our 10th major release by now it feels like we're doing a lot of things better. The most satisfying thing about it is that it's not totally clear to any one of us where all the inefficiencies went the knowledge of how to release quickly isn't stored in any single brain.
One thing I think is an absolutely crucial aspect of this process is making it discreet. During a release cycle I take our release process as absolute. I try as hard as I can not to even think about ways to fix it. Between release cycles I step back and look for ways to tweak the process and ignore 1st order feature development. I'm not sure what it is that makes a discreet process work better, it might just be that it frees up mental bandwidth, but if you find yourself getting bogged down in the process of releasing rather than actually releasing while you're trying to develop the product to release try shutting off half the equation. It's helped me a lot.
Also another way to solve this is to have separate people focus on each aspect. That can be tough at smaller companies because so much communication needs to happen between the 2 but it certainly can work.
