There is a ritual in most engineering organisations that happens every Monday morning. A programme manager opens a spreadsheet — or a dedicated OKR tool — and starts chasing team leads. “Can you update your Q3 objectives?” The team leads are busy. They type a number from memory, or from last week’s number plus a guess, or from whatever they can find in thirty seconds before the next meeting.
By the time the numbers reach the quarterly review, they represent a fossil record of what someone thought was happening, not what was actually happening. The OKR board becomes a status report authored by people who are too busy doing the work to report on the work. The objectives survive as formal commitments. The key results become theater.
This is where objectives go to die.
The problem is not that teams lack ambition or rigour. The problem is that the data underlying the objectives lives in systems that have no connection to the OKR tool. Your reliability objective lives in Jira, Datadog, and the incident log. Your architecture health objective lives in your dependency graph, your tech radar, and your MTTR records. Your data governance objective lives in a spreadsheet someone updates quarterly. Copying numbers from those systems into an OKR tool — manually, on a Monday morning — is expensive work that adds no value and degrades the moment it is done.
OKRs in Dependra
Today we are shipping OKRs as a native capability in Dependra, available on Enterprise and custom plans.
The core model is familiar: Cycles contain Objectives, Objectives contain Key Results, and Key Results track progress from a start value to a target. What makes Dependra’s OKRs different is where the values come from.
96 computed landscape metrics
Every Key Result can be driven by one of 96 built-in metrics sourced directly from your architecture model — no manual entry, no Monday morning chase. The metrics span fifteen groups:
- Health & availability — health score, capability availability, MTTR, uptime
- Incidents & SLA — frequency, resolution time, breach count, compliance rate, penalty exposure, P1 count
- Blast radius & resilience — SPOF count, chain depth, redundancy coverage, resilience score
- Risk — aggregate risk score, high-risk count, unmitigated risks
- Actor & revenue impact — revenue at risk, revenue lost
- Technology & tech radar — EOL count, tech debt ratio, standardization
- Portfolio TIME, lifecycle roadmap, data lineage & GDPR, documentation quality, security & compliance, architecture & dependencies, cost & IT spend, process & governance, and OKR rollup
Values refresh continuously — hourly by default. The baseline locks at Key Result creation, so a goal expressed as “−20%” is always relative to the landscape as it was when you made the commitment, not as it drifts over the quarter.
Computed risk signals — the seven-layer chain
Here is the part that matters most.
Imagine your reliability team sets an objective: reduce P1 incidents per month from eight to two. They link three Initiatives to that Key Result — one each for database cluster hardening, service mesh retry budgets, and on-call runbook coverage. Each Initiative has scope items: the specific components they are touching.
Now one of those components — a read replica that the scope items include — has a primary fail and no automatic failover. A replica is promoted under load. For thirteen minutes, query latency spikes. An incident opens.
In a traditional OKR tool, nothing happens to the objective. The programme manager will find out on Monday.
In Dependra, a risk signal appears on the Key Result within the hour. The chain is:
Objective → Key Result → linked Initiative → initiative scope items → Component → active incident
Seven layers, computed automatically. The signal is tagged Critical, shows the peak severity, and links directly to the incident. The objective now knows the database is down.
The same chain surfaces signals for degraded component health, stale initiatives (not updated in 14+ days), components with high downstream blast radius (10+ dependents — risky to change), and trajectory gaps (15 or 30 percentage points behind expected pace for the point in the cycle).
None of this requires configuration. Link initiatives to Key Results, and the signals follow.
Jira and API feeds
For metrics that live outside the landscape model, two additional drive modes cover the gap.
Jira Key Results run a JQL filter on a scheduled sweep — issue count, story point sum, or a custom numeric field sum, up to 10,000 issues. They use your existing Atlassian OAuth connection, broadened to include Jira scopes. On-demand sync is available from the KR detail view for when you need the number now rather than at the next sweep.
API push accepts a POST /api/{tenantId}/key-results/{krId}/ingest with a value, an optional status, and an optional comment. Authentication is via an API key scoped to key-results — separate from the landscape write scopes. Datadog, Salesforce, CI pipelines, custom report scripts — anything that can make an HTTP call can drive a Key Result. Values appear as check-ins in the history, timestamped and attributed to the integration.
Alignment map
Strategy rarely respects team boundaries. A platform team’s quarterly objective often carries an organisation-level annual one. Dependra lets objectives contribute to other objectives across teams and cycles, and the Alignment Map shows the whole picture at a glance: each team a row, each objective a card with its live progress, contribution lines connecting them. Leadership sees how every team’s goals ladder up — and which branch is falling behind — without leaving the tool.
Carry-forward
When a cycle closes, carry-forward lets the cycle owner select Key Results to move into the next cycle. The current value becomes the new start value, so relative goals re-evaluate against the fresh baseline. A KR targeting “−20%” remains valid regardless of where the baseline moved between cycles. Lineage pointers keep the historical chain intact across cycle boundaries.
Shareable board summaries
Cycle owners can generate a secure-token summary link — viewable without login, with an optional expiry date and optional email delivery. Board updates and quarterly reviews no longer require everyone to have a Dependra account.
Who this is for
OKRs in Dependra are built for engineering and architecture teams that already have their landscape modelled in Dependra and want their objectives to reflect what the landscape is actually doing — not what someone typed last Monday.
The feature is available on Enterprise and custom plans. If you are on an Enterprise plan, OKRs are live in your account today. If you are evaluating, get in touch to arrange a demo.
Ready to try it? Run your first OKR cycle — or read the Strategy & OKRs concept page for the full model.