Why I Wrote the Handbook I Couldn't Find

The books you find when you’re knee-deep in the flood water of a leaky dam fall into one of two categories.

The first category is lofty academic practice — frameworks built for organizations with the luxury of time, dedicated architecture teams, and a CDO who reports directly to the board. Useful in theory. Impossible to implement while you’re triaging and treading water.

The second category is platform-specific or stack-specific content that either doesn’t translate to your environment or costs more than most mid-market data budgets can justify.

Neither one helps you when there’s a three-alarm fire and the entire C-suite is standing between you and the problem demanding answers.

What I actually wanted

I wanted something that turned documentation and process into iterative improvements. Something that gave practitioners permission to get started instead of falling into analysis paralysis waiting for the perfect architecture, the right budget cycle, or organizational consensus that was never going to arrive.

The approach I kept coming back to in the field was incremental. Small, defensible wins that compounded. Fix the report that takes 45 minutes to run. Resolve the vendor master entries that are creating duplicate spend. Document the logic that only one person understands so it doesn’t leave when they do.

These improvements are almost imperceptible in the moment. That is the point. You are not declaring a transformation. You are quietly making things better. And eventually — without a big announcement, without a program name, without a steering committee — people forget that reports used to be slow. They forget that servers crashed on month-end close. They forget that the customer count was different in every system.

It is the opposite of slowly boiling the lobster. The lobster, in this case, is the technical debt. The organization never feels the heat because you are turning it down, not up.

What I’ve seen

I’ve inherited the system where the institutional knowledge walked out the door with the previous lead. You spend your first 90 days asking “what in the world?” — while working hard to approach it with the grace of recognizing that they did the best they could with what they had.

Two things turn that situation from insurmountable to iteratively achievable.

The first is listening without acting. Not yet. Not until you have the entire picture. The panicked leader hears a problem and fixes it. Then hears the next one and fixes that. Then the next. Over and over, never realizing that some of the problems downstream are self-inflicted — consequences of acting without full understanding, compounding in a system they never fully mapped.

The second is governance before implementation. Document everything. Document the system as it existed when you arrived. Document every decision point. Document every change, every improvement, every tradeoff you made and why. Not because anyone will read it — they probably won’t, at first — but because documentation is the only way to see when an implementation made something worse instead of better. Without it, you are flying blind and calling it progress.

The practitioner who listens first and documents everything builds something durable. The one who acts on every fire call fails to build anything — and the knowledge burns out when they do.

I have been both. The handbook reflects what I learned from each.

What the handbook is

The Data Leader’s Handbook is my attempt to document the approach that actually works — not the approach that looks good in a slide deck.

Fourteen chapters across five parts. The first 90 days. Governance without a team. The budget problem. Inherited architecture red flags. Staying credible when the data is bad and the leadership wants answers. Twenty-three templates included — not because templates solve problems, but because starting from a blank page when you are already underwater is a tax you do not need to pay.

It is written for first-time and fractional CDOs at mid-market companies. It is written for the practitioners who are the data function, not the ones who manage one. Applied experience only. No theory borrowed from McKinsey decks.

If you have been there when the C-suite is standing between you and the problem, this is for you.

Available at store.rdm.is for $69. No subscription. No upsell.