Organizational Flexibility

Recently, I’ve been helping our company make a handful of business-critical hires for the team, one of which is an open managerial role in our New York office1. I’ve long believed that hiring is a core management responsibility, and I’ve grown to enjoy chatting with candidates about what we do and whether our environment lines up with what they’re looking for in their next job. Of course, we’re also quite fortunate in that we’re still in a position to expand the team and fill in some of these personnel gaps.

In some ways, managerial hiring is even more of an art than evaluating individual contributors (i.e., software engineers). From my own experience interviewing for managerial roles at various companies—and in having hired a bunch of managers myself—a candidate’s style and cultural alignment become much more important factors in making a hiring decision. Different teams intra- and inter-company legitimately have a unique set of expectations for their managerial function, which ultimately means that someone doing the same thing can thrive in one setting and struggle in another. The corollary to all of this is that I’ve learned to not take offense when I’m declined a role, and I message my candidates the same; the bar for effective managers is less a line to cross but more a fuzzily-defined shape to fill.

Anyway, in a number of conversations with candidates these past few weeks, I’ve noticed that many have been asking about how hands-on we expect managers to be, specifically with the team’s technical output. Somehow, this has become the question that engineering managers revisit over and over again; a cursory Google search shows that everybody has their own take. My interpretation of the diaspora is that a universally correct response doesn’t exist, going back to the idea that each team has its own expectations and should filter for candidates that fit their profile.

My own actual answer, though, tends to be a bit more meta: since individual managers themselves have an idea on how hands-on they want to be, we should try to support that preference via maintaining organizational flexibility.

It starts with understanding individual motivations. Given that everybody is driven by different motivations, it stands to reason that whether they’re excited about the prospect of coding-while-managing can vary widely. If you’ve worked within engineering teams for a while, you’ve likely come across a few of these admittedly rough, and definitely not an exhaustive list of archetypes:

• Technologists, who really enjoy working with various languages and frameworks;
• Team builders, who end up finding ways to improve the overall team’s cohesion, culture and eventually output;
• Mentors, who add a lot of value in leveling up the people around them;
• Product evangelists, who are excited not only with the act of building products but how that product effects the end-users;
• Business experts, who care about how the work affects the bottom line

Reality, unfortunately, has a way of discounting individual preferences. Variables that tend to dominate the discussion isn’t whether someone wants to code, but rather—how many engineers report to them, how senior are those engineers, the manager’s own technical background, and how much (extra) time and energy they have. Most VPs don’t design their organizations where one of their managers has 20+ direct reports2, but sometimes that does happen, though natural people movements and reorgs and attrition and shifts in domain strategy.

It follows then that the best chance to honor a manager’s own preferences—and in doing so leveraging their own personal strengths—is to build in enough slack and capacity on the team to absorb organizational irregularities. Ideally, managers have enough reports to merit some level of reporting hierarchy, but not so much that it precludes them from other types of work, technical or otherwise. If someone leaves the company or transfers to another team or transitions to an IC, there should be enough bandwidth elsewhere to fill the gap in the short run, and a path to a more stable structure in the medium-to-long run. On the flip side, managers who want to remain very technical should be recognized and promoted on those efforts, not just on the size of their team.

In practice, this is of course easier said than done; most companies do not have excess management capacity waiting in the wings to be utilized. Despite that caveat, though, I still think it’s a useful framework in thinking about how different styles of management fit alongside each other; it recognizes and allows for the fact that an organization’s needs aren’t uniform and homogeneous. The baseline, ultimately, lies in the team’s output.