A lot of the technology people use every day persists not because it’s good but because leaving is expensive. Accumulated files, habits, and training make switching feel costly enough that better alternatives don’t win by being better. The useful engineering problem, then, isn’t only building something good; it’s building something good enough that the cost of switching stops being the deciding factor.
That’s most of why I care about impact over cleverness. Impact is the thing that actually moves people off the old option.
The obvious objection is that switching costs aren’t irrational. When an organisation stays on software everyone already knows how to use, it’s making a defensible trade: retraining is a real expense, and a better tool that nobody can operate yet is worse in the short run. My argument treats inertia as something to overcome, when some of it is an assessment I’d make too.
What I’d add is that the engineer’s job includes lowering the switching cost itself (e.g., familiar interfaces, migration tooling), not only making the destination better.