Posted by on April 23, 2013 in Technical Management

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 went into the experiment excited about the opportunity to work on a single-page application in Javascript, a back-end Java integration project, a WinForms C# desktop application, an ASP.NET MVC Web API service, a Ruby on Rails app, iOS and Android applications. Maybe I could even squeeze in some time on our Windows 8 app. With several of these technologies, my experience was limited to dabbling, so I was looking forward to learning, as well as contributing to the production code base. After all, that was how I measured my contribution to the company before moving into management.

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.

About Christopher Bradford

Christopher Bradford is a Senior Director of Engineering, responsible for the application development teams that produce Ancestry.com's mobile and desktop applications, integration with social networks, sharing, DNA applications, and new products to help expand the audience Ancestry.com serves.

1 Comment

Tyler Jensen 

I appreciated your blog post. Knowing where you fit in the development strata is a good thing. I’ve often been tempted to take a management role but I think it would be a poor fit. So I stick to coding.

April 24, 2013 at 3:22 pm

We really do appreciate your feedback, and ask that you please be respectful to other commenters and authors. Any abusive comments may be moderated.

Commenting is open until Tuesday, 7 May 2013