Build a Team that Ships

I started my first company 15 years go, and I still can’t manage. I suspect that very few people can. With AngelList, we want a team of self-managing people who ship code.

Here’s what we do:

  • Keep the team small. All doers, no talkers. Absolutely no middle managers. All BD via APIs.
  • Outsource everything that isn’t core. Resist the urge to pick up that last dollar. Founders do Customer Service.
  • People choose what to work on. Better they ship what they want than not ship what you want.
  • No tasks longer than one week. You have to ship something into live production every week – worst case, two weeks. If you just joined, ship something.
  • Peer-management. Promise what you’ll do in the coming week on internal Yammer. Deliver – or publicly break your promise – next week.
  • One person per project. Get help from others, but you and you alone are accountable.

If they can’t ship, release them. Our environment is wrong for them. They should go find someplace where they can thrive. There’s someplace for everyone.

It’s not perfect. We ship too many features, many half-baked. The product is complex, with many blind alleys. It’s hard to integrate non-engineers – they aren’t valued.

But, we ship.

29 thoughts on “Build a Team that Ships

  1. This is an extreme view but I have a hard time disagreeing wholesale with any of it. I have been writing code, shipping things and managing teams for over a decade and the environment you describe is the ideal that is worth moving towards.

      • I agree with the fact that engineer is responsible for end to end delivery of the module but what happens in a case where everything falls as responsibility of the engineer .For example

        Consider a person working for a company XYZ where he is a coder and he has been assigned the module and he completes the design,implementation and unit testing end to end .But what happens in scenario where operations dont do there job properly in terms of provisioning the required systems for the production and not set up the required connectivity and developer keeps polling and checking them on stuff and the project gets delayed due to such circumstances .Is the engineer still reliable if the other people dont work properly and make engineer responsible for the delay

    • We split it into a much more micro-basis. Most of our developers do front end and back end. Design is a shared resource.

      • How is design a “shared resource”? Just curious. Do you only hire engineers with design capabilities, or is it like declaring design a shared responsibility?

  2. Sounds like you’re ideally setup for distributed teams. These are exactly the kinds of personality traits I look for when building one. You want people who will do what they think is the right thing, and do it on its own merit, because of internal motivation. Zero management required.

  3. Totally agree with you! The principles you outlined would personally energize me as an engineer and that’s what it’s all about. But what would you do if the feature you’re working on isn’t ready to ship? Shipping is key, but should be adjusted based on the project. A usable functioning product is much more important. For instance, how would build out an android app if after a week it didn’t provide functionality crucial to your product?

  4. Fantastic points — always believed in small effective teams that attack the market directly. Given opportunities to outsource even hardware and materials work — this approach can be implemented in other fields, maybe with some minor modifications.

  5. lean team = profitable team!

    In one word “collaboration” a product built from multiple views has a broader reach than a product built with only one point of view.

    I build companies/teams in terms of milestones, managed labor is a waste of time and payroll. keep cost low and outsource when needed.

    Build part and ship, the next team member gets excited and challeged to build something a little better, a little sexier, then ships and so on, all with one goal of complimenting the products end UX.

  6. probably optimal structure for exploration and discovery. only thing I wonder about is may not be optimal structure for maximizing user conversion behavior, and keeping UX simple. but I won’t argue with success… it’s great to see how fast you folks get stuff out there.

  7. Great tips, thanks for sharing Naval. Just curious – what processes/tools do you use to keep track of what is currently being worked on, what’s in the pipeline etc? It sounds like some kind of Kanban-lite would fit in nicely here.

  8. As a maker, I like the spirit, but I would rather say, “build a team that ships valuable software,” with valuable not defined by the team but by how it impacts the customer.

    Judging a team by features shipped is like measuring by lines of code.

  9. Our business lives by this. I guess the question should be though can you still continue to live by this mantra when you get to be a big company. I know Facebook try’s to carry this on but its probably harder for some other businesses to accepted that not all code is QA tested.

  10. Naval,
    Can you share wisdom on which tools you use internally for task / project management?
    e.g. Pivotal Tracker vs Trello vs Sprintly vs Kickoff or similar.
    Thanks
    Dave

  11. Fail forward.

    Customer Creation is shipping. If they can’t create customers, let them go.

    Absolutely NO management required… but a ton of LEADERSHIP required!

  12. Seems like a great approach, and you’ve clearly proven it successful in your own case.

    However I wonder how realistic the “one person one project” is for most startups/organizations? By your rules people very strong in one area (i.e. programming) but very weak in others (i.e. design) would have no role, anywhere. It seems to me that teams of two or three for some projects is more realistic, and could result in better results even because your pool of expert-level potential candidates is much broader if they don’t have to be excellent in all things.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s