3 ms·

> You hire a ton of people for these projects but end up letting them all go when they realized those projects weren't going to pan out. Which is weird, becaus

> You hire a ton of people for these projects but end up letting them all go when they realized those projects weren't going to pan out. Which is weird, because they're not especially difficult projects. OpenSea was built by like five people.

cmsj 4y ago
Presumably the difference is that those 5 people really wanted to build OpenSea, where Coinbase staff were just assigned to projects.
robswc 4y ago
I agree with your sentiment and I think you would agree with this, just wanted to get it out there. I've seen teams of 10-15 people that do absolutely nothing. Have 10 meetings about specs but space them out over a year, so that by the time the next meeting happens, everyone forgets the entire context of the project... so you have to cover everything again. By the end of year, its gone absolutely no where due to 2-3 layers of bureaucracy. Coinbase _can_ hire good talent... wonder if managing it is the/a problem.
- vgatherps 4y ago
  > Coinbase _can_ hire good talent... wonder if managing it is the/a problem. I've worked at a company where at an individual level people were quite talented, moreso than competitors who did better than them .... but getting anything done required Y different meetings with X different teams, satisfying N different gatekeepers who just want to push their own product on you, avoid stepping on the toes of persons X,Y,Z, etc etc. Company multiplied in size a few times over the course of a few years and had just no idea how to handle it.
- yamtaddle 4y ago
  I've seen a large non-tech company (you probably know them) increase dev time by like 50% (plus increase defect rates) across several projects because someone inside had built an identity as "the [niche database] guy" and successfully sold [niche database] to the org (with the help of [niche database]'s marketing material) as the solution for all problems, when it was actually a pretty terrible fit for almost everything they were doing. This dude cost them millions, for no benefit whatsoever, by causing morale-crushing slowdowns on every project. It was crazy. Wouldn't be surprised if he's running the tech-side of that whole place by now, either. They seemed to love the guy.
dayvid 4y ago
The more people you have, the longer things take. Everyone has an opinion and you need to spend time to get people to agree on things. This compounds with XFN teams and people coming up with make work or competing for top spot for the sake of performance reviews. Probably better to have a small team quickly ship a v1 and get everyone involved after.
_fat_santa 4y ago
It's a classic problem with big companies and software development. Say you worked for a Fortune500 company and they wanted you to build a TODO list app. The core app can be built in a week, but it ends up taking 3 months and a team of 10 engineers, why is that? * Well we need to integrate it with our engagement platform, meetings required with engagement to determine scope and requirements. * Well we need it to also integrate with our productivity API, another set of meeeting to determine scope of integration. * We need deep reporting capabilities, please get with the reporting team to determine requirements. * Also this app will need to integrate into EXISTING_TOOL_A and EXISTING_TOOL_B. App cannot be built in React and must be built in Angular with OLD_SOFTWARE_PKG_1 and OLD_SOFTWARE_PKG_2 in order for it to successfully integrate with these old apps. * Hey we just signed a contract with CLOUD_PROVIDER_Y, we know you were using IN_HOUSE_PROVIDER_1 for your infra but now please modify the entire app to work with CLOUD_PROVIDER_Y. * Oh and it also needs to be backwards compatible with IN_HOUSE_PROVIDER_1 because it needs to run in parallel while we onboard CLOUD_PROVIDER_Y
- jerf 4y ago
  The requirements will expand too. The startup is probably not worried about ADA compliance, deep Unicode compatibility, localization (the reason why we need to be good at Unicode), complying with the backup policy, security team review, auditing requirements, immediate compliance with privacy laws in other jurisdictions (e.g., a US startup might ignore EU law right away but the Fortune500 might not want to), especially with regard to personally identifiable information, etc. You list a lot of perfectly valid "external" things that a Fortune500 company might add, but there's also internal things that it may need immediately that a startup won't. (The backup policy being a particularly trenchant one, in my opinion. It's not an every day thing, but we've certainly seen several stories over the years on HN of startups basically going "whoops, we accidentally the data, sorry we're shut down now because this is unrecoverable for us".)

