How This Book Happened

This book started as a readme.

TransitOPS won a contract to build a transit data app, and I recruited a recent college grad to work on it. When we first met, I asked him, Have you ever worked on a product team? No. Do you have experience with Agile? No. Okay, what about code reviews—have you ever provided one? No. Did you ever work with a UX designer? No. Project estimation? No.

So I was thinking, okay, this will be a learning experience, but let me just start jotting down some notes for us to go over. Then I kept adding things. And I couldn't stop.

At the same time, a few weeks into the new management job, I observed more gaps. Smaller gaps, but gaps nonetheless. I met an engineer who had been building an app for months and didn’t know what it did. I attended a daily Agile theater as people went through the motions and never corrected course. I spoke to someone who seemed to want a promotion based on his legendary achievements at his last job. Maybe there was a broader need for a book that addresses the judgment, collaboration, and discipline of a healthy, productive software team.

Before this job, I'd spent 8 years at the MBTA, most of it as Director of Engineering. At one point, with forty direct reports spread across ten teams. I had helped grow the department from about 20 people to over 100, with a mandate to change how people actually experienced the transit system, not just ship features.

It wasn't all rosy. There were some remarkable performers and a few grifters. Inspirational leaders and plenty of uninspiring ones. But over those years, I partnered with a small group of people: Paul Swartz, Siobhan Cunningham, Kristin Taylor, Matt Shanley, Grejdi Gjura, Benji Maur, and Josh Melucci. Together, we figured out how to do this work. How to guide teams to better results. How a single bad behavior can poison an entire group. What qualities do teams actually need to be innovative, versus what just looks innovative. How to build a team for impact and how to eliminate one that makes none.

I remember the day we finally killed a project that would have been just as bad as the one it was supposed to replace. Three engineers had spent months on it; the demo looked impressive, but it wouldn’t make a difference. That conversation was hard. But it was the turning point where we started asking, "How will this make people’s lives better?" instead of "What can we build?"

It occurred step-by-step. It was multiyear. But we were so busy doing it—course-correcting teams, confronting bad behavior, supporting amazing team members—that we never stepped back to see what culture and processes we'd built. We never had time to reflect on the full body of the work.

For me, this book became that reflection.

There was a draft of this book that only had a few stories. When Julia Schaumburg and a few others reviewed it, they said the stories were the best part, and there should be more. I don't know if it's because I'm my dad's son or an Irish thing, but I've always loved telling stories, and it's been part of my management approach. If I had to deliver critical feedback, I'd often frame it around "let me tell you about a time when..." Maybe it was my learning opportunity, or someone else's, but I think it helped people understand: we're all learning. At one point, I was doing twenty 1:1s per week. You develop a repertoire!

The thing I keep learning and re-learning: transformation isn't a graduation. In this field, and really in life, you need to keep growing, and to grow, you have to be open to not one but many personal transformations.

I was the team member who wanted to be the smartest person in the room, but didn't realize how close-minded I'd become. I was the one who treated the sprint like a contest rather than a team effort. I avoided uncomfortable conversations, and my career stalled as a result. Every failure in this book is one I've made. Every transformation I'm asking of you is one I've tried to make myself. Sometimes more than once.

This is my first published book, but it's the fourth one I've written. If there's something in here that helps you work better with others, that helps you be part of a team that ships code that makes a difference in people's lives—then it was worth it.