Zoosk R&D – A Retrospective
Earlier this year, Zoosk decided to try something a little different with our hiring and onboarding process.
Every year since I’ve been with Zoosk (3!) we have roughly doubled our headcount in Engineering. And each year, that process has come with new challenges.
- How can we keep quality high?
- How can we keep an open and positive culture?
- How can we keep process and bureaucracy to a minimum, and still work efficiently?
Well we began 2012 with around 30 engineers on our team, and we expect to close the year with almost 70! That still blows my mind.
A lot has certainly changed since the days when we could count our engineers on one hand, but I can honestly say that we have managed to keep a lot of the attractive cultural aspects of a small startup. Some startup-y things have been lost, but we’ve gained some great new things as well, and I think that R&D is a great example of that.
This year, it became obvious early on that our old way of onboarding employees would not scale to satisfy our hiring needs. In the past, we’ve done what most companies do: throw the new hire straight onto a team and ask them to start swimming. With talented people, this approach works. They pick things up quickly, and rapidly begin contributing. But at our current size, it also has some pretty big negatives. For one, every team has to have its own onboarding program. There’s a lot of overhead in that. More importantly though, we’re large enough that this approach means new employees would never gain a broad understanding of our product. We think that being broadly informed is critical for engineers to make good decisions.
So we took a look around at how other companies handle this, and a number of us agreed that Facebook has one of the most outstanding examples in their “bootcamp” program. For those unfamiliar with it, Facebook’s bootcamp is a training team that every new engineer passes through. There they work on a broad range of products before heading to a specific team. We like that concept a lot, but we still wanted to do something a bit different.
The best way to explain Zoosk R&D might be to look at how we picked a name for it. At first we called it Zoosk University, because we thought it would be purely a training program. But after a bit of thought, we realized that it could be much more. Why not take these new employees, with all of their excitement and new perspectives, and ask them to do something new? In this way, we would get both a training program, and an incubator for new ideas. We toyed around with calling it “Zoosk Labs” to convey this concept (and personally I like the aspiration to the legendary Bell Labs), but that also felt a bit one sided. This was a program for both exploring new ideas, “Research”, and training new employees, “Development”.
Zoosk R&D.
Our idea was that every so often, a lead engineer would take a small group of new hires and act like a startup for 2-3 months. For the inaugural session, we decided to create a new feature, which we ultimately named “Zoosk Engagement”. This would be a social wedding planning tool. It would reuse a lot of our existing architecture, but recombine it in a new way to help people manage and plan their weddings. Making it work would require working with our APIs, databases, platform services, UX design, and much more. We built a content feed, tag clouds, a bookmarklet to help users share content from the web, and tied it all together into a simple, fun experience.
I had the opportunity to lead this first session, and we learned a lot.
1. Zoosk R&D is an opportunity for everyone.
This turned out to be one of the biggest surprises. We thought that it would be a good thing for the new people and the person leading the team. What we didn’t anticipate is that it would offer so many opportunities to our existing employees. Many of our engineers are interested in exploring different roles, and this gave us an easy way for them to try it out. We had a mobile developer with a talent for product design volunteer to PM the project. We had “point persons” on the core teams who got to be both a mentor and a representative for their teams. We had people from marketing, developers, UI designers, and more, who all got a chance to step outside of their normal roles in some way or another and try something different.
2. Move fast and break things, and still put your users first.
I appreciate the sentiment behind Zuck’s famous philosophy, but I dispute their attitude that being a “coding ninja” requires you to allow inexperienced developers to run straight into the fray, guns akimbo. You end up doing silly things. I would also argue that our R&D strategy actually gives new developers more freedom to move quickly and break things. They’re nervous, and they suspect that no matter what you say, deep down maybe you aren’t really totally okay with them taking down the site. By putting them first into a realistic sandbox, and still keeping the pressure to deliver high, we get the best of both worlds.
3. Power to the newbies!
Everyone still starts with a few bug tickets, but I heard over and over again from the new hires how great it was to have immediate responsibilities of their own. I love this. I’m a big proponent for delegating not just tasks, but responsibility. People crave this stuff, and it motivates them. They work harder, you get more from them, and they’re happier and more satisfied at the end of the day.
4. Flexibility
When we started our first R&D session, we thought the new folks would be headed to our API and Web teams. They all ended up on our Mobile and Touch teams. This was a surprise, but it worked out perfectly. By the time we wrapped up, it turned out that those teams had the greatest hiring needs, and the new hires all got to participate in the decision after seeing how the company works.
Our next session starts in about a month, and I can’t wait to see how the program evolves. If you end up working at Zoosk some day, I think you’ll find the R&D experience totally worthwhile, and a lot of fun at the same time.
I definitely did!
