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

  • Empathy first
    I asked about kids’ daycare pickups, energy peaks, and how each person liked to learn. The answers shaped sprint plans more than any Jira dashboard.

  • Lead by example
    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.

  • Team‑wide pairing sessions
    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

  1. Outcome tickets, not line‑by‑line orders—describe why and done, let the engineer choose how.
  2. Pair to share—sync time isn’t wasted if it replaces ten async misunderstandings.
  3. Celebrate the different routes—UML sketches, TDD sprints, or white‑board 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.