Hacker News new | past | comments | ask | show | jobs | submit login

I think the small team aspect is far more important than anything else. With two developers in a startup, you can split up key components and have quick informal talks concerning design choices. In a real company, huge amounts of time are wasted on all-staff meetings, team meetings, 1:1 meetings, management fads, mandatory compliance trainings that come up quarterly and take hours, and the sheer human problem of coordinating that many people. Big companies have huge waste stemming from many different areas. For example, at a large company they have people in charge of requirements that have no understanding of the domain or how to write software. It's like the telephone game you get as a kid where the message completely changes by the time it gets around the circle. Of course you could have your devs do that job, but most companies simply aren't that logical. I bet Paul Graham and another competent developer could use a language that is not considered to be very productive (Ex: C++) and still swim circles past a large IBM team that is being held down by it's own weight.



> mandatory compliance trainings that come up quarterly and take hours

Compliance has a bad name because it's bureaucratic. But in software, compliance can cover important things like privacy, security, internationalization, and accessibility. Getting these things right is a moral imperative in many cases. For this reason, the rise of move-fast-and-break-things startups, with their developers unfettered by bureaucracy, worries me.


I'll agree that there is likely some value (usually CYA for the company) and some real value too. However, those things still take up significant time that the two-person startup doesn't have to worry about and that is just one class of time wasters for big companies. It's always something: A big day-long network outage, firedrills, performance reviews, management shakeups, water cooler gossip, sending emails, reading emails, sudden surprise requests from executives, having to have IT install something as they took away admin rights, preparing for audits and disaster recovery...etc. I bet a startup could easily avoid 30% of the work which just comes with having 100-1000 people in an organization.


For various reasons I have to examine byzantine fault tolerant consensus mechanisms. One of the surprising things I noticed is something like Dunbar's number falls out of it naturally.


I was not aware of either of these things (and now have some interesting reading to do) thanks. I will say that it doesn't surprise me that there is some limit on how much social coordination can be done in a group.

I guess you're doing this for blockchain?




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: