What a head-of-engineering is meant to do?

Recently, a person who was earlier part of my team and is transitioning to a head of engineering role asked what a head-of-engineering is supposed to do. I did not have a ready answer. Even though I have played this role for few years before taking broader responsibilities, I had never really thought about the responsibilities associated with the role. I guess I just learned the responsibilities while growing into the role. As I look back, I see three broad responsibilities for a person in this role.

Before we get into the responsibilities, let me first define what I mean by head-of-engineering. A head of engineering is a person responsible for the end-to-end lifecyle of a customer. In companies that have multiple lines-of-business, it may be the person with engg responsibility for a line of business (e.g., flights at Makemytrip OR advertising at Airtel); in smaller companies it may be the CTO. The person should NEITHER be a person responsible for multiple lines of business NOR someone who owns only a part of the customer journey - if a customer faces a technical pain, this person is responsible for fixing it.

With the basic definition out of the way, let us get into the responsibilities. Many engineers believe that the role of a head of engineering is to maximize engineering throughput. That is an important outcome but it is important to understand the things you need to do well to achieve the outcome. I broadly see the following things you need to do well to succeed in this role

• Integration architect - A line of business will often have multiple applications that need to work together to service a customer. Each of these applications may have their engineering leads and dedicated PODs/squads. However, all of these applications and services need to integrate together in a seamless fashion. If one of the services makes a change, someone needs to assess its impact on other services and on the overall customer lifecycle. This person has a visual map of the entire customer journey and how all the applications integrate together. If there is an operational problem, this person will be able to quickly isolate the issue and have a remediation plan. This person is, for all practical purposes, an integration architect. Since many companies do not have a separate architecture team, an important responsibility of the head-of-engineering is to play the role of an integration architect. If you can not play this role well, you will fail as a head of engineering.
• Team Culture - A head-of-engineering represents the team externally and reviews the work internally. Everyone will follow their cue. Even if there is a CTO, the amount of time the CTO will spend with engineers is way too less. If you want a team that has a high degree of ownership, is metric-driven and believes in direct communication, the head-of-engineering needs to showcase these values every single day. He/she needs to push the product managers hard to provide metrics for the projects they bring, he/she needs to own the failures of the team as his own, and avoid indirect gossip favoring direct communication. A head-of-engineering who blindly executes on deliverables without questioning the work they are doing will build a team of foot soldiers. The foot soldiers will execute well but when something goes wrong due to a wrong call or a missing use case, a blame game will start. The RCA will conclude that every one did what they were supposed to do, while the customer suffered.
• Engineering process - Many head-of-engineering only focus on throughput and attempt to achieve high throughput using a process (sprint plans, daily scrums, retrospectives etc). The throughput is usually defined by the number of points delivered every sprint. The engineering process needs to be defined in a way that complements the metric-driven culture. A head-of-engineering needs to define a process that optimizes the throughput both in terms of points as well as the metrics that are achieved. The process needs to not only focus on engineering working on their tasks diligently but on ensuring the appropriate tasks are picked; tasks that have high impact, tasks that have fewer dependencies; tasks that are completing a flow. The process needs to minimize work-in-progress, minimize the number of hand-offs and iterations. Running a team hard or attempting to reduce the story point for a task will only increase throughput marginally; ensuring clarity on tasks and minimizing wasted effort will drive much higher throughput and also keep the team motivated.

In my own experience, many folks in head-of-engineering roles consider the engineering process as a core responsibility. However, they don't often own the culture. They also don't go deep on the technical side and are unable to play the role of an integration architect. If you are getting into this role, you need to pay equal, if not more attention to these two aspects; otherwise all you become is a glorified program manager.