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

I wonder if a certain type of software business is most amenable to this.

For instance, if you are a growing SaaS that doesn't need to pivot, but rather to scale and add features.

In that case, a certain number of your objectives are inherent and obvious. Features that exist should be stable. Features that work now, for the current number of customers, should continue to work as more customers are added.

Well, if your SaaS is doing something valuable, just meeting those criteria is likely to involve a lot of work (otherwise it seems the product wouldn't be valuable), and profitability (customers indicate that it's valuable with their wallets).

And at least for some subset of SaaS companies, up to a certain number of developers, those criteria can be met by developers looking at metrics and saying to themselves, "hmm, this or that bug exists that I can fix", or "I wonder if it would be worth it to containerize the app and write tests that work against the whole container," and do a feature branch and then a PR, and if this initiative turns out to be new or valuable enough it eventually gets written into a blog post and may become part of the nature/value of the product, or contribute to the culture of the company.

So for companies with the right circumstances, I can readily imagine that the jobs that bosses do can be replaced by IRC, Github and the obvious objectives the product itself provides.

I don't know how it would work for companies more generally.

For companies that are still trying to decide what to do? Or what to do next? That seems quite experimental. For instance, Valve software; they have had such a headwind from Steam, for so long, that we may not really know how well the "bossless" approach will work for them until it produces their Next Big Thing.




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

Search: