Engineering calibrations: how senior are you?
How does the technical lead of a small startup get calibrated against a senior engineer within a larger organization? Do we discredit the engineering and team building achievements of the person in the startup because it’s not done “at scale”, or should the broader, “all rounder” skill set being deployed in the startup outweigh a more siloed set of responsibilities of the person at Big Scale Co. We could bike shed about it for a while, but it’ll likely resolve to the consultants answer of “it depends”. A better starting point might be “how do we define senior?”.
Note: You can calibrate your level using the evaluation tool here.
Ladders and expectations
Most mid-size and larger organizations have defined ladders for their technical and management teams. These ladders help set clear principles and standards for professional growth within an organization, something by which everyone can be fairly evaluated against and where lines can be drawn between sets of responsibilities.
These ladders often contain some of the usual defined skills traits like Creation, Leadership, Communication, Innovation, Ownership etc. each with their own nuanced description per organization. What’s not often appreciated though is that the technical skills begin to represent an increasingly smaller portion of the responsibilities per level on the ladder as they increase in seniority. Engineers moving up the ladder are expected, without much notice, to be actively acquiring a broader set of non-technical skills for their future roles and responsibilities. The technical skills are table stakes when approaching senior and beyond, now you need to bring mentorship, product management, getting alignment etc. to the table, as well as being a lead technical contributor.
So which person between startup and Big Scale Co. can best fit into a senior role at another company? Well, which has a more balanced practiced skill set? If you’re a phenomenal engineer but completely unable to mentor, guide and bring others along with you technically, it’s hard to make the case that you’re truly senior. Least of all, you’re not the type of senior which is best for your own growth. Your current role might need you to be that person who can pull a project back from the brink, but eventually, with a few years, you’ll be expected to have a more holistic skill set. There’s a risk that holding on to a current programming badge of honor becomes a signal of skills stagnation as you approach future more senior roles. There are diminishing returns on being purely technical.
Pursuing seniority
Becoming more senior is a process which requires intention, and for your own benefit, it should be self directed. Delegating responsibility for your professional growth to your manager isn’t in your best interest. Your manager should be leant on for support, guidance and feedback but leaving the whole definition of your path through the ranks of seniority up to them, is a bad idea. You need to define what skills you want, what kind of contributor you want to be, whether you want to pursue management, and then collaborate with your manager on how to get you there.
Know where you are, know where you’re going
Knowing where you stand, is the best point from which to make a go forward plan. Growing in seniority doesn’t have to be arbitrary, it’s not just a product of the years of your experience, but it does take an honest evaluation of where your strengths and weaknesses are right now, relative to your current and future role.
Taking an evaluation
I’ve built a tool here to help engineers and managers self evaluate their current skill set. There are frameworks for both technical and management tracks, with a set of questions to help you identify your strengths and weaknesses.
Taking action: balancing 2 want to’s, 1 have to
After evaluating your current skill set, it’s helpful to break down your future development plan into 3 balanced areas: 2 areas where you want to take action, and 1 area where you have to take action. For example:
- I want to improve my ability to answer questions and propose product initiatives with data.
- I want to double down on my system design skills for upcoming distributed systems projects.
- I have to become a better mentor to support my team.
The have to is arguably the most important one, but also the one we’re most likely to deprioritize. It feels unproductive and doesn’t have the same instant gratification that coding does, but that’s the trap. This is where you eat your vegetables, you might not be good at it, it might be uncomfortable, but not exercising this muscle may be the thing which actually holds you back from forward progress and promotions. Seniors lead and support other people, not just ship code. Mind your have to’s, the want to’s will take care of themselves.
The 80/20 rule and temptations
The 80/20 rule says that we can get most of the benefit by doing part of the work. The same logic can be applied to professional development when pursuing higher levels of seniority. For engineers, it’s tempting to try and brute force professional progress by optimizing for the last 20% of your technical skill set, while neglecting the 80% of your non-technical skills.
Take an evaluation, create a balanced professional development plan, and turn what might be an achilles heel, into what distinguishes you as a senior.
—
DevPlan is the professional development platform for software engineers. You can check out more about engineering calibrations here: https://getdevplan.com/evaluations-explained
