Sounds painful. I remember I did have to field questions from management on why one teams velocity wasn't "as good" as another's. They seemed to think it was some kind of globally objective measure rather than something particular to each team and their estimations.
Your example has always been a common conversation. And a bit like The Neverending September, at some point the training became overwhelming. This misunderstanding about velocity has become prevalent, you could maybe say more common than its intention as a tool.
There was a time when software teams didn't meticulously ticket and estimate everything. Hard for some to fathom, but stuff got done if you worked with honorable craftsman. Just differently. #noestimates feels very long ago.
Sounds like you moved on wisely. Aberrations like these vary of course, but along the rise of large tech giants that demand alignment and are threatened by autonomy, it's become more de facto.
It's sad to see small teams take it as a given for how things are done. I genuinely think it deforms and delays the solutions they're trying to make for their customers.
Sadly, this constant push to measure and control all processes and tasks infects everything, not just development.
Enterprise software is appalling at imposing workflows on everything in sight, and they always have pretty graphs and reports for management.
I feel quite strongly that software should serve humans, rather than the other way around. These tools do not exist to help you get your job done, they make you its servant.
Imagine how much more productive we could be if we had tools designed to actually help us. Management could still get nice reports, but some manager might have to knock up a spreadsheet. I can dream...
I can think of some qualities those tools would have. Ease of use, focused simplicity. Interactions should be voluntary, not enforced by a workflow system. Usage metrics shouldn't be exposed outside its users, giving them
flexibility to use it however makes sense for them.
