Venture Hacks

AngelList “corporate policy” is that team members should ask forgiveness, not permission.

We would rather have someone do something wrong than ask permission to do it.

Or better, we would rather have someone do something right and not need permission to do it. This is the most common outcome.

We would rather have people ship to production whenever they want, than go through an internal review process. We can fix it on production. We prefer the customer’s review process. And it isn’t too hard to reveal a new feature to a small portion of our users and iterate on it as we expand it to more users.

Eliminating permission increases speed and diversity

Eliminating permission increases the speed and diversity of our decision-making. Our incubator applications are a good example of diverse decision-making: one of our team members built it even though I was telling him, “This is fine, but I don’t think it is that important. Why don’t you work on something else.” It ended up being very important to our users and mission.

There are some sensitive parts of our product that are walled off from this “ask forgiveness” policy. There are some things we want reviewed by the people who “know better”. But it’s really rare.

How it works

This policy only works if you hire insanely smart and capable people, and let go of the ones who are not. We also filter for people who are mission-oriented, care about our customer and want to learn more.

And it doesn’t mean that the founders aren’t standing over your desk telling you, “this isn’t good enough to ship”. That’s why we write down and promote these ideas. Because there is always pressure from someone important to do it another way.

It also wouldn’t work without these other items of corporate propaganda:

You break it, you bought it

If you break something or your stuff is buggy, please fix it. As in straight away mate.

Sweat the details and corner cases

If people are going to ship whatever they want, we need them to sweat the details if they’re going to avoid mistakes.

The best way to do that is to have the rest of the team constantly complain that your code and/or design sucks or, in polite terms, “contains opportunities for improvement.”

Actually, mistakes are fine. They’re something you trade off for other variables like speed of iteration. We just want people to sweat the details because we care about the details.

Be real

Again, if people are going to ship whatever they want, whenever they want, how do we get them to make good decisions? One answer is that we ask them to “be real”. As in, treat our users like real people. Treat your teammates like real people. Just be real and do the right thing.

Do what you think is right (and be right)

If you have the freedom to make decisions, you also have the responsibility of being correct.

S/he who codes, rules

Another way we promote good decisions is by pushing the decisions down to the people doing the work. We memorialize that with the motto, “s/he who codes, rules”. As in, when we disagree, the person doing the work makes the decision.

Own the result

Pushing the decision-making down to the worker works best if the same person is responsible for the metrics. So we try to have 1-wo/man teams whenever we can, and we ask them to own the result. We also hire people who care about our customer and want to solve problems for them.

Freedom and Responsibility

All of these dictums are variations on freedom and responsibility. Netflix has a great presentation on the topic. So does Valve. Peter Drucker probably wrote about it 50 years ago. We didn’t invent this stuff, we don’t claim to know what we’re doing, nor is this a perfectly accurate or complete model of how we operate.

Freedom

1. Ask forgiveness, not permission
2. Do what you think is right (and be right)
3. S/he who codes, rules

Responsibility

1. You break it, you bought it
2. Sweat the details and corner cases
3. Be real
4. Own the result

If you’re interested in working with us, we’re always hiring.

Comment on Hacker News →

Eric Paley’s Curve of Talent is a brutal must-read. I’ve remixed it a bit to come up with the following definitions; the word’s are Eric’s, I’ve just re-ordered them:

F performers are not at all productive.

C performers struggle to competently fill their role, but are somewhat productive with sufficient coaching. Hard to admit, but most people in the business world don’t have a particularly clear idea on how to do their job well. Startups need to help C players transition out of the organization.

B players understand their objectives well and deliver them competently with minimum coaching. Coach B players on the need to not just competently deliver their function, but drive toward innovation within that function.

A players write the book and not just read it. They not only have a clear idea how to competently accomplish their functional objectives, but actually lead the organization to innovate and be world class within their functional area. They raise the bar on the entire organization. One way these candidates can be identified during an interview is when they actually teach the interviewer something about how the company can win.

Go read Steve Newcomb’s essay on building teams:

Cult Creation

Steve’s the founder of Powerset. This essay is very long and very good. It’s the best article I’ve read on building teams. And team building is 10x more difficult, tedious, and important than raising money.

I love/hate this essay.

I love the fact that Steve is open sourcing his secrets. I hate the fact that high-quality startup advice is the exception and not the norm.

I love that this essay was written in Silicon Valley. I hate that Silicon Valley dominates the world in quality startup advice.

Here’s a sample from Steve’s essay:

Engineers Suck at Negotiating, so Don’t Negotiate, Be Fair –from me, after being pissed off about hiring practices I experienced from bad founders.

Over the years, I have noticed some sort of weird inverse correlation between the talent an engineer has for coding and their ability to negotiate. I’ve seen people that could have hacked into NSA suddenly shit twinkies the second I bring up the topic of their salary. I don’t exactly get it, but it’s there.

Founders, on the other hand, are almost by nature programmed to negotiate everything. In some cases, I have seen founders take advantage of engineers who don’t negotiate well, or who simply hate to negotiate so much that it’s a near-phobic experience.

DO NOT DO THIS! If you do, you’re an ass-hat.

Besides being unfair and a dick move, it is also stupid and even worse yet in my book – it’s illogical.

What inevitably happens is that the engineers, who all have different deals, get drunk one night. Then the shit hits the fan when they tell each other what they all make and what equity they got. Come Monday morning, every engineer’s password is “my_founder_is_a_dick,” several viruses and backdoors are suddenly installed into the code base, and the founder gets the silent treatment – none the wiser of his impending doom. Way to go ass-hat!

If you can’t tell, this one pushes my buttons. I don’t give a frog’s fat ass how good a negotiator an engineer is when I’m interviewing them. I want them to have such pristine code that it makes my other engineers cry. I want them to have a beautiful mind that can use logic and reason to solve the engineering challenges that I hand them. It is completely irrelevant how good they are at negotiating.

Go read the rest.