Observability Engineering — Part 8: Why Learning Speed Is Your Biggest Bottleneck

For most of software history, the expensive part was writing the code. Companies built entire org charts, approval chains, and release calendars around the assumption that code was scarce and precious, so you’d better plan carefully before touching it.

AI has quietly broken that assumption. Generating code is now cheap. What’s still expensive is figuring out whether the code you just generated does what you meant, and what it’s doing to real users right now. Part VI of Observability Engineering opens with a blunt reframing: the bottleneck has moved from shipping to understanding. This post covers Chapters 23 through 25, where the authors make that case to engineering leaders, borrow systems-thinking tools to explain why some organizations adapt and others don’t, and use that same lens on why the observability tooling market feels like such a confusing mess.

The Bottleneck Has Moved

Chapter 23 is framed as an open letter to CTOs, and its argument is simple: every previous “everything changes now” wave — cloud, DevOps, microservices, Kubernetes — left the same underlying behavior untouched. Engineering orgs got faster at deploying infrastructure, but not at understanding what their software actually does once it’s running. Production stayed something you check when things break, not a routine part of how developers learn.

That gap was tolerable when change moved at a human pace. AI removes the cover. When an engineer (or an agent) can generate a working-looking pull request in minutes, the old safety net — design review, code review, a QA phase, a release sign-off — either gets skipped or can’t keep up. Developer Boris Tane, quoted in the book, puts it sharply:

The SDLC is dead. The new skill is context engineering. The new safety net is observability.

The traditional, staged lifecycle — requirements, design, code, test, review, deploy, monitor — is collapsing into something closer to a single loop: state intent, build it, observe what happened, repeat. Once everything else compresses, the one stage that still has to hold is the observing part. If you can’t tell what a change did, nothing downstream of “ship it” is trustworthy.

What Sociotechnical Debt Actually Looks Like

The book’s term for this gap is sociotechnical debt — the accumulated mismatch between how a company’s technical systems have evolved and how its people and processes have (or haven’t) kept pace. Like technical debt, it comes from reasonable shortcuts that made sense at the time. Unlike technical debt, you can’t refactor your way out of it in a sprint; it requires changing how people actually work.

The authors point to three specific forms of it that show up almost everywhere:

Developers who only know a world of tests. Two decades after DevOps promised to close the loop between developers and production, most engineers still hand code off at merge and move to the next ticket. The only team watching production is usually ops, and their signal arrives as alerts and complaints — after something has already gotten bad enough to notice. A developer who ships Friday and only learns something broke when a support ticket surfaces two weeks later isn’t unlucky; their organization has structurally chosen slow learning.

Telemetry treated as infrastructure instead of product. When systems were simpler, basic monitoring — a handful of dashboards and threshold alerts — was genuinely good enough. As architectures fragmented into microservices, containers, and multi-cloud sprawl, the right response would have been to rethink how developers relate to their own systems. Instead, most companies just bought more monitoring and slapped an “observability” label on it. One striking data point the book cites: a Gartner reference customer went from spending $50,000 a year on monitoring in 2009 to $24 million a year on “observability” in 2024 — a 48% year-over-year increase sustained for fifteen straight years. Despite that spend, production is often just as poorly understood as it was in 2009.

Developer tools that were never designed as products. Internal tooling tends to accumulate from the infrastructure side of the house, built to keep systems running rather than to help developers understand their own code. The result: something as basic as “add good telemetry” turns into a maze — metric or log line? counter or histogram? where does any of it show up afterward? Platform engineering, done well, fixes this by treating internal developers as customers and building paved paths. Done badly, it’s just an infrastructure team with a new name and the same old habits.

Your Org Is a System, Not a Factory

Chapter 24 zooms out and asks a different question: given that these debts exist, why do some organizations pay them down while others stay stuck for a decade? The authors reach for systems thinking — treating an engineering organization not as a set of individual tools and teams, but as one interconnected sociotechnical system, where the technical side and the human side constantly shape each other.

This traces back to what’s sometimes called the Trist principle, after researcher Eric Trist: you have to jointly optimize the social and technical sides of a system, because optimizing only one reliably produces a worse outcome. Buy better tools without changing how people use them and you get expensive shelfware. Reorganize teams without addressing the technical constraints they operate under and you get a new org chart with the same old bottlenecks.

Systems researcher Donella Meadows described a hierarchy of places you can intervene in a complex system, ranked by leverage. Tweaking a budget or a metric sits near the bottom — the system absorbs it and snaps back. Higher up sit things like goals and team autonomy. Sitting right in the middle of real leverage is something more specific: information flows — who can see what, and how fast. Observability is exactly that: your code reporting back from production about what it’s actually doing. Change how well that information flows and you change hundreds of daily engineering decisions, without touching an org chart at all.

That information flow creates loops, and the book distinguishes two kinds:

• Amplifying loops feed on themselves. A change in the system makes the next change bigger. They can spiral upward into something great or downward into something awful — the mechanism doesn’t care which direction it’s headed, it just keeps accelerating whatever it’s given.
• Balancing loops push back toward equilibrium. A thermostat is the classic example: past a threshold, it corrects. These loops don’t drive growth, but without them, an amplifying loop has nothing to keep it in check.

Good observability is what lets an amplifying loop turn into something the book calls a confidence loop: clean feedback means smaller, more frequent deploys, faster detection when something’s off, quicker fixes, and more trust to take the next risk — which repeats. Take observability away, and the same mechanism runs in reverse: deploys get scarier, so they get rarer and bigger, so failures get harder to isolate, so recovery takes longer, so deploys get even scarier. Same underlying structure, opposite direction — the difference is whether the team can see clearly enough to notice when it’s headed the wrong way and correct course.

