I once ran a two-year program to write a book fueled by more than 70 authors, and not one of them reported to me.
I didn’t have budget authority. I wasn’t responsible for their performance reviews. There was no solid or even dotted line on an org chart. We all just shared the belief that Site Reliability Engineering deserved a book. I raised my hand, taking responsibility for getting dozens of volunteer contributors, scattered across every Google SRE office, to write it in whatever spare cycles they could carve out of their day jobs.
After years leading engineering programs, I stepped away to write and create independently full-time. This site is supported by readers: when you buy books or tools through the Amazon links here, I may earn a small affiliate commission at no extra cost to you.
That project became Site Reliability Engineering: How Google Runs Production Systems, published with O’Reilly in April 2016. The book was written by SREs about SRE and featured contributors collectively representing 500+ years of Google production experience. The book went on to become a tech bestseller.
The book was no one’s day job, not even mine, which is exactly what made it hard. Projects like this are often described as an exercise in herding cats. Ten years later, with the second edition now in early release from O’Reilly and available to pre-order on Amazon, I keep getting asked how the first edition went from idea to reality. Here are the 13 program management tactics that I used to get the book over the line.
How to Motivate People Who Don’t Report to You
The first challenge was motivating people with influence rather than organizational authority.
1. Find a carrot to dangle
The SRE book was never a one-quarter project, or even a one-year project. It was clear from the start that finding subject matter experts and shaping their contributions into something coherent (a symphony rather than a cacophony, as our O’Reilly editor would say) would take time. “Write this chapter, and in two years you’ll see it in a book” is not a pitch that survives contact with a volunteer’s actual workload.
Instead, I worked with our small core team of co-editors to find a carrot to dangle. We cultivated a partnership with USENIX’s ;login: editor to pre-publish content, timing submissions to land around special-issue deadlines to create real urgency. BeyondCorp became our first externally published piece this way, and about nine articles found a home in ;login: before the book was published. Since ;login: was Open Access, we maintained the right to fold everything back into the book later.
This “carrot” delivered short-term gratification and a slow and steady stream of publication-ready content for the book.
2. Get explicit commitment, in writing
Social psychology is a powerful thing. Since this book project wasn’t anyone’s day job, I needed a clear record of what people had actually signed up for, preferably in writing, and preferably with other people in the loop. I set up a quarterly Objectives and Key Results (OKR) process that authors acknowledged by email. Once someone had committed to an OKR, I had a limited but real mandate to push for that work to get done.
We rolled over a fair number of OKRs from one quarter to the next, and that’s fine. The point wasn’t a perfect track record, but rather setting up a psychological compact so people felt a little uncomfortable if the work didn’t happen, like they were letting someone down.
3. Stay on the radar without adding overhead
Setting OKRs at the start of a quarter and checking back at the end doesn’t work. As a program manager, you have to stay visible without creating a bunch of toil for the team. I ran a biweekly virtual stand-up as a way to achieve this.
The stand-up was virtual because our contributors were spread across Asia Pacific, North America, and Europe with no common time zone overlap. I asked for a 1-2 line update by email: progress, blockers (where they needed help), and next steps. If I didn’t hear back, I’d follow up with a ping.
4. Be the cheerleader
I sent out biweekly updates to everyone working on the project, and I made a point of publicly calling out finished work.
The people who’d completed a chapter felt appreciated, and everyone else subliminally registered that they were falling behind, which lit a fire under them.
There were plenty of moments where I privately thought our efforts to crowdsource a book were bound to fail: No one has attempted something like this before. How is this ever going to get done?
None of that doubt ever made it into an email. My manager once said I wouldn’t rest until I had a book in my hands. He wasn’t wrong.
Pre-Order the 2nd Edition of the SRE Book on Amazon.
5. Engineer a sense of urgency
Signing our contract with O’Reilly was itself a tactic. I timed it deliberately: not so early that we’d burn people out chasing a deadline years off, but early enough that a legally binding date could be used to motivate people to finish their contributions. As we got closer to our editorial deadlines, I ratcheted that urgency up in the stand-ups and with the core team.
It turned out our core team of co-editors was a group of perfectionists, and when O’Reilly floated the idea of letting our deadline slip by a month or more, I pushed back. I pointed out that slipping meant missing our chance to launch at SREcon, our namesake conference.
We hit the original milestone, pushing the book to production in January 2016. Work expands to fit the time and space you give it. Use deadlines in a way that ensures perfection doesn’t become the enemy of good enough.
6. Use FOMO to your advantage
By the later stages of the SRE Book project, we’d built up enough genuine buzz across the Google SRE organization that a simple ultimatum worked on the stragglers: finish by this date, or you won’t be in the book. Fear of missing out (FOMO) turned out to be incredibly motivating.
Ways to Build (and Rebuild) the Right Team
When you are working with volunteers, you need to be realistic about what they can deliver. Circumstances and priorities change, and you need to overprovision even more than you would for other types of projects.
7. Build a community around the work
Throughout the SRE Book project, I made a point of framing this as a global effort involving SREs from every office and every product area. Pride in being part of something that would tell the world what SRE actually does turned out to be one of the most durable founts of motivation we had, well beyond anything an OKR could capture.
8. Know when to send in reinforcements
We paired every chapter author with a tech writer, and I quickly learned who I could count on when a contribution stalled. Betsy Beyer, an early tech-writer volunteer who later became a core team member and co-editor of the book, was the person I sent in on the hardest cases.
Without fail, she’d wrangle the author and deliver a solid chapter. She did such an outstanding job that she is now the lead program manager for the second edition and (unsurprisingly) is nailing it again.
9. Know when to swap people out
Sometimes a pairing just doesn’t work. We had one very opinionated tech writer paired with a very opinionated author, which produced a few fireworks. Swapping tech writers on that contribution solved it cleanly.
Separately, I once found an author on an internal mailing list willing to take on a chapter comparing SRE best practices to those in other industries. This was someone I’d never worked with before. They signed up for an OKR in writing, and about a quarter later, went completely silent. I emailed, I pinged, and all I got back was radio silence. After several attempts, I sent one final note saying I assumed their day job had gotten too busy to continue, and reassigned the chapter.
I ended up writing it myself with Betsy’s help. We crowdsourced content from interviews with about a dozen Google engineers who’d worked in other industries before SRE.
There is always a Plan B if you think about it hard enough.
Pre-Order your copy of the 2nd Edition of the SRE Book on Amazon.
10. Adapt your approach to the individual
Some contributors followed my process to a tee. Others responded best to a ping, a personal email, or working directly in our bug tracker. Even when it created more work for me, minimizing friction for the person actually writing the chapter mattered more than my own convenience.
How to Get The Project Over the Finish Line
Projects like this can drag on forever. At some point, you need to declare what good enough looks like and call it done.
11. Understand what’s critical to success
Early on, the core team sorted every proposed topic into publication-blocking versus nice-to-have. From there, I focused my attention on the P0 content. We started with more chapters than we finished with, but every topic that we believed was actually critical to the book made our editorial deadline.
12. Know when to bring down the hammer
This one I don’t love using, but sometimes it’s necessary. Late in the project, one of the authors told me they couldn’t finish their chapter after all: a publication-blocking chapter with no backup author available. I immediately escalated to a director on the SRE team in the author’s location who was known for having a strong, determined personality. They also happened to be a contributor to the book with a real stake in the outcome. That conversation was enough to get the original author back on track and the chapter delivered.
13. Celebrate success
Using these tactics, we delivered an externally published tech bestseller in about two years. My last piece of advice: celebrate the win. It’s easy to skip this part when you’re tired and already looking ahead to the next thing, but celebrating is what makes people feel proud of what they delivered, not to mention eager to work with you again.
Volunteers need to feel genuinely appreciated. If they don’t, they won’t volunteer again. We ended up having launch parties (with SRE Book cake!) in all of Google’s major SRE offices.
The Bottom Line
Ten years and a second edition later, I still think of the SRE Book as the purest test I’ve had of what program management actually is: delivering results through people who have no obligation to listen to you. It all boiled down to trust and a common, highly motivational goal, built one biweekly update at a time.
I’m The Reliable PgM™ because I’ve built my career at the intersection of Program Management and Site Reliability Engineering, and this project is where that crossroads is most literal: an engineering culture, captured in a book, delivered using the same tactics that work in any domain where you need people to finish something they didn’t have to start.
If you’re leading a project full of people who don’t report to you, borrow whichever of these 13 strategies fits your situation. Go find your own carrot to dangle.
Site Reliability Engineering: How Google Runs Production Systems, 2nd Edition is available now in early release from O’Reilly.
Read More from the Reliable PgMTM
Cat-Herding the Way to a Bestseller: 13 Program Management Tactics for Leading People Who Don’t Report to You
I once ran a two-year program to write a book fueled by more than 70 authors, and not one of them re…
A Garden Leave Retrospective: Hope is Not a Strategy, But Origami Might Be
When my “gardening leave” began, I didn’t dig in the dirt; I am not an outdoorsy person.…
19 Things I’ve Found to be True Over 19 Years in Tech.
After 19 years of working at Google, I’ve decided to embark on a new adventure. The team has handed …