🚣 Rowing the race you need at the end

Daniel James Brown's The Boys in the Boat follows the University of Washington eight-oar crew that won gold in Berlin in 1936. The part that stays with me is how they rowed the middle of a race.

Washington was a come-from-behind crew. Other boats tore off the line and took an early lead. Washington took a clean start, settled to a lower stroke rate than anyone else, and let the field go. What the crew was buying with those middle thousand meters was swing, the state where all eight pull as one and the boat lifts and seems to carry itself. Swing is where the speed actually comes from, and a crew that blows itself out in the first minute never finds it.

George Pocock, the boat builder who made the Husky Clipper and served as the crew's quiet mentor, put what rowing teaches this way:

"Harmony, balance, and rhythm. They're the three things that stay with you your whole life."

The pressure at the start of a project runs the other way. Get a demo up, show motion, take the early lead. That first sprint always looks like speed, and an early lead bought with skipped foundations is a rate no team can hold.

The middle of the project is where a team finds swing. Builds get fast, releases become routine, the pieces fit together, and everyone can see how the whole system works. That investment feels like lost ground while it is happening, because the boat ahead is still ahead.

But the race is won at the finish, and in product development the finish is long: the release, the update after it, the field bugs, the second product built on the same foundation. That is what the reserve is for.

Release First should not be confused with fast, explosive starts. Release First starts small and unimpressive, and the focus is on the smallest increment that is useful to others, not a big show.

This is where AI can deceive us. It can very quickly put together a very impressive first demo with a very nice-looking UI: it looks ... nearly done. That time would probably have been better spent using AI to help write plans, document architecture, research technologies, better understand user needs, etc.

The schedule asks how fast we can go. The more important question is what rate we can hold for the whole race. A fast explosive start is impressive, but rarely what matters in the end. And the only way to go fast for the long haul is to invest in efficiency. What matters is each stroke along the way.