Saturday, April 29, 2017

Framework for Assessing value of Software Engineers

How does the industry differentiate between a junior software engineer from a senior software engineer? What are the set of attributes we use to assess the value of an engineer so that they're compensated appropriately? 

These are important questions with answers that seem to vary wildly, but having some method of approaching these questions are crucial for arriving at a mutual agreement between the hiring manager and the engineering employee on the value that the engineer brings to the organization. That shared understanding is really important for initial salary negotiations and for maintaining a amicable business relationship overtime. 

As an engineer, even if the companies you're applying for jobs for or are currently working at have no structure for compensation, it's still in your best interest to know what your metrics are for measuring your value so you can improve more effectively. For example, if "leadership quality" is a valuable attribute in your system, then you can very intentionally seek out ways to acquire that trait. 

But what does this value structure for engineers look like? What are the metrics? 

It's easy to come up with a list of things that you think are most important, but they're not helpful if they don't align with what a company or the industry as a whole deems most important. You can't approach companies asking to be paid a million dollars a year just because you can recite methods in the C++ standard library. Impressive? Maybe. Valuable? Not necessarily. 

One way to approach this question is to simply ask hiring managers at top companies. Luckily, many great engineering teams have shared their views on this publicly. After looking at the engineering ladders / compensation structures for these companies and identifying commonalities, I arrived at this general structure for engineers:
  • Technical Expertise (clean and efficient code, language mastery, editor mastery, etc)
  • Qualities (leadership ability, communication ability, maturity level, etc)
  • Execution (planning ability, ability to get shit done, hitting goals)
  • Scope (area of impact, sub-component, component level, sub-system, system, business unit value)
Some companies also mentioned "experience" and "public artifacts" such as Github projects. However, I left those out because those only serve as signals for the traits we're looking for. When you look at someones experience, you're trying to get a sense of where they're at in terms of things like leadership ability or technical expertise. 

The specifics of each and how they're prioritized will vary by company and by industry. You don't have the time to evaluate every attribute that could fall under technical expertise, so as a hiring manager you need to identify which ones you value and come up with strategies to measure how different candidates stack up on that metric.

I highlighted scope in a different color because it's not so much a skill as it is an area of responsibility. Skillfulness in other areas does lead to expansion in the scope of responsibility for an individual within an organization through promotions, but they're still quite distinct from one another since it's not inherently a skill. Nonetheless, it's a key metric because increasing scope does have a significant and direct effect on your value. You can have flying marks in all three areas of technical expertise, qualities, and execution but work on relatively small system compared to other members of the organization with very little business value. 

How this generic structure helps engineers

You can use this list as a framework for thinking about your skill set in the context of your domain / industry. How do you think you rank on technical expertise? On your personal qualities like communication ability? Do you want to become knowledgeable about other critical parts of the system to expand your area of responsibility? If you find a weak area, start working on it. 

Admittedly, this structure isn't very actionable if you can't fill in the specifics. One particular area where finding the set of important skill seems daunting is in the area of technical expertise. A million things can qualify as technical expertise. For example, if you work in embedded systems, having knowledge of Angular.JS isn't as valuable even though it certainly qualifies as a technical expertise. The solution here is to focus on durable skills. 

Durability is a trait that exists for each skill and across skills. First, we'll look at an example of two different skills that differ in durability.

1. Knowledge of classic computer algorithms
2. Knowledge of the API of a brand new AWS web service

#1 is not likely to change. #2 is more likely to change. Whether or not #1 is directly useful to you is a different story. But it is knowledge that is more durable because the most efficient sorting algorithms don't change in a matter of weeks or even years. 

Lets take one skill: editor mastery. 

Durable skill: Mastery over a popular, mature, productive editor that is available across systems. 
Non-durable skill: Mastery over an editor that is buggy and works on a single platform.

Every time you decide to learn something, keep durability in mind. You're making an investment and you want to make sure you're investing in something that will pay dividends for years to come. 

Resources


1 comment:

  1. I was diagnosed as HEPATITIS B carrier in 2013 with fibrosis of the
    liver already present. I started on antiviral medications which
    reduced the viral load initially. After a couple of years the virus
    became resistant. I started on HEPATITIS B Herbal treatment from
    ULTIMATE LIFE CLINIC (www.ultimatelifeclinic.com) in March, 2020. Their
    treatment totally reversed the virus. I did another blood test after
    the 6 months long treatment and tested negative to the virus. Amazing
    treatment! This treatment is a breakthrough for all HBV carriers.

    ReplyDelete