Joining YC

I’m excited to share the news that I’ve joined Y Combinator as a partner.

YC has done more than anyone else to get people to start companies. If not for YC and for Paul Graham’s eloquent writing about startups, I would never have gone down this path in life. The same is true for probably thousands of other people. Many of the products you use every day would not exist.

I was talking to a company earlier this week that was unsure about applying to YC. I told them to talk to any, any YC founder and ask them if it was worth it. I gave them a list of 20 names at random. I didn’t need to pick, because for virtually 100% of people who go through YC, it becomes the defining moment of their career. Paul Graham says that you are better off having a product that a few people love a lot, than a lot of people like a little. If YC is a product, he’s followed his own advice.

You can tell a lot about an organization by the people it hires, and YC is hiring the best people in the world. In the last year, we’ve added Peter Thiel, Anne Wojcicki (23&me), Ben Silberman (Pinterest), and Joe Gebbia (Airbnb) as part-time partners to an already outstanding team. I’m humbled to get to work with these people.

Most VC firms encourage innovation by investing, but they don’t tend to innovate much on their own business. YC acts like a startup. We are making big, bold bets: launching a research lab, a new venture funding model, and a new program that could someday be bigger than YC itself. Sam has a vision for putting YC at the center of all kinds of innovation, and you can see it emerging piece by piece. Much like when I read PG’s essays a decade ago, it’s inspired me all over again to believe in the power of a small group of individuals to create the future.

Why I wouldn’t use rails for a new company

We built Scribd into the #3 largest rails site by traffic and it worked for us, but these days I see a lot of new companies using rails and it feels like a mistake.

I started using rails in 2006 right after DHH’s screencast which introduced rails to the world with a bang. We wrote the first version of Scribd in rails 0.7, when they hadn’t yet invented fancy things like migrations.

At the time, rails had buzz but was far from a safe choice. Most new sites were still being written in PHP or Java, and there were huge numbers of engineers for those platforms. We were making a bet that rails would continue to gain mindshare, creating a deep set of open-source libraries and, most importantly, a pool of developers interested in working in it.

It was the right bet. As we grew Scribd to the #3 largest rails site, Rails grew with us, becoming the default web application stack for new silicon valley startups. Java Spring, PHP and ASP.NET developers saw the writing on the wall and sought out jobs where they could switch. As one of the first rails sites to hit scale, we benefited enormously from this, picking up great talent by offering a chance to work with rails.

The winds are changing

I worry now that rails is past its zenith, and that starting a new company with rails today might be like starting a company using Java Spring in 2007.

This graph shows the relative Google search volume of different web frameworks.

(from Google Trends).

You can see how rails is losing mindshare to newer frameworks.

Rails’ big problem: ruby

Everyone knows that ruby is slow. In fact ruby is by far the slowest mainstream programming language.

Why is ruby so slow?

Some people will point to language design characteristics, which are part of the story, but I think the deeper reason is that ruby does not have a serious corporate sponsor.

Back in 2007, Python, PHP, and Javascript were all pretty slow scripting languages. Facebook made a huge investment in PHP, building HipHop to make it fast. And Google accidentally enabled the explosion of server-side Javascript by making a fast Javascript JIT compiler.

The ruby interpreter is just a volunteer effort. Between 2007-2012, there were a number of efforts to fix the interpreter and make it fast (Rubinius, JRuby, YARV, etc) But lacking backers with staying power, the volunteers got bored and some of the efforts withered. JRuby is still active and recent versions are showing more promise with performance, but it’s been a long road.

As the first major tech company to grow up on rails, Twitter could have embraced rails and fixed the interpreter, much like Facebook did with PHP. That would have been a game changer, ensuring rails’ continued dominance for years. But Twitter’s engineers decided it was easier to rewrite Twitter in faster languages than to make ruby fast.

Rails is static while others have caught up

Rails pioneered many concepts for making common web applications faster to write. But over time other frameworks simply picked up those innovations. Django for Python is largely a rails clone, and sail.js is the same for Javascript. These other frameworks are not hampered by building on non-major programming languages.

At the same time, development on rails itself has stalled. Rails 3 was released in August 2010 but Github didn’t upgrade to rails 3 for four years because the benefits were not that compelling. Based on the pain we experienced upgrading to rails 3 at Scribd, I’m not sure if we will ever upgrade to rails 4.

It’s been interesting to compare the explosion of innovation in Javascript and front-end development with the relative stagnation of rails. In the last 7 years while our back-end has changed incrementally, our front end has gone from Prototype to jQuery to Coffeescript to Angular to React with major productivity improvements each time.

