Comment by awithrow | Hacker News Reader

Comment by awithrow | Hacker News Reader

Parent Full thread

None of the presented KPIs are quantifiable which misses entire the point of the KPI.

Also its unclear how the team KPIs tie into overall Objective (Key Results are missing here). The way its structured, every team could meet their KPIs and the company could still miss the objective. Eng can build a stable k8s, product could research all the things they want, support could understand everything, marketing could understand everything. If customers don't buy the product, the objective has been missed

I don't say this to pick on you but these examples are typical of what i've seen in practice when orgs roll this out. They end up not really groking the idea behind OKR, and slap the label on a process that is largely similar to what they had before but with a trendy new name. The net result isn't better business outcomes but instead a lot of toil, infighting about why OKRs were missed, gamed KPIs, vague and unhelpful "targets", and a distaste for the whole process.

Well I've taken 3 business public/sold to public company this way and brought countless to profitability so who knows I guess?

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

Reply on news.ycombinator.com