Posted by Christopher Bradford on April 23, 2013 in Operations

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.

Christopher Bradford

Christopher Bradford is VP of Engineering, responsible for the application development teams that produce's web, mobile and desktop applications.

1 Comment

  1. 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.

Comments are closed.