Tuesday, May 20, 2008

The Right Stuff: Building The Team

This is the last post in a series of three articles on Xobni’s launch. Check out the first episode on the ideas behind Xobni, and the second post about the journey to building the right product. Co-written with Marie Baca.

This is the story of how we are building Xobni's team and culture, and the things we've learned along the way. I think the jury's still out on whether what I'm describing is the right way, but I’ve certainly learned some things along the way.

Origins

In Xobni's application for YCombinator funding, the company was called "EmailDM," where the "DM" stood for "Data Mining". As Matt describes here, Adam was also toying with the name "InboxAdvisor" when Paul Graham suggested Xobni – the word "inbox" name backwards. The domain name was still available and so we snapped it up.

I met Adam and Matt during a 2006 trip to the East Coast. What was initially meant to be a friendly brainstorming quickly morphed into a caffeine-fueled two-day coding session at 16 Elmer Street in Cambridge, MA (Xobni's original headquarters). Over the course of 48 hours, I coded a new project for Xobni. While that product was never released, the concept of coding assignments during interviews would become a Xobni tradition.

Hiring

Some months later, Adam and Matt moved to San Francisco by driving Adam's rebellious Toyota Avalon across the country. I joined as the VP Engineering, and one of my first duties was to define a hiring process for engineers.

Everyone seems to know Joel Spolsky's motto of "Smart and Gets things Done", but finding a way to easily identify that in job candidates is a different animal altogether. Initially, I modeled our interview process off of Google: tough interviews that test "smartness." In the spirit of "seeing the juggler juggle", we added a crucial component: a coding assignment where candidates are given a workstation and a project to complete. This has helped us tremendously in identifying productive developers. Instead of testing for knowledge of algorithms and ability to solve brain teasers, you can see a person's coding style, maturity, and whether they were able to complete the project on time with a reasonable set of features.

Quality Assurance

My biggest mistake during my first months at Xobni was that I didn’t bring in top-notch quality assurance talent early enough. While it
s true that Xobni’s range of functionality is not as complex as, say, Microsoft Word, the product is still exposed to a wide variety of configurations and environments: Different versions of Windows, Outlook, user permission settings, email account types, and storage types. It's no coincidence that Microsoft allegedly has a 1:1 ratio of developers to quality assurance staff.

We needed someone who would think about QA night and day. After our private launch at TechCrunch 40, we learned our lesson, and I'm happy that we found Ryan and Tyler, who have taken ownership of making Xobni rock-solid. They of old laptops, set up test accounts and mail servers, virtual machines, and wrote test plans. I only wish we had brought them on earlier!

Data, Data, Data

Historically, we've made our best decisions when data and statistics were readily available. This isn’t always possible in every decision making process, but it's a good rule of thumb to try to surround yourself with as much relevant data as you can. For example, when you’re deciding what to have for lunch, it helps if you see what others are getting, and what you ate last time. When you’re debugging an odd bug from the field, it’s best to have log files, exception counts, and more. When you're making decisions about how to grow the user base, it helps if you have data about past user growth, uninstalls, and reasons why people like or dislike your product.

At Xobni, we’ve built systems and dashboards for all of the data listed above, from Greg’s exception robot to Bryan’s product dashboard (not to mention Ryan's lunch ordering system). When encountering a problem, we like to think about when we’ll need the same data in the future, and if the answer is yes, we build a system, not a one-off solution. There’s a lot going on behind the scenes.

The Future

Xobni the product, and the engineering team behind it are growing. It's interesting to participate in this process because with every new person, our engineering culture morphs as new hires bring new viewpoints, insights, and abilities. Jeff, our CEO, has said that with every 20 people, the company feels different, which means that we are getting close to experiencing the next chapter of the Xobni story. Oh: we're also hiring.

4 comments:

Christian said...

Gabor, I like that article as well, however, it has not much to do with the title...
In addition, I wonder if you can really find out whether a candidate gets things done by letting him code something. It's definitely a good idea, but as it's limited to a very short time and leading to a direct pay-off (the candidate could get hired) it predicts future performance only to a certain extent. In addition, the candidate is not distracted by his daily business and private life during the interview. Two aspects that seem to make me unproductive quite often...
I don't have a better way to do interviews and I wonder whether it's possible to do better in that short amount of time?

Gabor said...

Hi Christian,

yeah, the title doesn't quite match the contents, but in some way, everything in there is about the team or the team's attitudes.

You bring up a good point: If you let someone write code for a few hours, you get much higher productivity than in a usual setting where there are interruptions and people have to deal with other stuff. However, I believe people who have a bad work ethic / are prone to interrupt others will give themselves away with bad code and bad habits (e.g. asking verbal questions that can be answered via a Google seach).

Ultimately, "gets things done" can only be measured via actual projects, which is probably why internships exist.

Gabor

Nick Leung said...

Gabor,
I would agree with the Google method of hiring. However, I would also look at motivation and passion. How do you find motivated candidates? There are a lot of foo and bar camps going on in the valley. These ppl, go to learn, hack, and to have a good time. Hence, you're more likely to find a great hacker, who hacks for fun and not money. At the end of the day, it's passion that drives us.

Gio said...

yep nice reading posts (the series I mean)

Basically agree on what you mention on hiring, two hours coding probably told you lots more than asking to solve problems with pencil and paper.

Wondering how you evaluate and weight personal attitude as often people performance depends not only on technical skill (for sure a pre-requiste) but also a sort of personality match with the future team.

ciao and really thanks for xobni!