Bootcamps

In the last two years, there has been an explosion of programming bootcamps. These bootcamps teach a variety of things, but when they teach server-side development, they overwhelmingly teach rails rather than other languages. Presumably this is the market’s response to the still-heavy demand for rails developers at startups.

On one hand, this benefits the rails ecosystem by increasing the talent pool. Unfortunately it has also had a perverse effect. Serious developers, particularly ones with CS degrees, look down on bootcamp programs as “programming light”. I’ve noticed a disturbing trend of experienced developers not wanting to work with rails now that it’s been “polluted” by this reputation. I saw a similar thing happen with Flash / actionscript where serious developers often (wrongfully) regarded it as a watered down language for designers.

New games in town

A few frameworks are strong contenders to be the successor to rails. Node.js is in the lead. Don’t believe me? Here’s the breakdown of server languages used by popular companies on AngelList:

(Source)

And here are the growth rates in job trends on indeed.com:

Granted, the new languages all have drawbacks. Node.js suffers from fragmentation with a half dozen frameworks competing. Go is hot right now for microservices but the frameworks are lacking for large-scale apps. Django / Python seems to be holding steady but not growing.

If you want to future-proof your web application, you have to make a bet on what engineers will want to use in three years. That’s more important than what framework lets you be most productive right now. If you’re Facebook, you can get away with using anything and people will still want to work for you, but most companies are not Facebook. If you bet right and get in early, you can ride the wave of momentum that a new popular framework generates.

Nine Years of Demo Days: How YC has changed

My first Y Combinator demo day was the one I presented at, back in the summer of 2006.  I’ve gone to every single demo day since then, making me, I believe, one of the few people who have seen virtually every YC company present.

People often ask me, “how has it changed?”.  In a word, utterly.

The demo day I went to today, about 100 companies presented.  It took place in a huge auditorium and basically every serious investor in silicon valley had a representative there.  The companies delivered polished presentations and together will raise hundreds of millions of dollars in the coming months.

The first demo day took place in a small building near Harvard.  A couple of VCs attended, but I think they were just being polite, because they certainly had no intention of investing in any of the companies.  The audience was mostly personal friends of Paul and Jessica.

12 companies presented, and the presentations were 10 minutes each (these days they are 2 minutes).  Not a single company raised money.  Most of them died within a few months and the founders went back to school or got jobs.

Here are some of the trends I’ve seen over nine years of demo days.

● Companies are much more ambitious now.  In 2006, getting acquihired by Google for a couple million buckets was considered a fabulous outcome and basically the goal of every company.  Today, there are six YC companies worth over a billion dollars, and as a result new startups aim much higher.

● Companies are joining YC at a much later stage.  When I started YC, most companies wrote their first line of code in the first week in the program.  Today, many of the companies have been working on their business for a long time and some even have substantial customers and revenue before applying. If the companies in my batch applied to YC today, I doubt that many of them would get in.

● Founding teams are much more diverse, and much older.  In 2006, almost every founder was between the ages of 20 and 25, majored in computer science and was building a website.  Today the average age is over 30 and the founders come from all walks of life – lawyers, doctors, real estate agents, and domain experts of all kinds.

● The companies are working in much more diverse areas.  This is maybe the most publicized change – that YC has gone from being all about software to doing everything from pharmaceutical research to fusion.  But even within software, things have gotten much more diverse.  In 2006, founders were essentially all making software for ourselves, which meant they had to be things that college students would want.  Today, YC companies make software for everyone from transit route planners to parking lot operators.

● YC is less personal.  Getting into YC in 2006 was like joining an outcast band of adventurers.  Our little band of rebels didn’t have much going for it, but in our shared struggle we made lasting personal connections.  Getting into YC in 2015 is more like getting into Harvard: you will be showered with resources and doors will open for you.  But you’re traveling a well-trodden path.

It’s been incredible to watch YC grow from a bunch of college students with big dreams to the very center of innovation of the technology world.  Every year I think “this must be the peak of YC”, and yet the quality of the companies has been monotonically increasing so I keep being wrong.

This didn’t happen on its own; Paul, Jessica, Sam and the other YC partners made it happen by force of will, hard work, and smart decisions. I don’t know what the future of YC is, but as long as those people are still running it and doing pioneering things like the YC Fellowship program, I think we could still be in the early part of a much bigger story.

How to Hire Recruiters

A shorter version of this blog post appeared on Redpoint’s blog

After talking with many founders, I’ve noticed there is a lack of good information out there about how to build internal recruiting teams.  This is the advice I give to startup founders on how to build their first recruiting team.

What an in-house recruiting team does and why you’d want one

