Live data from Hacker News

Build a Team that Ships

startupboy.com

21–30 of 37 posts

Re: Build a Team that Ships

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

Re: Build a Team that Ships

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

Re: Build a Team that Ships

#26
post #21

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?

Re: Build a Team that Ships

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

Re: Build a Team that Ships

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

Re: Build a Team that Ships

#29
post #12

Earlier quoted context omitted.

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

Re: Build a Team that Ships

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

Post reply on HN