The whole scenario only exists because of the axiom introduced between points 3 and 5:
> 3 ...ORG spends an egregious amount of money on middleware SaaS
> 4 ...executive figures they should be able to replace SaaS with in-house system
> 5 ...manager tasks one of ORG ’s finest engineers with the job of building it
If in Point 4 it was determined this was a low value, high TCO project with many replacements, the stud engineer doesn't work on the project, no events past this point occur.
If point 3 was that they had an opportunity to build a flagship product/feature in their wheelhouse and drastically grow market share, nothing past 6 and or 7 happens.
Like I said, there are interesting things here about knowledge transfer, but the root cause seems to be missed from the analysis. Maybe there's some other real world scenarios where teams of critical software are getting replaced whole sale and remain confused, but I'm not convinced most of these issues would come up in a situation that wasn't the one described in 3-5.
> The whole scenario only exists because of the axiom introduced between points 3 and 5...
I'll argue that the higher-level context introduced in point 2 is even more important here: "ORG shifts from assume we have infinite budget mode to we need to break even next year or we’ll die" i.e. the whole scenario exists not because the business can't accurately evaluate TCO, it's because the business is in do-or-die mode and long-term TCO doesn't matter NOW.
That is, this whole scenario takes place in a situation where there is a organizationally vital need to cut costs. What happens afterwards is a trade of long-term risk (internalizing an essential business function and giving it a bus factor of one) for immediate financial improvement (no more SaaS spend). Long-term TCO doesn't matter if the company collapses next quarter, right?
And in that short-term frame, the project is an unqualified success: X10 delivers exactly what was needed, and the SaaS spend is eliminated. But the risk hits: X10 leaves the company.
[So, pointing out this hypothetical company isn't correctly estimating TCO is correct, but irrelevant; they're in a position where having to pay the long term costs will be a better problem than the one they have now - a reasonable business decision, though not a great one to have to make.]
For what it's worth, I completely agree with your original point: organizations really do systemically underestimate the total cost of ownership of a service. Within the example in the article, the flawed assumption is pretty explicitly laid out in point 7: "For all intents and purposes, development is done, they only need to keep the lights on." - and exploring WHY this assumption is flawed is the core of the article (section 3).
So, ultimately I agree with dambi0 in the GP comment - the lede hasn't been buried here, rather the whole article is a discussion of one aspect of the very point you make. Why DO organizations systematically underestimate service TCO? Because, at least in part, there is not yet a widespread understanding that a service is not "software" in and of itself; rather, a service is the organizational understanding of a solution to an organizational problem domain, and maintaining organizations is orders of a magnitude more expensive than maintaining tools in and of themselves.
> 3 ...ORG spends an egregious amount of money on middleware SaaS
> 4 ...executive figures they should be able to replace SaaS with in-house system
> 5 ...manager tasks one of ORG ’s finest engineers with the job of building it
If in Point 4 it was determined this was a low value, high TCO project with many replacements, the stud engineer doesn't work on the project, no events past this point occur.
If point 3 was that they had an opportunity to build a flagship product/feature in their wheelhouse and drastically grow market share, nothing past 6 and or 7 happens.
Like I said, there are interesting things here about knowledge transfer, but the root cause seems to be missed from the analysis. Maybe there's some other real world scenarios where teams of critical software are getting replaced whole sale and remain confused, but I'm not convinced most of these issues would come up in a situation that wasn't the one described in 3-5.