But they exist to guide the technical direction of the company. It’s harder to pin down the day-to-day execution of this role because each person’s journey depends on their own expertise, and how they can apply it to help the business achieve its goals. The reporting line varies from one company to another, but they have a certain level of autonomy: usually, they report to a manager but control their own day-to-day activities. Staff engineers tend to work directly with permanent teams as well as pairing with other temporary project teams. And they give technical performance reviews, aiming to improve the technical capacity of the entire engineering organization. They also play an important coaching and mentoring role by sharing best practices with other engineers and creating new opportunities for their growth. The percentage of their time spent coding differs from one person to the next, but averages around 20%. They support the organization by providing context and technical direction, defining technical specifications, and documenting processes. These folks lead deep, complex, or high-risk technical projects, and control the communication around them. As well as technical strength, core leadership skills such as critical thinking, judgment, listening, empathy, and communication are essential at this level of seniority. Staff engineer is the first IC leadership position, a level above senior engineer. To find out what IC leaders do have in common, LeadDev spoke to a group of staff, principal, and distinguished engineers and asked them to describe their own roles and responsibilities. There’s a wide variety of the same role across different organizations, making it hard to identify patterns around job scope, skills, and experience. It’s less established or well-documented than the path for engineering managers, with all tech companies approaching titles in their own way. 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.Talking about leaders in the individual contributor (IC) path can be confusing. 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. 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. In terms of leveling, hierarchy and compensation, this means we’ve aligned Staff = Principal, Sr. 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. A more humane, and individually-aligned career track should provide career support based on individual needs, skills and interests. 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. Most of this effort means less time doing what they do best, however-coding. 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. 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).
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.
As a quick refresher, here’s the general track framework: 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.
0 kommentar(er)
