build-a-team-that-ships.mov
Loading…

Build a Team That Ships

by Naval Ravikant · April 2012 · 3 min · read the original ↗

chapters

    transcript

    Build a Team That Ships. An essay by Naval, from April 2012.

    A team that manages itself

    Naval starts with a confession: fifteen years after founding his first company, he still can't manage. He suspects hardly anyone can.

    So at AngelList, he wanted people who manage themselves, and whose output is working code.

    Small, and only doers

    Rule one: keep it small. Everyone builds; nobody is there just to talk. And no middle managers, none at all.

    Partnerships? They go through the API, not through a business development staff.

    Anything that isn't central gets handed to outsiders, even if that means leaving some money on the table.

    And who answers customers? The founders, themselves.

    Pick your work, ship every week

    Who decides what each person works on? They do. People pick their own projects.

    Naval's reasoning: “Better they ship what they want than not ship what you want.”

    No task may run past a week. Something reaches live production every week, or every two at the very worst.

    Just joined? You still ship something.

    Promises in public

    Instead of a boss, there are peers. Each week you post a promise on Yammer, the internal feed: here is what I will do.

    A week later, you deliver it, or you admit in front of everyone that you broke it.

    Every project gets exactly one person. Others can pitch in, but the accountability is yours alone.

    When someone can't ship

    And someone who can't ship? They're let go.

    In Naval's view, the problem is the fit: this place is wrong for them. Elsewhere they can thrive, because there's a place for everyone.

    The price, and the payoff

    Naval doesn't pretend it's perfect. They ship too many features, and plenty of them half-finished.

    The product grows complicated, with dead ends. And non-engineers have a hard time fitting in, since the culture doesn't value them.

    But they ship.

    In short

    Keep the team small and hands-on: no middle managers, and anything non-core goes outside.

    Let people choose their work, and get something live every week.

    Promise in public, give each project one owner, and part ways with those who can't ship.

    It gets messy. But they ship.

    The original is short, and better than this. Read it: nav.al/build-a-team-that-ships