The greatest enemy of Continuous Improvement in Tech

I've been thinking about the idea of Continuous Improvement a lot recently. By empirical observation, I wanted to learn:

what makes it happen (triggers it)
what impedes / suppresses / prevents it from happening
what's the recipe (proper set of people / skills / attitudes / ...)

One more clarification: I was not really interested (at this point) in personal improvement (self-development). What I really cared about was the bottom-up, internally inspired desires (& actions that follow them!) to improve work methods & processes AND products & solutions on team level at least, for instance:

fighting the technical debt
improving code maintainability
automating the deployment processes
shortening the feedback loop
etc.

If I were to write down all the observations, I could write a whole book probably (well, maybe one day ...), but for now, I'd like to focus on the most improvement critical pre-requisite for continuous improvement:

Perceivable impact on business performance

Remark #1: perceivable = preferably measurable
Remark #2: perceivable by both devs & sponsors

OK, I believe you deserve a rationale:

Developers are smart creatures. Even if you procure a rather average squad, there will be always at least one with a unfulfilled desire to learn, improve, explore & tinker (my favourite verb ;>) with code. And (s)he will be doing that in work of course, (s)he won't be able to resist. So in theory there should come some, gradual improvement out of these experiments ((s)he'll drop what has failed and keep what has brought some benefit), right?

Unfortunately, it's not enough. Perfectly unit testing one class (of 5000) doesn't make a meaningful difference, neither does properly handling circuit breaking in one service, re-writing one controller to use immutable data structures, fixing accessibility in one view. Fixing stuff (& doing it permanently, so it doesn't regress) is usually painful, requires a lot of focus, untangling a lot of dependencies, taking some additional risks & convincing everyone around to adhere (that may be a challenge by itself).

So, the developer considers his/her situation ...

(s)he's supposed to do some, specific code construct - new page / view / function / module / interface ...
even if (s)he does this new item two times faster than before, (s)he'll be paid the same amount of cash, but (s)he'll possibly be expected to deliver stuff faster thereafter
(s)he's sure, that if (s)he does this new item two times faster than before, the company will run exactly the same as before the change - developer's work doesn't translate directly into company's results (customer's acquired, net profit, cost control, etc.)
the future of the product (application / system) is unknown & is not to be decided by devs - projects just happen & team may be forced to completely twist & turn up-side down whole app in a hurry, completely neglecting past efforts to keep things tidy: technical excellence is the first thing to get sacrificed in such case

So, in plain words: developer may take the risk and make an effort, but in the end, even if (s)he succeeds, no-one will appreciate that. What is more, whole effort may easily be wasted due to unforeseen necessities. Under such circumstances, isn't the most proper thing to:

fiddle a bit in a single piece of code, just to learn something, prove the idea work & satisfy intrinsic motivations, ...
... but give up ambitions to make changes in whole product / project scale & leave things as they are; everyone's still OK with that, assumed work is done & there's no risk that anything gets broken

Capiche?

This is NOT a result of one-time observation. I've seen that happening several times already. Frankly speaking - it makes sense, doesn't it? Obviously this doesn't affect:

start-ups: where people work on their own account and they know how much depends on their work (sometimes it's a matter of company's life & death)
truly agile teams
IT-driven organizations: that offer/sell IT services which quality / attractiveness is driven directly by quality of developer's work (it's efficiency, flexibility, etc.)
at last, but not least - individual, unfulfilled Netflix/Facebook/Google-rockstar wannabes, who somehow got stuck in more mediocre reality ;) Ambitious, still convinced that the biggest achievement is ahead; half-blind to the fact, the other people around may have different idea for life / career, etc. It's a complicated case - if they are charismatic enough, they can inspire & lead people towards continuous improvement; otherwise they'll just get more & more frustrated over time