5 ms·

It's unfortunate that as startups get larger, the speed of improvement on their product often gets slower. It's strange to me that Dropbox has thousands of emp

It's unfortunate that as startups get larger, the speed of improvement on their product often gets slower. It's strange to me that Dropbox has thousands of employees, people have wanted this for a _long_ time, and yet this hasn't been built. You'd think that with more engineering/PM/design talent the product would get better, and faster. Anyone have any insight into why happens? I've never worked at a early stage startup but here are some hypotheses: - Maybe this is a good thing. After a product is "done", adding more functionality makes it worse, not better. - Maybe the company leadership's focus shifts from building a great product to scaling as fast as possible. And doing both at once isn't possible. - Maybe the engineering division grows substantially, but the number of people actually working on the product doesn't change much. Instead the new engineers work on important, but auxiliary things, like dev tooling, security, infra, ops, etc - Maybe developing features takes longer because there's more process: security/legal/ops needs to review it, several layers of management need to approve it, it needs to work in multiple countries, etc - Maybe the urgency to keep improving your product disappears after you feel that you've made it - Maybe it's more important to take longer to build stable, complete features instead of shipping as fast as possible

franze 7y ago
Overhiring. Individual productivity goes down the more the company hires. At one point big software companies are only big because they can afford to be big. I wrote about it here https://medium.com/@franz.enzenhofer/overhiring-b966a6ff383d?source=friends_link&sk=2c4e3013c14534e1ec9a7f464da6be80 https://medium.com/@franz.enzenhofer/overhiring-b966a6ff383d...
- veeralpatel979 7y ago
  I read this somewhere on HN: if your company has $1 million in ARR with 3 people, you'll likely feel need to hire more people, even if the 3 people get the job done. Now repeat this with $1 billion in ARR...you get the picture. I've seen "Bullshit Jobs" recommended here on HN [1]. [1] https://en.wikipedia.org/wiki/Bullshit_Jobs https://en.wikipedia.org/wiki/Bullshit_Jobs
twblalock 7y ago
The larger a product gets, the risk and customer impact of regressions increases, so even "simple" changes require significant engineering and QA effort. There are also so many feature requests that prioritizing them is a full time job.
- degenerate 7y ago
  That, and, as people move on - their code remains... so part of adding new features means sifting through the codebase to learn what everything does and be very careful not to add new bugs.
- idoh 7y ago
  I'd say customer impact, even without regressions. As an example of something that I'm currently working on: - there is a need to add a single link to a page - some percentage of the customers will not like this change (perhaps 5%), because it links to a non-whitelabeled area of the product - as a result, a list of customers that will be upset has to be assembled, and then each one reached out to, which a different department, that doesn't really care if the link is there or not, has to do I'd say that doing the above will take a month or so. All for a link.
krsdcbl 7y ago
I know "we" in the dev community are always eager for improvement, better tooling and often specific features. Many non-dev folks will also sometimes express the need for certain functionality. But there's one factor that plays a big role in this i think: most people don't like it when somebody changes "their stuff", regardless of possible benefits. So once a product is well established, tweaking and changing it puts you at quite a risk of annoying or losing some of your aquired userbase, and further development therefore ensues much more prudently and slowly.
commandertso 7y ago
One thing I’ve seen: feature priority driven by what is expected to drive sales. This is a feature that I could see, justified or not, as not driving adoption.

franze 7y ago

Overhiring. Individual productivity goes down the more the company hires. At one point big software companies are only big because they can afford to be big. I wrote about it here https://medium.com/@franz.enzenhofer/overhiring-b966a6ff383d?source=friends_link&sk=2c4e3013c14534e1ec9a7f464da6be80 https://medium.com/@franz.enzenhofer/overhiring-b966a6ff383d...

veeralpatel979 7y ago
I read this somewhere on HN: if your company has $1 million in ARR with 3 people, you'll likely feel need to hire more people, even if the 3 people get the job done. Now repeat this with $1 billion in ARR...you get the picture. I've seen "Bullshit Jobs" recommended here on HN [1]. [1] https://en.wikipedia.org/wiki/Bullshit_Jobs https://en.wikipedia.org/wiki/Bullshit_Jobs

twblalock 7y ago

The larger a product gets, the risk and customer impact of regressions increases, so even "simple" changes require significant engineering and QA effort. There are also so many feature requests that prioritizing them is a full time job.

degenerate 7y ago
That, and, as people move on - their code remains... so part of adding new features means sifting through the codebase to learn what everything does and be very careful not to add new bugs.
idoh 7y ago
I'd say customer impact, even without regressions. As an example of something that I'm currently working on: - there is a need to add a single link to a page - some percentage of the customers will not like this change (perhaps 5%), because it links to a non-whitelabeled area of the product - as a result, a list of customers that will be upset has to be assembled, and then each one reached out to, which a different department, that doesn't really care if the link is there or not, has to do I'd say that doing the above will take a month or so. All for a link.

krsdcbl 7y ago

I know "we" in the dev community are always eager for improvement, better tooling and often specific features. Many non-dev folks will also sometimes express the need for certain functionality. But there's one factor that plays a big role in this i think: most people don't like it when somebody changes "their stuff", regardless of possible benefits. So once a product is well established, tweaking and changing it puts you at quite a risk of annoying or losing some of your aquired userbase, and further development therefore ensues much more prudently and slowly.

commandertso 7y ago

One thing I’ve seen: feature priority driven by what is expected to drive sales. This is a feature that I could see, justified or not, as not driving adoption.