Leading by Listening (and Pair-Programming)

June 10, 2023

Our new squad looked like the start of a sitcom — a self-taught JavaScript guru who once built a marketing campaign in a weekend, a distributed-systems PhD who quoted Paxos at lunch, a former QA analyst making her first jumps into Go, and a fresh grad who measured time in memes.

My reflex was to "keep everyone on track" by nit-picking pull requests down to variable names. Three days in, I realised that hovering turned brilliant adults into anxious typists — and robbed us of their best ideas.

What actually worked

I started by just asking questions. About kids' daycare pickups, energy peaks, how each person liked to learn. Those answers shaped sprint plans more than any Jira dashboard ever did.

Then I grabbed the gnarliest legacy bug myself, narrated my thinking in Slack, and pushed the first refactor PR. Showing beats telling. The team mirrored the style guide and commit hygiene without a lecture.

Every Thursday we did a "pair-programming roulette" — two-hour blocks, cameras on, one driver, one navigator. Patterns spread, standards converged, and nobody felt lectured because they helped write the code.

The shift

I stopped writing line-by-line orders and started writing outcome tickets — describe why and done, let the engineer choose how. Sync time isn't wasted if it replaces ten async misunderstandings. And I learned to celebrate the different routes — UML sketches, TDD sprints, or whiteboard epiphanies all reach the same finish line.

I still love clean code, but I've learned it grows best when people feel heard, trusted, and occasionally invited to steer my keyboard too.