A few days ago, I was promoted to Principal Engineer at $dayjob.
While I feel grateful for the recognition, I have to admit I’m a bit of a
skeptic when it comes to career ladders and titles. People aren’t comparable,
nor are their talents or knowledge. Attempts to reduce a group of
humans to points on a number line erase a lot of individual strengths.
On the other hand, titles are a way for the group to officially
recognize the personal practice of improving at the craft of
engineering. So, I’ve been stewing on this for a couple days now: what
does this promotion mean?
Speaking for the tech industry, titles are a measure for your experience,
efficacy, and ability to deliver value to your organization. They
represent how the organization at large views your talents and often
how they value your contributions. In theory, they reflect your day to
day responsibilities.
However.
The measure, as a proxy for the job, is doubly flawed. For one, it doesn’t
describe the job accurately across organizations; further, two people with
the same title within the same organization may execute the title in wildly
different fashions. For two, we measure individuals, but the our ability to
contribute on an individual basis depends greatly upon the team around us, and
that team’s perception of us.
On the other hand, the measure corrects for insidious biases: the title can
lift some of the burden of constantly having to prove your worth, especially if
you’re not a member of a historically privileged group. It can also correct for
compensation bias: two staff engineers should be making the same amount, even
if one of them is a white guy and the other isn’t. (Compensation can get
perilously out of whack without banding tied to titles.) The bias is still
there, it’s been compartmentalized into convincing the org that you meet a
rubric, but you can at least bring receipts to that conversation.
So, I’m conflicted.
I am an ardent believer in self-improvement — that the craft of engineering
can be practiced like art in any other medium. I also believe that you will,
over the course of your career, encounter engineers who have practiced far
more (or less) than you, possess raw talent for thinking (analytically or
otherwise), whose communication skills and techniques you will envy and
seek to emulate for years afterward. You’ll work with people all across the
spectrum of possibility. Trying to reduce them to a number line erases so
much of what they have to offer, encourages zero-sum mentality, and stands
in the way of your own self-improvement. But that’s the realm of the ideal:
only a privileged few are afforded the ability to treat programming as an
art that can be practiced in isolation from society.
On the other hand.
I’ve been at the pointy end of a shift in organization culture. Two years ago
at a previous job, my manager told me point-blank that I had been doing the
Principal Engineer job for some time per the career ladder rubric, but because
of organizational changes there was a new VP who could not be convinced that I
should be promoted. Ironically, before the change in management, I was one of
the parties responsible for designing the rubric for that career ladder! That
same VP had pulled me aside earlier to explain that, because I had worked so
closely with the prior, unceremoniously booted, management, it “wasn’t clear”
what I had contributed over the past four years. I stuck around for months from
that point, trying to do everything I could to change their mind.
I still feel hurt by this, obviously. The insecurity I had internalized from
this experience factored into my decision to turn down a Principal Engineer
position during my subsequent job hunt. I’m here now though, so it’s all for
the best, I suppose. The lesson, however, is clear: a career ladder is a social
construct that is only as real as the people in power at your organization make
it.
Titles hurt in other ways: I’ve seen a brilliant, absolutely stellar programmer
get turned down for a position at a company because their ability to impress
their interviewer with a whiteboard and dry-erase marker wasn’t sufficient to
justify the title they were interviewing for. Again, there’s a lesson here: a
focus on measuring humans against a number line tends to turn technical
interviews into a hazing ritual. The point of the ritual hazing is to buy the
necessary cachet to justify a title with the existing engineering staff. This
is stupid and cruel, as you know.
So much of what exhausts me in tech is tied up in the constant drive to
establish a pecking order, and that might be what I’m really reacting against.
Career ladders are a pragmatic concession to this: if we’re going to keep
trying to rank engineers, we may as well do so with an established rubric. At
least then we can try to confront our biases. It’s worth considering the title
a floor when considering a person’s talents: they may be wildly more talented
than their title. There is no iron-clad rule that says an associate engineer
cannot teach a staff engineer something valuable.
I suppose this is all to say: I’m grateful for the recognition. I take it with
a grain of salt, because titles and career ladders are a mushy, social
construct that changes as people enter and leave the organization; I won’t let
it go to my head because there’s obviously so much more I can learn from my
colleagues, no matter where they are on this ladder. My intention as a
principal engineer is to highlight the achievements of my coworkers, work to
make sure they’re empowered, trusted, and happy, and to become better engineers
by working together.
I’ll write more about what’s worked for me in a subsequent post.
Source link