Maximizing long term impact as an engineering manager

Smart engineering managers foresee what actions maximize long term impact and prioritize those actions accordingly. That is challenging to pull off in practice. The linkage between an EM’s immediate action today and its ripple effect a week, a month, or year from now can have little connection to time spent on the act itself. It also commonly lacks a paper trail or concrete “proof” of action taken. And managerial outcomes often depend on the fickle influences of human psychology and plain luck.

I’d argue individual contributors, a.k.a. developers have an easier time making the connection between action today and impact tomorrow. Most engineers deep in code have clean artifacts of their work to show progress. Developers edit files, merge pull requests, close Jira tickets, and pass automated tests. When they ship features, there’s often a tangible outcome, be it a new set of UI, a performance boost, or a database migration. Past performance across similar technical challenges becomes a predictor for future velocity. This factor is why more experienced engineers become more accurate at making estimates for their work, and why task estimation is such a core tenet of software development.

Contrast a developer’s day to day with your average EM. Everyday actions may include:

  • Assigning engineers to projects, with one eye towards productivity, one towards individual career growth.
  • Serving as the tiebreaker to competing technical approaches within the team.
  • Giving feedback to a report in a one on one.
  • Making an off the cuff high level estimate of the time necessary to complete a feature in a cross-functional meeting.

These actions rarely leave many tangible artifacts of effort for the exception of a few emails, Slack threads, or meeting notes. The less reference material to learn from, the harder it is to make the right managerial decision the next time.

Add to this the wide range of fungible human factors that play into the effectiveness of almost any action an engineering manager makes. For instance, say you’re giving feedback to a report. The quality of feedback itself (actionable, immediate, specific), of course, plays a factor in its impact. Then there’s the element of social standing between manager and report; a lack of trust or respect from either side can greatly dampen how feedback is received. Luck matters as well; if the report is having an off day for reasons outside of work, even the best feedback can get lost in the shuffle.

If we’ve established there’s an extensive amount of unpredictability to impact tomorrow, and the data illustrating the past is limited, how do you get better? Start by setting aside an extended block of time to reflect on your reports’ career trajectory. I like to focus on bursts of high productivity or periods where you find your reports had an opportunity to level up in their career, like an extended mentorship session, new ownership on a technical project, or a noteworthy fix on a difficult bug. Generally, all of these achievements have definite, concrete evidence to latch onto.

Once you’ve found a report’s highlights, work backward to find connections to the actions you took. Remember the linkage is generally indirect, subtle, and may not have the clearest paper trail. For instance, one of your engineers independently authors an engineering design document for the first time. Perhaps the connection is project related: a month earlier, you purposefully put senior engineers on other critical work to give the report extra bandwidth to ensure she had extra wiggle room to experiment with the doc and succeed. Or it is mentorship: six months earlier, you had the report own small sections of an engineering doc with a senior DRI overseeing the larger effort and providing feedback. Or maybe budget: you petitioned the higher ups for a learning and development budget per engineer. The report invested in an online writing course to learn how to craft an argument succinctly before tackling an engineering doc on their own.

From my experience, when an action you take is linkable to not just one, but multiple outcomes among your reports, you’ve found a pattern. Use those patterns, in turn, to help isolate actions that can deliver meaningful, long term impact for the team.

At a glance, this sort of backward reflection can feel tenuous. Engineering values the concrete and linear, and the outcome of such an exercise rarely is. But stick with it. Assume you’ve had a genuine impact in your reports’ future. The alternative leads to imposter syndrome, which can affect even the most senior of managers. By looking back at the influence you’ve had at the managerial level, you’ll make better decisions moving forward.