Engineering Management, in my own words
What is the role of an engineering manager?
At a high level, it's to deliver value, keep the engineering team engaged, and retain and grow direct reports. But let's unpack this a little further.
This means ruthlessly prioritizing while simplifying complexity and promoting deep work. Tactically, an effective EM knows which architectural and project considerations can be made to increase the throughput of delivered value as the organization pivots and scales.
As a leader, the EM sets the pace for others to follow and models the organization's values. The EM also must win the team's and their peers' trust and be trusted to make wise and quick decisions when needed.
An empathic EM cultivates a high-trust environment and knows how to get the most from their team. They are practiced in delegation and coaching, and they give quick and effective feedback. They promote deep work, and they appreciate the role of developer experience in a highly effective team.
In addition, the engineering manager is also the primary point of contact with many stakeholders across the organization, working collaboratively with product managers, other engineering managers, and domain specialists. The engineering manager presents frequent and disciplined communication with stakeholders, directors, and executives, keeping confidence high and surprises low.
How do you measure your engineering team?
Maybe more than anything else, the meat of being an effective EM is a healthy obsession with metrics – leveraging data for measurements in all areas. For example, here are just a few areas that jump to mind:
- Establishing quantitative criteria for business objectives and the continued measurement of progress towards said goals, such as via KPIs or OKRs.
- Service-level indicators to form service-level objectives, such as expected response times or cycle times across a range of percentiles, to know a service is performing as expected and without degradation.
- Internal measurements correlated to team velocity, perhaps measure improvements around previously-identified bottlenecks such as code review, the time it takes to run a test suite or the number of specific incidents per week.
- Weighted decision matrixes for capturing backlog items, technical debt, code quality and design complexity. For example, quantifying how decoupled a module is from the rest of the system or how many dependencies a given module has.
- Individual performance measurements to facilitate promotions and growth goals for direct reports. For example, being able to draw attention to an individual's contributions in crucial areas, the quality of the contributions, and the correlated impact on the business.
- Capacity estimates that influence architectural and infrastructure decisions. For example, being able to accurately estimate the load and utilization of a system so that it's used optimally under regular conditions while also scaling to peak conditions.
At a business objective level, I use the OKR framework to ensure that my team delivers the right value at the right time and is moving in the same direction as the organization. At this level, I tend to use a mix of leading and lagging indicators. If a team is having difficulting hitting leading indicators, the lagging indicators will be even more challenging. More importantly, leading indicators enable faster iteration.
I work more tactically at the team level, employing a "theory of constraints" approach. Instead of specific generic engineering metrics (number of commits, DORA metrics), I look for bottlenecks, then figure out a metric that correlates with unblocking, and work toward that. For example, in my previous role, a team was bottlenecked on incidents causing rework and context switching. I identified "incidents per month" as a metric and strategized with the team for solutions, considering process change, architecture change, and additional testing. Later, the bottleneck moved to code reviews, and the focus became reducing the cycle time on a code review.
Throughout my experience, I've found using a mix of high-level and low-level objectives, and a mix of leading and lagging indicators, enables a predictability in software management that I really enjoy.