I've been managing software engineering teams for a few years now, and one of the conversations that I keep having over and over with different people centers around delegation of responsibilities. Whether I'm trying to help someone grow into a management role themselves, or just trying to spread the load from an overworked manager (who is sometimes me), I've found it helpful to systematically break down the various responsibilities of an Engineering Manager, which has led me to a deeper understanding of what can be delegated effectively, and how.
Broadly speaking, I break down the responsibilities of a Software Engineering Manager into six categories:
Project Management
Project Management was something I started to take on well before I became a manager, and it's one of the first things I start delegating to a senior engineer who is looking to take on more responsibility. I look for engineers to first start managing their own projects (including writing technical specs, setting milestones, tracking deliverables, etc.), and then to start managing multi-developer projects for which they are the lead.
I would expect an Engineering Manager to understand Project Management and be relatively good at it, although I would not expect them to do all of it directly for their team, unless the team as a whole was both small and particularly junior.
Cross-team projects are generally larger and more complex, and an eng manager may often need to take on the Project Management role to get them done well (individual team members may have neither the proper visibility nor the clout to do it), although larger companies may employ a specialized project manager (or even whole teams of them) for just this purpose.
Process Management
Whether this refers to some flavor of Agile (Scrum, Kanban, etc.) or a more traditional Waterfall process, an Engineering Manager is a critical stakeholder in the process of how software gets built. However, it might not seem like management of the process is the job of an individual engineering manager:
- Scrum specially says that a manager shouldn't also be the Scrum Master, due to a conflict of interest
- Larger companies will often impose a process from above, and may even support that process with external teams of managers
That said, even if the specifics of the process are not necessarily in their control, an Engineering Manager who is focused on delivering quality software can't simply abdicate the process by which that software is developed and delivered. Being engaged with the process and advocating for improvements is key to avoiding pitfalls that might otherwise result in late, poor-quality software.
The good news is that, often for the reasons I listed above, this responsibility is easy to delegate, either to another team member or an external person responsible only for the process. If neither of these resources exist, however, a manager must be prepared to take on this responsibility themselves.
Inter-Team Communication
The manager of a team is, by default, the point person for interfacing with every other relevant team in the company. The manager must know who the stakeholders are and build working relationships with them. Communication of status and resolving of cross-team dependencies are critical to making sure that the team's projects complete on time, and do not unnecessarily block the work of other teams. The engineering manager should thus be familiar with all of a team's projects, current status, and future roadmap.
However, especially in the case where there is a long-standing relationship with another team, it is entirely appropriate to delegate some of this communication to another team member, one who is senior enough to effectively act as a point person for a particular relationship. One thing to consider when delegating this responsibility is whether or not you are comfortable with the selected team member making time/scope commitments on behalf of the team, at least within their limited area of responsibility. Either is ok as long as everyone is clear on who is able to make the decisions.
Intra-Team Communication
Team members communicate with each other all the time, and most of it happens organically. However, even within a functioning team, people don't always communicate well with each other, or often enough. This area generally involves managing communication channels, as well as mediating the (hopefully!) occasional interpersonal dispute.
This responsibility is not generally something a manager would want to delegate on a permanent basis, but it's important to have someone take it up on a temporary basis while you're on vacation. This may be as simple as designating someone to lead daily or weekly team coordination meetings.
Mentoring
An effective engineering manager need not be the most technical member of his or her team (and usually they are not), but they must of course be a good enough software engineer to provide mentoring and guidance to junior engineers, and help them grow into senior engineers. And while senior reports may eventually outstrip their managers technically, a manager is expected to be able to provide career guidance for all of their reports at all levels.
Mentoring, like Project Management, is an aspect where the manager doing it all themselves may be detrimental to the team, long-term. It can be a resource contention point for a manager trying to do it all themselves, while senior engineers potentially miss out on a wonderful opportunity to grow their careers. On any team, I would actively look to delegate mentorship of junior team members to more senior ones, provided I had senior team members who were both willing to do this and able to provide effective teaching.
Along with Project Management, I consider Mentoring to be one of the key skills I look for in helping senior individual contributors grow into future leaders in their field, and it's a useful skill-set even if the person has no intention of ever becoming a manager.
People Management
Hiring, performance reviews, salary adjustments, layoffs, firings, etc. These are the sole responsibility of the Manager, and cannot be delegated to someone else on the team. If you have delegated these responsibilities to someone, congratulations, you have promoted them to management!
One small area where you can delegate is in the hiring process, specifically in initial technical interviews (usually phone screens). If you trust the judgement of a senior team member, they can conduct these interviews for you, but the ultimate hiring decision still rests with the manager, so the onus is on you to conduct later interviews to solidify your own opinion of the candidate.
What about Technical Leadership?
You'll notice that I have yet to say anything about Technical Leadership. While technical skill is often what gets people noticed for advancement in the first place, Technical Leadership is not the primary responsibility of an Engineering Manager. Instead, the managers promotes and focuses those who are providing technical leadership.
However, even if a manager is not a leading technologist, technical ability remains an essential skill for their job performance. Primarily, to be effective, a manager must be technical enough to earn the respect of the engineers who are the technical leaders of the team. They must be able to communicate technical ideas effectively, and they need to have honed a "bullshit detector" with regards to the technical ideas of others -- even the most seasoned software professionals need someone else to call them out when their ideas are half-baked, and if their manager can't do this, those half-baked ideas will often make it into production.
Delegate, Delegate, Delegate
As it turns out, an Engineering Manager can delegate quite a lot -- almost everything, if needs be. I would actively look to delegate some Project Management and Mentorship in almost every situation, and larger companies especially will provide extensive support for both Project and Process Management.
Communication (both inter-team and intra-team) is harder to delegate, and I wouldn't do it long-term unless I was looking to put someone on a management track, but it's there if a manager is overloaded and forced to delegate, and it's always a good idea to have redundancy when it comes to communication.
Moreover, for those software engineers who display some talent for leadership but specifically do not want People Management responsibilities, it's worth considering that you can delegate to them almost all of the responsibilities of an Engineering Manager without actually making them a manager, and sometimes this is the best way to make a situation work. The danger here, of course, is a manager who delegates too much without making the delegate an actual manager may become detached from the team, and the team will wander adrift, lacking proper leadership.
Every situation is unique, and a manager must display judgement and some feel when choosing what to delegate to whom and when. But by breaking down these responsibilities into relatively distinct, grok-able categories, I believe a manager can make such decisions with more intention behind them, and provide more guidance for ownership of those responsibilities by those being delegated to, thus making such decisions ultimately more effective.