The same lens applies to things you wouldn’t normally call a “feedback loop.” Pull too many people into an incident and you get coordination chaos; pull too few and learning doesn’t spread past one exhausted expert. Without good signal, teams can’t tell which is happening, so they swing between the two extremes. The fix isn’t a policy — it’s better information flowing back to whoever’s making the call.

Two Loops, One Gap

Chapter 25 turns this systems view onto the observability market, starting with a simple observation: most organizations run two separate loops, and only one of them touches production.

The development loop is fast but self-contained: write code, run tests locally, iterate, merge, move to the next ticket. A developer knows their code will eventually reach production but often has no visibility into when or what happens after. The operational loop is the only one that includes production, but it’s reactive by design: something alerts, someone investigates, someone fixes it. Because alerts fire on thresholds, they only trigger once a problem is big enough to matter — often weeks after the change that caused it shipped.

Between those two loops sits a gap: nothing connects “I wrote this” to “here’s what it actually did in production.” Tests are a decent proxy for reality, but passing tests only tells you your tests pass — it says nothing about how real users behave or where they drop off. Closing that gap is the work the book has been building toward: giving developers a fast, routine way to see the consequences of what they just shipped, instead of waiting for a green test suite or an angry customer.

Two Tooling Models, Two Feedback Loops

That gap explains why the observability vendor landscape feels so noisy: two genuinely different generations of tooling are on the market, and they were built to serve these two different loops.

The three pillars model — metrics, logs, and traces kept in separate stores — grew out of classic infrastructure monitoring, where you’re mostly watching third-party components you didn’t write: routers, disks, container runtimes. It’s mature, it integrates with almost everything, and it’s genuinely good at the operational loop. Its weakness shows up the moment you need to ask a question that crosses signal types, because splitting metrics, logs, and traces apart at write time throws away the relationships between them. Reassembling those relationships later takes manual correlation and educated guessing.

The unified storage model takes a different approach: every signal is ingested as one structured event, in one columnar store, with all the relationships intact. That structure is what makes it good at the developer loop — it can answer specific, exploratory questions on the fly, like isolating every checkout error from trial-tier accounts in one region running a specific fraud-check flag, without pre-building a dashboard for that exact combination. It’s not built to replace infrastructure monitoring, and it isn’t trying to.

The authors’ advice for cutting through vendor noise is refreshingly simple: don’t start with feature comparisons. Get leadership to agree on which loop is actually your bottleneck — operational stability or delivery velocity — and let that point you toward the right model. Most companies, they note, have already overinvested in the operational side (the safety net) while starving the developer side (the actual engine of learning) — a bit like spending your entire budget on a world-class goalie and fielding no one else.

The chapter closes with a short letter from Darragh Curran, CTO of Fin (the AI customer service product built by the team formerly known as Intercom). His team’s engineering culture treats shipping as the company’s heartbeat — they push their Ruby monolith to production around 70 times a day, each deploy taking roughly 8 to 15 minutes from merge to full rollout. His point isn’t that speed alone wins; it’s that speed only compounds into advantage paired with fast, precise feedback about what each change did. Shipping fast without understanding fast just means finding out you were wrong more often, and more expensively.

Key Takeaways

• In an AI-accelerated world, writing code stopped being the bottleneck; validating and understanding what that code does in production is the new constraint.
• Sociotechnical debt is the gap between how fast your technical systems changed and how much your people, processes, and tools changed to keep up — and it doesn’t show up until change accelerates enough to expose it.
• The three concrete debts to check for: developers who only learn from tests, telemetry managed as a cost-center infrastructure line item instead of a product, and internal tooling that accumulated instead of being designed.
• Treating your engineering org as a sociotechnical system means the highest-leverage fix is usually improving information flow, not reshuffling budgets, metrics, or org charts.
• Amplifying feedback loops (which accelerate whatever direction they’re pointed) and balancing loops (which hold things steady) both depend on clear, timely information — take that away and the same structure that builds a virtuous cycle builds a death spiral instead.
• The three pillars model and the unified storage model aren’t competing on features; they’re built to close two different loops — operational and developer — and most organizations need to be deliberate about which one they’re underinvesting in.

Sources

• Majors, Charity, Liz Fong-Jones, George Miranda, and Austin Parker. Observability Engineering, 2nd Edition. O’Reilly Media.
• Tane, Boris. “The Software Development Lifecycle Is Dead,” February 20, 2026 — quoted in Chapter 23 as a contributed perspective on observability replacing the traditional SDLC.
• Tamburri, Damian A., and Elisabetta Di Nitto. “When Software Architecture Leads to Social Debt.” Proceedings of the 12th Working IEEE/IFIP Conference on Software Architecture (WICSA 2015), Montreal, QC, Canada, May 2015 — cited as the source for the sociotechnical debt framing.
• Trist, Eric. The Evolution of Socio-Technical Systems: A Conceptual Framework and an Action Research Program. Ontario Ministry of Labour, 1981 — source of the joint social/technical optimization principle discussed in Chapter 24.
• Meadows, Donella H. Thinking in Systems: A Primer. Chelsea Green Publishing, 2008 — source of the systems leverage-points framework applied throughout Chapter 24.
• Curran, Darragh, CTO of Fin (formerly Intercom) — contributed the closing letter in Chapter 23 describing Fin Engineering’s approach to shipping and organizational learning.
• DORA (DevOps Research and Assessment), 2025 report — cited in Chapter 24 for the observation that “successful AI adoption is a systems problem, not a tools problem.”

This is an independent summary and personal commentary on the book — not affiliated with or endorsed by the authors or O’Reilly Media.

This is Part 8 of a 10-part series on Observability Engineering. Continue to Part 9: Making the Business Case and Driving Change.