Lessons scaling from 10 to 20 people • Hacker News Board

Re: Lessons scaling from 10 to 20 people

#21

Post by amorphid » Sun, May 14, 2017, 10:52 PM UTC

dodorex wrote: post #6

can somebody explain why posthaven is so widespread? i don't see any reason to use it over medium etc

Posthaven was started by Garry Tan, a YC alum & founder of Posterous. When Posterous, a blogging-ish platform, was acquired and later shutdown...

http://techcrunch.com/2013/02/15/posterous-will-shut-down-on...

...Garry started Posthaven. Posthaven got press as the "never gonna sellout and/or shutdown" blogging platform. I still remember Posthaven whenever I think about starting a blog that I'd like to be around forever. It's a good pitch for people who value the longevity of things they write. I'm not confident Medium will be around forever, and major content sites do go bye bye: Posterous, Geocities, Vine.

Re: Lessons scaling from 10 to 20 people

#22

Post by dasil003 » Sun, May 14, 2017, 10:54 PM UTC

dilemma wrote: post #5

dasil003 wrote: post #4

Earlier quoted context omitted.

I understand the appeal of this, but the hardest thing in the very beginning is keeping a laser focus on the critical task of building and validating something people want. Resources are so precious at that stage, and the green field is so wide open, that you have to be obsessive about keeping an eye on the ball. It's extremely easy to drink your own koolaid and start believing the narrative in your pitch deck before…

I think you've misunderstood the parent. By making explicit that the founder does all these things, it makes the urgency of hiring and delegating clear.

Sorry, what do you think I'm misunderstanding?

The GP is clearly suggesting thinking about role definition from day one rather than waiting until the 10-20 employee phase. I'm stating unequivocally that I think that is a mistake.

The "urgency of hiring and delegating" only kicks in once you have a level of certainty of what needs to be done. Every employee you bring on adds not only burn rate, but also communication overhead. The only thing that gets a startup from the garage phase to actually being able to series A and credibly hire more than 10 people is for every founder and early employee to ruthlessly identify things that need to be done and execute on them. This idea of documenting what exactly founders are doing and thinking about delegating them is what YC has dubbed "playing house"*.

[0] http://www.paulgraham.com/before.html

Re: Lessons scaling from 10 to 20 people

#23

Post by Silhouette » Mon, May 15, 2017, 3:51 AM UTC

dasmoth wrote: post #20

Silhouette wrote: post #18

Earlier quoted context omitted.

What you describe is often true in larger companies, but IME not in the kinds of 10-20 person outfits we're talking about here, or even quite a bit bigger. At that level, one experienced "generalist" person who can do a whole job end-to-end can still get the same visible results as a small team of less experienced "specialist" people, and if we're talking about salaried staff then that single more experienced person…

Agree with all of this. But there seems to be active distrust of coders working solo, both from managers and from other coders. There's a surprisingly strong perception the "a team" is the safe option.

But there seems to be active distrust of coders working solo, both from managers and from other coders. There's a surprisingly strong perception the "a team" is the safe option.

It's been my experience that capable developers tend to appreciate other capable developers. It's also been my experience that capable developers appreciate managers who are actually doing a useful job, and vice versa, and that both of those groups are also quite willing to support those who are currently less experienced but are interested and trying to learn and grow.

I suspect the kinds of objections you're thinking of most often come from managers or developers whose own positions are threatened as soon as someone competent enters the picture. A capable one-person development group has no need of a micro-manager to take the credit on their behalf, nor of a developer who has just enough knowledge and skill to be dangerous and/or in the way but no inclination to get any better.

At some point obviously you need more than one developer for scalability and resilience, but even then you can still do a lot with a few good developers and a useful manager co-ordinating them compared to a large group of mediocre developers and a whole management hierarchy above them.