500 Hours, 20 Years: What I Learned Writing the Engineering Leadership Playbook

It’s here! The first copy of Product Driven!

I slit the bubble wrap, lifted one copy, and felt the weight of two decades of late‑night stand‑ups, production fires, and customer calls—condensed into 260 pages.

It took roughly 500 hours of pre‑dawn writing sprints to make sure every sentence earned its place.

This process did more than produce a book. It forced me to confront where my own leadership had drifted and what still wasn’t clear. Each rewrite came with a punch-in-the-gut reminder of how products—and teams—really scale.

Below are the five lessons that kept resurfacing.

Grab your copy of Product Driven on launch day, this Thursday, and skip the mistakes it took me twenty years to learn.

Lesson 1
Velocity without direction is just faster waste

My earliest drafts read like a typical sprint board: lots of words, no impact.

I could feel myself “shipping pages” instead of solving a reader problem. It echoed the teams I once pushed to “go faster” only to ship features no one used.

What it means for your team:
Look at the last release notes. If you can’t tie each line to a user outcome in 30 seconds, you’re burning calories, not delivering value. Instrument speed after you’ve instrumented purpose. Kill one backlog item this week that isn’t anchored to a customer pain.

Lesson 2
Culture is how it feels to work for you

I wrestled with the word culture for 30 pages—until one sentence survived every edit: “Culture is how it feels to work for you.”

Once that landed, the rest of the chapter practically deleted itself. Theory was replaced with feelings: safety, curiosity, pride.

What it means for your team:
Posters and values docs don’t fix disengagement; micro-moments do. In your next 1:1, ask, “When did it feel risky to speak up?” Then fix that risk. When engineers feel safe challenging a requirement, they protect you from your own blind spots—and bad releases.

Lesson 3
Clarity is the fuel

Every time an editor said, “I’m lost here,” they handed me a mirror. I learned that clarity isn’t decorative; it’s functional.

The book finally clicked when every chapter could be explained to a non-technical founder. That insight became the refrain: “Clarity is the fuel.”

What it means for your team:
Replacing half a stand-up with a Clarity Check will do more for delivery than doubling sprint points. Start by restating the user’s problem, then ask, “What’s still fuzzy?” Make dialogue—not docs—the place where clarity gets built, because questions reveal misalignment faster than Confluence ever will.

Lesson 4
You don’t scale yourself. You scale trust

I used to brag that nothing shipped without my review. Turns out I was scaling exhaustion, not excellence. Writing forced me to crystallize the uncomfortable truth: “You don’t scale yourself. You scale the story, the thinking, and the trust.”

What it means for your team:
Hand a decision to the squad and hand them the context you normally guard. Stay available—then stay out of the pull-request queue. The moment they deliver without your stamp, tell the story of why you trusted them. Your narrative sets the ceiling on their ownership.

Lesson 5
Trust → Ownership → Impact → More Trust —
The Flywheel

While hunting for a unifying diagram, I kept sketching loops. One finally stuck: Trust → Ownership → Impact → More Trust. That became the Ownership Flywheel chapter . Every real story in the book nested inside that loop.

What it means for your team:
Spot the next engineer who crosses lanes to fix a bug “outside their ticket.” Praise the behavior publicly. That single signal tells the group, “Cross-lane ownership is the job.” Each rotation of the flywheel compounds judgment and speed—no heroics required, just system design.

Why the book, and these lessons, had to exist

Most leadership books give you slogans: empower your team, move fast. Useful in theory, useless in Tuesday’s sprint review.

I wrote Product Driven so you can hand a playbook to a staff engineer tomorrow morning and watch them run it. The five foundations—Vision, Focus, Clarity, Ownership, Courage—are the operating system for product-minded teams .

Your move

Pick the lesson that stings the most and ship one tangible change this week.

Then tell me what happened—good, bad, or hilarious.