Operations | Monitoring | ITSM | DevOps | Cloud

The Monday morning thread. Someone asks who owns checkout-service. Someone else asks what changed in the Production Readiness Scorecard last week. A third person wants to know if the Kubernetes migration is blocking the launch next Thursday. The answers exist. They live in Cortex. But getting them into the thread means someone stops what they're doing, opens a tab, finds the data, and pastes it back. By the time they do, the conversation has moved on.

Most engineers can tell you exactly how many PRs they merged last quarter. Far fewer can tell you what any of it did for the business. The best engineering leaders can. They draw a straight line from their team's work to ARR: which reliability investment protected revenue, which migration unblocked a strategic customer, which operational improvement reduced churn. They lead with outcomes, not story points.

Software development has never moved this fast. JetBrains' 2026 AI Pulse Survey found that 90% of developers now use at least one AI tool at work. CircleCI's 2026 State of Software Delivery report, covering 28 million workflows across 22,000 organizations, found that daily CI workflow runs jumped 59% year over year, the largest single increase they've ever recorded. In that same period, CI success rates dropped to a five-year low.

Most engineering career advice treats the leadership track as a ladder where each step is a slightly bigger version of the one before it. That metaphor is the reason so many career transitions go sideways. IC, manager, director, and VP are four different jobs. Each has its own failure modes, its own definition of what counts as your work, and its own relationship to the code. The skills that earn a promotion to one level are rarely the skills that make someone effective at the next.

Tamar Bercovici has been at Box for 15 years. She leads the core platform, the backend layer that storage, search, metadata, and AI capabilities all run on. When her systems go down, Box goes down. On a recent episode of the Braintrust podcast, she said the debate around AI-generated code tends to focus on whether the models will write clean code and/or introduce bugs. Tamar's focus is somewhere else entirely.

Every engineering team wants to ship high-quality, reliable software quickly. Historically, engineers used a few guiding principles to help them consistently write clean code: keep code DRY, shift security left, write solid test cases, own your services, document your runbooks, and more.

Though AI tools have made individual developers dramatically more productive at writing code, most engineering organizations report moving only about 20% faster than before. As Honeycomb CTO Charity Majors recently wrote, "AI came for code generation first because it was the easiest problem to solve, but it was never the thing holding developers back.".

KubeCon + CloudNativeCon Europe 2026 recently brought the cloud native community to Amsterdam. We were there all week bouncing between the booth, a Braintrust event with engineering leaders from across the community, and more hallway conversations than we can count. One talking point dominated the week: AI is shipping code faster than most engineering orgs can govern it. It also became clear that we weren't the only ones talking about this challenge.

The best QA engineers are always asking themselves (and others around them) what might break. When engineering teams shifted to agile delivery, that mindset largely moved out of dedicated roles and into the background. Automated testing took over the repetitive work, developers owned quality end-to-end, and velocity improved. What didn't carry over was the habit of looking at a feature and asking how a real user, an edge case, or unexpected load might expose it.

Engineering teams are great at innovating and delivering products, but the work that's required to maintain them over time and keep them running well tends to get deprioritized. Planning processes are designed to move features forward, not to catch whether those features are generating too many alerts, degrading in performance, or creating compliance exposure over time. As a result, that class of work accumulates quietly.