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!

Dilbert.com

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

Resources and Articles

comments powered by Disqus