2014 and My Transition to Engineering Manager

07 Jan 2015 In Personal 0 Comments

This last year was a roller coaster ride both personally and professionally. I will save the personal story for another post, and instead talk about the big transition I made professionally. In 2014, I made the transition from a software engineer to an engineering manager. This was a big change.

Like most programmers, I loved the highs from programming. Solving technical problems and building products gives one a great sense of accomplishment and pride. As much as I wanted the extra duties and influence that comes with a promotion to manager, I wasn't sure I wanted to give up programming. I was also hesitant to trade programming for boring HR people management stuff like approving vacations and writing reviews.

It turned out that I was able to trial run a manager position and see how I liked it. There were a few other engineers at Return Path who were also considering a move into management, also there was an unusually high amount of Engineering manager positions opening up. So three other engineers and I were given the chance to lead our teams as interim managers for three months.

Those three months were very eye-opening and taught me a lot about myself. I learned that my team respected me and accepted me as a manager (I had doubts about how my team would feel). I also learned how rewarding it was to help develop and mentor my team members. The deciding moment was when I was given the opportunity to make an engineering intern that worked on my team over the summer an offer of a full time position. It was an amazing feeling presenting the offer letter -- it far surpassed any sense of pride I felt as a programmer.

Making the Transition

Once I decided this was a transition I wanted to make, I sought advice on how to adjust. I read some great advice on various blogs; the best was this article from Stephen Haunts discussing how to make the transition. I followed his advice on giving up day-to-day coding duties. I now take on code projects that have no mission-critical deadlines that I can work on when I get free time. I also keep my technical skills sharp by taking on more personal projects (like this blog), and I even started to get more involved in the meetup community by co-organizing the Boulder Python meetup and giving presentations there. This also helps me recruit, which is now a very important part of my job.

I believe it is important to stay sharp in this area. As an Engineer, I preferred technical, former-engineer bosses as I felt they had a better grasp of my job, and were obviously better mentors. I don't want to be Dilbert's boss!

I have now been a manager for 90 days, and have grown my team by hiring three more engineers and guiding the team to some very important milestones for the company. I have also read some great articles and blogs on what it means to be a great Engineering manager and on leading engineering teams. Those articles helped me build my personal management philosophy:

My Philosophy on Leading Engineering Teams

Simple is Elegant
I value an ability to learn and a strong curiosity over raw experience
My teams should have a mix of Junior, Mid and Senior Level engineers
- This really builds a strong dynamic of learning and teaching.
Languages, frameworks or patterns don't matter as much as the solution.
Many engineers value the code over the product; those engineers won't work on my team.
Having said that, I am a Python fan-boy
Good engineers should know how to extract and transform data to gain real business insights
I think remote engineers and teams work well and give a company flexibility to build highly talented teams.
However, Junior engineers should be in-office learning from others
Remote tools and team OS are important. SLACK and Google Hangouts work well for us.
My job is to meet the business objectives on time with high quality, while also developing and engaging my team members
Have fun, fight for fun, budget for fun
Observe - Throw team lifeline when they fall down rabbit holes
Let Engineers pick their own solutions and methods as much as possible.
All these philosophies are subject to change

My Blog