As is often the case with technical managers, I started out as a software engineer, and miss the experience of day-to-day coding. I became a team lead and then “officially” moved into the ranks of management as I took responsibility for multiple development teams. As I considered how to be more aware of how these teams were running and how to provide constructive feedback to the leads of those teams, I decided to try an experiment: I would spend a few hours each week pair programming on these teams. This way I could be in the midst of the operation of the team, see how they interact, what their code looks like, their testing practices, their communication, and so on – with the added benefit of scratching my own coding itch.
I paired with several teams over the course of about a month. What I discovered was that I got so involved in the specifics of the problem at hand that I didn’t get the benefit of the insight into the team that I had been hoping for. I thoroughly enjoyed coding, designing, talking through solutions, identifying areas that affected multiple teams, and even (believe it or not!) occasionally teaching a developer a new trick. But I didn’t really get a great sense for the team dynamics.
I decided to abandon the experiment and replaced it with more in-depth one-on-one meetings with my team leads. I got a much better sense for what was going well and where my leads and their teams needed my input. Lesson learned: lead and manage at the right level. As much as I wanted to be in the code, it was the wrong level for me.