Operations | Monitoring | ITSM | DevOps | Cloud

At EVOLVE, Cortex’s annual engineering leadership conference, Nathen Harvey (Google Cloud’s DORA lead) asked the audience to name the biggest friction point in their software delivery lifecycle. Of 69 people who voted, none picked “building”. Reviewing changes and measuring impact nearly tied for first. Risk, security, ownership, and trust topped the EVOLVE audience's list of what keeps AI-built software out of production, and all four are platform problems.

Summary Spotify Backstage is a free, open-source framework for building internal developer portals, with a software catalog, templates, TechDocs, and a large plugin ecosystem. It’s a strong fit if you have a dedicated platform team that wants to build and run its own portal. If you want a current catalog, enforced standards, and org-level reporting without maintaining the infrastructure, a managed platform like Cortex is the better fit.

Scroll LinkedIn for ten minutes and you'd think every engineering organization already runs an autonomous SDLC, with agents writing, reviewing, and shipping code while humans watch. Inside large enterprises, the picture looks different. Coding agents there have to work around sensitive customer data, recurring compliance audits, a larger attack surface, downtime that costs millions, and a CFO who wants to know what last year's token spend bought.

Last week we hosted our annual conference, EVOLVE, where global engineering leaders came to talk through the realities of building AI-native SDLCs. When asked to name the biggest friction point in their software lifecycle, attendees gave telling answers: ‘reviewing changes’ took 36 percent, ‘measuring impact’ took 35, and ‘building’ drew zero votes.

Engineering organizations spent the past decade learning to measure developer and team productivity. Measurement of the organization itself did not keep pace. Now that agents are responsible for writing most of the code across many engineering organizations, it’s more important than ever to have an effective methodology for measuring productivity.

When Nicole Forsgren, Margaret-Anne Storey, and their coauthors published "The SPACE of Developer Productivity" in 2021, they settled an argument the industry had been losing for years. Productivity is not one number, and it is not a proxy like commits or story points. It is multidimensional, and any attempt to flatten it into a single metric will mislead you. Most of what came after in developer productivity measurement builds on SPACE. SPACE and DRIVE were built for different jobs.

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.