If you want to scale your company by 20 highly skilled people or more in the next year, you should have an in-house recruiting team.  Below ten new engineering hires a year, and you should be ok having your internal team collectively own recruiting. But there will come a point when this becomes  too distracting and will fail to deliver the quality and quantity of new hires you need.

If you’ve used agencies or contingency recruiters before, you might think that an in-house recruiting team will be similar.  Not so.  Contingency recruiters are, in my experience, generally a bad deal for tech startups hiring engineering talent.  What distinguishes in-house teams is that they will take all aspects of hiring new people off your plate, not just send you candidates.  An in-house recruiting team will do all of the following:

• Manage your talent brand and public presence as an employer – your jobs site, job board posts, etc.
• Go to physical career fairs, meetups, and other events on your behalf
• Be the primary point of contact for all candidates from first email to close
• Organize and schedule interviews and travel
• Make sure your team is aligned on what they are looking for in each role, and help bring the team together when evaluating candidates
• Train interviewers and build a culture of recruiting excellence
• Run a tight, organized interview process that impresses candidates and positions your company in the best possible light
• Reach out to passive candidates directly
• Work with your existing team to generate more employee referrals
• Use job search 2.0 services like Hired.com, SmartHires and InterviewStreet so you don’t have to
• Do initial screens for every candidate

Note that most of these are internal facing.  A common misconception is that your recruiting team is all about reaching out to candidates, but in fact that’s probably only 50% of what they will do.

Various roles in a recruiting team and what they mean

In a large recruiting team there are specialized roles.  Generally, more junior people get the top of the funnel and the seniority goes up as you move down the funnel towards closing.  These are the main ones:

Sourcer – a sourcers find candidates (i.e., by looking through LinkedIn).  In some teams sourcers will send the initial contact email and hand off to a recruiter if they get a positive response.  In others, sourcers just provide recruiters with a list of candidates to reach out to.  Often, the sourcer has the deepest network (particularly those that specialize in a field)

Recruiter – recruiters do initial screens with candidates and shepherd through the interview process.  They may or may not source themselves.  And in large teams, candidates may get handed off through a couple of tiers of recruiters, with the more senior ones towards the later stages of the process.

Recruiting coordinator  – coordinators schedule interviews, book candidate travel, and post job ads  At startups, it’s common for recruiters to offload some coordination tasks to office managers rather than hiring dedicated coordinators.

Recruiting manager / HR manager – varies greatly.  Sometimes they do recruiting themselves, sometimes they focus on closing candidates, sometimes they just build the process but leave individual candidates to the recruiters.

Deciding how much to specialize your recruiting team is analogous to deciding how much to specialize your engineering team.  Do you want front-end developers and back-end developers, or just a flat team of full-stack developers?

Most companies start with generalist engineers and only hire specialists later, and I recommend doing the same with recruiters.  You’re best bet initially is to hire a couple of great senior “full-stack” recruiters, who can do every part of the hiring process.  If you have to scale beyond that, you can hire sourcers to feed them more candidates, but having specialized roles makes everything more complex and I’d avoid it until you need it.

That doesn’t mean that the people you hire were necessarily full-stack recruiters beforehand.  You can certainly hire someone who was a sourcer at Google and turn them into your full-stack recruiter.

Understanding recruiter career trajectories

It’s helpful to understand the context of recruiter career trajectories when interviewing candidates.

Very few people grow up wanting to be recruiters.  It’s a field people fall into.  There are two main paths.

Many recruiters start off in the agency world.  Contingency agencies will hire people with no experience for junior level roles.  Initially, they will be compiling lists of candidates or scheduling interviews, and over time they’re given more responsibility.  Agencies tend to breed strong sales skills, high pressure and high tactics, experience working with lots of hiring managers, and a focus on the numbers, as they are incentive comped.  They don’t stress evaluating candidates well.  Agencies are generally sweatshops with poor employee satisfaction, and many agency recruiters are looking to go in-house at a client company.

The other way is for recruiters to come up through a large recruiting org like Google.  Largecompanies will also hire people with no experience, often as recruiting coordinators, who can graduate to sourcers and eventually recruiters.  It’s common for startups to think “Oh, a recruiter from Google – they must be awesome”.  But you should be aware that recruiting at Google is very different from recruiting at a startup.  Because their brand is so strong, these tech companies don’t need to hunt very hard or be particularly creative. They are used to enjoying a 50%+ response rate to cold messages.  Google and Facebook have some of the best engineers in the world but don’t assume that this applies to their recruiters as well.

