Culture fit just means no assholes

A lot of companies claim they look for a “culture fit” when hiring. In practice this just means “we don’t hire assholes”.

Does culture fit mean hiring people who share the same sense of humor? Or who think in similar ways? Or with similar personalities? When that 100x engineer comes along with mad skills and is incredibly nice but has nothing in common with everyone else at the company outside of work, are you not going to hire him/her because of a lack of “culture fit”?

A more useful definition of “culture fit” is whether they fit with the company’s core values. E.g. Zappos defines “weirdness” as part of their culture. However, if someone is not quirky in any way but is a great hire otherwise, would they not hire them? If they are nice to the limo driver, get along with everyone well and are functionally superb, I doubt they’d get a no.

Hiring for “culture fit” is often just a euphemism for “we don’t hire assholes”. It pans out this way because companies often have similar, positive core values e.g. humble, works well with others, determined etc. It’s rare that a company defines one trait as more important than another e.g. we’d rather hire extremely ambitious people and don’t mind if they’re arrogant. If they do, putting that into practice when hiring takes a lot more guts, especially when there’s a glut of supply in the market for talent.

I don’t think this is a bad thing. I think companies should be accepting of people with different backgrounds, interests, personalities and judge them on how they’d function on the job, and being great to work with is definitely a large part of how they’d function. But turning people away because they might not have the same personalities or values as everyone else might lead you to turn down super talented people that were just fine to work with.

Culture is a natural extension of everyone in the company. When you hire someone new, your company culture is infused with that person’s values, character and personality. This means company culture keeps evolving. It emanates from the founders and can be controlled to the extent of who you choose to hire. Nobody wants a company of assholes, but there’s also value in diversity of personalities and values, [1] so in the end, most companies are open to hiring different types of personalities as long as they’re functionally superb, have good character/integrity and are good to work with.

Have you seen a company where “we hire for culture fit” can’t be substituted by “we don’t hire assholes”? Has it been a contributing factor to their success?

[1] Perhaps diversity slows you down at the super early stages: http://www.quora.com/Entrepreneurship/Among-Max-Levchins-lessons-learned-as-a-young-entrepreneur-which-are-the-greatest/answer/Max-Levchin

Use your advantages

When I went for Startup School 2010, Adam D’Angelo, the founder of Quora, gave a talk about using your advantages. He cites some examples:

  • He used his engineering experience at Facebook to build scalable, powerful technology to power Quora 
  • He and Charlie Cheever, his co-founder at Quora, used their reputations from Facebook to seed the site with big name people from the valley, and to raise money 

You can check out the full talk at http://www.justin.tv/startupschool/b/272178681

