This is nearly my exact experience at work. I work on an internal tools team, so my users are other engineers at the company. Product teams have Product Managers and seem to put in a lot of effort into their OKRs, but for the internal tools team, we're in some limbo: still forced to write OKRs, but no parts of the process that are actually useful. We might have an OKR to upgrade Jenkins before an EOL date, but no introspection about whether the company at large would be better served by GitLab CI (as an example). Management only cares that we have defined KPIs like "Days remaining until Jenkins EOL date" and that they are improving. I still try to have the difficult conversations, but it's a constant battle with management as improving developer happiness by allowing them to use a better system isn't easily demonstrated on a dashboard.

Also, like you said, teams write their OKRs in a vacuum without coordinating with other teams. So, one engineering team might have an OKR to fix some memory issue affecting their Jenkins pipelines, but they didn't communicate that with the internal tools team that operates Jenkins. It then became a struggle between the two managers, one saying "We need to fix this Jenkins issue or we'll fail our OKRs commitment" and the other saying "We already committed to different OKRs this quarter, we can't take on new work." The engineers are stuck between this battle trying to help each other in secret without management hearing about it.