Let's talk about "seniority" - but not in the usual way, in a context of career progression. I'm more interested in speaking about the "seniority" itself, regardless of specialty/path chosen, compensation, labels & position names. It's the kind of discussion that revolves around the following questions:
what makes senior "senior"?
how to measure/compare "seniority"?
does seniority have boundaries? (what is the ceiling, how to recognize it and ... what happens when you reach it?)
Answering these questions ain't trivial & every organization does it its way (or pretends the problem doesn't exist ...). I have my ways as well: dimensions, criteria, weights, ... But I always knew there's something beyond all of those, something I couldn't name/frame properly - even if I knew that it does summarize them all.
It was like that until I have read (some time ago) Andy Grove's "High Output Management". Yupp, it's a book about management in general (and I mean "core" management, not leadership) but it presents a very simple term that IMHO can be very nicely applied to the concept of seniority in Software Engineering (& probably not only):
The Leverage
Your leverage is the sum of ratios of general value brought directly or indirectly (!) by your actions within a topic to the effort you've spent on this particular topic. The leverage is interesting as total - it's a general measure of your positive influence wherever you've decided to apply it.
Leverage = Sum(Value/Effort)
The higher the leverage, the better - because it means that you have the higher positive impact on your work environment (teams, projects, products, etc.).
Examples?
Sure, here you go - if you invest (apply effort) in ...
- ... recruitment, employer branding, community presence - your team may get better job candidates & your team will get more capable & effective
- ... coaching youngsters, e.g. by pairing with them, they may gradually get better, grow professionally & e.g. get more independent or simply produce better/more effective code
- ... rolling up your sleeves and hacking the solution of a certain problem just by yourself, your coding flow will be quite smooth & uninterrupted, but ... your "capacity" will be the constraint (not mentioning some other negative aspects)
Formula hacking
Unfortunately, this ain't an easy formula (contrary to how simple it appears at the very first glance):
- indirect value is not obvious sometimes
- value is frequently deferred (e.g. you reap the outcome of building teams over time) - the "investment" way
- different kind of value are sometimes hardly comparable
- there are negative consequences that count as negative value - those are also not trivial to take into account
Keeping all that in mind, how can we maximize the result of such formula? There's not much to do about the denominator:
- minimizing effort in total doesn't make sense (there's no value w/o effort, this whole play is about maximizing "the multiplier")
- actually it could make more sense to increase the total effort, but ... sure, you can go beyond 40h per week to 50h, 60h, 80h - however even if you pretend there's no price pay (in terms of unit efficiency), how far can you scale that way?
Human catalyst
Finally, we're getting there!
The only reasonable way is to hack the nominator - a person of a high leverage is able to increase value by extending her/his influence upon several other people. By out-scaling instead of up-scaling. There's a clear limit of what you can do just by yourself (24h per day ... I've learned it the hard way ...), but it disappears if you can "boost" others (lead, coach, support, trigger, drive, help, ...).
That's the whole secret of "seniority" - it's tightly coupled to your leverage as a person.
If you impact (/affect) only your own work, you're at most a solid, regular individual contributor. You may be a Subject Matter Expert - have an unique knowledge of something. Or you may have enough experience to fly through a certain topic(s) faster than others. But that makes you just a limited-usage tool. Maybe quite a sophisticated one, but nothing more.
A "senior" person goes beyond that. And it doesn't have to mean managing a team or supervising people in any way. It applies to all kinds of specialties, incl.:
- architects setting course for whole companies
- tech. evangelists inspiring local communities
- coaches revealing new techniques unheard of
- experienced developers - who share their experience by coaching others
- great organizers
- product visionaries who can infect others with inspiring ideas
- data freaks able to draw conclusions that can impact work of many
- ...
The mental barrier
Becoming truly "senior" means breaking a very tough mental barrier - it's so challenging that many never manage to do it. What kind of barrier is that?
Investing in anything that is not artifacts of your individual work (e.g. code commits) means that you actually produce less artifacts. And this hurts - as it feels like your productivity has dropped (and such investment doesn't have an immediate ROI, correct?), which can be very frustrating. It happens e.g. when instead of coding everything yourself, you delegate the work to someone more junior, help them plan & prepare the work, provide feedback & review, patiently go through the areas for improvement, etc.
I know this feeling, I went through all of that myself. But there's no other way, there are NO SHORTCUTS. You either break this mental barrier or you're stuck (in personal development as well). Regardless of the career path you choose.
My way of fighting off this depressive feeling was a daily ... "test of conscience" - something I keep doing until this very day. Every day after I'm done with my work, I reflect for few minutes on what has happened since morning - with one sole purpose in mind: to evaluate whether I made a difference.
- Did I help someone who has needed my help explicitly?
- Did I unblock anything / remove any obstacle my fellow colleagues where struggling with?
- Did I provide any insights / perspectives / hints / support which have advanced something that got stuck?
- Did I make anything others would not be able to perform (because of limited experience, difference in skills or knowledge)?
- Did I grant / enable any learning experience I feel my fellow colleagues will benefit from in future?
- Did I reinforce any behavior that corresponds to our culture and / or express my displeasure over one that is against it?
- Did I provide any valuable feedback / conduct any meaningful conversation that solidify relationships within the team?
Answering such questions HONESTLY requires a lot of self-awareness, self-criticism & ... humility. But gods, is there anything more satisfying than feeling you've acted like a multiplier for your team's performance?
