Why I Wrote Live Life Automated (The Honest Version)

Every author has two answers to "why did you write this book?" There's the one that sounds good in interviews, and there's the real one. I'm going to give you the real one.

The Clean Version (Still True)

The clean version goes like this: I spent years doing DevOps at scale, developed a framework for automation that produced measurable results, couldn't find a book that covered what I'd learned, so I wrote one.

That's true. Every word of it.

But it's not the whole story.

What Was Actually Happening

In 2022, I was burning out.

Not dramatically, not in a way anyone around me noticed. But I was doing the kind of work where you're always responsive, always available, always the person who knows how things work because you built them, and there's a quiet exhaustion that comes from that position that doesn't show up until you step back and look at how you've been operating for the last 18 months.

I had become the hub of a wheel. Things worked when I was there. When I wasn't, they sometimes didn't. That's not a sustainable position for a team lead, and it's not sustainable for the person either.

The automation work I started doing wasn't just about team efficiency. On some level it was about getting myself out of the center of things — building systems that could run without me, so I wasn't the single point of failure, so I could actually log off on a Friday without anxiety.

When the ticket triage service went live and I watched it run through a Monday morning backlog without anyone touching it, the feeling I had wasn't just satisfaction about the technical result. It was something closer to relief.

The MSP Piece

When I left the corporate role and started Fitzgerald Tech Solutions, I was delivering IT services to small businesses — most of them with 10–50 employees, none of them with a real IT team.

These clients needed enterprise-quality infrastructure: reliable backups, monitored systems, secure authentication, patch management. They needed it delivered by one person (me, at first) at a price point they could actually afford.

The only way that equation works is automation. Not someday — from day one.

I built client onboarding scripts that could set up a new client environment in under 30 minutes. I built monitoring configurations that auto-deployed to new machines. I built backup verification scripts that ran every night and emailed me if anything looked wrong.

I was essentially building a software product on top of IT services — and selling the outcome, not the hours.

That experience taught me things about automation that you don't learn in a corporate environment, where you have colleagues to catch your mistakes and a salary arriving regardless of whether your scripts work at 2am.

When you're running an MSP alone, automation failures are your problem. The clients don't care that your script had a bug. They care that their server isn't backed up.

That sharpened my thinking about reliability, error handling, and monitoring in ways that the corporate work hadn't. And it gave me a second audience for the book that I hadn't originally planned for: the solo operator or small MSP who is trying to deliver enterprise-quality work without an enterprise team.

The Writing Process

I started writing in early 2025 with the vague intention of producing something useful. The first three drafts were bad — too abstract, too close to a DevOps textbook, too much theory.

What fixed it was a simple question I started asking myself every time I wrote a section: "Would this have helped 2019-me?" 2019-me was smart enough but had no framework for finding automation opportunities, no template for evaluating whether something was worth automating, no model for what a reliable production automation looked like.

Every section that wouldn't have helped 2019-me got cut or rewritten.

That question also kept the book honest. There are things I write about that I tried and got wrong. The section on ML-based classification includes the story from week 2 — I built something more sophisticated than I needed and paid for it with two weeks of debugging that a simpler approach would have avoided.

I could have left that out. But a book that only shows the wins is a marketing document, not a manual.

What I Want the Book to Actually Do

I want someone to read Live Life Automated, run one part of their day through the book's Five Criteria for Good Automation, and end up with one working automation within a week.

Not a gadget bought and forgotten in a drawer. Something running reliably that handles a repeatable part of their day — that they can trust without thinking about it.

If the book produces that outcome for the people who read it, it's done its job.

Everything else — the numbers, the case studies, the chapter-by-chapter walkthroughs — those are in service of that one goal: helping people build things that actually work.

That's why I wrote it.

Live Life Automated is available now. Matt Fitzgerald writes The Operator's Edge newsletter every Monday and runs Fitzgerald Tech Solutions.