Can't a CI/CD pipeline + various processes be good enough to achieve a similar efficiency for under-100-engineers companies? Honest question - because I'm pretty sure I've heard some people claim similarly fast "idea to production" times.
There may be some communication between product and design to figure out how it should look and feel.
Then it'll go into a sprint most probably, but not the current sprint, because that would change the scope and affect estimates and possible delivery timelines. You'd only change the sprint scope if the team is running out of work to do or there's a major customer request or other panic.
There will be some measure of QA, ideally. Some people fly by the seat of their pants, and rely on fixing things in production if it breaks in production. This is using your customers as QA. Can work if you roll out gradually and are very responsive to any reports of regressions.
All in all, this is unlikely to happen in less than a couple of weeks. The processes are designed for predictable, consistent delivery and to minimize surprise. Shortening the chain will mean less integrated decision making and will increase the amount of surprise and inconsistency in the product and its delivery.
If someone secretly implements an awesome feature, others might be envious as it does not seem deserved if their idea did not receive the same level of scrutiny by the usual processes as other decisions did.
Theoretically, it probably won't cause much chaos at all if programmers are allowed to add small GUI tweaks and the product likely benefits from it.
The degree to which this would work probably depends a lot on the extent to which the programmers have reached Kegan level 5, so practically it probably won't work all that well.
The envy isn't about the awesome feature: it's about the fact that this developer gets even more attention and positive notice from leadership by means that aren't available to other workers due to social status (rather than merit).
This is not so much a problem when you add a new feature like this triple-click which doesn't change existing usage and workflows. But even here you want to add that to your documentation, inform your support staff about it etc.
For changes that affect the look & feel of the product, your users will curse you if you roll out multiple of those per week, even if everything is totally stable and free of bugs.
In a larger team the flow of info is DevOps/Developer spot error in CI/CD, find out which commit/Developer broke the build. Email/slack/ walk over to let them know and sit down for a friendly troubleshooting session.
Resolve the problem. Follow necessary processes to commit change. CI/CD hosted agent is busy building other projects because not enough budget for multiple hosted agents and all CI/CD is handled in the cloud. Time to go home!
Obviously that was a bit facetious but you get the picture.
Additionally, beyond trivial projects, some changes may require changes to architecture, even small ones. A new feature may require a new index, a schema get updated, a new worker be setup to run in prod, etc.
And usually there are multiple PRs waiting to be added, which have to be deconflicted, and the lead dev still wants to code so everything takes longer than you'd think.
Those 100 engineers have to first agree on a CI/CD pipeline.