A lot of good bakeries decide to start making sandwiches. It’s an obvious value-add and adds margin. But sandwich customers are different from bakery customers, a sandwich shop has a different layout from a bakery, and making a great sandwich is a very different skill set from making great bread. So it’s not easy to stay a successful bakery and add on a successful sandwich business.
On the other hand, a great sandwich shop can pretty easily hire a baker and set up an oven to make exactly the bread that it needs to elevate its sandwiches.
When Google attempted their Facebook clone, it was just one of the many who took a spin at the wheel. It was always more likely to have failed than succeeded.
Building a B2C with hysteric adoption is difficult because it's very mysterious what elements of the product will actually lead to success, because it's a psychological thing. E.g., if Facebook chose green instead of blue as their theme color (all else equal), it might've died in obscurity.
When you're at a particular layer of the stack, you understand your immediate customer (the layer above you) reasonably well. But two layers up? Three? You're basically guessing. And the higher you go, the more the problems become messy human problems rather than clean technical ones.
I build accounting tools. The technical work is manageable - parsing bank statements, matching transactions, posting to ledgers. But understanding why a bookkeeper categorises something a particular way, or what makes a reconciliation workflow feel "right" vs frustrating - that took years of sitting with actual users and watching them work. A database company could technically build what I build in a few months. They'd never ship something anyone actually wanted to use.
I am now founder of Skyflow, we are runtime AI data security platform. This is my third startup, and previously I ran strategy for Salesforce.
The view of the article seems to be that companies solve problems. The way they solve problems is actually baked in to the structure of the management rather than any individual (sometimes there is an individual like a CEO with enough vision to reshape the management structure to solve new problems, although that is rare). It is also why acquisitions fail so easily - if you take an existing company and graft it under an existing management structure geared to solve some other problem then there is a lot of risk.
IBM didn't "happily" do anything of the sort. The company was undergoing multiple anti-trust investigations at the time and was trying to avoid incurring a large fine or even a structural remedy for creating a vertical monopoly.
The reason Microsoft went to the mat so hard when the government was trying to separate IE from Windows was Gates' fear that the company would end up being similarly crippled by the specter of anti-trust action from the government.
THIS!! A Thousand Times This!
I have had many successful projects putting the coders in direct contact with the end users.
In contrast, every time a manager is inserted between the real user requirements and the code, the project descends a lower ring of endless-feature-creep hell, doubles in length, and doubles it's likelihood of failure.
Yes, managers are needed to provide some insulation from very noisy and chaotic feature requests from users, but insisting on at least some frequent time with some actual coders in contact with actual users pays massive dividends.
The Stack Fallacy (2016) - https://news.ycombinator.com/item?id=26177629 - Feb 2021 (28 comments)
Why Big Companies Keep Failing: The Stack Fallacy - https://news.ycombinator.com/item?id=10927600 - Jan 2016 (169 comments)
1) It may well be a dumb thing they do, but is this really "why big companies keep failing?" There's no real examination of this causal assertion which seems central.
2) Is it really the "stack"? That is to say, do people really assume that just the layer above them is trivial? I see engineers all the time assume that basically everything they don't understand is trivial. For example Elon Musk's famous assertion that the hyperloop is "Basically just like an air hockey table. It's not that hard". Well in turns out air hockey pucks don't need to transport people, g-forces aren't important for air hockey versus not murdering your passengers is quite important for a public transport system. Air hockey pucks don't need to breathe versus people do which makes the vacuum part quite critical and challenging especially since you have to figure out how to get people in and out without rupture. To think of it as like air hockey you are assuming that all interesting/challenging parts of the problem are trivial. To be clear: I think that this hubris is basically essential for innovation. I really don't think people would ever innovate if they worried too much about every small detail of things, but this is why a large proportion of experiments by everyone (big and small companies alike) fail. I don't think the layer above you in the stack is the important part here and the article doesn't examine whether that characteristic is important.
There was once a programmer who was attached to the court of the warlord of Wu. The warlord asked the programmer: "Which is easier to design: an accounting package or an operating system?"
"An operating system," replied the programmer.
The warlord uttered an exclamation of disbelief. "Surely an accounting package is trivial next to the complexity of an operating system," he said.
"Not so," said the programmer, "When designing an accounting package, the programmer operates as a mediator between people having different ideas: how it must operate, how its reports must appear, and how it must conform to the tax laws. By contrast, an operating system is not limited by outside appearances. When designing an operating system, the programmer seeks the simplest harmony between machine and ideas. This is why an operating system is easier to design."
The warlord of Wu nodded and smiled. "That is all good and well, but which is easier to debug?"
The programmer made no reply.
It isn't so much that I think the criticism is wrong. Many people do think they could more effectively do something in a different area. But this isn't a stack thing. People are largely ignorant of a ton of work happening everywhere.
You see that ignorance quite commonly in stuff like climate activism. Young activists are convinced that nobody is working on the problem. And to be clear, it would be nice if maybe more people were working on some problems. But please don't ignore the progress made by a lot of hard work, in the meantime.
But back to "why companies keep failing." I could as easily assert that big companies fail when they stop pouring money into growing. Wouldn't be hard to build an argument that the more "funny money" is at play in a large company, the more they are stifling innovative ideas in their walls. Of course, if you pour money through leveraged debt, some day that comes due, as well.
Except today. Even since this was written, large cap growth funds or "blue chip" stocks have tremendously outperformed everything else, more than doubling the return of small cap value. Big companies are absolutely not failing. They're doing better than they ever have at any other time in history, granting this is the admittedly short span of human history in which we had public equity markets.
and our technolords telling us plebs will be technoserfs to be replaced by a.i or that everything will be built by a.i
Holy fuck, all you need is a server application, a database, HTML, JavaScript, and CSS to make a CRUD app. Seriously, that is really all you need. The problem though is that nobody trains developers any more and so you get a little bit of helpers to help the developers along, which turns out to be a mountain of bullshit that developers use to line their resumes like notes on toilet paper.
As a counter point I wrote a large single page app and then adapted it into removable modules that can be turned off from a JSON file. So, its modular, which then solves for the design goal of most modern JavaScript browser frameworks. But, it's just vanilla TypeScript. It is stupid simple to scale, extensions from one of two TypeScript interfaces without tech debt. The best part is that its fast... like completing all initial execution, rendering, and garbage collection in less than 130ms.
https://github.com/prettydiff/aphorio/blob/screenshots/paper...
So, in practice it seems you could easily replace 10 React/Angular developers with a single TypeScript developer and a series of small TypeScript interfaces. The bonus is that you get faster releases, 100% accessibility (because its mostly raw HTML instead of compiled templates), and a substantially faster product.