cmsj 4y ago

Presumably the difference is that those 5 people really wanted to build OpenSea, where Coinbase staff were just assigned to projects.

robswc 4y ago

I agree with your sentiment and I think you would agree with this, just wanted to get it out there. I've seen teams of 10-15 people that do absolutely nothing. Have 10 meetings about specs but space them out over a year, so that by the time the next meeting happens, everyone forgets the entire context of the project... so you have to cover everything again. By the end of year, its gone absolutely no where due to 2-3 layers of bureaucracy. Coinbase _can_ hire good talent... wonder if managing it is the/a problem.

vgatherps 4y ago
> Coinbase _can_ hire good talent... wonder if managing it is the/a problem. I've worked at a company where at an individual level people were quite talented, moreso than competitors who did better than them .... but getting anything done required Y different meetings with X different teams, satisfying N different gatekeepers who just want to push their own product on you, avoid stepping on the toes of persons X,Y,Z, etc etc. Company multiplied in size a few times over the course of a few years and had just no idea how to handle it.
yamtaddle 4y ago
I've seen a large non-tech company (you probably know them) increase dev time by like 50% (plus increase defect rates) across several projects because someone inside had built an identity as "the [niche database] guy" and successfully sold [niche database] to the org (with the help of [niche database]'s marketing material) as the solution for all problems, when it was actually a pretty terrible fit for almost everything they were doing. This dude cost them millions, for no benefit whatsoever, by causing morale-crushing slowdowns on every project. It was crazy. Wouldn't be surprised if he's running the tech-side of that whole place by now, either. They seemed to love the guy.

dayvid 4y ago

The more people you have, the longer things take. Everyone has an opinion and you need to spend time to get people to agree on things. This compounds with XFN teams and people coming up with make work or competing for top spot for the sake of performance reviews. Probably better to have a small team quickly ship a v1 and get everyone involved after.

_fat_santa 4y ago

It's a classic problem with big companies and software development. Say you worked for a Fortune500 company and they wanted you to build a TODO list app. The core app can be built in a week, but it ends up taking 3 months and a team of 10 engineers, why is that? * Well we need to integrate it with our engagement platform, meetings required with engagement to determine scope and requirements. * Well we need it to also integrate with our productivity API, another set of meeeting to determine scope of integration. * We need deep reporting capabilities, please get with the reporting team to determine requirements. * Also this app will need to integrate into EXISTING_TOOL_A and EXISTING_TOOL_B. App cannot be built in React and must be built in Angular with OLD_SOFTWARE_PKG_1 and OLD_SOFTWARE_PKG_2 in order for it to successfully integrate with these old apps. * Hey we just signed a contract with CLOUD_PROVIDER_Y, we know you were using IN_HOUSE_PROVIDER_1 for your infra but now please modify the entire app to work with CLOUD_PROVIDER_Y. * Oh and it also needs to be backwards compatible with IN_HOUSE_PROVIDER_1 because it needs to run in parallel while we onboard CLOUD_PROVIDER_Y

jerf 4y ago
The requirements will expand too. The startup is probably not worried about ADA compliance, deep Unicode compatibility, localization (the reason why we need to be good at Unicode), complying with the backup policy, security team review, auditing requirements, immediate compliance with privacy laws in other jurisdictions (e.g., a US startup might ignore EU law right away but the Fortune500 might not want to), especially with regard to personally identifiable information, etc. You list a lot of perfectly valid "external" things that a Fortune500 company might add, but there's also internal things that it may need immediately that a startup won't. (The backup policy being a particularly trenchant one, in my opinion. It's not an every day thing, but we've certainly seen several stories over the years on HN of startups basically going "whoops, we accidentally the data, sorry we're shut down now because this is unrecoverable for us".)