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.
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.
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.
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!
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.
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 its 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.
