
Build a Team that Ships - dwynings
http://startupboy.com/2012/04/27/build-a-team-that-ships/
======
adammichaelc
Depends on the style of the company. Different companies would say different
things about this.

Apple: "Bad advice. Let a "Jon Ive" type design-lead think through the product
and detail every page of it. Don't let engineers run product. Give them the
ability to give feedback on product, but give the ultimate authority to
somebody who understands human emotion, art, UX, etc"

Google pre-Page: "Good advice. Engineers should control product. They are
smarter than everybody else, and therefore will make the best software."

The reality of these company's positions is more nuanced than this, but these
caricatures have their place in helping to understand how they think.

------
MediaSquirrel
Supreme Irony: Neither of the founders at AngelList actually code.

~~~
naval
I'm actually a former coder, albeit not very good.

------
simonw
We have a "ship on the first day" policy for new employees which has been
working really well - it forces the issue on getting development environments
set up, keeps our deployment process quick and simple, and means that by the
end of day one we have another person who is ready to ship improvements to the
site.

~~~
thebluesky
What type of ships do you use?

------
rollypolly

      No tasks longer than one week. You have to ship
      something into live production every week – worst
      case, two weeks.
    

Does this actually work? What I mean is, no matter how much you break down a
task, aren't certain sub-tasks going to take more time than this?

~~~
naval
In my experience, tasks that take longer than one week sometimes take two
weeks. But if they don't make it within two, they basically never ship. It's
like you can go out and have one drink, or two, or many. But never three...

~~~
james4k
That's such a great way to put it. You hit the nail on the head. For the rare
exceptions to this, you better be damn sure it's worth the time, and that you
really need it. Because if you think about it some more, you will probably
discover you're better off not doing it at all.

I've had a few tasks like this that we just ended up scrapping, even after
several weeks of work, because we found we didn't need the monstrosity of a
feature as much as we thought we did.

------
hkarthik
All of these things are doable, but require a combination of people and their
skills that are very difficult to find. You need the following:

1) Product people that have shipped code themselves in the past and can
provide enough detail for an engineer to run with.

2) Fullstack Engineers that are empowered to fill in the gaps in business
analysis, process flow, and UX on the fly using their gut. They also need to
have a good eye for design and shouldn't have to ask a designer to help for
everything.

3) Solid instrumentation to rollout, measure, and rollback features on a live
system in way which limits user impact.

4) Bulletproof trust on the team and a culture that supports being able to
make mistakes and learn from them.

------
zdgman
I feel like at a certain point you are moving too fast. The author makes it
seem like he is chasing after speed at his own peril.

Isn't it better to take an extra week to polish a feature than to just "ship
it" and then patch it later? At a certain point as your organization grows and
your product becomes more mature shouldn't your focus shift from quantity of
features released to actually shipping quality releases?

I know there is a balance here. Don't be so worried about polish that you
don't ship anything but don't be so blinded by speed that you ship everything
within a week. You just can't make blanket rules like this.

~~~
naval
The problem is that there is an incentive to always pad estimates. By forcing
a one-week schedule, you counterbalance that tendency, and make it possible to
measure yourself more accurately. Despite this, I'd say that many of our
projects fail, never ship, ship and have to be rolled back, or ship and have
to be iterated 5 or more times until we get them "good enough." But it still
beats taking 3 months to ship something interesting, which is the cycle most
startups are on once they're out of an incubator or done with their initial
release.

------
flavien_bessede
Probably the best way to ship "wrong". You ship, granted. But I imagine that
part of the feature you push weekly are small, and so would have more meaning
if part of a bigger push. You also probably end up with a lot of non-polished
features, half-baked as you name it. I honestly don't see anything good point
in that article, what happens to 2 months project? You cut it in 3 to 6 pieces
just to have to ship? Meaning you waste time forcing yourself to push
something that works rather than focusing on the end goal.

------
tdr
> Keep the team small. All doers, no talkers.

Totally agree here. Best teams I work in were the small and focused ones!

I can't really see why small companies with high revenue/traction are
portrayed as "risky/volatile" because they have 5-15 employees.

To some extent, the same is with single-founders. Why "dismiss" a 1-man team
if he did the work of 2-3 people?

PS: I know the motivations for both, but there is a distinction between
possibility and likelihood of a risk to actually occur.

------
JoeAltmaier
WOrks for some set of development projects. Especially if you develop using
libraries that have the 'hard stuff'.

But consider who wrote those libraries. They took longer than a week. They are
not just a basket of features, they may be a large architectural puzzle.

The point is, the author's advice may work for a web page, and there are a lot
of startups that just make a web page these days, so sure.

------
rachelbythebay
"All BD via APIs". I know what APIs are, but what's BD?

~~~
naval
Business Development.

~~~
neolefty
Still not getting it -- how do you do business development via APIs?

~~~
sajid
In the past you got distribution by making deals with partners. Now you get
distribution via APIs (think Facebook and Apple).

~~~
MortenK
An API is still an application programming interface right? What kind of
distributon / business development are we talking about here? And how can it
possibly be conducted through an API?

~~~
_pius
You don't have to wine and dine Facebook's business development team to get
the user actions in your app syndicated on Facebook, you just use their API to
do it yourself.

~~~
MortenK
The definition of business development here being actions done by users in an
app, showing up on facebook?

~~~
_pius
You asked about distribution and that's an example of distribution.

[http://www.businessinsider.com/growth-hackers-are-the-new-
ma...](http://www.businessinsider.com/growth-hackers-are-the-new-
marketers-2012-4)

~~~
MortenK
That was a very interesting read, thanks.

~~~
_pius
No problem.

------
troels
As long as you control the product entirely, I believe that it's possible to
break tasks down into one-week chunks. But what happens when you depend on
external parties to complete your task? If they don't delivery, or if it just
takes a lot of pm legwork to get things moving, a technically simple task may
well take many weeks to get through.

------
stu_wilson
Problem with such one week shipping stufff is you are inadvently creating a
mess. Everybody is concerned about shipping but everyone forgets to do the
gardening and trim the weeds.

