Operations | Monitoring | ITSM | DevOps | Cloud

Traditional code review no longer keeps pace with how much code teams are shipping. Risk-based code review is the response: instead of giving every pull request the same scrutiny, you route human attention by risk, letting low-risk changes ship with light or automated review and reserving deep human review for the changes that are expensive to get wrong.

Most engineering leaders are drowning in data but starved for insight. We have dashboards full of metrics, but they often create more questions than answers and rarely tell us what to do next. In the age of AI, where development velocity is accelerating at an unprecedented rate, this problem is only getting worse. Shipping code faster than you can fix it is an existential risk, and a dashboard that doesn't lead to action is just a distraction.

This is the fifth and final post in the DRIVE Deep Dive series, following Delivery, Reliability, Initiatives, and Vigilance. For the complete model across all five pillars, download the full DRIVE framework. -- Engineering money and time land in three places a leadership review can actually act on: the cloud bill, the internal spend on AI and LLM tokens, and the split between building new things and keeping old ones running.

This is the fourth post in our DRIVE Deep Dive series. Over the coming weeks we're examining each pillar of the DRIVE framework in turn. For the complete model, download the full DRIVE framework. Our last post covered Initiatives. Up next: Efficiency. The bottleneck on writing code is gone, and the industry is responding the way it always does when a constraint disappears: by producing more.

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.

You can hit every DORA target and still be losing ground. Deploy frequency up, lead time down, change failure rate and MTTR both healthy, but underneath it could be hiding an organization slowly getting worse at turning work into reliable software. New services shipping without clear owners, an attack surface widening faster than anyone is tracking, on-call rotations quietly filling up, a migration that was supposed to close last quarter still limping along.

This is the second post in our DRIVE Deep Dive series. Over the coming weeks we're examining each pillar of the DRIVE framework in turn, and mapping DRIVE against the frameworks engineering leaders already run on, including DORA and SPACE. For the complete model, download the full DRIVE framework. Our last post covered Delivery. Up next: Initiatives. --- AI has removed the last real constraint on producing code, and organizations are shipping more of it than ever.

This is the first post in our DRIVE Deep Dive series. Over the coming month we'll examine each pillar of the DRIVE framework in turn, and map DRIVE against the frameworks engineering leaders already run on, including DORA and SPACE. For the complete model, download the full DRIVE framework.

Incident response is a context problem. The first minutes of any incident are spent reconstructing what the affected service is, what it depends on, and who owns it. That reconstruction happens during the worst possible window. The Cortex catalog already holds this data: services, teams, domains, and the relationships between them, maintained by the engineers who run those systems.

Ask a software engineer what they do and the answer, for years, has been some version of "I write code." That assumption is unwinding fast. AI agents can now write code, review pull requests, run tests, and ship to production, and they're taking on a fast-growing share of that work. As agents absorb more of the execution, the human role shifts.