Career Advancement in Large Teams

I had a chance to chat with someone who recently joined one of the major tech companies1 as an engineering manager. Upon settling into their team, they were disappointed to learn that the actual work environment, plus the work itself, is much less interesting than they hoped for given the quality of the brand. They knew what they were mostly getting into—the interview process is a two-way street, after all—but didn’t quite appreciate the construct necessary for a large organization to function, and for themselves to advance its ranks.

Now, I don’t ascribe to the cynical idea that big teams are inherently bad because they’re full of people who are either too incompetent or disincentivized to produce efficiently. It’s tempting to slippery slope into the principle that growing teams is intrinsically undesirable; it sounds vaguely contrarian, a bit like the “best code is no code” mantra that actually requires mindful application but gets slung about like it’s deeply insightful. Yes, with added people comes more overhead in communication and coordination, and there’s no excusing actual dysfunctional organizations that allow that overhead to overwhelm actual useful work. But teams generally grow because the surface area of the product is genuinely increasing, and the additional product and technical complexity from more users and history and handling exponentially more edge cases necessitate more people. An operating system built by a single person is technically astounding, but it’s not exactly Windows 11 either.

The technologist in me believes that computing’s primary value proposition is speed coupled with infinite replicability, the combination that unlocks efficiencies wherever we can apply it to our lives. If we accept this premise, then the best and most interesting way to leverage software is at scale2, which then requires a team at scale, which means that anyone interested in impactful software needs to figure out how to navigate both the code and the team behind it. This is not news for folks who’ve worked in even mid-sized software shops, or who have advanced into lead engineering roles. Seniority within engineering teams tend to not depend solely on technical excellence, but allow—sometimes outright encourage—aspects of leadership and influence, even for individual contributors.

Layered on top of new role expectations is another challenge: small teams are run very differently than large organizations. This is particularly acute for folks who started with the former, but product success has necessitated growth into the latter. At some point, the rules for success start evolving; what made for a good engineer for a 10-person team will not be what enables someone thrive within a 1,000-strong engineering organization. For instance, someone who can jump on any issue and wear multiple hats, even imperfectly, is immensely useful for a small startup getting started. With a large team, however, there’s more room for specialization, both because the organization can afford to have them, and optimizations at the edges with a competitive advantage justified by scale.

An additional wrinkle that shows up with large teams is the introduction, integration, and eventual sublimation of formal HR systems. Regular performance reviews, managerial trainings, Performance Improvement Plans, career ladders, and the like: everyone grumbles when they’re introduced, but the battle-tested processes do provide utility and eventually everyone accepts them as a part of that overhead of teams. Don’t get me wrong, though—I’m a fan of explicitly creating structure and formalizing mechanisms around that structure, if the alternative is merely ad hoc frameworks cobbled together via reactionary decisions. The hard part is limiting the secondary unintended consequences that inevitably come from people looking to game the system.

Consider how management works for small teams vs. large ones.

Small teams don’t need much management to begin with, and it’s easy enough to shift a senior individual contributor into an equivalent management role when the engineers are themselves experienced and self-sufficient. The communications overhead is small with a tight-kit group, and people processes stay minimal as standardization provides little benefit with so few people. This is the early stages underlying the founding-engineer-as-CTO pattern, one that I encounter down the line when the team struggles to scale beyond this construct.

Large organizations have developed hierarchies, with a career ladder formalizing levels of management and plenty of managers within the hierarchy falling into those defined roles. Some will have been hired from other companies, so the overall management style will be a mishmash of experiences and processes3. Additional complexity comes from multiple factors in communications across teams and individuals, which itself becomes an entirely new set of work4. The rules for career advancement within management are now explicit, but have to now account for these added dimensions that result from scale, and generally makes promotions harder as a result.

It’s not entirely inaccurate to label all this extra stuff that comes from dealing with large teams as big company politics, as much of it does have to do with dealing with the vagaries of people. But knowing the meta-rules of the game enables strategy; one of the ways to scale with your team is to stay on top of—perhaps help define—the rules as they evolve with the team5.