One-on-Ones on a Pair Programming Team

One-on-Ones are a well known management strategy. They help reduce communication misses, keep everyone on course and provide an easy platform for feedback. I’ve done them throughout my management career, but the past few years I had a few start and stops with them.

My scenario over the past few years has been working as an engineer and often a tech lead on small teams where we paired as much as 80%. Sitting side by side and rotating pairs often led me to experiment with skipping out on one on ones. If you’re having regular conversations over the code, do one-on-ones serve enough of a purpose?

I decided they were important enough to restart after my first year on the new job. Part of my reluctance was the need to come up to speed on a number of technologies. I skimped on spending time for tactical management tasks. I relished staying deep in the code and design, but I should still have carved out the time for one-on-ones.

When I transitioned to leading a new team about 6 months ago I again let the one-on-ones slip off my radar. I told myself I would restart them after I felt out the new team. Turned out I got lazy and took 6 months to restart them. Even on teams that pair and sit in close proximity, some conversations never come up and it’s rare to discuss items like career aspirations when the whole team is housed at one long table.

I have made a single adjustment from my old style where I ran 30 minute one-on-ones once a week. For my current team:

  • Scheduled for 30 minutes.
  • Most of the agenda is up to the employee, and sometimes we discuss future career type goals.
  • The last 5-10 minutes are for me, news I need to pass on or lightweight feedback.
  • Generally the one-on-ones average about 15 minutes, but they’re still scheduled for the full 30.
  • I rotate through all of them one after the other so with 3 we’re often done after about an hour.
  • If we miss a week for some reason it’s not a big deal, since these are weekly.