About
I grew up poor and religious in rural central Florida, with no expectation of going to college. School bored me, and bored plus lazy is a dangerous combination for a teenager. I dropped out of high school a few weeks before graduation because I needed extra credits and couldn't muster the energy to care. Eventually, I went back for my GED. The proctor who handed me my scores told me they were the best he'd ever seen. "You're going to college, right?" I wasn't. College wasn't in my world.
Instead, I bounced around for a while, including a stint in a religious community in New York, and eventually landed a job answering phones at an unsaleables company, handling reverse logistics for retailers. I was lucky. My manager was good, and I did well enough that I started helping with data work on the side. One day he came to me with an opportunity: the company was adopting something called Lotus Notes, and he thought he could get me a developer license if I was willing to learn it.
"Buy me a book," I told him, "and we'll see."
He bought me the book. I taught myself from nothing. Lotus Script was brutal, and I beat my head against it for weeks until something finally clicked. I remember dancing in the hallways between the call queues the day it all came together. That was my first taste of what it felt like to build something.
I did that for a couple of years before realizing I was a Notes developer making a phone-answerer's salary. So I left for a company that worked on big iron, AS/400s, and mainframes, doing Notes development for manufacturing clients. A few years in, my boss came to me again: "Java is becoming a big deal with our clients. Think you could learn it?"
Same answer: buy me a book, and we'll see.
Java changed everything. It led me to discover that there was this thing called computer science, a whole field I'd never known existed. I fell into it completely. For the next five years, nights and weekends, I studied lambda calculus, probability and statistics, and programming language theory. I became obsessed with languages. All the families, all the paradigms, finding the right tool for the right job. It was the most intellectually alive I'd ever felt.
That self-directed education carried me through several companies until one day, Amazon called. I flew out and spent an entire day interviewing, 8 AM to 5 PM, lunch included. I went back to the hotel room and collapsed. But I got the job. I think of that as defending my thesis: proof that a kid from central Florida with no degree could compete at the highest levels of the industry.
At Amazon, I landed on a small R&D team that a VP had assembled to explore some ideas he was interested in. The team was a Principal Engineer, a Research Scientist, and, somehow, me, a mid-level engineer who had no business being there. We spent a couple of years on problems that produced patents and taught me distributed systems at a depth I couldn't have gotten anywhere else.
From there, I moved into Amazon's large-scale build and deployment infrastructure. This was the early 2000s, and we were deploying and managing software across tens of thousands of servers, doing things that wouldn't become common industry practice for another decade, at scales that still seem improbable.
I eventually left Amazon and spent the next ten years doing distributed systems work at various companies. What I didn't expect was how much I'd learn about organizations during that time. Almost every engagement involved building new teams to support new systems. I made a lot of mistakes. I also started to notice a pattern. We rarely failed for technical reasons. When things went wrong, and they went wrong more often than I like to admit, the cause was almost always communication, or incentives, or structure, or politics.
That decade culminated in writing Erlang and OTP in Action, a book about building distributed systems at scale. It was well-received, and it marked a transition point for me. I went from someone who was doing the work to someone who was also teaching it.
But the pattern kept nagging at me. If the failures weren't technical, then being a better technologist wasn't going to fix them. And if I didn't want to fail, I needed to be the one making the decisions that actually mattered.
So I moved into leadership.
It was a hard transition. I came in at the director level, which meant I'd skipped all the lessons you learn as a line manager, as a senior manager, as someone who grows into the role gradually. I learned those lessons the hard way instead, through mistakes, through realizing how often I'd been wrong, and eventually through humility.
The hardest lesson was this: the engineering version of "right" is not actually right. You cannot make good decisions on pure engineering principles. Real decisions require weighing risk, probability, context, people, politics, everything. I thought I understood that before I led organizations. I did not. Understanding it has been the work of the last several years.
When I took my current CTO role, the engineering organization was producing maybe one release every two months. Morale was low, the business was struggling, and nothing was moving. Within a couple of years, we went from 20 deployments a month to averaging between 300 and 400. We solved SEO problems that had been dragging on the business for years. Revenue started growing again, 5 to 10 percent year-over-year. The mobile team was growing 30 percent annually. And we did it with fewer people than we started with.
That turnaround didn't come from better technology. It came from building a team that understood they are the business. Engineers sometimes talk about "the business" as if it's somewhere else, some other group making demands. I push back on that. In a technology organization, you're not an artist in residence. You're not a hobbyist. You are the business, more than anyone else in the company. The teams I build understand that, and it changes how they operate.
That's the path that led here. I started from scratch, taught myself from books, and eventually figured out that the interesting problems aren't technical. They're organizational. This site is where I write about what I've learned: how to build teams that move, how to make decisions that stick, how to lead engineers in an era where the ground is shifting under all of us.
I'm currently a CTO. I'm also writing The Dao of Delivery, a book about engineering leadership that captures the frameworks and mental models I've developed over the years. If that interests you, subscribe to The Desk Reference. I write infrequently, but when I do, it's because I have something worth saying.