That quote's perspective now seems to me to be correct and fundamental to our industry, but it was basically ignored during my degree and I'd say it's still very much under-appreciated in software engineering.

I'd guess it looks under-appreciated on the surface, because it is hard to run a business on such a premise.

Admitting it "officially" ultimately boils down to retaining by all means the engineers who already acquired the knowledge. Some of those will ask for more benefits, others will play games of power, others still will simply refuse to stay once they stopped learning.

(In my industry and geo) businesses chose the opposite -- they slice and dice the knowledge into tiny bins so that a total newcomer can learn up quickly enough. This drives down wages but now requires many more people where a few should suffice.

Solution to that? Total subcontracting of sw development. Which is of course a slow death for the business, but a) at least it looks like a business model, b) death is slow enough so that managers have time to move on, c) this has a merit of being implementable. The alternative -- finding people who already know or learn very fast, and then keeping them -- is not for every budget.

> Admitting it "officially" ultimately boils down to retaining by all means the engineers who already acquired the knowledge

I mostly agree. Admitting it acknowledges the importance of the humans in the system, and diminishes somewhat the allure of the code they write. It pushes for more focus on learning and sharing, and strengthened the labour power of the human interacting with the engineering system, as they're full acknowledged as inseparable from it.

And from the first quote, which I strongly agree with, it follows that when people leave the company after building something together, the organization is losing something invaluable. I am baffled that this is not understood and I have witnessed first hand how great teams that are able to work well together collapse and the company has to rebuild the knowledge, wasting time and money.

I suspect most of the time that's because you can't justify keeping a team idle for even a week between projects if that's what it takes to ready the next project for them to work on. I'd be surprised if most businesses even allowed a day of idleness to get a running start with a well-functioning team.

I had a friend who worked as a project manager for a major telecom and their policy was to basically furlough her for a few weeks (paid time off) after a major project winds down. She's there if something bad happens, but otherwise it's downtime (and retained experience!) before the next project. It seems like a sensible and healthy policy.

Perhaps it is different where you are from, but I would usually understand furlough to mean unpaid time off at the company’s request.

I just meant it in the general sense of the word, as a leave of absence at the company's behest that could be paid or unpaid.

Spot on. The tragic irony is that giving a good team a breather will usually pay dividends, from a strictly utilitarian ROI perspective.

Which is why the concept of 20% time is important. It means that 1 day a week your manager can't tell you what to do, so you can work on whatever you think is most important. You could use that time to work on what your manager wants, and most do, but if you have things that you feel are more important you just go and do them.