This post tries to explain what engineering managers do, and what makes an engineering manager “great”. In my opinion, engineering managers have four roles. Great engineering managers excel at two of them, at least.
People manager and coach: This involves hiring, developing, coaching, and managing the team's performance. This also involves setting the vision for the team, setting goals and then creating a culture of accountability, including holding themselves accountable. The best people managers bring out the best in their employees, and take a personal stake in the career development, growth, and learning of their employees. The teams of the best people managers are characterized by high retention, high productivity (their teams get a lot done) and high work satisfaction. To borrow a sports analogy: a great people manager operates as a team captain, coach, cheerleader, and talent scout at the same time.
Architect (or Technical Lead): Engineering managers have to operate with a very good understanding of the architecture of what their team is building, and what their team owns. They have to participate in, influence, and drive their own team’s as well as partner team’s architecture. In many cases, they are expected to work across company boundaries. Internally, they are accountable for making their team’s code corpus reasonably future-proof. They are also accountable for the quality of code their team produces. The best in the role not only understand how their pieces work, but also how everything else is connected to each other. The teams of the best software architects are characterized by low product defects, low maintenance costs, and a high-availability service.
Project Manager: Engineering managers are accountable for their team’s delivery and the timeliness. As part of this, they are involved in their team’s planning sessions, they have ways to track their team’s progress, and they are also involved in retrospective sessions on making their team’s execution better. They also have ways to keep track on partner and dependent team’s work.
Product Manager: Engineering Managers should have the vision of not only the “what” and the “how”, but also of the “why” of what their team is building. As part of that, they need to understand the customer, how their product or service will get used, and how their product or service is being used. The best engineering managers happen to be an equal peer to their product manager counterpart, and provide inputs at the requirements and specification phase.
I have found these pillars to be true for an engineering manager of a team of six to VP of Engineering of a multi-site organization. As engineering managers grow in responsibility and scale, their “coach” and “product manager” roles become more important. They end up delegating many of the details of the project management and software architecture roles to their network; but focus more on the “systemic and risk-management” aspect of software architecture and project management. Most of my favorite engineering managers are excellent people managers and coaches, and then excel in at least one of the other three.
So, where does strategy and strategic thinking fit in? I belong to the school of management that believes that great execution is the best strategy. A great manager focuses on fine tuning their execution, and as part of that, they think about structure. For example, a software developer thinks about the structure of their code. At the design level, they think about the structure of their classes, or modules. At a much higher level, they think about the structure of multiple processes and components. Similarly, at a team manager level the structure is at the individual interaction level. At an organization level, the structure is about how teams interact with each other. At the company level, it is not only how organizations interact with each other, but how the external environment and the business environment interact with the company.
Great managers operate at the right structural level, and they not only think about the static structure but also the dynamic structure. That means, just having an organizational chart with roles and responsibilities (static structure) is not enough; what is equally important is how the components of the chart (the various individuals in the team, the teams in the organization, the organizations in the company) interact with each other as part of executing towards the common goal.
