A blog about startups

Recently, I had the rare opportunity to have a couple of months without a regular full-time job.

The common thing to do with a break like that is to travel. I considered doing a round the world tour. But with Starbucks in 65 countries now, the world is flatter than ever, and it didn’t feel like I would learn that much.

Instead I decided to stay in San Francisco and spend the time working on projects and reconnecting with people. Over the nine years I’ve lived here, I’ve met a lot of incredible people. I’ve generally not done a great job of keeping in touch with them. I was focused on building a company, and staying in touch with people for its own sake never got priority.

Now I had an opportunity to change that. So I sat down and made a list of people to “get coffee” with. It had hundreds of names. It was a little intimidating, so I prioritized them. For each person, I made a list of the things I wanted to ask them and the things I thought I might be able to help them with.

Two months later, I’ve gotten coffee with over 200 people. I say get coffee metaphorically. Sometimes we’d go for a walk, or out to dinner. A couple of people I met at museums, which is a fun way to talk.

One of the cool side effects is the number of cross connections I was able to make. A surprising number of those people turned out to be the answer to what someone else was looking for. Also surprising was how open very busy people were to having a meeting without a clear agenda, just as long as they didn’t have to think of proposing it.

A six year study of middle aged men showed that having more friends was the most powerful predictor of having a long life, more important than not smoking or getting exercise. We don’t fully understand why, but connections are important.

200 coffees might seem overwhelming. But if you reconnect with just two people / week, by next year you’ll have done it. So take a minute, find a friend you have’t talked to in a while, and drop them a note.

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.

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.

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:

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.

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 a male between the ages of 20 and 25 from an Ivy League school who 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 much more diverse. 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.

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:

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.

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.

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.

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.

Here’s a problem I ran into while trying to recruit employees long-distance.

We hired this awesome guy Alex from Germany. We went through all the work of getting Alex an H1B visa and helping him move to San Francisco. Everything is great.

Unfortunately, Alex is married and his wife has a profession as well. She’s ok to not work for a while because Alex makes enough to support both of them, but pretty soon she understandably wants to return to her career.

At this point, we have a bit of a dilemma. On the one hand, Alex’s wife’s job is not our problem. Most companies would leave it at that. But if Alex’s wife can’t find a job, he’ll likely go back to Germany. If he’s a key employee, we are now rationally incentivized to help his wife find a job so he will stay.

I’ve run into this problem surprisingly often. Or maybe not surprisingly, because it makes sense that the significant others of highly skilled employees are likely to be skilled and ambitious professionals themselves.

How to find a job for a significant other

The first thing we tried to do was outsource it. After all, job finding is not a core competency. So we tried calling contingency recruiters we knew to see if they’d take on the case. Some said yes. Unfortunately, contingency recruiters are a fickle bunch. Because you’re not paying them, they only work for you to the extent they feel likely to close a hire. When the going gets tough, which is exactly when you need them, they drop you like a hot potato and move on to more promising clients.

Next we tried subsidizing career counselors. These people are paid out of pocket, so they stick with it. Unfortunately, we had a tough time finding career counselors who were *any* good in San Francisco, particularly for younger people who want ‘new economy’ jobs. The industry seems geared towards retraining / emotional help for older people who’ve lost their jobs.

Finally, we ended up just doing it ourselves. We took our recruiters, who normally try to hire people, and had them do the reverse, helping people find jobs. It turns out they were good at this and were reasonably successful.

Will someone make a service for this, please?

But the experience left me wishing someone would just create a service for this. Doing it ourselves was a strange use of company resources and was internally controversial. Have the same problem? Say so in the comments and maybe we can get something started.