Step away from the vehicle05 Jun 2016
Engineering management can be extremely rewarding. It’s great to be able to see your staff achieving their goals, advancing their careers, and building some really cool stuff. As you travel further up the org chart, you get the reward of seeing even more of your staff doing this, and if you do a good job as a coach and mentor, you’ll end up with a roster of teams that are shipping exciting software and, hopefully, having fun and learning new skills while they are doing it.
The main struggle - one that I certainly deal with all of the time - is frustration that I’m not committing any lines of code on major projects. I’m not the only one that feels this way: many of my peers have expressed the same frustration. After having spent countless years proving my technical skills in order to take on team lead roles, then having the opportunity to take that next step up to be a manager of team leads, one can easily forget that this isn’t a linear track for all software engineers; it is in fact a very separate track.
Here is a completely unordered list of what my day consists of. Each day is very different.
- Emails and Slack messages. By having lots of concurrent teams and projects, you need to get good at knowing what you should read closely, what you should skim, and what just isn’t worth your time.
- Catch-ups. These range from 1 to 1s with direct reports to progress updates on key projects, and includes our weekly management meeting and my own 1 to 1 with the CTO. These are always scheduled in the calendar and take some preparation and follow up before and after. I live and die by the information I have in my notes and brain.
- Ad-hoc meetings. Everything and anything. Hiring discussions. Upset people and personal issues. Discussing how to tackle a technical issue. Working out what the hell just exploded and why and who is going to do something about it.
- Reviewing code. I still care a lot about this, as it keeps my technical skills sharp and I can understand how things are being built.
- Interviews. I tend to only get involved in latter stages now, but during periods of aggressive hiring this takes up a fair amount of time as I want to make sure I meet as many people as I can. I bundle reviewing CVs into here too.
- Planning. Discussing what might be coming up beyond the current projects. What do Product want? What do Engineering want? How should we balance our time between building new features, scaling out existing architecture or replacing some bits of architecture completely?
I’d say that this takes up 70% of my time. What should take up the rest? When I initially had a VP level role I thought that it would be worthwhile to chip in my 30% of remaining time into one of the development teams, taking on some small pieces of work. That ended up being a terrible idea for me. I was the most unreliable member of the team due to interruptions and meetings.
So here is what I spend my other 30% of time doing:
- Being thankful that as soon as the shit hits the fan, I am free enough to take ownership. I cannot stress how important this is.
- Assisting other areas of the business. Recently I’ve been looking at different tools for improving the documentation of our API, because our Professional Services teams and clients have a hard time integrating with it. I also gave some technical assistance to our Operations team to integrate data with another piece of software. This helps me see what the rest of the business is up to, improves the relationship between them and Engineering, and helps me know more people.
- Reading up on the latest technology so that I can still participate meaningfully in technical discussions. Typically, as a backend guy, this is keeping abreast of the latest in the Apache world, and reading and watching talks from good conferences. I may tinker with some toy projects if I can.
- More code reviews. There’s always more code to review.
None of those things involve writing real code for any of my teams. They can do that a lot better than me. I’ll keep keeping away.