In an open letter to engineering leaders everywhere, Fin CTO Darragh Curran explains that AI isn't a magic wand but rather an amplifier—of the good and the bad—of your engineering practices. And engineering rigor is more important than ever.
By: Charity Majors
The Second Edition of Observability Engineering Is Here
The second edition of Observability Engineering is available for download on our website.
Download The world is especially hard right now. The future of the software engineering profession looks more uncertain than ever. Execs are under heavy pressure to turn AI into magic results, and teams are fighting product competition and AI-induced burnout on one side, melting mental models and hellish oncall on the other side.
Observability was supposed to be a solved problem by now. But we heard over and over and over from staff+ engineers, managers, and executives that it continues to be one of the biggest pain points:
“We spent six months evaluating and choosing a tool, and got overruled behind our back.”
“It takes 15 minutes to recover from an outage if the principal engineer is on call, and 45 minutes if he isn’t. Nothing we seem to buy or do or try seems to change this.”
“I’m pretty sure the competitive research is all faked.”
We weren’t planning to write a whole book-within-a-book to speak to technical decision-makers from the top down, but that’s what happened. The first five parts of Observability Engineering are written for software engineers and the people who need to understand their code. The sixth is written for technical decision-makers.
We start with an open letter to CTOs, explaining why all their grand ambitions and goals with AI are blocked behind their organization’s’ ability to learn. Then we cover software delivery and observability from a systems perspective—no technical terminology, just systems thinking. We then talk about how to quantify the case for observability as a cost center or an investment, how to drive change in your organization, how to make good buy-vs-build decisions, how to partner with vendors, and how to approach instrumentation and security from a top-down perspective.
New Engineering Realities, New Questions: A live AMA with the authors of
Observability Engineering
The chapters are loosely organized in order of hierarchy from the top down. We start with the CTO letter, then move down to things every principal engineer, director, and VP should have straight, then staff+ engineers and managers.
The first chapter of part 6 closes with this guest chapter from Darragh Curran, CTO and head of engineering of Fin, formerly Intercom.
Too many engineering leaders right now seem to be acting like AI is magic, and engineering rigor is no longer needed. But AI is an amplifier: it amplifies whatever you already have, both good and bad. If there’s anyone who knows that for truth it’s Darragh, who was one of the very first engineering leaders to lead an org through a radical AI-first transformation—and come out the other side alive and better than ever.
We are honored and delighted to print his letter—in our book, and now here.
A Letter From A CTO #
How Intercom Engineering (Now Fin) Optimizes for Learning, by Darragh Curran
The thing that sparked Intercom into existence was an unignorable itch to make business online a little less awful. To put an end to: “Dear valued customer,” “you are ticket number 123,” “do not reply to this email.” Instead, to make business online personal and human. Like you’d expect in a store you love: a friendly welcome, personalised service, and real care if something goes wrong.
To do this, we made Intercom. It didn’t magically make your business better, but for people who cared, it gave them the right tools. And many did care. They realised good service was good for business.
These tools didn’t exist yet. The shape and surface area weren’t figured out. And figuring out the shape of a product—then evolving and refining it—benefits hugely from fast feedback loops:
Do a thing. Learn something. Do the next thing.
That is the core function of a software team. Do it well, pair it with product vision and judgment, and you can build great products, fast.
Doing a thing means putting software in customers’ hands. Until you ship, your software creates no value. If shipping is sluggish, risky, or error-prone, you’ll do it infrequently—and sluggishness infects your entire company and culture. If shipping is fast, reliable, and high-confidence, you’ll do it often. Frequent shipping means frequent learning, better decisions, and faster progress in the right direction.
We wrote this down 13 years ago as “Shipping is your company’s heartbeat.” It rings true now more than ever.
And then came the AI wave.
Times of change force you to ask: what really matters? What do you keep? What do you change?
For us, the focus on enabling incredible customer service stayed constant. But we saw a clear line of sight to a future where AI could actually do the work of customer service—and do it faster and better than humans. That led to the birth of Fin, the best AI Agent for Customer Service. We pivoted our entire R&D team to building it, and shifted our culture to be AI-first. Fin is now on a trajectory to be far more successful than our original product ever could have been. Once again, we’re in uncharted product territory: a huge amount of software to build, uncertain shape, fast-evolving technology. But that plays to our strength—shipping and iterating at speed. And AI itself has given us new tools and agents to move faster than ever before.
But it’s also made me appreciate the most essential skill of software engineers, especially in an era where AI threatens to eat the job of writing code: the ability to understand what’s really going on in the messy, wonderful systems we create. Without fast understanding, you lose confidence and precision. You’re either guessing, or wasting endless time trying to figure things out.
To be a great engineer, you need to be great at:
Understanding your customers– how they use your product, what’s working, what’s not.** Understanding your production systems**– why something is slow, why something’s broken, where to fix it.** Understanding how your software is built and deployed**– why it’s brittle or slow in places, and what it would take to improve it.
Each of these gets harder in the AI era, which only increases the importance of this core skill:
Products are more complex. Instead of deterministic behavior, AI is probabilistic. It will surprise you. It won’t just work because it worked on your machine.Production systems now depend on costly, slow, unreliable (but magical) LLMs.- Development environments are cohabited by AI agents prolific at producing “sort-of working” code. Your job is to harness the upside and contain the downside—while moving at speed.
The complexity ratchets up, but the truth becomes clearer: the bottleneck isn’t shipping (we’ve largely optimised that), and it isn’t even writing code (easier than ever). The bottleneck is understanding. Developing the depth and speed to know exactly what to do next to make your product or system better.
If shipping is your heartbeat, then understanding is your breathing. Thankfully, we can use AI tooling for faster and sharper understanding. The deeper and more effective your breathing, the more oxygen you pull in. In turn, that fuels sharper decisions, faster fixes, and better products. Grab your free copy of Observability Engineering
and learn the foundationals of observability
from the experts.