The reality of being a director of engineering

7 minutes

Being a director means juggling business impact, influence, and engineering manager growth. How can you do it all successfully?

During a recent skip level with a senior engineer, I received the question, “What does your day-to-day actually look like?” As a director of engineering, my role is somewhat nebulous to the individual contributors (ICs) in my organization. They see me during an all-hands or on Slack, but unlike their manager, I’m not visible every day. 

In my days of being a manager, I was still in the thick of it, handling standup, fixing bugs, and providing input on software design. The move to director disconnected me from the day-to-day of software engineering – a gap that will only increase the further up I go. This disconnect from the software engineering discipline is a new challenge for directors and requires a large number of new skills that aren’t always visible at a glance.

Finding the balance between business vision and operational tasks 

Directors are the glue of an organization between the tactical and the strategic. On the tactical side, we could be leading a cross-functional initiative, defining a new incident response process, or laying out our observability goals. However, there is an expectation to think more broadly about how this tactical work fulfills the mid to long-term strategies we (or our VP and CTO above us) have laid out for the organization. This requires us to always be bridging that gap, understanding company vision while being able to distill that into tactical units of work.

In this position, the size of the company significantly impacts your role. In smaller companies, you may not have a VP or CTO above you, requiring you to be more strategic in your work. In larger companies, you may find the opposite to be true. Similarly, in larger companies, you may have a more focused scope and technology whereas in startups a director could oversee an entire engineering organization. My expertise lies within companies ranging between 20-150 engineers, particularly during that transition from a startup to a “small” enterprise.

Building up people and processes

The director’s goal of making an organization’s vision a reality requires a lot more focus on people and processes. Efficiency and effectiveness are two words that get thrown around a lot and finding ways to improve those aspects constitutes a large portion of my day-to-day work. 

Hiring in talent 

Making sure that people and processes are running at their most optimal starts with strong hiring of both engineering managers and ICs, growing a talent-dense organization in the process. 

Strong hiring decisions can be different depending on the team but should be rooted in the vision and values of the organization. To do this, you need to have a well-documented and understood hiring plan. Hiring is another example of taking the organizational vision and strategy, and distilling it into an interview plan and process that lets you hire the right people.  

Strong engineering managers are integral 

Beyond hiring, your success as a director is dependent on how well your team works together. When thinking about a strong manager, the first skill I would highlight is healthy communication and the ability to manage up, specifically around project impact, achievements, delays, and what’s coming next. This information will feed into a lot of my work which ties different projects across different teams into a collective goal, so it’s necessary for me to have that context. 

In my organization, engineering managers are also accountable for the technical services of their teams, ensuring they are of the quality required by the business. Different products and services may require different error budgets, availability numbers, and architectural maturity but it is up to the engineering manager to ensure these needs are being met. While managers don’t need to be the most technical person on the team, they must be able to lead the architecture in the right direction or delegate to trusted engineers. Inheriting technical services and products that are difficult to maintain or poorly architected is a failure of the leadership, not the engineers who built it. 

Engineering managers have to possess strong project management skills to deliver on promises while juggling priorities and ensuring career progression of their reports. 

It’s important for engineering managers to deliver on these skills. Some managers may need extra support in this area, especially if they are new to the role. In those cases, I generally have more frequent conversations and meetings with them. We’ll talk about resourcing, limiting projects in flight, and how to handle their agile ceremonies. We work together to ensure they are properly communicating timelines, status, and what’s coming next. If they continue to struggle with execution, I may need to step in, diverting my focus from strategic priorities, in turn, reducing my influence, and preventing me from making a larger business impact.

Helping your teams in their professional development 

The growth of my team and department is something that is always on my mind. Like many leaders, I continually try to find places for both my managers and ICs to stretch, grow, and learn new skills. In comparison to my days managing ICs, I have found that providing direct feedback to my managers and seeing their granular successes is much harder. This is because we don’t have daily touchpoints and I’m not able to see their tickets on a Jira board as IC managers often do. To help make up for this limited visibility, I have a standing agenda topic in 1:1s with my reports to discuss achievements. Even with different tactics and leveraging 1:1s, finding those areas of feedback can be more difficult as a manager of managers.

Successful processes require careful thought

As a director, finding improvements in our software development life cycle (SDLC) and my organization’s agile process is always top of mind. This is partly due to my passion for the subject and implementation of an effective and efficient software development life cycle. I view a strong SDLC as one that values continuous integration/continuous delivery (CI/CD) and small units of work. Having small units of work (or smaller tickets) can allow the teams to work quickly, reduce pull requests (PRs) – thus lower PR times – and experiment. 

If the workload is too big or takes too long to integrate and get to production, it can hinder a team’s agility and ability to respond to change. By establishing and measuring metrics like cycle time, PR time, and deployment times we can identify bottlenecks and address them. This allows us to be objective in process changes and measure whether they are having a positive effect. Without that data, ICs and managers can be skeptical of change and may feel a proposed improvement is subjective. This can limit the advocates and champions we have to influence the organization.

Influencing the organization

Although we focus a lot on people and processes, directors are not and should not be in the weeds making technical decisions. We have to think above that. However, this comes at the price of requiring others to follow through with our ideas, processes, and initiatives. To do this successfully necessitates having influence within and outside of your teams. Internally, your managers and technical leaders should be the champions of the process changes you want to make. Since they are in the day-to-day of the organization, they will need to be the individuals who enforce and advocate for a director’s ideas, processes, and initiatives on the ground level.

To build influence outside of the engineering sphere, we must get out into the larger business and understand other teams’ needs and challenges. By understanding other teams’ challenges, for instance, the customer service department, we can help uncover inefficiencies between teams. This can lead to new efforts to improve overall organizational efficiency. One key piece of feedback I receive from my CTO on a regular basis is to talk to my peers and executives in other departments. To ask questions, learn how they work, and how they currently interact with engineering and product development. This has led to me focusing on areas where my skills are needed most (like driving cross-team standardization), building trust, and improving cross-department collaboration and processes.

Job satisfaction as a director of engineering 

Being a director doesn’t include hands-on keyboard work like when I was a software engineer. We won’t be the person writing the cool new feature, which is a change most leaders have to go through, but we can enjoy watching others become more effective. The director of engineering role brings its own sense of satisfaction, and for me, those are process improvements, career development, and watching our engineers and teams achieve their goals.