Operations | Monitoring | ITSM | DevOps | Cloud

Most engineering leaders know they should be measuring more. What holds many of them back is a quieter concern about whether the organization is actually ready to see the numbers. This tension, however, did not keep Ganesh Datta, our co-founder and CTO, and Randy Shoup, SVP of Engineering at Thrive Market, from diving down this rabbit hole on the Braintrust podcast.

Think about the last time your team shipped something impressive. It was probably on time, clean code, and had great metrics. And yet somewhere along the way, the business priorities had shifted, and what the team delivered was no longer the top priority. The work was solid, but the direction just wasn't quite right anymore. This is usually what happens when engineers are disconnected from business context.

We’ve all had that moment where it seems like you've solved your company's biggest engineering challenges after a weekend of hacking something together. Your prototype is so good, you feel, that the obvious next steps are to build a slide deck, rally the team around your work, and prepare the ticker tape parade for your hero's welcome. Jeff Schnitter, a Solution Architect at Cortex, knows this roller coaster of experience all too well after his time at Workday.

We've all heard from an engineering leader about the exact moment they realized their architecture had gotten too complex. It usually happens when they look at a service map and realize it looks like a box of tangled Christmas lights. This cognitive overload is exactly what Steve Evans, the former SVP of engineering at Chegg, reflected on in a recent post on LinkedIn. He argued that microservices were a trillion dollar mistake because we often over-build for future problems that never actually arrive.

At Cortex, our mission is to help engineering organizations deliver reliable, secure, efficient software, faster. With Cortex, teams can standardize against best practices and create a culture of continuous improvement to achieve this. Today, we’re excited to announce a formalized partnership with Semgrep, a leader in modern static analysis and code security.

We know that AI has been transformational for engineering and it will continue to be, so stop me if this sounds familiar. Imagine an engineering lead opening a pull request for a critical security patch and finding five hundred lines of AI-generated code. While the solution is (mostly) usable, it follows a pattern no one on the team recognizes. This shift away from manually writing every line of logic has introduced a unique level of complexity for teams.

Most engineering leaders have a very known and very annoying "normal error." It's the log entry or deployment glitch that has been around so long that it is simply accepted as part of the status quo. Jeff Schnitter, a Solution Architect at Cortex, describes this as a form of organizational Stockholm syndrome. This mindset is unsustainable for several reasons.

I remember the first time I used an AI coding assistant. I watched the cursor dance across my screen and generate a hundred lines of code in seconds. It felt like I had finally found a cheat code for software engineering. That initial rush of productivity is a dopamine hit that's intoxicating and makes you think you can do anything with just a simple prompt or two.

Anyone who has ever attempted to learn the guitar knows the lure of buying high-end gear. Surely, an expensive guitar and a best-in-class amplifier will hide the fact that you only know a few chords and maybe the lead line to that one song you keep hearing on the radio. What most players find out, however, is that spending thousands of dollars on gear doesn't change the fact that you're not that good yet.