We’re hiring!
It’s been almost half a year since I wrote about Rypple and the Joel Test. Since then, we’ve been taking off and accelerating the search for talent. We understand that in a startup, it’s people people people. Great talent simply begets greater talent.
For those of you who are not familiar with the Joel Test, it’s a quick way of measuring the quality of a software development team. We’ve used it as a quick checklist to ensure quality. If you’re looking for a job, you can use it to as a rule of thumb to see whether you’d like working here.
In January, we rated 11 out of 12. In the meantime, things have changed. Let’s see how we did (previous rating in parentheses):
1. Do you use source control? yes! (yes!)
2. Can you make a build in one step? yes! (yes!)
3. Do you make daily builds? yes! (yes!)
4. Do you have a bug database? yes! (yes!)
5. Do you fix bugs before writing new code? yes! (yes!)
6. Do you have an up-to-date schedule? yes! (yes!)
7. Do you have a spec? yes! (yes!)
8. Do programmers have quiet working conditions? yes! (yes!)
Update: Since January, we’ve been expanding our office space. We’ve split into Rypple Enterprise and Rypple Core development teams and moved to separate rooms. This arrangement has allowed us to collaborate and yet keep distractions to a minimum. Of course, there is a lot of overlap and the development team meets regularly to communicate changes and reflect for Kaizen.
9. Do you use the best tools money can buy? yes! (yes!)
Update: We have stacks and stacks of relevant texts, rocking development setups and the entire team was just at Mesh. Still no Rock Band, but we do have Nerf guns now which means that we have to be prepared for an ambush at any time.
10. Do you have testers? yes! (yes!)
Update: Last time I provided a glimpse of the testing mentality at Rypple, that the entire Rypple team are testers, right up to our CEOs. Having everybody care about the quality of the service is a good thing, however, there is one little snag that the “Everybody, Somebody, Anybody, And Nobody” story illustrates (Dan had sent this to us with regard to getting a Support rotation set up, but it applies just as well to testing).
Couple this story of accountability and responsibility with flying full-speed and rapidly churning out new features and I’m sorry to say that for a period of time, quality suffered. So, the development team met and decided to designate a Release Manager rotation, making the Release Manager responsible for QAing the items going into the weekly release. The Release Manager was also the Support person for the upcoming week, so it was in his best interest to do a good job QAing! If I recall correctly, it was Ryan who introduced the idea but the rest of the development collaborated to work out the clinks.
11. Do new candidates write code during their interview? yes! (no)
Update: Writing code during an interview is something that we’ve debated about on the development team. On the one hand, who would hire a photographer without seeing his work? On the other, you wouldn’t necessarily have him shoot something on the spot. So in recent interviews, James Tam and Ryan would do the technical chats while Tiho and I would dig a bit deeper. On the usability side, Jay and James Wu also test the candidate with a usability design exercise, so we’ve covered on all bases.
12. Do you do hallway usability testing? yes! (yes!)
Update: Previously, I noted that we constantly pick James Wu’s brain when it comes to usability. In the meantime we’ve also brought Jay on full-time to boost our usability and design profile. If there’s one thing that separates Rypple from other companies, it’s the premium we place on usability. I don’t know what the proper ratio of designers or UX experts to developers is (it seems to vary from 1:4-6 to 1:50), but our current ratio is 2:4 and that’s definitely unusual.
We’ve also just had a 2 hour session over lunch today to walk through design decisions to improve a first time Rypple user’s experience (after looking at data that pointedly noted that this is one area we could improve). The entire team was involved in the decision making, with James Wu taking the initial cut and leading the UX design. Needless to say, this is an expensive exercise that doesn’t happen everyday, but pays off immensely as everybody is involved in the product and learns a little UX.
So, we’ve made some improvements to our process. In true Agile fashion, we do make mistakes but try to correct them with each iteration (Kaizen). We’re doing well on the Joel Test and we hope that continues to translate into a delightful, simple and useful Rypple experience for you.
How do you think we are doing?
Recent Comments