Outsource things you don’t care about

A fundamental principle of business is that you do things in house that you think can give you a competitive advantage and outsource things that you don’t. At an early-stage technology company this means you do in house: product design, software and/or hardware development, PR, recruiting, and customer relations/community management. Ideally, most of these activities are led by founders. You should outsource legal, accounting, website hosting, website analytics etc. (Unless you are starting a company where one of those activities can give you a competitive advantage, e.g. a securities trading startup would need to have in-house legal).

A lot of startups over outsource. A few years ago, you’d sometimes hear tech startups say they were going to outsource software development. Thankfully, founders have gotten smart about this and it rarely ever happens except as a stopgap. It is still common for startups to hire outside PR firms. If you decide to hire an outside PR firm, that means you don’t care about PR. Just because you are willing to spend some of money on it doesn’t mean you think it’s important. You probably shouldn’t hire an investment banker during an acquisition unless your company is later stage. And you might occasionally use an outside recruiter but the core recruiting activity needs be done by founders.

Recruiting programmers to your startup

Here are some things I’ve learned over the years about recruiting programmers* to startups. This is a big topic: many of the points I make briefly here could warrant their own blog posts, and I’m sure I’ve omitted a lot.

– The most important thing to understand is what motivates programmers. This is where having been a programmer yourself can be very helpful. In my experience programmers care about 1) working on interesting technical problems, 2) working with other talented people, 3) working in a friendly, creative environment, 4) working on software that ends up getting used by lots of people. Like everyone, compensation matters, but for programmers it is often a “threshold variable”. They want enough to not have to spend time worrying about money, but once an offer passes their minimum compensation threshold they’ll decide based on other factors.

– Software development is a creative activity and needs to be treated as such. Sometimes a programmer can have an idea on, say, the subway that can save weeks of work or add some great new functionality. Business people who don’t understand this make the mistake of emphasizing mechanistic metrics like the number of hours in the office and the number of bugs fixed per week. This is demoralizing and counterproductive. Of course if you are running a company you need to have deadlines, but you can do so while also being very flexible about how people reach them.

It is sometimes helpful to think of recruiting as 3 phases: finding candidates, screening candidates, and convincing candidates to join you.

– Finding means making contact with good candidates. There are no shortcuts here. You need to show up to schools, hackathons, meetups – wherever great programmers hang out. If your existing employees love their jobs they will refer friends. Try to generate inbound contacts by creating buzz around your company. If you have trouble doing that (it’s hard), try simple things like blogging about topics that are interesting to programmers.

– Screening. Great programmers love to program and will have created lots of software that wasn’t for their jobs or school homework. Have candidates meet and (bidirectionally) interview everyone they’ll potentially be working with. If the candidate has enough free time try to do a trial project. There are also more procedural things that can be useful like code tests (although they need to be done in a respectful way and they are more about getting to know how each side thinks than actually testing whether the candidate knows how to program (hopefully you know that by this stage)).

– Convincing them to join you. This is the hardest part. Great programmers have tons of options, including cofounding their own company. The top thing you need to do is convince them what you hopefully already believe (and have been pitching investors, press etc): that your company is doing something important and impactful. The next thing you need to do is convince them that your company is one that values and takes care of employees. The best way to do this is to have a track record of treating people well and offer those past employees as references.

A few things not to do: you will never beat, say, Google on perks or job security so don’t even bother to pitch those. You’ll never beat Wall Street banks or rich big companies on cash salary so don’t pitch that either. You’ll never beat cofounding a company on the equity grant, but you can make a good case that, with the right equity grant, the risk/reward trade off of less equity with you is worth it.

Finally, I’ve long believed that early-stage, funded startups systematically under-grant equity to employees. Programmers shouldn’t have to choose between owning a fraction of a percent of an early-stage funded company and owning 50% of an unfunded company they’ve cofounded. Naval Ravikant recently wrote a great post about this:

Post-traction companies can use the old numbers – you can’t. Your first two engineers? They’re just late founders. Treat them as such. Expect as much.

Making those first engineers “late cofounders” will dramatically increase your chances of recruiting great people. This is a necessary (but not sufficient) condition for getting the recruiting flywheel spinning where great people beget more great people.

* As someone who personally programmed for 20 years including about 10 years professionally, I preferred to call myself a “programmer.” Some people prefer other words like “hacker” “developer”, “engineer” etc. I think the difference is just uninteresting nomenclature but others seem to disagree.

Entrepreneurs need to learn some law

I recently wrote a post where I said entrepreneurs need to understand term sheets on their own, without the assistance of lawyers.  I got quite a bit of criticism for this, e.g.

@rafer Never ever sign a term sheet without your atty’s review. sry but thats crazy talk @cdixon http://bit.ly/UOgiC myreblog http://bit.ly/cJ9d0

I’ll agree that entrepreneurs, especially first timers, should have lawyers review everything they sign.  But I stand behind my main point:  you can’t outsource the understanding of key financing and other legal documents to lawyers.

Here’s just one of many examples of why.   A company I know was recently confronted with the following trade off.  Get a higher valuation with full ratchet anti-dilution or a lower valuation with weighted average anti-dilution.   The only way to assess this trade off is to understand what these terms mean and try to compute the expected value of the two offers.   In this particular case what matters is the likelihood of a future down round.  This is a business judgment, not a legal one, and the people best able to make it are business people.

You also need to consider your personal utility function.  For example, as a founder, I don’t care very much about anti-dilution provisions because I figure in the cases where it matters I will already have been fired and my equity crammed down.