Ideally, you’ll hire recruiters from some other startup where they have proven that they can work effectively inside a startup environment.  But the market is competitive and that may not be possible.  If you’re hiring a recruiter out of an agency, keep in mind you may have to retrain them out of bad habits.  If you’re hiring a recruiter out of a big company, look for someone who’s aggressive and scrappy enough to be successful without a big brand behind them.  And when recruiters from big companies tell you how many candidates they hired, keep in mind that any recruiter will be able to hire way more engineers per month at Facebook than at your startup.

Where to look for recruiters

Start with job ads.  Recruiters live on LinkedIn, so putting up job ads on LinkedIn and putting some advertising budget behind them will get you in front of the right people.

A more creative approach is to “recruit your recruiters”.  All the engineers in your company are probably getting daily unsolicited emails and inmails from recruiters.  Give everyone a template response to write back along the lines of “I’m not looking now, but by the way we are hiring recruiters and you should apply”.  I’ve actually hired people this way.

If you’re working with contingency recruiters now, invite them to come interview for an in-house role (if you like them).  Or ask them if they know someone who is looking to go in-house.  Recruiters do tend to know each other.

There are recruiting bootcamps these days much like engineering bootcamps that you can hire students from.  A couple are http://www.geekology.biz/ and http://recruitingtoolbox.com/

If you want to hire someone more junior, here is a good post about what to look for.

How to interview recruiters

My overall approach to interviewing recruiters is unusual: I treat them just like engineer interviews.

When you interview engineers, you do a practical, hands-on interview where you force them to demonstrate technical skill.  For some reason, no one does this with recruiters – they just ask some questions about work history and trust they know what they are doing.

I have no idea how to do that effectively, so instead I sit with recruiter candidates and force them to basically do recruiting for an hour with me watching.  These are the specific tasks I’ll take them through.

1) I’ll show them three resumes of engineers who recently applied to work here.  I’ll ask them: what do you like on these resumes and why?  What don’t you like?  How would you rate these resumes (1-10) for general engineering promise and what forms the basis of your rating?   I’ll force them to walk me line by line through the resume, and tell me how they interpret each line.

You are looking for someone who really knows how to evaluate engineering talent.  They shouldpossess a ton of background knowledge: which companies have strong / weak engineering teams, which schools have good CS programs, what every programming language and technology means and how they relate to each other.  Their judgement about good / bad engineer resumes should be similar to yours.

Some people will say “oh a great recruiter can do anything, tech or non-tech”.  That might be true, given a year to get up to speed.  But tech recruiting is particularly difficult and not learned overnight; if your main focus is hiring engineers, you want a recruiter who really gets engineer recruiting.

2) Send me the last three unsolicited outbound emails you sent to engineers (or their favorite three).  If they don’t have any, have them write an email to a potential engineer on the spot.  You are looking for someone who takes the time to write personalized, persuasive emails.

Bonus points if they’ve referred to content in their blog, Twitter, specific repo in their Github, etc.

By the way, the following is a fantastic read on how to send outbound emails: http://blog.alinelerner.com/what-i-learned-from-reading-8000-recruiting-messages/

3) Find me three interesting iOS (or Android, etc) engineers using GitHub or Stack Overflow or your preferred other source.  I will watch them use these sites to see how facile they are at navigating them.

4)  Pretend I’m a candidate and convince me to work at your last company.  They should be able to pitch it persuasively.

5)  Have them go over their personal recruiting metrics funnel.  # of emails sent, # responded to, # of phone screens, # of first-rounds, # of second rounds, # of offers, # of closes.  What were the biggest bottlenecks, and what did you do to improve them?

You can’t necessarily believe the numbers they tell you – people can easily lie – but you can tell if they are constantly thinking about their performance in a quantitative and rigorous way.

6)  How do you source candidates?  Bad answer: LinkedIn recruiter exclusively or job sites like monster.com.  Good answers: something creative / unusual that shows them going outside the norm to find good talent.  Once they tell you their cool sourcing strategy, have them demonstrate it to you on the spot.

7)  Tell me about a candidate you are particularly proud of recruiting.  Good recruiters should have a good story of how they had an impossible role to fill (a machine learning scientist with experience in the construction industry who speaks Nepalese) and how they scoured the globe for the perfect person.  Or how they were able to close an amazing candidate with numerous offers.  Or at a minimum, they should have good recall of the details of candidates they’ve hired.

Final caveat: recruiters are expert interviewers. They interview people for a living so they’re particularly good at this, and this can give you a false reading.  Be sure to backchannel reference your recruiter.  Ideally you should talk to both candidates they’ve hired and hiring managers they’ve worked for.

