Build a Team that Ships | Hacker News Reader

Build a Team that Ships

startupboy.com

58 pointsdwynings34 comments

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.

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

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

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.

What type of ships do you use?

  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?

I feel like the author sort of answers this question with the following statement:

  It’s not perfect. We ship too many features, many half-baked.
  The product is complex, with many blind alleys.

It sounds like his team is more focused on just getting something out and improving it iteratively than it is on producing a polished product that is architected beautifully.

This is a great approach. It's also not always appropriate for everyone.

I wonder if refactoring work is allowed to meet this requirement, even though it's not customer-visible?

Promise you will deliver the refactored code in a week, set out some metrics, ship it.

The other devs will be happy someone improved the code. Like the guy said, it's better they ship what they want than not ship what you want

Brilliant IMO

We do regular one-day long refactoring sessions where everyone refactors. But yeah, our codebase is not a thing of beauty. We're more focused on figuring out what users actually want, and we'll rebuild it when it's falling over.

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?

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.

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

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.

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.

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.

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.

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

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.

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

Business Development.

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

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

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?

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.

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

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

http://www.businessinsider.com/growth-hackers-are-the-new-ma...

That was a very interesting read, thanks.

No problem.

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.

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.

Reply on news.ycombinator.com