From a DevOps perspective, speed is often the indicator that you're doing things right. If you integrate code quickly and often, if you deploy quickly and often, if you patch and upgrade software quickly and often, if you detect, diagnose and fix issues quickly and often, those are all indicators of a high-performing team. Quality isn't always correlated, but high-performing teams tend to care about quality, so it's not uncommon to add quality improvements to the list if you're doing everything else.
I think that part of the problem is companies/executives/manager who think that teams need to 'do' that in order to become high-performing rather than, as you stated, it's an indicator.
There needs to be a suitable environment, skills/training, support framework and everything else around to enable the team to become high-performance over time, that when starts showing that indicator.
Correlation not Causation.
All too often these are mixed by those who read the books that offer 'Acceleration' and think that enforcing these processes will somehow make the team fit.
We tend to get better at the things we do often. Companies which have annual release cycles are almost always terrible at actually shipping software in my experience. One of my first goals in any new organization is improving iteration / feedback cycle speed.
