Sure, OKR's can help keep multiple teams aligned on business and product goals. And that's an advantage that's too big to ignore. But the problem with OKR's is too often, they're handed down by well meaning people multiple levels removed from the day to day software development work. There can be a lack of ground truth. But too often they miss the bottom-up intelligence, creativity, and engineering needs that comes from the people who work on the product day to day. It's also important not to load your product roadmap into OKR's and call it a day, or else you'll end up with teams of people who check boxes and software that barely makes it out of the driveway. Personally, I would encourage a reflection period after each series of OKR's. Not to just discuss outcomes amongst the senior leaders, but to collect intelligence on the ground, talk to devs, talk to users, talk to support reps, and decide what really should be the priority. But hey, what do I know I'm just a person who's comment you're reading.
The biggest problem I've seen with OKRs as an engineer is that the objectives are business goals the engineering team has little or no ability to influence. Like, an objective of "onboard 5 new large customers" makes sense for the business, and the engineering team could definitely screw it up by, say, building a system that can't scale that high. But when the sales team only closes 3 new deals, the engineering team fails its OKRs no matter how good a job everyone did. I've seen this be quite demoralizing, especially when meeting OKRs is tied to bonuses.
The second-biggest problem is that the time horizons of OKRs are often longer than the interval between pivots that cause the old OKRs to no longer make sense.
Or building things that help retain current customers vs acquire new customers so sales has something to sell.
The bigger problem as I've seen it is engineers that don't see themselves as part of the business, either because of the culture or personal choice around lack of focus on soft skills.
All too often engineers spend zero time understanding the market and customers, and scaled agile, as it's typically implemented and managed, definitely doesn't help.
> All too often engineers spend zero time understanding the market and customers,
From my perspective the problem is that companies invest zero time in training engineers about the market and companies, and instead just treat engineers like assembly line cogs that produce business value on-demand.
