Lately, I've been thinking about the rate of innovation and the size of a company. It seems to be commonly accepted that enterprises are slow and recently I came across a very good article that explains that from the internal aspects of building software in a big company: https://zwischenzugs.com/2018/10/02/why-are-enterprises-so-slow/
I mostly agree with the author, but I'd like to see it from a different angle: big companies don't care much about the time to market, but they care about the impact they'll have in customers. Doing things fast may lead to bad press due to unexpected errors from not being careful, but besides, enterprises don't have to struggle to get more customers, they're there for free. To deep dive into this, we'll have to differentiate between two kind of features, the so called one way doors versus two way doors (i.e. reversible decisions). In this post I'll focus on the first kind, the ones that once you launch there's no turning back. You may ask: How can a feature be non reversible? Well, if you launched something that the customers love and they didn't have, you can't take that out.
In the startup world, it's used to build prototypes fast and throw them away in case they didn't work. You may ask, why doesn't big companies do the same? I believe (and this is a personal opinion), that it has to do with the size of the reachable audience. If you're startup, it means you're in the way of building your customer database which will be growing gradually. This gives you time to scale your solution and eventually that solution will be a big differentiator that will help attracting more and more customers to you. This is usually seen as the time to market: there's this sweet spot where your feature may not be good enough, but the sooner you launch it will allow you to have more profit in the future than waiting to have it completed.
On the other side, if you are a big company, you'll probably have a database of customers that can easily be 100,000 times bigger than the target audience of your prototype. So, will your proof of concept prototype be ready to receive such scale? Probably the answer is no and you'll have to invest a lot of time into building the software and infrastructure to support such load. But you can't remove the feature from your customers, which puts you in an awkward position:
- Your customers that don't have the feature will start requesting it (if you're a big company your feature will be on the social networks and quickly in the news)
- Your business partners will start pushing for the feature to be ready, as they'll start seeing every delay as a loose of money.
- Your team will start having to make quality sacrifices in order to deliver fast, leaving a lot of technical debt that will come back as operational burden.
This is why, I believe enterprises try to build the right thing from the begining. There's no point to be the first on releasing such a feature: while a startup could use that as a differentiatior to attract more customers, a big company already have them. So they put a lot of effort in estimating the load of each service, building software that can support that expected load, adding monitoring and alarms and preparing the team to operate the system.
- Estimating the load of each service: this allows companies to properly scale the system. The issue with underscaling should be obvious, while overscaling at a big company means loosing a lot of money: a 2x estimation miss in a small company maybe means having 2 or 4 extra servers, while in a big company it can represent having 500 unutilized servers (it's just a naive example but I hope it helps).
- Building software that supports the load: you can easily build an application with a load balancer to serve a small set of customers. When it comes to big scale you'll have to start thinking in going multi-region, sharding your databases, decoupling your services into small ones, being careful on dealing with the memory and concurrency, consolidating logs and metrics, etc.
- Preparing the team to operate the system: You'll have not only to train your engineers to respond fast to issues (as they'll be affecting thousands of customers), but also you'll have to train your customer service to deal with new issues, new customer contacts, etc.
Does this means that enterprises are slow? Well, it depends, when you see the big picture, in the long term, the enterprise will reach an amount of customers that could take the double or more time to be reached by the small company. That's because trust is very important and building your customer database takes time. The big company is usually reluctant to put customer's trust at risk as they identify them as a valuable asset that they have to keep, to please and also surprise with new features that are not only novel but that also work well.
On the engineering side of things, building software at that scale comes with its own challenges. You get to learn a lot and you have to solve problems that rarely you'll face in a small company. The caveat is that you'll have to be resilient and find this challenges motivating, otherwise you may feel you're not innovating. But it's about how you see innovation, because probably nobody had to deal with the issues you'll face in a big scale enterprice, so if facing novel problem and comming up with smart solutions is not innovating, probably you're not seeing it from the right perspective.