As I continue figuring out the work to manage engineers, I’ve asked other, more experienced and better managers to give me whatever advice and commentary they have on a job that’s both less discussed and less defined.
Here is what they said:
- Learn how to manage projects. It’s not a formal part of the job description, but managers have to pick up the slack. Mundane tasks like bug triage and iteration plans are tedious, but necessary to run a team.
- Find feedback between the lines. Whatever metric or heuristic that may have worked when my output was just code no longer apply when my output is a function of the output of my team. Find feedback however I am able.
- Earn the respect of my reports. The practical difference in a manager who is also an engineer and one who’s only a human manager is that the former can relate, reason, and discuss engineering problems. That both of us speak within the same occupational framework allows for a much higher chance of mentorship and growth for both parties, but it only manifests when reports respond to the technical expertise of the manager. That said, it does not mean managers have to double as technical leads; architectural direction should still be determined by the team.
- Figure out how to say no. Focus is a good business strategy, and it applies equally well to engineering teams as it does to businesses. I am the external interface to my team, and it’s on me to set the balance between tech debt, foundational work, internal projects, and external requirements. Project prioritization should become a core competency.
- Grow the team. For healthy companies, recruiting is a shared responsibility for everyone in the organization, but engineering managers have both the authority and the need to expand our teams. Not only is it slightly easier to get initial contact, we also have the breadth to really explain the work, the culture, and the projects across the company. If this is not an explicit job requirement, it’s still very much implied and expected.
Quite a list, huh?
One thing that I’m trying to get used to is the sheer amount of work management entails. Whereas (good) code will happily run on its own when I go home for the evening, communication is 24-hours a day, and necessarily tailored to the situation and people involved. Not only that, the volume, if left unchecked and unbounded, consumes nights and weekends and vacations indiscriminately.
When everything falls in place and my team just executes, it’s one of the greatest feelings in the world.
