Staff vs Principal Software Engineers

As a follow-up to my last post Designing Engineering Culture @ Shutterstock, I wanted to get a little bit into some of the rationale behind the decisions that were made. As a quick refresher, here’s the general track framework: Shutterstock's New Software Engineering Career Paths & Tracks

I’d like to drill a bit into the bifurcation that we created as part of the IC Track at Shutterstock, specifically between team and organizational dimensions. At a large number of places I’ve worked, there have always been IC engineers that were exceedingly good at solving deep technical problems in their domains and products of choice, but, at the same time, had little to no interest in marketing themselves outside their respective teams or increasing their visibility beyond the work that interested them (coding) done. One of the common expectations that exist today is that in order to move beyond the Senior Software Engineer level, you must shoulder greater organizationally-scoped initiatives, have broader visibility across the org, and generally work on projects that impact more than a single team. Most of this effort means less time doing what they do best, however—coding.

I found that requirement as anachronistic as the ritual of promoting top engineers to management, even if they don’t have a the requisite people management skills. A more humane, and individually-aligned career track should provide career support based on individual needs, skills and interests. That’s not so say that roles with broader mandates don’t exist—they do, as Principals in a parallel track to the Staff path. In terms of leveling, hierarchy and compensation, this means we’ve aligned Staff = Principal, Sr. Staff = Sr. Principal. In this model, being a Staff Engineer does not mean you don’t have broad, organizational impact or visibility, merely that the proportion of explicit mandate in those areas is less than that of a Principal. Principals just spend more time working on problems that may span across the org and less at the product engineering level, though that proportion can easily shift from one end of the spectrum to the other depending on current business needs.

My personal opinion is that a well-conceived career development framework accounts for the obvious, broad differences in individual personalities and career aspirations, while supporting and cultivating the growth of all talent within the wider organization.

comments powered by Disqus