My point is you can’t leave these judgements to lawyers.   They don’t have the expertise to make these expected value calculations nor do they understand how various scenarios affect the founders personally.

Another common mistake entrepreneurs make is let their lawyers argue over terms that don’t matter.  This puts deals at risk and costs money.  You need to understand what they are arguing over to decide when it matters and when it doesn’t.

You learn about these legal issues from experience, by talking to lawyers, by talking to experienced advisors, and by reading blogs and books (every entrepreneur should read The Entrepreneur’s Guide to Business Law).

What to look for in hiring a VP Engineering for your internet startup

Tom Pinckney was VP Engineering and co-founder of SiteAdvisor (along with me and Doug Wyatt) up through and beyond SiteAdvisor’s acquisition by McAfee. Tom sometimes gets asked by friends who are starting internet companies what to look for in potential VP Engineering hires, so we thought it might be helpful to put Tom’s thoughts down in writing here. (In addition to being co-founder and VP Engineering at three VC-backed startups, Tom has a BS & MS from MIT in Computer Science). Here are Tom’s thoughts:

This is based on my experience with very early stage Internet companies. I’m sure if I were building an ethernet switch I’d want someone different. But if I were building a website, whether for consumers or other businesses, this is what I’d look for.

Note that we think of the VP Engineering role (as opposed to the CTO) as the person who makes software that gets built on schedule, on budget, in a reliable, scalable way etc. You might also want a CTO at your company to think of big, creative ideas but often those people aren’t good VP Engineers.

Technical Skills

1) They are comfortable with web-speed development — release every week, ok to have minor bugs on the site vs never getting a release out etc. You don’t have any users right now so you can afford a few bugs. In six months you will have users and then you can start worrying more about having more process.

2) They are not overly process oriented — you’re not building the space shuttle so don’t need to spend three months designing the next release. You do need to know how the big pieces of the problem will interact with each other and what the overall system architecture will be. No Gantt chart experts, non-techy people managers, or high level big company guys who haven’t been hands on in years.

3) They are someone who can architect the system, understands how to test/QA a site, what IT needs to do to keep the site running fast and reliably. They need enough technical expertise in all areas to see how each person’s work affects other people’s work, what it’s inputs and outputs are, see how each piece fits into the rest of the system, judge trade-offs being made, estimate complexity, timelines etc.

Make sure they can talk in intimate detail and have opinions about all of this. How should the DB clustering work? What exactly were the test scripts checking and how did they get written so that as the software changed all the scripts didn’t have to get thrown out? That sort of thing.

4) They have experience using open source technologies such as MySQL, Apache, Java/Python, Linux etc. I’d avoid people who want to use MS
technologies since you have to pay a lot for it and most of the kids these days want to work on the open source stuff.

5) They are someone who can code and wants to code on day one and could even build the first version of the system, but understands that by day 365 they won’t be coding any more. You’re not so big that you can afford anyone who just manages in the early days.

6) They can architect the system in a way that developers can build your project with maximal parallelism and so that computers can run it with maximum parallelism so that you can scale to the millions of users, terabytes of data, or whatever it is you need to do.

7) They should prefer the simple to the Baroque. Most simple, reliable and quick-to-build systems can also be built as a complicated, slow, bug-laden piece of software too. Every line of software that doesn’t exist because of your simple design is a line that has no bugs, can’t slow the system down, and won’t take time for new developers to understand. Can they talk about how they design things to be simple, what they gave up to make the system simple, etc?

Personal Skills

1) Watch out for people that seem dogmatic about unreasonable things (”Anyone who uses Postgres instead of MySQL is an idiot” etc etc) (Note, see my comment above about anyone that uses Windows technologies being an idiot).

2) Watch out for empire builders or people who need lots of resources. Do they believe they can build anything with a couple of great guys or have they never worked with a few great people before? Do they want to hire a large over-seas staff because everyone else is doing it and it will look good on their resume? Do they know so little about things that they need lots of expensive tools or consultants?

3) They should be outgoing, fun, intense people. No one likes to work for a low energy introvert. Ask them why they want to manage instead of coding. See if they are an engineer who got promoted into management because they wanted the higher pay but really would be happier just coding all day and not interacting with people. A lot of people aren’t into managing but end up doing it for the money. Or maybe they are an ego maniac that needs to be in control since otherwise no one pays attention to them?

4) Are they really excited about technology, do they do techy things in their spare time, etc? Do they talk about how they programmed for fun in high school or wax poetic about the cool game they wrote back in the day?

5) Most technical hiring is about convincing engineers that your problems are the best to work on and that the rest of the team are super smart people, so your VP Eng will have to be able to pitch this.

6) The ideal VP Eng could build most parts of the system themselves, but they’re self-confident enough to work with people better then themselves too.

7) They should be hungry to step up and prove themselves. Ideally they have been a tech lead or had some managerial exposure already, but are
eager to step up and build something even bigger then they’ve been responsible for so far.

Where do you find someone that has these qualities?

Unfortunately, there’s not one good answer. I’ve seen people have good luck by having a recruiter target specific companies. Your personal network is obviously the ideal way so that you can get trusted references. If you have outside investors, their network might be useful too. We’ve had basically no luck using job boards like Monster and Hotjobs.

I think it’s hard for people with no technical background to interview a VP Engineering candidate. If you don’t have a technical background, have someone technical (if not someone full time at your company, perhaps an advisor or board member) interview with the candidate as well.