Designing Engineering Culture @ Shutterstock

There are as many ways to build software engineering career ladders as there are ways to skin a cat, so to speak. Based on the existing landscape of tech companies and their respective takes on this well-worn, but organizationally-bespoke subject matter, the industry has made positive strides. As technology leaders we continuously reassess existing models, both internal and external, to ensure we have the right frameworks in place to recruit, develop, retain and grow talent, so I wanted to write about some changes we’ve recently implemented at Shutterstock , but before I write about those, let me cover a little background.

Prior (Ground)work

One of the most notable, relatively recent enlightenments to engineering tracks is the splitting of management and individual contributor tracks within software engineering as parallel, and not sequential. It once used to be that when an engineer reached a certain level of competence, they were required to go into management to progress or see their careers more or less stall. Given that most people (especially the majority of engineers in my personal experience) are not suited for the demands of people management, this change was a momentous (though with the benefit of hindsight, painfully obvious) advance. Now, though everyone still begins their careers as software engineers, after a certain level, a fork in the path appears where an engineer, should they be suited for the role and selected by the powers that be, may embark upon the management track or remain in the individual contributor path which continues before them.

So now we have parallel individual contributor (IC) and management (M) tracks at most large tech companies.

Individual Contributor (IC) Track

When we look at the IC track, progress therein is usually linear in a single dimension. For example, an engineer would progress from L1 through L5, etc. over the course of their career. In many places, as you go up the ladder, this not only means that you’re getting progressively better at the specific competencies and expectations of you as a software engineer, but also means, especially after the Senior Engineer level (i.e. L3), that you may need to acquire skills that may not be in your interests or wheelhouse.

For example, expectations for L4+ (i.e. Staff Engineer+) come with the implication of broader focus on more cross-cutting concerns across the engineering org, as opposed to going deeper into the product engineering stack for their team; this almost always means less coding coupled with i) public speaking, ii) mentoring, iii) cross-team collaboration/communication, iv) taking on broader, organizational initiatives (e.g. architecture reviews, process design, general “thought leadership”) and, again (and importantly), v) less coding.

From my own experience along with anecdotal evidence, not everyone is suited for or interested in leading organizational initiatives and, as odd as it was in forcing engineers to become managers in the past, it seems just as odd to take the engineers who are best at what they do (i.e. coding) and make them do less of that, just because of arbitrary career definitions which fail to account for more nuanced differentiation between individual interests. At smaller companies (i.e. startups), you have no choice but to be a generalist and work on everything that comes your way, but at larger companies, specialization becomes an imperative and, at far as Shutterstock goes, existing career models did not satisfy the specific needs of the organization.

Management (M) Track

The entrypoint to the engineering management track typically comes after the Senior Engineer level (i.e. L3), as a promotion up and out of the IC track into leadership, which implies that an entry-level manager is on par with L4 engineers in terms of experience. The nature and roles of Engineering Managers varies widely across the industry, however, fundamentally, the defining characteristic of the role is that of being responsible for managing people. The extent of their day-to-day technical involvement varies widely with companies, however, the explicit mandate of leadership positions broadens further along the management track. As with the IC track, I believe there’s clearly a difference between types of technical leaders that we’ve sussed out in our new tracks.

Building for Purpose

At Shutterstock, individual career development was historically overlooked for various reasons including frequent technical leadership turnover coupled with a host of other organizational factors. Even up to a few months before my arrival in late 2017, some engineers did not even have titles or levels associated with their roles, which meant they had very little idea of where they were career-wise (obviously) or how to get to the next level. At the same time, most engineers, if they had titles, still weren’t aware of any systematic career path through the org. This naturally led to non-trivial retention and growth challenges which these changes are intended to counteract.

What We’ve Done

We launched Shutterstock’s new career tracks framework across the Engineering organization last week. In our case, we had a need for deep, product-level and broad, cross-team/organizational specialization. In order to support growth in what we see as clearly differentiated specialties, we created two distinct and parallel paths within the IC and management tracks, corresponding focus at team or organizational levels. This is best illustrated with a diagram:

Shutterstock's New Software Engineering Career Paths & Tracks

IC Track

This does not mean that an IC is 100% focused in one area at the expense of the other at L4+; it’s more about proportional allocation of focus over long periods of time (e.g. calendar yer). A Staff Engineer is a deep product-level expert, however, that doesn’t mean they’re not involved in broader initiatives outside the team. By the same token, a Principal Engineer is not myopically focused on organizational initiatives alone; they still belong to teams and contribute to team initiatives regularly, but that is not the overarching focus of their attention. This also does not preclude the ability to switch between Staff and Principal paths once an IC has committed to either route.

M Track

We’ve adopted a similar bifurcation with the leadership track, where we’ve identified team- and organizational-scopes for career development therein. Entry-level engineering managers (M1—a level which is equivalent to overall experience as a Staff or Principal) and more experienced engineering managers (M2) are classified as team-scope leaders. We expect our leaders to have attained a senior level of technical expertise before taking on the challenges of leading engineers. Though we expect our Engineering Managers to be technical and present as technical advisors/coaches, we don’t generally expect them to write code or make day-to-day technical decisions for their teams; their responsibilities are primarily concerned with maintaining, cultivating and growing healthy engineering teams along the dimensions of individual skills growth, project execution, job satisfaction and career development. At the M3 (Director) level and above, the mandate of the leadership becomes more organizational (i.e. across more than one team) and typically involves managing managers. This track goes to M5 (VP).

Breakpoints

We’ve also introduced the concept of “breakpoints” in career paths. These are levels at and after which a given role is terminal. In other words, once reaching a breakpoint, an individual can conceivably remain there for the rest of their careers. However, up to a breakpoint, all individuals are expected to continue growing professionally through their respective tracks. This concept supports individuals that, for reasons of competence, ambition or outside commitments (e.g. family), are not willing/able to make the contributions necessary to advance to the level above a given breakpoint level.

Conclusion

I’ve generally described the structure and reasoning behind the new career development framework at Shutterstock, but have not gotten into any specifics around implementation details. There’s obviously a lot more to the framework, so I may cover more detail in a future post.

comments powered by Disqus