When small meets large, small almost always wins(firstround.com)
firstround.com
When small meets large, small almost always wins
http://firstround.com/review/leslies-law-when-small-meets-large-small-almost-always-wins
5 comments
What IBM noticed (or rather Louis V. Gerstner did) was that companies didn't buy computers to do payroll, they bought solutions to solving the payroll problem, which happened to eventually be computers.
And IBM were going broke trying to sell their computers instead of the best solutions, which they changed: even if that was on competitor's hardware or software.
And IBM were going broke trying to sell their computers instead of the best solutions, which they changed: even if that was on competitor's hardware or software.
This seems like just a basic restatement of Clayton Christiansen's Innovator's Dilemma without ever invoking it directly.
Sure, when you pick the cases of when small beats big, small beats big every time tautologically. But you also have cases of when big stays big over many generations and takes on all comers. In reality, almost every time small meets large, small loses. The difference is, small just needs to win once, big needs to win every time.
Sure, when you pick the cases of when small beats big, small beats big every time tautologically. But you also have cases of when big stays big over many generations and takes on all comers. In reality, almost every time small meets large, small loses. The difference is, small just needs to win once, big needs to win every time.
This just seems like selection bias or some similar fallacy I'm forgetting the name of. There are plenty of small companies that go up against large companies and lose. You just don't hear about them very much.
The thing I don't get about this argument is that there are many, many, many small companies for every large one. The piece gives several examples of small companies winning against large ones, but (at the same time) there were many more small companies losing against those same big companies.
Is there a way to prevent a mid-to-large size company from tripping under the weight of its own bureaucracy, if you're the one running it?
I've put a lot of thought into this, usually immediately after being forced to sit on my hands because some other department isn't doing their job, and it wouldn't surprise me if they're blocked for the same reason.
I can't think of a good way to do it.
Perhaps having a back channel to communicate with department heads/managers where work blockages can be reported and dealt with, but I'm not sure how that would be implemented, or if it would even work. But after 3 years in the trench where I am now, it seems very much like a large enterprise only moves as fast as its slowest department...
I've put a lot of thought into this, usually immediately after being forced to sit on my hands because some other department isn't doing their job, and it wouldn't surprise me if they're blocked for the same reason.
I can't think of a good way to do it.
Perhaps having a back channel to communicate with department heads/managers where work blockages can be reported and dealt with, but I'm not sure how that would be implemented, or if it would even work. But after 3 years in the trench where I am now, it seems very much like a large enterprise only moves as fast as its slowest department...
It's tempting to put all the sysadmins in one group, all the dba's in one group, all the front end guys, etc. There is some value to that.
But if you think about when stuff really happens, you sort of need all those people working on one project.
It's tempting to say, oh there's not enough work for a sysadmin full time. Really? do you have solutions for backups, logging, monitoring, and upgrades? does it all really work? I don't mean to harp on sysadmins, programmers don't test, managers coast through meetings.
Amazon's everything is a service seems like a nice way to be somewhat resilient against that kinda stuff.
I think when stuff is broken out the other way, by function rather than project, managers want to protect their resources. Use as few resources to complete the narrow task, rather than doing what really needs to happen to be successful. (like actually handling failure modes)
Big organizations have the evaporation problem too. A system can be really dysfunctional, but it's fine as long as it makes money. When competition heats up, the smart people just go find other jobs. So, the second best and second brightest take charge. They solve problems as well as they can, but often it's stuff like stopping reimbursement for cell phones.
It's hard. There's a season for everything. Organizations grow and thrive, get sick, recover, change shape, all sorts of crazy things.
But if you think about when stuff really happens, you sort of need all those people working on one project.
It's tempting to say, oh there's not enough work for a sysadmin full time. Really? do you have solutions for backups, logging, monitoring, and upgrades? does it all really work? I don't mean to harp on sysadmins, programmers don't test, managers coast through meetings.
Amazon's everything is a service seems like a nice way to be somewhat resilient against that kinda stuff.
I think when stuff is broken out the other way, by function rather than project, managers want to protect their resources. Use as few resources to complete the narrow task, rather than doing what really needs to happen to be successful. (like actually handling failure modes)
Big organizations have the evaporation problem too. A system can be really dysfunctional, but it's fine as long as it makes money. When competition heats up, the smart people just go find other jobs. So, the second best and second brightest take charge. They solve problems as well as they can, but often it's stuff like stopping reimbursement for cell phones.
It's hard. There's a season for everything. Organizations grow and thrive, get sick, recover, change shape, all sorts of crazy things.
Its true that when new technology enters the market, it creates an opportunity for the markets to be recontextualized in terms of that technology. Sometimes the incumbents embrace it, sometimes they don't. Mark's example of IBM is interesting by as much by what it omits as what it leaves in.
The DEC, Data General, Etc. growth of minicomputers came at IBM's expense of market share, but microcomputers were dominated by IBM (there is a reason it was the IBM PC and IBM PC compatibles for so long). The outcome of a new technology "meeting" a large incumbent is rarely predictable, and so a poor basis for establishing a "law" or even a reasonable insight.
The thing that I have always observed is that history doesn't repeat itself so much as there are capabilities that people want (services or products) and as the economics of those products or services can be improved by re-implementation in new technology, that technology takes over the implementation role for people.
For example small business has to do payroll, which they started on ledgers, then moved to punch card machines, then to computers, large, mini, and then micro, and then to service bureaus like ADP. This had nothing to do with history repeating itself and everything to do with the overhead cost of running payroll and keeping in compliance with all of the various labor laws.
Perhaps a more actionable observation is that when ever a change to a good or service is enabled by technology which allows it to be provided at the same price with a higher margin, or a lower price with the same margin, that technology change will push out the older technology. If the incumbent doesn't see it or can't act on the change there is an opportunity to capture market share.
Using that observation to translate Uber's success, Uber is using two innovations, independent drivers who own their own cars (arguably the more important change), and a sales protocol based on smart phones to do the same thing taxis have done for centuries. In so doing they can deliver a taxi service at the same price as current services but with better margins, or at a lower price with the same margins. So they capture market share, the incumbent is constrained in their response by regulation and is making changes there but until they do, Uber succeeds. Small isn't meeting "large" rather the service is getting reshaped by the available technology to lower (or sometimes shift) costs.