Hi folks,

This is the weekly digest for my blog, Irrational Exuberance. Reach out with thoughts on Twitter at @lethain, or reply to this email.

Posts from this week:

- Interesting work happens at the edges.
- Tech Lead Management roles are a trap.
- Pacing and isolating change.

Interesting work happens at the edges.

Many engineering managers become obsessed with the transition to managing managers rather than managing a team directly. I’ve seen that pursuit of managerial scope become almost an obsession for some folks. That’s a shame, because group management is a very different job than team management, and is often both less rewarding and less likely to facilitate ongoing learning. In particular, I often get email from folks considering joining a hypergrowth company in pursuit of their first group management role, and my advice is, in its most concise form: Do it if you must, but be cautious.

There are only three paths to group management roles: getting hired at another company that has a group manager role, replacing an existing group manager within your company, or working at a growing company that frequently creates new teams. Companies hiring externally want to “hire in experience” and rarely hire folks without prior group management experience into group manager roles. Replacing an existing group manager within your company is a real option, but the timing is uncertain: it depends on an existing group manager leaving. This process of elimination leads many folks to pursue third path: joining a fast-growing company whose growth creates an ongoing demand for new group managers.

When I was considering what to do next after working at SocialCode, the company that acquired Digg, I was frustrated that I couldn’t get interviews for group manager roles. I was fixated on the pursuit of managerial scope, and that ultimately became my deciding factor in joining Uber. The organizational pyramid scheme of hypergrowth is hard to resist. Six months later, I was managing a team of teams–goal accomplished. It took me a while longer to realize that I didn’t care for much of the work.

Fast growing companies generate a huge amount of change, and the primary function of group managers in those organizations is to absorb change effectively. However, they often lack much control over that change, and end up with the underwhelming choices of pushing the chaos to their team or personally absorbing it. The former violates the manager’s pact–you’re there to help–and the later is a reliable path to burnout.

Learning to manage change effectively is an essential management skill, and you can learn a great deal navigating a chaotic organization, but you can only usefully learn the same lesson so many times. Because the other group managers around you are similarly consumed by change management, the role often settles into an odd mix of contentious, exhausting, and boring.

That doesn’t mean you should never take these roles, there are many exceptions. If your leadership is adept at change management, you’ll find working in their organization to be a rare combination of sustained growth and impact. Similarly, there are periods in your career where the financial and prestige advantages of these roles may be a worthwhile exchange for being grist.

One related observation is that there are many interesting long-term jobs at hypergrowth companies, just not in group management. The most interesting work at hypergrowth companies always happens at the edges. If you have the opportunity to be a senior leader at such a company, then you’ll be stretched in remarkable ways. The second most interesting jmanagement jobs are as a team manager. As a team manager, you’ll be directly involved in solving a critical, rapidly changing business or technical problem–as the constraint evolve, you can keep learning indefinitely. If striving for perceived career growth is preventing you from considering team manager roles, you’re doing yourself a disservice.

Tech Lead Management roles are a trap.

The tech lead manager role is often presented as an easy on-ramp to team manager, but my experience is that being a tech lead manager is a considerably harder first management role than pure team management. Rather than an on-ramp, tech lead manager roles are usually a trap for first-time managers.

The theory of the tech lead manager is that you find a capable engineer who is defacto leading part of the team, and make them the official manager for that sub-team. Because they're already defacto doing the work, it can seem like a formal recognition of what's already happening. Because they'll be working with a small team, it'll be easy for them to keep contributing their technical strengths in addition to spending a bit of time on people management.

In practice, these roles usually work out a bit differently. Your team is usually too small to focus exclusively on managing people and execution. Typically you're the senior-most member of the team, which requires that you stay heavily in the technical details. You're also expected to make direct technical contributions, which mean you need to structure your time to have extended blocks of uninterrupted time. It's hard to balance these constraints, and it's even harder to balance them without falling prey to the most common failure mode of new managers: micromangement. (If you've ever gotten the advice that "managers shouldn't code," rest assured that advice isn't really about whether mangers should actually code, it's just a clunky preventative for micromanagement in new managers and an equally clunky preventative for senior managers who've forgotten how to listen to others.)

The reality is that when you're trying to learn something brand new, like team management in this case, you're almost always going to be better off getting to focus on that area. In a team management role, you'll be encouraged to lean on your team for technical leadership rather than fulfilling both roles. Folks attempting to fulfil both often retreat towards work they find familiar, which typically results in tech lead managers who forget to perform the management part.

Another problem with the split focus is that the tech lead manager role is a bit of a dead end. Down the managerial path, the evolutionary step is towards group management. Down the technical path, the evolutionary step is towards staff engineer. Splitting your time across both functions isn't ideal for pursuing either path, and unfortunately it's the rare role and organization that supports ongoing growth for folks in tech lead manager roles. They do exist, but they tend to be a bit specialized, for example working on infrastructure efficiency, performance engineering, or applied machine learning.

Tech lead manager roles are not always a bad choice. If you've built up your experience as both team manager and technical contributor, then sure give it a whirl if it's what checks the most career boxes for you, but I do consistently recommend against folks starting their management career in such a role.

Pacing and isolating change.

One of the downsides of being a group manager is that you spend most of your time on change management, but it must be said that organizational change management is a pretty interesting topic, particularly within a fast growing company.

Gelled teams–teams that know how to work together effectively–are considerably more effective than newly formed teams, but can be difficult to maintain when you’re hiring rapidly. One strategy for allowing teams to gel is to have a predictable fast-slow hiring cycle, where you hire rapidly for 6-12 months followed by a 6-12 month consolidate phase where teams gel. Teams hire towards a steady state where they can gel, spend some time gelling, and then switch back into hiring afterwards.

Many organizations do an unpredictable fast-slow hiring cycle where headcount appears and disappears unpredictably, and while it appears superficially similar, unplanned changes disrupt organizations as they find themselves optimized for an existence they’re no longer heading towards and end up shifting teams to adapt to their new constraints. This adaptation shuffles folks across teams and resets the gelling clock. This scenario is even worse than constant hiring, because you get fewer gelled teams and fewer trained engineers. I guess your salary expenses are lower, but you’re still accomplishing less with that budget.

The strategy of predictable fast-slow hiring cycles is somewhat hadr to pull off due to structural constraints. First, you probably have a recruiting team and it’s very difficult for them to surge and retract their team along with those cycles without either overworking the booms or overstaffing the busts. Second, if your busines is growing very quickly and outpacing your engineering organization’s bandwidth, you’ll find very little sympathy from your leadership team when you tell them that you’re “trying to gel the teams.” That’s nice, now hire faster.

Fortunately there’s an easy solution here: isolate hiring at any given point to a subset of teams, then switch hiring to another subset while the earlier teams get time to gel. Avoid keeping any team in the hiring seat for too long, and you’ll get the benefits of pacing change without the organizational drag that comes from practicing it at an organizational level.

This approach of isolating change works for a lot more than hiring, try it for handling emergency projects, new product launches, whatever your organizational sources of churn happen to be.

That's all for now! Hope to hear your thoughts on Twitter at @lethain!