This is the third post in our DRIVE Deep Dive series. We've covered Delivery and Reliability so far; this post takes on Initiatives. For the complete model, download the full DRIVE framework. Up next: Vigilance.
---
Every engineering organization is, at any given moment, carrying a body of non-product work that no one outside the org will ever see: a migration off an unsupported version control system, the adoption of a shared platform that every new service is expected to build upon, the gradual deprecation of a dependency no team wants to own, or a security remediation bound to a fixed deadline. Such work is undertaken on the premise that it pays off later, in the form of greater leverage, reduced risk, and a smaller blast radius when something breaks. The organization concedes that the work is worth doing, but then returns its attention to shipping features.
That is the point at which many of these initiatives quietly die. They forfeit the calendar to feature work, are relegated to a spreadsheet or a project board that leadership consults ad hoc, and never accumulate the kind of repeated, visible attention that signals to every team that leadership regards this work as a pr.
AI raises the stakes. The initiatives that decide whether an organization captures the upside of AI are themselves org-wide, engineering-driven, and non-product: rolling out agent configuration and skills files, standing up AI governance, changing tooling, setting standards for how agents contribute code. Get them moving and the whole org gets more leverage. Let them stall and every team keeps paying the tax the initiative was supposed to remove.
The Initiatives pillar of the DRIVE framework asks two questions at once: is our most important non-product work moving, and is the review meant to drive it actually working?
What Initiatives measures
The DRIVE Initiatives pillar focuses on the work that compounds over quarters rather than the work that ships in a given week, and it examines that work from two angles. The first is whether the non-product technical work is progressing, measured by Tier 1 milestone completion. The second is whether the OpEx review driving it is producing change, measured by the completion rate of action items from prior reviews.
Tier 1 milestone completion rate
The percentage of milestones completed on each Tier 1 initiative, tracked per initiative and never averaged across them.
A Tier 1 initiative is one whose stalling would leave the organization meaningfully worse off: Log4j-style vulnerability remediation, adoption of the standard platform every new service is expected to build on, or a migration off a version control system that is about to lose support. Where that line falls is a matter of judgment rather than formula. Work at Tier 2 and below, such as a multi-year dependency deprecation, is lower-leverage or unfolds over a longer horizon; it warrants tracking, but not during the leadership review. The boundary between tiers should be revisited as circumstances change, since an initiative's risk profile can shift faster than its plan does.
The rollup rule is important: compute progress from the raw numerator and denominator at each level, never by averaging the percentages beneath it. Averaging across initiatives of different sizes often produces a number that looks like progress but isn't.
For example, take an org at week 10 of a 12-week quarter with three Tier 1 initiatives running. The VCS migration is at 80%. Platform adoption is at 40%. Vulnerability remediation is at 20%. Average those three and you report 47%, which reads as roughly on track, and the meeting moves on. Reporting each initiative independently, as DRIVE prescribes, surfaces the actual problem: the remediation is badly behind pace while the other two are progressing normally. That is the initiative requiring attention, and the review responds by identifying the blocker and assigning an owner to clear it. The averaged number would have concealed precisely the signal leadership needed to see.
As a default red signal, flag any Tier 1 initiative sitting below 30% of its quarter-end target, whether you trigger on the threshold, the trend, or both. Recommended thresholds are provided in the full framework.
OpEx action item completion rate
The percentage of action items from prior Operational Excellence reviews that are now complete, rolled up across teams and domains from raw counts. The same rule applies: count, don't average.
This is the integrity check on the entire Operational Excellence program. When a review surfaces action items week after week and those items fail to close, the review is not producing change. What everyone takes to be a leadership practice has quietly become a status meeting. This metric belongs on the main dashboard rather than a team-level drill-down, because an integrity check retains its meaning only while it remains visible.
A defensible default is to flag red below 60% closure across the trailing four reviews, with a healthy program landing closer to 75 to 80%. A rate that stays red across two or more cycles rarely means that teams are idle. It usually points to something structural in the meeting itself: the wrong people in the room, a facilitator without the authority to make calls, or named owners who were never properly positioned to execute what they were assigned.
Secondary drag metrics
Once the Tier 1 work is moving and action items are closing, the relevant question shifts from whether the critical work is progressing to what else is at risk and how stale the backlog has grown.
Tier 2 and below initiatives get tracked outside the critical view. The reason to watch them isn't day-to-day progress; it's to catch the moment a Tier 2 should be promoted because its scope grew or its risk changed.
Age of OpEx action items measures how long open items have been sitting. An item that's been open for six weeks is usually a signal of stalled work or unclear ownership, not of steady effort grinding away in the background.
Where project management tools fit
You likely are already using project management tools like Jira, Linear, or Asana. Most organizations do this; the data already resides there, and that constitutes a useful starting position. No one needs another place to file tickets.
The Initiatives pillar sits atop that tool as a governance layer rather than a replacement for it. A project management tool tracks tasks; it does not connect the standard that defines what "done" means, the ownership that establishes who is accountable, the surface on which that work appears for the people who own it, and the leadership rollup that arrives in the weekly OpEx review alongside the other four pillars. Initiatives measures whether the organization is meeting its standards on the entities that matter, with the leadership cadence built in. The project management tool is where the tasks live; the pillar is how leadership knows whether the organization is clearing its most important bar.
Measuring Initiatives in an OpEx review
The Operational Excellence review is where leaders read the two signals and decide where to durect people and attention. The Initiatives portion of the review should watch for three things:
Which Tier 1 initiative has fallen below pace, what is blocking it, and who owns clearing that block.
Whether the previous cycle's action items in fact closed, and, where the completion rate has been red for two cycles running, whether the meeting itself is the problem and requires different attendees, a facilitator with greater authority, or owners with real room to execute.
When a Tier 1 initiative stalls, are there flags in additional pillars as well? The Delivery and Reliability signals beside it might offer additional insight: a team buried in incidents or absorbing a wave of injected work is not going to advance its migration.
Where the Initiatives signals come together
Cortex Initiatives are Scorecard-attached goals with deadlines, owners, and automatic progress tracking. Progress rolls up from individual entities measured against Scorecard rules, not by averaging percentages between layers, so the never-average rule is handled for you rather than left to a spreadsheet formula someone has to remember to get right. Action items land on each owner's Engineering homepage, where the work is, not in a report they need to go find.
A Tier 1 initiative becomes an Initiative tied to a Scorecard that represents the standards the org cares most about, whether that's production readiness, a security baseline, or an end-of-life migration, with a deadline that materially affects the business if it slips.
With Cortex, Skyscanner they landed three major engineering-wide initiatives, each one faster than the last, across a team of more than 800 engineers. Read the full case study here.
For organizations that want to see where they stand on Initiatives and the other four DRIVE pillars, the DRIVE maturity assessment is an excellent starting point.
Next in the series: Vigilance, the pillar that asks whether security and compliance risk is accumulating faster than we're retiring it.
