Look I'm not trying to make this an attack on you. My generous read is that you just chose some poor examples. But teams can and do succeed despite bad manageme

Look I'm not trying to make this an attack on you. My generous read is that you just chose some poor examples. But teams can and do succeed despite bad management techniques like poorly implemented OKRs all the time. If the goal is to build a managed k8s service, a team of talented people can build it without the need for OKRs. Coming from an SRE backround I see a better OKR breakdown on the Engineering side as follows: * Objective: A stable Managed service that the business can sell * Key Result: - A monthly availability of 99.99% * Key Result: - Monthly P90 API latency below 500ms * Key Result: - a new instance of the service serving customers in the new region by the end of the quarter. (Yes, these are really just SLOs, they're a good fit for this) I know the objective rolls up to the business goal of a revenue target. I know that if i'm meeting my own goal buy the metrics we can measure from the service. I know how to prioritize engineering work. If one target is being missed consistently, the fixes are going to be prioritized At review time, I can point to improvement work that fixed/improved the results an know the business thinks its important. Give me some vague objective and unmeasurable of researching and understanding something? I'll BS my way through filling out the form and go back to improving the service