Just last week, Xianhang Zhang wrote a post on Quora (http://www.quora.com/Xianhang-Zhang/Startup-Advice-Strategy/Disregard-ideas-a…) titled “Disregard ideas, acquire assets”. It talks about how many successful businesses are built on the founders acquiring assets long before they start their companies e.g. Joel Spolsky & Jeff Atwood having huge readerships at their respective blogs, and leveraging that to publicize Stack Overflow. He talks about how acquiring these assets takes a long time, but that they can potentially become the reason why your startup makes it.

It’s easy to find reasons (or excuses) to not be able to do something. It’s also easy to focus on why life sucks—too much work, too little time. Focusing on your advantages starts with identifying them, then thinking about how you can use them in the best way possible. For example, when you’re in college, you have access to the college network, to professors, to students. You can do a lot of things while you’re in college that will become a pain in the ass to do later in life. If the founders of Facebook were not in college when they launched it, it would have been much harder to acquire the initial user base at 1 college—you can’t send out invites to an entire mailing list, you don’t have connections to the school newspaper, etc.

Product vs Engineering States of Mind

In the last few weeks, I’ve been interviewing with a couple of
technology startups in Silicon Valley. At the same time, I’ve also
been trying to brainstorm for ways to pivot Askapade.com to make it
more useful and compelling for our users, or brand new ideas for a
startup. Also, I’ve been watching videos and reading articles on how
companies architect their systems, both because I find it fascinating,
and because I might have to do this someday so I’d better learn the
ins and outs earlier. I noticed that there’s a stark difference between my product and
engineering states of mind. When I’m learning about architectures, or
preparing for technical interviews, I’m in my engineering state of
mind—I’m trying to find a solution to a well defined problem, or in
some cases, learning about solutions to well defined problems. On the
other hand, when I’m brainstorming for startup ideas, or looking at
Askapade’s data to see how best to improve the product, I’m in my
product state of mind—I’m looking for the best problem to solve.

What’s also interesting is that sometimes I have to switch between
both while doing something—specifically, when I’m implementing a
feature for Askapade, I need to look at it from both perspectives.
Here’s what my process has been like so far: 1. Figure out a big picture idea with Ailian (http://ailiangan.com/)
(my sister and technical cofounder). We generally get quite specific
on how the pages should look, how the user flows should be like, and
what core functionality should be there. Sometimes we’ll even do mock
ups together.
2. Depending on how far we got in 1, I’ll fill in the rest of the
gaps, which usually means walking through the user flows and creating
mock ups. Thinking about what could be annoying from a user’s point of
view.
3. Implement it on my development server, and try it out for myself.
While I’m implementing it, I’m thinking in both product and
engineering states of mind because I notice design issues that I try
to fix immediately through changing the code.
4. I share it with Ailian through the staging server, and we go
through it together to see whether the user experience and copy makes
sense, and iterate from there.

What I’m wondering is—is switching between these a good idea? Does it
slow down development and iteration time in the end? Should I design,
implement, then design a better version etc. Are the context switches
expensive, or are these 2 different states of mind or ways of looking
at things not mutually exclusive? One could argue that engineering is
designing a solution, and product is engineering a user experience,
and engineering the question. My goal is to become skilled at both product design and strategy as
well as engineering, but I’m guessing at some point I’ll have to
choose which one I want to be truly great at.

Impact

Maybe it’s because I’m new at this, but it’s quite an amazing feeling to see my summer’s work covered in the tech media.

Box.net’s blog

TechCrunch

CNET

VentureBeat

Now all I need to see is Apple approve the update, and for people to start using it. Until then the jury’s still out on what the impact I’ve made was.

On My Internship at Box

I wrote the following entry for Box.net’s recruiting team on what I loved about my internship at Box. I also had the opportunity to share this at our company lunch as an impromptu thank you speech. Upon reading it again, I realized these things are not specific to good internships or even just good jobs, but can be applied to what I think will make me happy in the greater scheme of things. Enjoy!

I’m Wei, a senior at Duke University, and I had the privilege of interning at Box as an iOS (iPad/iPhone) developer this summer. People’s general advice for internships is to “go and make the best of it.” However, when the company you intern for gives you amazing opportunities to contribute, and you also give it your best, you’d be surprised how much you can learn and how much impact you can make in a few months. Here’s what I loved most about my internship at Box.

Awesome Mentor
I worked with Michael Smith, Mobile Product Manager at Box. On the first day of my internship, Michael asked me what my goals for this internship were. From the start, I knew that Michael cared as much about what I got out of this internship as what I could do for Box in my time here. He also understood my interest in both the engineering and product design aspects and not only let me in on mobile product design decisions, but made me an integral part of that process. It was common for me to simply build out certain interface features as I saw fit, and more often than not these would make their way into the final product design.

Michael taught me a ton technically, but more importantly, he truly cared about my learning and my internship experience and gave me autonomy and independence to work on the iOS apps which gave me a strong sense of ownership of the product and the feature I was building.

Ownership
Ownership is a very powerful motivator. As the main developer for the feature to save your files for offline access on the iPhone and iPad, it basically meant that if the feature I built was lackluster, it would reflect poorly on me, but if it was great, it would be something I could be extremely proud of for a long time to come. When your developer “street cred” lies on a release, you’re going to give it your best shot. Ownership and independence gave me the space to find creative solutions to both design and engineering problems. At Box, I felt like I had ownership of the iPad and iPhone apps, and especially of the feature to save files to view offline, and this motivated me to put my best work into these apps.

Impact
As powerful of a motivator as ownership is, what got me most excited about my work was the impact I was making in people’s lives by making Box’s iPad and iPhone apps better. Millions of people use Box.net’s web application to collaborate on content in the cloud. Box’s mobile apps help our users access this content on the go. Knowing that my work is helping make so many people work better is not just important to me, it’s what gets me excited to come to work everyday.

Interning at Box gave me a unique opportunity to learn and contribute. It’s not at every company that an intern gets to contribute so much and make such a big impact, but Box is special like that. I dare say that I couldn’t have asked for a better internship experience (except maybe more free schwag.) Thanks Box, for an amazing and unforgettable summer!

I may be wrong, but I have to believe that at some point, using his own iPad and measuring the true distance he had come to make it real, Steve Jobs must have found himself crying…

No matter what you are trying to do, whether in business or charity or social enterprise, if the thought of it doesn’t scare the hell out of you — and if imagining the manifestation of it doesn’t make you cry — it isn’t worthy of who you truly are.

Dan Pallotta, When Your Goal Is the Impossible

I have just spent over an hour reading Dan Pallotta’s blog archive. ALL his entries are good. Thought-provoking, original, colorful. I have yet to read a single dud. How does the man do it! 

(via ailian)

Lessoned Learned from WeiWatch

During my previous semester in school, I developed an iPhone application called WeiWatch. It lets you time how long you take to do routine activities, such as how long you to take to shower, how long your morning commute is, so you can get a better idea of how long you really take and make better estimates with your time. I wrote it to learn how to develop iPhone apps, but naturally, I also hoped it would catch on and people would find it useful.

My friends gave me tons of support, they loved the minigame I put in, they bought the app from me. For a while I was really pleased with myself—I had an app in the app store. My professor, Owen Astrachan, even showed it off on his iPhone in a class I wasn’t in. I thought I was hot shit.

I hadn’t even sold enough to make back my developer fee and I still haven’t (unless you count my internship income.) As far as it goes, WeiWatch has been an App Store failure.

Here’s what I learned:

  1. You can’t just release something in the App Store and expect it to become a mega hit. You have to do a bare minimum level of marketing. In retrospect, I could’ve done some creative ghetto marketing: write a song about WeiWatch and post on YouTube, make some funny videos. No one wakes up and looks up the app store for something they can use to time their daily routines. It’s something I need to convince people to do, not an existing need I’m fulfilling.

  2. If you want your product to succeed, you MUST figure out why it’s not doing as well as it can and improve it. I believe as long as the idea isn’t complete shite, you can probably get a decent amount of users through pivoting your product to become something more people want and find useful.

  3. If your target audience is everybody, you’ll sell to nobody. I thought the more general it was the better because then everyone would want to buy it. It was a little useful for everyone but not useful enough for them to make the purchase in the App Store.

I believe my biggest reason for failure is because I got disheartened by the weak sales and didn’t want to push to make a much better product. This is partly because I was in school, had already gotten an iOS developer job etc, but in all honesty, I gave up on it.

So what’s happening with WeiWatch? It’s still in the App Store. In fact I released an update for iOS 4 multitasking as well as a feature that lets you email yourself your timing data so you can analyze it where ever you want. Unfortunately, I’ve been focusing my time on a new project, so it’s unlikely that WeiWatch will get any more love from me ): It’s been a great learning experience to put a product of my own out there in the market.

For this new project, I’m setting the bar higher and I’m not going to give up until I’ve exhausted all my creative energy to try and make it into something people want. I’ll be writing more about that soon.

To all my friends that wondered how WeiWatch did and why, I hope this provides you with a worthwhile explanation.