What to do with recruiters once they get there

A few tips to get the most out of your recruiting team.

• Immerse them in your company culture and team.  They should be friends with your engineers.  They should know what projects are being worked on, what everyone’s backgrounds are, what each person is particularly good at and likes doing.  This will help them sell the company by creating excitement about current projects, and pair up candidates with the right interviewers.
• I don’t recommend comping them on performance, like a bonus per hire.  Recruiting is not sales.  Comping your recruiters on performance is a good way to either hire a lot of mediocre employees or create constant conflict by not wanting to hire the recruiter’s candidates.
• It’s a good practice to occasionally do joint interviews with recruiters.  They’ll learn from you how you pitch your company, and you can help them get better when you see what questions they ask.
• Create outreach templates and messaging together.  Review the outreach emails they’re sending and help them improve them.
• Do have a weekly metrics review in which you look at the numbers for all the stages of the funnel and see where the choke point is.
• Consider sending them to one of the many coding bootcamps.  Most recruiters have literally zero programming knowledge and even a rudimentary understanding will help.  They’ll be very appreciative.

Thanks to Barry Kwok, Amy Knapp, and Hadley Wilkins for reading drafts of this post

How the No-Management Trend Could Disrupt Everything

It’s hard to remember now, but there was a time when silicon valley companies did not serve free meals to employees.  Back in the first .com boom, even lunch was not a typical perk and dinner was rare.

 

Google changed that.  Google made amazing free, high quality meals on-site a centerpoint of their recruiting strategy.  This simple idea was monumentally successful.  To keep up, everyone who competes with Google for talent, which includes all silicon valley startups and most large tech companies here, have had to match Google’s perk.

 

I believe this story may play out again with a different perk.  And that perk is unstructured / democratized management.

 

We don’t like bosses

 

There are now a handful of companies that have publicly come out with a management model that rejects the traditional top-down hierarchy and gives an unprecedented amount of decision making power to individual contributors.

 

Valve probably made the first splash in this area, releasing a document describing their manager-free culture.  When you show up to Valve on you first day, no one tells you what to do.  You look around, see what needs doing, and start working on something that seems important.  People self-organize into small, temporary teams.

 

Judging from its reception on Hacker News with hundreds of comments, this struck a nerve.  I don’t know if Valve released this document as a recruiting strategy, but if they did it was a smart one.

 

The things is: engineers don’t like bosses.  Millennials in general are resistant to authority.  So even in conventionally structured organizations, there has been a trend towards less hierarchy.  Google pioneered 20% time, which in less flattering terms means that you only have a boss 80% of the time.  At one point, it was most common for engineers to report to a professional manager, probably an MBA, who was not himself an engineer.  That would never fly these days, where managers are more like coaches than bosses.

 

More recently, the excitement is around Holacracy, which attempts to build a very structured framework for running this kind of organization.  Zappos made headlines when Tony forcefully switched the 4,000 person company over to this new model.  It was a tough transition for a large company and many people left, but you have to give Tony credit for having the courage to stick with it.

 

How do you run a company with no one in charge

 

Management science is still at the early stages of figuring out how to run a company with something other than a conventional hierarchy.  There are still only a handful of companies that have pulled this off.  About 50 companies  are now using Holacracy, but the only other big name in the valley is Medium.  The prominent software companies using some non-Holacracy flat management system are Valve, Github, and Treehouse.

 

Many smart people are still skeptical that unstructured management is a good idea.  There is a legitimate argument that the companies that made it work have succeeded despite their unique culture not because of it.  There are examples of companies that tried to do this and changed their minds after hitting major obstacles.

 

From a purely practical standpoint, there is insufficient information on how to actually implement this.  There are a million management books and advisors who can tell you how to run a conventional company.  The only alternative that is well documented right now is Holacracy.  What Valve or github are doing is very different from holacracy, but they haven’t released enough information for someone to copy it.

 

The future of management?

 

So many question marks still remain.  But if the market can work out a template for running companies this way and there are a few more big success stories, sentiment could tip quickly like it did with free food.  Companies with less structure will have a major recruiting advantage.  Engineers will vote with their feet, putting pressure on the market to match the early movers.

 

One difference is that it is much harder for existing companies to change their management structure than to change their cafeteria prices.  Large tech companies will be very slow to adopt a management change – even within engineering – so this could become a sustainable competitive hiring advantage for startups.

 

I would caution anyone who wants to “try this at home” with their startup that the going is likely to be tough.  But if you are ambitious enough and ready to be an explorer of new management models, the timing is right to give yourself a recruiting advantage, and to build a team and culture that will be unusually dedicated.