Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Build a Team that Ships

startupboy.com

Post reply on HN
Print view View original

11–20 of 37 posts

Re: Build a Team that Ships

#11

Post by naval »

zdgman wrote: post #6

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?…

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.

Re: Build a Team that Ships

#13

Post by 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.

Re: Build a Team that Ships

#14

Post by naval »

cullenking wrote: post #4
rollypolly wrote: post #2

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?

It does if your problems are simple...

Even complex problems can be chunked down into smaller things. That's pretty basic.

Re: Build a Team that Ships

#15

Post by rollypolly »

naval wrote: post #14
cullenking wrote: post #4

Earlier quoted context omitted.

It does if your problems are simple...

Even complex problems can be chunked down into smaller things. That's pretty basic.

True, but...

  You have to ship something into live production every
  week – worst case, two weeks.
In your experience, have the smaller pieces always been in a state that can be pushed to production every week? If not, how was that handled?

Re: Build a Team that Ships

#17

Post by lupatus »

rollypolly wrote: post #2

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?

At my job, our policy is no task longer than 3 hours. Longer than that and our clients start questioning the invoices.

Re: Build a Team that Ships

#19

Post by james4k »

naval wrote: post #8
rollypolly wrote: post #2

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?

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...

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.

Re: Build a Team that Ships

#20

Post by 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.

Post reply on HN