Hacker News Reader

Comment by ztratar | Hacker News Reader

This is why startups kill big companies.

Lots of stupid little processes that add up and make the managers feel power, but end up killing the performance of the business.

Brings up the interesting differences between leadership and management. Managing is what gets people into situations like this, whereas leadership (in late stage companies) is what gets people questioning these processes instead of moving like cattle into a slaughter.

I saw this exact type of behavior at General Electric back in 2011. People wanted to argue about acronyms and process design all day, whilst Samsung ate up 20% market share in 1 year. That business of GE no longer exists and was sold to a foreign buyer. Move fast or die -- this rule does not only apply to startups!

View on HN

It's easy for startups to be nimble because they have no legacy processes to maintain.

The startup may have 5 guys in a warehouse building their product, while the big company has 100 people on a $10M assembly line.

When the startup wants to scale by 20%, they work longer hours or add another worker. If they didn't plan properly and find that they don't have another workstation for that worker, they buy a table at OfficeDepot and there's their new workstation.

The assembly line might need an entire process flow redesign to add more workstations, plus a physical reconfiguration, software changes, etc.

If a developer just blindly adds a parameter that adds 10% to the workday without going through reviews and tests, he may find out from the physical plant engineers that they no longer have enough time to do preventative maintenance so they need to scheduled an outage to do deferred maintenance.

There's a reason why process exists in large companies, and it's not just for the sake of process.

That small startup might be able to usurp the large corporation, but the large company still has an advantage in throughput and/or efficiency. The corporation can promise Walmart that they'll have 100,000 units delivered by Dec 1st... to meet the same goal, the small startup might have to scale their workflow 100X, and they can't do that by scaling from 5 guys in a warehouse to 500 guys in a warehouse.

I don't know, for every justifiable decision I've seen in corporates there have been ten where it was all about politics, needless bureaucracy, incompetence and power and nothing to do with getting things done.

> whilst Samsung ate up 20% market share in 1 year

Right a 78 year old company with hundreds of billions of dollars of revenue is a startup killing big companies.

I'll just note that while Samsung is about half of G&E's age it makes twice as much in revenue.

The comment you are replying to included:

    Move fast or die -- this rule does not only apply to startups!

So I think they are aware that Samsung is not a startup.

Apparently "startup" doesn't mean "company which has just started running" these days, it means "company which is growing rapidly."

I don't know. It seems more like 99% of startups die, and 99% of large companies stick around. Not that I enjoy working for large companies, but just saying...

Right. For every startup that skips process and gets lucky there is a pile that rolled snake eyes and died.

Big companies aren't taking the chance.

Big companies tend to not take that chance even when it's worth taking though. Not everything is mission critical but the procedures around them pretend they are.

Large companies stick around because they've solved the one problem all startups have - finding and keeping customers and turning them into revenue through sales and product pipelines.

Code is pretty much a footnote to that process. It's exactly one of very many tools a business can use.

It's true that technical debt can cause business problems. But it doesn't cause nearly as many problems as having an ineffective sales team, getting killed by regulation, or being eaten alive by a competitor.

> 99% of startups die

And no one bothers suing into the ground a muppet with two packs of ramen to their name ...

Startups can afford to have their critical systems explode.

Considering how inefficient big companies are it's surprising that they don't get killed in the market immediately. You would expect that there are plenty of nimble newcomers who kick their asses but that's not really happening.

Two words: Regulatory Capture.

See Also: Boeing, IBM, CGI Group, AT&T, NRC, etc.

I don't read that as being the point of the article. Regulation is not even mentioned or alluded to. Also, my understanding of regulatory capture has little to do with regulation slowing down business. If anything, rather the opposite. But that's off-topic anyway, and definitely not appropriate for this week.

Edited to update comment on regulatory capture.

I don't know what you're talking about, it's in there plain as day. The company has a department called IT Security. Not IT. Not Security. IT Security. Companies that legitimately care about security integrate security personnel with all of their operations, into every department. Top-down security departments exist to check boxes on regulatory forms. So I will be shocked if "IT Security" is not a made-to-order department whose existence is solely to satisfy things like PCI, HIPAA, etc.

What? In any large company, you are going to have access controls - not everyone is going to be allowed access to every system. In the example given, the guy was requesting access to a new system he didn't previously have access to; having a security team that is in charge of that access doesn't seem to have anything to do with regulation.

True, but the greater danger of integrating security into every department is discounting security in favor of the main requirement of your department. Your department is viewed for political and performance reasons, budgeting time away from the main goal of your area towards security is technically ... waste.

Additionally, you ignore the business logic cross-departmental issues when you do not have a centralized security department.

I understand your point if you're referring to government regulation. I don't think your argument makes sense if you're referring to "regulatory capture":

Regulatory capture is a form of government failure that occurs when a regulatory agency, created to act in the public interest, instead advances the commercial or political concerns of special interest groups that dominate the industry or sector it is charged with regulating.[0]

[0]: https://en.wikipedia.org/wiki/Regulatory_capture

In the case of regulatory capture, you'd think regulation would most likely be reduced rather than impeded.

> In the case of regulatory capture, you'd think regulation would most likely be reduced

No, in regulatory capture you expect regulation to be increased so as to form a barrier to entry to new competitors, while advantaging (comparatively) established incumbents that have the inside track with regulators and the regulatory process.

Makes sense. Thanks for the insight. My believe main point that using the term "regulatory capture" is not what the commenter intended or is appropriate in this case (as it's regulation in general that would affect this rather than tangential effects of regulatory capture).

Just sign the paper for PCI or HIPAA and here you go. Fully PCI and HIPAA compliant.

There is really no need for full IT Security PCPAA compliance department.

Honestly, that's way too simplistic a point of view.

The biggest reason large companies that move slow continue to succeed in their original business, is because their original processes and flow are from when they were growing, while they were learning and more agile in their space. As a result, they still generally provide much more value there than the average startup can compare to, in at least a few specific areas, specific to each business.

That's why the blue ocean approach often succeeds much more than trying to take on a large company at their own game. It's hard, because it's a huge organization dedicated to being good at that one thing- and nothing more. So the better answer is to sidestep, not to take them on directly.

There are advantages to scale and disadvantages. Just looking at the disadvantages makes you wonder how giant companies can exist. Just looking at advantages makes you wonder how tiny companies can ever hope to compete.

Some inefficiencies are more equal than others. Brand, the number of people in your network, reputation all add up.

In software it's often because the can afford expensive lunches with the people buying their software. The buyers are several steps away from the users of the software.

Reminds me of the bike shed effect: https://en.wikipedia.org/wiki/Law_of_triviality

It's easy to criticize this type of thing as wasteful and inefficient for the one time in a thousand where it really is just a single line code change that doesn't break anything, but the reason things like mandatory code review, required tech debt fixes, and all of the rest end up existing is because developers are notorious for saying, "Oh, it's just a one line change!" and then breaking everything when they slam it through to production without thinking about it.

So... one of the places I work is one of those 'nimble little startups', and it gets more and more bogged-down by the day due to some poor technical decisions taken early. There are seven different kinds of timestamp in the database, for example. That's pure dev overhead that gets applied for everything. And because the nimble little startups are pressed to work on new features rather than refactoring, more tech debt just gets added to the pile...

Also, don't forget selection bias - most small companies, startups included, die in the first few years. Only the success stories make the papers.

Reply on news.ycombinator.com