A couple of months ago, I was working on a project to improve our CI infrastructure. We use GitHub and Jenkins at HubSpot and we wanted to automatically configure and trigger Jenkins builds via GitHub web hooks. I had about 80% of the work completed when my calendar started to overflow with management responsibilities. What comes first, migrating over 500 projects or focusing on recruiting, retaining, and growing our engineering talent? The answer was simple. I hired exceptionally talented developers for a reason; they don’t need me as an individual contributor, they need me to build an autonomous dev team that is always ten steps ahead. I realized my top priority at HubSpot was to manage our dev talent and take it to the next level. What I didn’t realize was that I had sacrificed coding for another kind of engineering. Designing, building, and debugging software is second-nature, but crafting a team culture that runs smoothly, fixing the parts that are broken, and managing talent is a different skill set entirely. It’s about people now, not products.
I still believe great engineering leaders must be capable of working side-by-side with developers in some form or other such as code review, bug fix, architecture, and hackathons, but I’m pulling myself away from owning production features. I trust our tech leads (who manage one or two engineers each) to write code for the implementation and operation of our software, while I focus on implementing and operating a world-class dev organization. My first realization has been that great leaders work for their engineers, and not the other way around. I may be their manager on paper, but my job is to serve them and enable them to grow their talents individually in order to make all the pieces of the team work. While I step back from coding, I’m hoping refreshing this old blog can share what I learn along the way throughout this new challenge to serve the engineering team.