Metrics & Mayhem
A CTO's guide to turning reliability into customer trust
Coming April 2026
Observability is the ability to understand what's happening inside digital services using the signals they produce. When payments fail, dashboards lie. This book helps you close that gap.
Coming Soon
Written for CTOs • Vendor neutral • Focused on outcomes
The gap no dashboard shows
Your monitoring says the payment system is healthy. CPU is fine. Response times look good. Error rates are within tolerance.
But customers can't complete transactions. Support lines are ringing. Trust is eroding.
This is the reliability gap: the space between systems that look healthy and customers who can't get their work done. Most organisations buy more tools to fix this. But observability isn't a tooling project. It's a decision-making capability.
This book shows you how to build that capability through people, process, and technology.
What you'll get
People: How to shift from firefighting to coordinated incident response. Build a culture where teams own outcomes, not just components.
Process: Pair customer outcome measures (like completed payments) with technical signals (like latency and error rates). Build the operating rhythm that makes this repeatable.
Technology: Stop chasing every new observability platform. Learn what your tools should actually deliver and how to evaluate them without vendor lock-in.
The three-move framework that connects critical customer journeys to the signals that matter and the teams who respond.
How to navigate compliance and regulation in banking and finance without turning observability into a burden.
Real-world case examples from banking, government, and enterprise software.
Who this is for (and who it's not for)
This is for you if:
• You're a CTO, Head of Engineering, or senior technical leader responsible for reliability.
• You've bought observability tools but still can't answer the question: "Are customers okay?"
• You work in banking, finance, or regulated industries where downtime means real consequences.
• You want a strategic guide, not a tool manual.
This is not for you if:
• You're looking for a tool comparison or vendor guide.
• You need step-by-step technical setup instructions.
• You think observability is only about logs, metrics, and traces.
• You don't have operational responsibility for live systems.
The three-move framework
Observability isn't a tool. It's a decision-making capability built through three connected moves.
Move 1: Pick your critical journeys
You can't observe everything. Start with 3–5 customer journeys that define your business. Payments is one example. Login is another. Focus your instrumentation and attention where it matters most.
Move 2: Pair outcomes with early warnings
Define what "healthy" looks like from the customer's point of view (like completed payments). Then connect that to the technical signals that warn you before customers feel pain. This pairing is where observability becomes actionable.
Move 3: Build the operating model
Observability only works if teams know who owns what, when to meet, and how to learn from incidents. This isn't bureaucracy. It's the difference between reactive firefighting and proactive control.
About the author
Allan Mann
Allan has spent 25+ years leading IT operations in banking and government, building resilient systems where failure is not an option. He's been on the receiving end of vendor pitches, budget battles, and 3am outages that weren't supposed to happen.
He writes and speaks about observability, resilience, and what actually works in highly regulated environments. He's the voice behind the Mastering Observability newsletter and the Metrics & Mayhem podcast, where he breaks down complex operational challenges into clear, actionable guidance for technical leaders.
No vendor agenda. No fluff. Just hard-won experience.
What leaders say
Testimonials from senior technical leaders (placeholder quotes)
"This is the book I wish I'd had five years ago. It connects the technical reality to the business outcome in a way no vendor pitch ever has."
— [Name], CTO, [Financial Services Company]
"Finally, a strategic guide that treats observability as a leadership capability, not a tooling problem. Essential reading for any CTO in a regulated environment."
— [Name], Head of Engineering, [Banking Group]
"Allan's three-move framework gave us a clear path from confusion to control. We went from chasing alerts to actually understanding our customer experience."
— [Name], VP Engineering, [Technology Platform]
✓ No vendor agenda | ✓ Written for CTOs | ✓ Focused on outcomes
What's inside
A clear roadmap for building observability as a decision-making capability
The observability gap
Why dashboards lie when payments fail
From signals to decisions
Building the link between data and action
Choosing your critical journeys
Focus where failure hurts most
Outcomes before metrics
Define what healthy looks like for customers
Early warning signals
See problems before customers do
Building ownership models
Who owns what when things go wrong
Cadence and rituals
The operating rhythm that makes it stick
Learning from incidents
Turn failure into system intelligence
Service promises (SLOs)
Setting commitments you can actually keep
Tools and technology
Choosing without vendor lock-in
Regulated environments
Observability in banking and finance
Making the shift
Your 90-day roadmap to observability
Frequently asked questions
Is this technical? +
It's strategic first, technical second. You won't need to code, but you will need to understand how systems produce signals and why those signals matter for decision-making. If you can read a dashboard and ask questions about what it means, you're technical enough.
Do I need a specific tool? +
No. This book is vendor-neutral. It covers principles and practices that work regardless of which monitoring, logging, or tracing tools you use. The framework applies whether you're using open source, commercial platforms, or a mix of both.
How long is it? +
Approximately 200 pages. It's designed to be read in 3–4 focused sessions, or you can jump to the chapters most relevant to your current challenges. Each chapter stands alone, so you don't need to read cover to cover.
Is it suitable for regulated industries? +
Yes. The book includes a dedicated chapter on observability in highly regulated environments, drawing on real-world experience in banking and government. It addresses compliance, audit requirements, data sovereignty, and how to build trust without compromising control.
What will I be able to do after reading? +
You'll be able to identify your critical customer journeys, define what healthy looks like, set up early warning signals, assign ownership, and build the operating cadence needed to turn signals into decisions. You'll also have a clear 90-day roadmap to get started.
How does this relate to SLOs? +
SLOs (Service Level Objectives) are service promises: commitments you make about how reliable your systems will be. This book shows you how to set SLOs that matter to customers, not just technical teams. You'll learn how to tie them to business outcomes and use them as decision-making tools.
Who is this NOT for? +
This isn't a tool comparison guide, a vendor evaluation checklist, or a step-by-step configuration manual. If you're looking for "how to set up Prometheus" or "which APM tool to buy", this isn't the book. It's for leaders who need to build the capability, not just buy the tools.
Can I share this with my team? +
Yes. Many CTOs buy copies for their direct reports, SRE leads, and product owners. The book works as a shared language for aligning technical and business stakeholders around what observability actually means.
About the author
Allan Mann
Allan Mann has spent more than 25 years leading IT operations and infrastructure teams in banking, government, and large software organisations. He's built monitoring platforms, led incident response teams, and helped CTOs make sense of the gap between system health and customer experience.
He writes and speaks on observability, resilience, and technical leadership. Allan runs Mastering Observability, a weekly newsletter read by senior tech leaders, and hosts the Metrics & Mayhem podcast, where he interviews CTOs and engineering leaders about building reliable systems in the real world.
He believes observability is a leadership capability, not a tooling project. And he's allergic to vendor pitches.
Ready to close the observability gap?
Stop buying visibility. Start building control.
Written for CTOs. Vendor neutral. Focused on outcomes.