It's not about scalability it's about developer experience which makes experimentation fast

In his interview, The untold story of SQLite, author D. Richard Hipp explains beautifully the value in fast experimentation - this is a real world practical example from history of how leaders in an industry get eaten for breakfast, whilst they don't even realise it's happening...

The story, in Richards words:

"What set this off was Symbian... on thanksgiving day in America, they asked me for a meeting in London...because SQLite had won against other databases... they randomly called and asked for some enhancements… SQLite eventually got included into their product ... (however) embedded development can be a slow development process with long development loops"

A few years passed, until he got contacted by Google, again about SQLite.

"This was before android was a thing... before the iPhone... and here we were in the office, with an (android) prototype, with the phone plugged into our workstation debugging a phone live, in gdb, on the public network..and his wife calls and the phone rings this was utterly mind blowing..nobody, not Motorola, nobody at Symbian, nor Nokia had anything close to that, and in that one moment I knew that android was going to be huge."

The interviewer, Adam Gordon Bell, presses Richard to explain what the other companies are doing by comparison since Richard had worked with many of them. Richard explained:

"17:29:  (at the other phone companies) there was a much longer cycle time between hardware and software updates and that was the thing you see... android people were burning a new operating system, and pushing it onto working phones which they were carrying around and working on the public network, multiple times per day, whereas that was a 30 day cycle or anybody else*... it wasn't like it was a production ready phone (it looked like it was 3d printed).. but it was portable... the engineers at the other companies had the 'big breadboard' approach for prototyping..which was not actually connected to a radio so they couldn't actually use it as a phone... I could not tell anybody (I was under NDA)..I could not go to Motorola, Symbian and say *guys.. this is important, you need to fix this* , I couldn't tell em.. and that made the difference... that was kind of their undoing I'm afraid."

At least three takeaways here:

1. Fast experimentation (from 30 days each time, to multiple times per day)
2. Being close to production when you're building (real working public network)- how many times have you been so far from production that you lose sight of the real world production experience before it's too late? Is your org doing that? Akin to GitHub's reasons for codespaces saving hours of valuable development time, investing in tooling is survival not inconvenience.
3. Be open to drastically change how you work. Inaction. Richard was under NDA so couldn't have raised this as an issue- but is it impossible to imagine that other engineers already knew what was possible at the competition? What were the conditions which kept the status quo from changing? Perhaps it was seen as a risk or too big, or closed to the ideas?
   As John Cleese said:

"...because as we all know, it's easier to do trivial things that are urgent, than it is to do important things that are not urgent, like thinking, and it's also easier to do little things we know we can do, than to start on big things, that we're not so sure about" - John Cleese on Creativity In Management speech.