Okr cascade
Skill Amey-Thakur/AI-SKILLS/skills/big-tech-processes/okr-cascade
Plug-and-play skills and prompts for every AI coding agent
npx -y skills add Amey-Thakur/AI-SKILLS --skill okr-cascadeAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 19 days oldThe repository was created 19 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Cascade OKRs so team and individual goals ladder up to company strategy without sandbagged targets or scoring that rewards easy wins. Use when setting quarterly or annual objectives across more than one team and you want alignment, not a spreadsheet of restated tasks.
SKILL.md
3.2 KB, 698 tokens by cl100k_base, as published. Nobody here has run it
OKR cascade
OKRs (objectives and key results) fail less because the format is hard than because the incentives around them are: people set targets they know they will hit, dress activity up as outcomes, and score generously so the numbers look good. A cascade done well aligns effort to strategy. Done as theater, it produces a quarterly ritual everyone quietly games.
Method
- Write objectives as outcomes, key results as measures. The objective is a short qualitative statement of where you want to be ("new users reach value in one session"). Each key result is a metric with a number ("cut median time-to-first-action from 9 minutes to 3"). A key result you either did or did not do is a checklist item, not a result.
- Align, do not literally cascade. A team's OKRs should name which company objective they serve, but they are not the parent's key results copied down a level. Let teams express their contribution in their own terms, and combine top-down direction with bottom-up proposals so the people doing the work own the target.
- Separate committed from aspirational. Mark each OKR as committed (you will deliver it, a score near 1.0 expected) or aspirational (a stretch where 0.7 is a strong result, per Google's convention). Mixing the two silently is how a missed stretch reads as failure and a sandbagged commitment reads as triumph.
- Kill sandbagging at review. When every proposed key result looks certain to score 1.0, push back: aspirational targets that always hit full are set too low. Ask what would have to be true to reach 30% further, and calibrate targets across peer teams so no one wins by aiming low.
- Cap the count. Three to five objectives per level, each with about three key results. A team carrying fifteen OKRs has a to-do list, not a set of priorities, and nothing has been chosen over anything else.
- Score honestly and decouple from ratings. Grade key results 0.0 to 1.0 at cycle end on the evidence, and read a 0.6 on a genuine stretch as healthy, not a miss. Tie OKR scores straight to compensation and you guarantee sandbagging next cycle, so keep scoring a planning signal, not a performance verdict.
Litmus tests
- Pick any team OKR: can you name the company objective it serves and how it moves that needle?
- If every key result is tracking toward 1.0, were the targets real or safe?
- Does a low score trigger a learning conversation, or a penalty that teaches people to aim lower next time?
Boundaries
OKRs are a goal-setting and alignment tool, not a project plan or a performance-review instrument: the moment scores feed directly into ratings, honesty collapses, so hold that line. Conventions vary (Google's 0.7 aspiration, Intel's origins, committed-only shops), so follow your organization's cadence and scale, and route individual promotion evidence to the promo-packet skill.