
On Being a Principal Engineer - kiyanwang
https://blog.dbsmasher.com/2019/01/28/on-being-a-principal-engineer.html
======
ryanong
This rings true to my experience. I'm a Staff engineer and of my 40 hour week
about 10-15 of those hours are interviews, meetings, and answering questions.
Questions about technical feasibility, architectural discussions and planning,
long term strategic planning, and lots of one offs from other developers.

I enjoy the soft work I do, a lot of emotional labor for other developers,
soft sells for tech/feature work around the company, process strategy and
such. I never expected this to be such a large part of my job, and how much
value comes from it.

But I am also at this weird point where I am not sure if the title of
"staff/principle" can be transferred to another company. A lot of the value
that I add now is because of the historical knowledge I have. What we have
tried as a company, what we haven't, why we built some things the way we did,
how things work currently, how the politics works and the trust I have built.

In the past year, I have seen less than 5 job posting for a staff engineer.

~~~
maxxxxx
"But I am also at this weird point where I am not sure if the title of
"staff/principle" can be transferred to another company. A lot of the value
that I add now is because of the historical knowledge I have. What we have
tried as a company, what we haven't, why we built some things the way we did,
how things work currently, how the politics works and the trust I have built.
"

This worries me too. Within my company I have a pretty good reputation due to
experience but I am not famous in the industry so I don't think any leverage I
have my with my current company will translate into finding jobs at other
companies.

That's a pattern I actually see quite often. People go very high in one
company, but when something happens and they leave that company due to layoffs
or other reasons they often find jobs only several levels lower and have to
work themselves up again.

~~~
bitL
> I don't think any leverage I have my with my current company will translate
> into finding jobs at other companies.

You are right. Even if you are at FAANG, it doesn't really translate to a new
environment, unless you are a direct pick by a CTO (you have to be famous in
some way) or use your networking, which I consider unethical and don't do it.

~~~
fouc
I think you misunderstand networking.

Perhaps you think it's a way for people to create and then exploit their
connections in order to get a job that they're clearly unqualified for. I will
agree that's unethical.

But that's not typically what networking is about, almost no one wants to
recommend someone for a job if that person turns out to be an unqualified
idiot. Networking is more about finding people/companies you have something in
common with and once they know about you it's a lot easier to get hired or
referred.

It's not really about some form of nepotism or cronyism.

~~~
foobarian
It feels like the OP came from a corrupt or communist locale where cronyism
and nepotism were rampant. I grew up in a communist country like this and
always found networking distasteful for that reason. However on the spectrum
of hiring signals available it just turns out to be one with a very good SNR
due to the trust involved.

------
jedberg
Re: companies that claim to have a fully equivalent technical track: What I've
found is that is mostly lip service. Yes, they publish salaries and
requirements for the highest levels of engineering, and those salaries are
equivalent to high levels of management as far as pay goes. But if you look a
little deeper you see the problem.

At Google and Amazon and Facebook, a Distinguished Engineer is equivalent to a
Vice President in pay. But how many of those engineers do they have? I'll bet
you could name most of them, because they are world famous experts in their
fields. How many VPs do they have? Can you name more than a few?

The ratio of DE to VP is about 1 to 100. To be a DE, you need to basically be
the best in the world at what you do. To be a VP, you have to be a great
manager. In other words, while they may claim to have an equivalent
engineering ladder, if you actually want to have a chance of moving up to
those levels of pay, you had better go into people management, unless you
think you're the best in the world at what you do.

~~~
zyncl19
I would argue that for a Distinguished Engineer to have as much impact as a
run-of-the-mill VP, they have to be the best at the world at what they do.

~~~
hn_throwaway_99
I agree completely. And as someone who has had senior engineering roles and
senior engineering management roles at different times, I'd argue that the
reason management is paid more is simple supply and demand. For a very large
majority of people, managing people is basically a more difficult, stressful,
and shittier job. Not that there aren't a small(er) group of people who really
love management, but management salaries have to be higher because, if they
were the same as corresponding IC levels, it would be very difficult to coax
people into management.

~~~
mixmastamyk
Huh, I'd argue more folks are interested in management then are being
engineers.

------
md5person
I appreciate the idealistic take on what a "principal" role should be like,
but in all actuality, principal engineers are commonly the ones that simply
stayed there long enough (ie. to survive multiple re-orgs), and played their
politics cards wisely. They were playing the title game. Often, their work is
invisible to most. They perpetuate tribal knowledge, and have trouble letting
go of the past and accepting change.

You'll notice plenty of comments here from people who claim to be principal
engineers - stating that they "kinda follow it all". I wish we could talk to
their colleagues though (the juniors, seniors, PMs, tech-leads,
support/escalation engineers, as-well as other principals).

~~~
throwaway98988
Unfortunately, I have to agree. I've been hired into an informal
"staff/principal" role for my part of the organization and it's simply
impossible to work. The other staff/principal engineers I see here are exactly
how you describe. They are against anything that will make their roles as "the
oracle" less important.

Documentation is such a mess because of that and the onboarding process
specifically says there are a lot of "oral history" newcomers have to learn
before doing anything meaningful.

~~~
hk-mars
So how to improve this situation? I think it’s human problem :)

~~~
mixmastamyk
If you can't convince them, you might try the boss.

------
mlthoughts2018
This article, along with a boatload of companies, fundamentally misunderstands
the way that senior / principal / staff engineers add value.

The article mentions it briefly in the small part about “force multiplier” but
then seemingly reverses course when talking about “soft” duties & especially
emotional labor.

The value of staff engineers is to give them autonomy in deciding how to be a
force multiplier. If they realize for themselves that this can be accomplished
with some soft skill application, so be it. If they realize this will happen
if they do not delegate some critical task and instead clear the calendar so
they can write the code that time, that is good too. And lots in between.

But _autonomy_ is the critical thing. These are engineers that you’ve decided
to trust greatly, so you cannot get in their way with compulsory person
management overhead, adding them to every product meeting, burdening them to
“sell” their vision on some architecture, recruiting policy, whatever.

These are the very people who you should be getting out of the way of, letting
them decide how to be a force multiplier.

~~~
brlewis
> burdening them to “sell” their vision on some architecture, recruiting
> policy, whatever.

Fair warning, if I ever interview you for a position of senior or higher, I
will be evaluating your ability to sell your ideas to other engineers. Anyone
who comes in as a Staff Engineer expecting to simply dictate their ideas to
lower-ranked engineers without selling those ideas, is going to fail.

~~~
mlthoughts2018
In that case, I would politely thank you for the chance to interview and
decline to speak further with you, because it would be clear I would not be
empowered to get my job done in the face of all the time-waster politics to
lobby for projects or quarterly goals, etc. I would feel, “why have they hired
an expert like me if they don’t plan to trust my advice on what action to
take?”

~~~
skj
The statement

> anyone who comes in as a Staff Engineer expecting to simply dictate their
> ideas to lower-ranked engineers without selling those ideas, is going to
> fail

was almost certainly about the field in general, not this person's immediate
org or even company. So it's more like, "why would we hire an expert like you
if we won't actually get the value we're paying for?"

~~~
mlthoughts2018
> “So it's more like, "why would we hire an expert like you if we won't
> actually get the value we're paying for?"”

But hiring them into a position where they are automatically subject to pre-
existing political barriers _guarantees_ you won’t get value out of them.

Giving them autonomy means you could possibly benefit from their value-add.

~~~
skj
I don't think it's fair to use the label "pre-existing political barriers"
when talking about being able to convince people that your ideas and vision
are worth the cost it takes to implement.

~~~
mlthoughts2018
That makes no sense at all. Pre-existing political barriers are the _primary
obstacle_ to convincing people in most business settings.

The actual technical merit or cost effectiveness usually has utterly no
correlation at all to how the business decision is made.

~~~
brlewis
> convincing people

I thought you didn't want to be burdened with selling ideas, but just wanted
authority to implement them without convincing people.

~~~
mlthoughts2018
“Selling ideas” is not related at all to demonstrating the technical merit of
ideas. They are completely unrelated things.

~~~
skj
That's an odd distinction and almost certainly not one that was made by anyone
else in this conversation.

~~~
mlthoughts2018
I disagree. It is a basic and ubiquitous distinction in any corporation,
because the distinction between appraising the technical merit of a proposal
and assessing the political implications, who gets credit, bonuses, etc. etc.
is so vast.

The connotation of “selling your vision/plan” is obviously political, getting
buy-in from a political / authority sense, unrelated to any technical
specifics.

This is just corporate day-to-day 101 stuff. My use of this distinction is not
unique in any way, it is the obvious interpretation that would be used
anywhere someone is discussing any type of business project.

------
throwaway000111
Could just aswell have called it on “On being morally righteous”. I worked
with several PEs in my last job. Two that stand out to me right now to make my
point...

PE 1: Complete fraud. He was also a people manager in addition to his endowed
“expertise”. He oversaw an Outlook mailbox, and had a chokehold on any
communication with the team. Any person emailing anyone in the team directly
would be reprimanded that they should contact him instead. His primary job
purpose was to read email, forward it, get reaponses, and then reply as
himself. Doing this for about 20+ years makes you look like a 50x engineer.
Especially when the people you forward to are other PEs and generally smart
people.

PE 2: Was actual expert, worked for PE 1. This guy was humble, generally
helped all the junior guys in the right direction, asked you how your day was,
wishied you happy 3/14 (pi) day, and had rolled plenty of his own software to
have cred. He made contributions that impacted 100s of millions if not
billions of people worldwide.

PE 2 was sacked. PE 1 was promoted to Sr PE. Sr PE has serious employee
retention issues, and is constantly on the prowl to sucker the next PhD grad
into his honey trap. He has snaked his way into academic conferences with
other people’s work. But who cares... I’m not about to get into a discussion
about being morally righteous...

Context: large blue semiconductor shithole.

------
johnwheeler
Titles in software are so stupid. Where I work, everyone is “Software
Engineer” whether they have 20 months of experience or 20 years. The respect
and pay are commensurate with on-the-job performance and output.

I know a “principal engineer” who can talk the talk, write books and articles
but can’t produce any software of real value, and I work with a guy who’s been
working 1/8 as long as me and he’s ten times better.

~~~
enraged_camel
>>I know a “principal engineer” who can talk the talk, write books and
articles but can’t produce any software of real value, and I work with a guy
that’s been working 1/8 as long as me and he’s ten times better.

Perhaps you're measuring value too narrowly. A principal engineer can act as a
force multiplier for the entire team, even if they themselves are no longer
efficient individual contributors.

~~~
syndacks
Can you elaborate a bit more on what you mean by "force multiplier" please?

~~~
bcherny
Andy Grove talks about this in his excellent High Output Management, where he
asks the question: how should knowledge managers (senior ICs) and people
managers spend their time?

His answer is: on high leverage activities. Instead of fixing a small bug that
affects a few customers, fix a big one that impacts revenue; train others to
be better engineers, multiplying their future output; improve the process your
team uses to build product. Essentially, look for activities that multiply
output, rather than add to it.

------
nevir
Though I am a principal that tracks very closely to what this article
describes, I think eng organizations need both "broad" and "deep" principal
technical roles.

E.g. at that level, the road forks three ways: deep principal ("pure" IC, & an
expert in an area), manager, and broad principal (the hybrid force multiplier
role).

The tricky part is making sure that the deep role doesn't devolve into
promoting people _purely_ on technical merits, and being blind to their
cultural impact. Everyone at that level is a role model, for better or worse.

~~~
solipsism
_deep principal ( "pure" IC, & an expert in an area), manager, and broad
principal (the hybrid force multiplier role)._

I don't understand what a "deep principal" would be. If this person is a SME
with incredibly deep knowledge and experience, what an incredible waste it
would be to not turn that person into a "force multiplier". I don't care how
complex the code is -- that person's impact would be tenfold showing/guiding
others compared to doing it themselves.

Perhaps I'm misunderstanding something about the distinction.

~~~
roel_v
Some technical roles require deep understanding of an extremely niche thing.
It just doesn't make sense to have such a person supervise 10 junior and
senior people, they wouldn't be able to do any more work than the one guy. For
example I've seen a GPU optimization expert who did his PhD on GPU chip
design. What sort of 'guiding' others would he be able to do? He could spend
2, 3 years teaching a team of 10 everything he knows - and then the company
has 10 people but no work for all of them, and they're years later.

Of course, often in such a situation it makes more sense to bring in a
consultant for this sort of specialized work, but you don't want to base the
core of your product on consultants either.

~~~
solipsism
In this situation you're describing, a _single person_ is responsible for, and
the only person at the company capable of working on, the "core of [the]
product"? Unless this is a company of 1, that's absolutely crazy!

There are many reasons you'd want more people (I don't know why you're jumping
to the large number of 10... why not 2?) on this "core of the product":

* mitigating risk from the bus factor ([https://en.wikipedia.org/wiki/Bus_factor](https://en.wikipedia.org/wiki/Bus_factor))

* lessening the "information silo" effect ([https://en.wikipedia.org/wiki/Information_silo](https://en.wikipedia.org/wiki/Information_silo))

* taking advantage of a diversity of perspectives/approaches

If these ideas aren't relevant, then you're probably not talking about a very
important part of a company. If they are relevant and this is a critical part
of your company, then it makes every bit of sense to build at least a small
team around it, thus leading to the "principal engineer" earning his/her
title.

 _What sort of 'guiding' others would he be able to do? He could spend 2, 3
years teaching a team of 10 everything he knows_

You make it sound like he'd have to quit his job and become a professor. He
would continue to work while teaching the people around him. They might never
learn "everything he knows", but that's not a requirement. And there's every
chance someone he trains might eventually surpass him. This is exactly what it
means to be a Senior+ engineer.

~~~
roel_v
_shrug_ I guess we'll just have to agree to disagree. Of course nobody wants
to build the single most important part of a company around a single person.
My point is that for some deep niches, building entire teams around it, _and_
pulling away the people who know most about those things in order to have them
'mentor' a bunch of people who in no way will be able to reach the require
depth for a long time just doesn't make sense. And from my understanding, it
is this sort of situation the GP was referring to. I don't think, and from my
experience which of course suffers from insufficiently large sample size, this
situation is not all that uncommon.

(as an aside, I especially object to 'taking advantage of a diversity of
perspectives/approaches' being a universal good/requirement. I have seen many
cases where having one person just get on with it absolutely beat the design
committee. But again this perspective is probably skewed by being involved
mostly in deeply specialized numerical software, where exceptional value
mostly comes from having both deep domain expertise in something unrelated to
computing _and_ deep technical/programming knowledge)

------
nickm12
It's worth mentioning that the level of "principal engineer" means different
things at different companies. Some companies have "principal" and "sr.
principal" while others have "staff" and "principal". See www.levels.fyi for a
rough alignment guide.

Regardless of what they are called, the different levels almost always involve
changes in job function, not just "more of the same". This is true even in the
distinction between "software engineer" and "senior software engineer", where
the latter typically involves a lot more consulting, mentoring, and review and
less writing code.

------
erentz
Unfortunately the Principal title has been abused and cheapened by some orgs.
In some ways necessarily, as comps in tech have grown it’s become necessary to
hire people at a Principal level in order to get the necessary comp. In other
orgs it’s been a way to lure people who are attracted to the title. Ideally
Senior positions would be more respected and have a greater comp range. But
now it feels like Senior is almost entry level for some companies.

~~~
pault
In my experience developers are going straight from junior to senior and
"lead" is the new senior.

~~~
thundergolfer
As an example, I recently got offered a Senior Software Engineer position with
6 months experience @ Zendesk.

~~~
tayo42
my whole dept seems to be filled with seniors younger then me, except my
manager thinks the title still means something at this point so i'm not being
considered for senior for years. im asking to be senior because i just want
the money fuck the titles...

~~~
skj
It's about what you can do, not about how long you've been around.

------
nichochar
Principal engineer in that kind of company does not at all mean the same thing
as principal engineer at google, amazon, facebook, twitter, pinterest, airbnb,
etc.. (and even those aren't equal).

The article is still good, but confusing names is a big problem for us
engineers. "Senior", "staff", "principal" mean nothing if they don't mean the
same thing cross-company

~~~
bastawhiz
> "Senior", "staff", "principal" mean nothing if they don't mean the same
> thing cross-company

Exactly this. At least three times, I've had EMs or recruiters approach me and
ask about the titles at a previous company. "We've got a candidate that's
coming in as a senior staff engineer, but they seem pretty junior." I've been
around for hirings of "senior" engineers that come in at a junior engineering
level (salary, I don't know).

A lot of companies hand out promotions like candy to keep people around.
Companies that don't need to hand out promotions have titles that actually
mean something. But the companies where title means nothing muddy the water so
much that it's unlikely that title at a previous job actually means anything
when changing companies.

------
kentosi
Sorry this is off topic, and I only found this out because I accidentally
clicked on your alias rather than the topic.

You've made 4 other exact posts in the last 12 days:
[https://news.ycombinator.com/from?site=dbsmasher.com](https://news.ycombinator.com/from?site=dbsmasher.com)

Is it common HN practice to report the same thing until it finally gets
attention?

~~~
wellpast
How is that HN didn't de-duplicate the URL?

~~~
grzm
From what I've seen, if a story hasn't gotten significant votes or comments
(and I think there's a time interval involved as well), it isn't considered a
dupe.

------
gnulinux
Should principal engineers necessarily be managers? My company has non-manager
principals, manager seniors, manager principals etc... Manager is just an
extra title added to someone to give them extra responsibilities, regardless
of their engineering experience. Is my company different than "usual"?

I don't know how they decide who is senior who is principal, but principal
engineers are absolute rock stars. They know anything and everything related
to company's engineering from hardware to embedded to massively parallel to
machine learning...; and it feels like they memorized every line of code of
company's codebase. My manager is a principal engineer, I am very junior
junior (not even 1 year into industry yet), and sometimes it really intimates
me how competent he is in terms of both breadth and depth.

I sometimes wonder if making such a competent engineer a manager is waste of
company resources; not that being an engineer is useless but it seems like you
don't need CS geniuses to be managers.

~~~
brown9-2
I think it is very hard for a principal engineer who is also managing people
to be effectively plugged into all the things going on that make him/her a
"principal" engineer while also being an effective manager, and vice versa.

------
RickJWagner
The relentless force of 'job title inflation' ensures there will be levels
above Principal. (For instance, some organizations have 'Senior Principal'.)

This is necessary because there are different grades of programmers. Frankly,
some are better than others and social pressures force us to acknowledge it in
some way.

It's been this way as long as I remember, one of the first things I was issued
at my first programming shop was a chart that enumerated who was an entry-
level 'E07', who were mid-level 'E08s and E09s' and who had reached the
coveted rank of 'E10'. The groupings will probably be similar no matter where
you go, though the titles will change.

I think it's a natural workplace dynamic.

~~~
brlewis
Deflation involves lowering existing titles, which can lead to a lot of
awkwardness even when done company-wide. As a result it's a lot easier to
inflate than deflate. Thus the natural workplace dynamic you mention.

------
xtreak29
Is there a path where one can get to work on code without getting to design
and architectural space. Is this thought as career stagnation when someone
doesn't wants to work more on higher level design and to remain close to
implementation side of things?

~~~
cddotdotslash
Ultimately it's going to come down to the value you provide the company. The
reason senior engineers get paid more than juniors is because of the value
they provide over a junior. The same applies to principal over senior and so
on. Eventually, there is only so much value you can provide if you limit your
skills to one specific area and are unwilling to expand.

I can't speak for every company, but I imagine that if you got to a point
where you are the best coder at the company, but you refuse to discuss
architecture or design, your salary and advancement opportunities will
stagnate. This isn't because you're not a great coder, but rather because the
value your code provides in isolation, without architectural context, is
limited.

~~~
mooreds
It's all about leverage. If you are a tremendous coder, do you have more
leverage to build business value than someone who can enable a team of five?
And can your organization recognize it?

The answer for most people and organizations is no.

(Edited to fix typo)

I also think it is worth recognizing that the challenges of higher
abstractions can be kinda fun. Different but fun.

------
d4mi3n
Interesting article. A lot of the qualities the author descrives as required
trains of a principal are things I always say a senior engineer/tech team lead
should have—e.g. ability to act as a force multiplier, leading by example, and
being active in less technical activities like mentorship and recruiting.

Am I off the mark? I suspect I may just not have been at enough orgs with a
well developed career track, what the author here calls a 2-level technical
track.

~~~
mharroun
This depends on the culture & hiring philosophies of the company.

I've seen many places that "only hire the best" or "only hire seniors" then
end up with a bunch of engineers who dont mentor or force multiply but tend to
just focus on what ever pice of a system they own.

I've also seen senior used only to justify a pay bracket as well.

Personally I agree that a senior or lead enginner needs to have these skills.

~~~
d4mi3n
I’ve been at the kinds of places you describe as only hiring seniors. I’m
personally not a fan of that kind of mentality for a few reasons:

1\. (In San Francisco) This can lead to reqs being open for way too long. My
company had several roles open for upwards of a year and wouldn’t back off
until I convinced my manager that we could train/mentor a less experienced
hire to fill those reqs faster than we could fill them directly.

2\. I think teaching a skill is important to the development of a skill. It
forces you to distill what you do know, and articulate it in a way others can
understand. This process is a huge boon to a lot of other traching-related
soft skills as well.

3\. (Personal opinion) I think we a professional, perhaps ethical,
responsibility to improve the quality of our craft. I don’t think most places
know how to write and maintain software well as an organization. The state of
software as a profession will not improve until we raise the lowest common
denominator and do a better job disseminating hard-earned lessons and best
practices.

~~~
yawaramin
4\. Companies have an ethical responsibility to provide their workforce with
on-the-job training. The ones that don't are not only mooching off the ones
that do (by hiring trained engineers away from them), but also pressuring
colleges, through their feedback to students ('You don't have relevant
experience in the stack we use') to provide training in 'current technologies'
like iOS and Android dev instead of timeless fundamental CS concepts that will
actually give them a good foundation for a career spanning several decades.

------
OJFord
In these org structures where Principal Engineer has significant say in
technical decision making but no reports: a) are they (at least potentially)
'tech lead'; b) who is the manager of the rest of the engineers on the team?

My only experience is with a full technical ladder being available, but the
team technical leadership being the same as the team people management.

~~~
scarface74
I can’t speak for larger companies, but classic organizational theory is that
there are three levers of influence in an organization - relationship, expert,
and role. I’ve found it much easier to leverage relationship and expert power
at smaller companies than larger companies. I insisted on a nice sounding
title when I was brought in to lead a project at a large company just for that
reason. I needed role power.

I insisted on _not_ having a grand title at a small company because I thought
it would lead to resentment and I knew I could leverage the other two levers.

------
man007
I've been working as a Principal Engineer for the last year. This experience
is similar to what I've experienced. Coordinating across teams, help
unblocking coworkers, distributing knowledge etc. I've worked with the same
company for the past 3 years, and as a result, I know the historical decisions
etc. Unfortunately, as a result, I am spending less time refining my craft and
coordinate business needs with technical solutions.

From an organizational standpoint, I believe I add much more value in this
role compared to strictly writing code. Unfortunately, the skills you learn
tend to be localized to the place you are working at, and are not really
transferable.

It's been a good experience, and I've grown my soft-skills as I've had to
handle different scenarios.

------
casper345
I am 23, just got my first real job and this has been on my mind as well.
Although its early (I have been programming unprofessionally for 10
years),what track I want to go Senior or Principal based on the author's
definition. Do I want to be the one who knows the tech stack from the back of
my hand or managing people to move the overall goals of the company. Although
the author says both roles involves people, at the end of the day the only way
to become a better engineer is working on hard problems in the trenches. So
the more you manage people the more you lose time "crafting" your skill. It's
based on the individual pref, but right now I am at that crossroads.

~~~
matwood
Software is so big and complex today that very little is built as a sole
engineer. You may not realize it yet, but you will always be managing people
even if you're not their manager. How you convey your ideas, _accept_ their
ideas, and work together to solve hard problems is often more important than
raw technical knowledge after a certain level.

------
abhishekjha
Titles like these scare me.

I mean when would I know that I need a different title? I am a Software
Engineer with around 2 years of experience who implements most of the already
made design by my seniors.

When would I know that I need a better title or that I am doing something that
needs a better title? Or should I just wait for the company to promote me with
a proper title? It will still leave me baffled though that somebody else is
able to measure my competence/worth much better than myself.

I am trying to learn designing software as much as I can which seems like a
gradual next step though sometimes I do have difficulty inverting a binary
tree in C++ which makes me rethink my worth.

~~~
empath75
Keep your linked in updated and talk to recruiters every once in a while. When
they start knocking down your door with job offers that are better than what
your current job, it’s time to push for a raise and promotion.

But generally once you start implementing your own ideas and stuff goes into
production, it’s time to ask for a senior role.

------
throwaway98988
What should a staff/principal engineer do if company culture is against
change?

Posted a related question here, if that's a better place to discuss this
question:
[https://news.ycombinator.com/item?id=19130451](https://news.ycombinator.com/item?id=19130451)

~~~
tristanperry
It can be a tricky one, but fundamentally the _reason_ why change isn't
happening needs to be understood. A company full of smart people is unlikely
to _never_ want change for any reason - especially if that change would
clearly make everyone's life easier. But maybe everyone is overloaded with
work and a bit burnt out, so 'big' change is scary to them? Or perhaps the
'important change' really isn't that important? I've worked with devs before
who have spoken for hours a day on the need to change x, y and z, when in
reality it wasn't fully needed (and/or their suggestions stemmed from
misunderstandings).

I guess my latter point there relates to the fact that there's not always a
single "right way" of doing something.

Now I know that this might sound like I'm the same as the people shooting down
your suggestions in your linked 'Ask HN' thread. Trust me, I'm not like that:
I left my previous job a few months ago for the exact same reasons that you
have outlined (i.e. there was clear change that was needed, but the 'powers
that be' weren't willing to make those changes).

But to circle back to your question: assuming there aren't massive
organizational problems at a company, change usually needs to be made slowly-
but-surely with the buy-in of any previous 'change blockers' (where possible).
Anyone trying to force through lots of change in a short period of time will
usually struggle.

If even minor change is not possible, there's two main possibilities:

1) You're wrong about the change, and you might be the problem. 2) You're
right about the change, the company is dysfunctional, and moving to a new job
is the answer.

From your linked thread, (2) does sound like the situation in your case
(fortunately/unfortunately).

------
austincheney
> It surprises me that many shops still claim to have a ‘flat org’

What is the rationale behind a flat organization?

~~~
nickm12
The argument for "flat" is that management is waste and unnecessary
process—you should just give smart people rein to attack your problems.

This notion is idealistic and appeals to people who have been burned by
bureaucracies, but it denies the important functions that good management
provides in setting priorities and coordinating work.

I once saw a case where a team switched managers and the team's output nearly
doubled. Was the team suddenly better engineers? No. They were a fine team,
but the manager worked to get everyone on the same page and ensure that their
work was connected in a way that it had a multiplicative effect. Rather than
everyone working on isolated projects, the projects leveraged each other to be
much more valuable.

------
kashif
My thoughts on this in a short post -
[https://medium.com/@kashifrazzaqui/a-simple-career-ladder-
fo...](https://medium.com/@kashifrazzaqui/a-simple-career-ladder-for-software-
teams-1056c86d79d3)

------
ww520
Those stated in the blog are leadership stuff which team leads and senior
engineers need to have.

Principle engineers are simply people who can design and build a major
product, a major project, or even a company's technology by themselves, alone
if needed to.

~~~
techslave
no way! principal engineers are those who have the technical vision and
understanding to build a product by themselves. And the people and leadership
skills to lead a large multilevel team of engineers to actually do so.

a project that could actually be built by a single person doesn’t have enough
scope to warrant “principal”.

~~~
ww520
The sounds like a manager or a VP.

------
bobmagoo
This was great, thanks for sharing. I'm currently pointing my career towards
principal (security) engineer and would love any similar articles on what it's
like and what makes a good one if anyone had recommendations.

------
candybar
In my experience, the best principal engineers are those who think of
themselves as just engineers and simply focus on the best ways to make a
difference without much preconceived notion of what that entails. The worst
are those who have these strong preconceived notions about what they are
supposed to be doing, often focusing exclusively on the more visible,
politically expedient tasks in the name of having organizational impact, while
eschewing hard technical tasks. Well if that was all that was needed, we don't
need the technical ladder - managers that used to be engineers are perfectly
capable of handling most of those. It's important to realize why principal
engineers are given such autonomy and organizational influence - they are
supposed to the best engineers that the organization has to offer and other
engineers look up to them because they can do the same things they do but
better. What you value in principal engineers should not be something you
don't value in other engineers and vice versa. This idea they should be
working on different types of tasks altogether and focus less on technical
things specifically makes a mockery of the technical ladder.

So the worst part about this article, to me, isn't necessarily this notion
that principal engineers shouldn't be all about tech - that I think is
relatively uncontroversial. But the reality is that if your organization needs
to stress this at that level, this should also be true at every level. If you
want to have a great engineering organization, nobody, not even the most
junior engineer should merely be converting tickets to code - they should
ideally be doing all the things that she thinks principal engineers are doing.
And whether someone on the team works more on soft, cross-team stuff or hard
technical tasks shouldn't depend on one's level - it's entirely possible that
interfacing with other teams or stakeholders is something your mid-level
engineer can do well and also solving a very narrow technical problem is
something you want your principal engineer should work on because it's
extremely difficult. I will go even farther and say that if your engineering
organization's challenges are such that the hardest problems that your best
engineers should focus on are exclusively non-technical, you should reconsider
why you need principal engineers instead of much cheaper project managers.

In one specific instance I observed at this organization, principal engineers
were, on the whole, less technical than their managerial counterparts or
senior engineers. Because the organization bought into this "principal
engineers ought to focus on high-level, organizational, cross-team stuff" \-
their principal engineers were for the most part too busy trying to direct
other teams' and people's work to do anything themselves. They had no
deliverables beyond being the multiplier so they were also even more removed
from the technical reality than line managers, who are at least forced to deal
with what their reports are doing.

~~~
hk-mars
good comment,thanks

------
visviva
On Being a Principal *Software Engineer

~~~
weego
This isn't Oil Drilling News, I thing we'll all cope with the ambiguity

~~~
mfgrimm
Actually, as a mechanical engineer at a consumer products startup, I would
have appreciated this clarification.

------
acroback
I hate being called a Tech Lead because I know dirty work I do in my current
Job holds no value when I start looking out.

No one cares that you took one for the team. Principal Engg or not, recruiters
are trash these days and they suck. Every numbskull keeps repeating "So, what
are you expert in?". How about none, because if I was a expert, I would not be
talking to you.

------
McP
What is "IC"?

[https://www.linkedin.com/pulse/acronyms-seriously-suck-
lesso...](https://www.linkedin.com/pulse/acronyms-seriously-suck-lesson-from-
elon-musk-nathan-tanner)

~~~
robterrell
Individual contributor. i.e. Not a manager.

------
PretzelFisch
[https://news.ycombinator.com/item?id=19027218](https://news.ycombinator.com/item?id=19027218)

------
debt
“without having _human_ direct reports.”

?

------
hk-mars
managers are all dirty guys, be far away from them :)

------
jeffdavis
This article uses "individual contributor" too freely. Many decisions even for
small projects have long-term impact on thr team.

Even if you believe it's an accurate term, I find it a bit dimunutive or even
condescending.

~~~
techslave
how much experience in tech and how many companies have you worked for? i ask
because IC is not intended as a condescending term. it’s industry jargon, and
not related to the importance or impact of the person.

for one thing, it defines where they are in the sexual harassment stack. as an
IC you require only an hour of training a year and you can freely have
relationships with people who aren’t in you mgmt chain. stuff like that.

~~~
scarface74
When I was a dev lead, I would not go to lunch alone with any of my reports
male or female. If I went to lunch with just the males it would seem like
playing favorites and if I went to lunch with just females, it could lead to
rumors and innuendos and it wasn’t worth the risk.

On the other hand, one of my former coworkers when I was an IC is now my
wife....

------
micksabox
Curiously, I'm trying to validate RefactorKit.com which will help with these
"soft-skills" like: \- stakeholder convincing campaigns \- org collaboration
signals \- consensus building

I've never heard of a principal or staff engineer before. I'm up on Twitter as
@refactorkit, find me there, would love to chat

[https://refactorkit.com](https://refactorkit.com)

------
alexandercrohde
Meh, nonsense. Standard buzzword bingo.

Every engineer I meet advocates for standards. Usually the more dogmatic ones
are the worse ones. This doesn't make you a 10x force multiplier (telling
people to lint makes them 2% more productive tops). Usually these "standards"
people though have a negative effect because they get into a dick-contest over
the most trivial details (e.g. tabs/spaces).

Even if cross-team collaboration-roles are important, what makes them a step
"above" a senior engineer? If the skillset has no relation to problem-solving,
it really isn't an engineering role.

What ACTUALLY happens is companies like pretty hierarchies at a 10:1 ratio.
They like these hierarchies regardless of the distribution of skill, and the
titles rarely align with the skill. Then they come up with a bunch of
buzzwords as they grow until they succeed like uber/twitter at losing a
billion dollars a year and go out of business.

~~~
erikpukinskis
The two examples you gave, linting and tabs, aren’t architecture at all. They
are toolchain.

Architecture is questions like should this class of functionality be services
or objects and why? Do these 3 functions belong in this class, or should they
be a helper? Should this helper be copied between repos or be a separate
module with a formal API?

I agree with your point though that every engineer makes the decisions and
having a separate role for them is weird.

~~~
deleted_account
These and the parent's examples are very team-centric. The heuristic I use
when thinking about these engineering roles is, "Where is this person expected
to be a leader?"

The progression is usually: Team, Cross-team, Organization, Industry.
Competent technical decisions are table stakes. The real differentiator is at
what level can they effect change.

~~~
alexandercrohde
This is the very thing I'm criticizing.

"Leader" is one of the worst buzzword bingo terms in a company. It means
nothing, it's just a convenient label to give people who you feel like
promoting to maintain the 10:1 ratio.

You could argue Linus Torvald is an industry leader, or you could argue he
doesn't show adequate leadership for cross-team.

~~~
deleted_account
I think you very much understand a leader can be something more than a
buzzword: "If you’re a leader in an organization, you need to be aware of the
stories that occupy the minds you oversee."

Or maybe more succinctly: "If a great manager screws up, he should lay awake
at night until he fixes it, just as a great engineer would wake up to fix a
production issue."

These traits combined with a scope of influence is what I was referencing.

~~~
alexandercrohde
Well, that very post is criticizing self-proclaimed organization "leaders" for
not holding themselves to the same level of basic accountability as a senior
engineer would.

I do believe in leadership, in the abstract. But at the end of the day
companies do whatever the hell people in power choose to (e.g. Fire Steve
jobs, promote their friend, hire somebody sexy) and then come up with fancy
meaningless words after the fact.

"Force multiplier" and "cross-team leader" are among those. If you really
wanted to promote "leaders" then have engineers vote on who gets promoted...

~~~
deleted_account
You believe there are qualities that good leader would exhibit — in the
abstract — but experience has never offered mentor, teacher, motivator you
respect thus all promotions must be based on facets unrelated to merit:
ignorance, nepotism, and sexism.

You may want to ask yourself if your viewpoints are a case of WYSIATI bias or
a generalizable fact about how businesses are run.

~~~
alexandercrohde
You've totally lost me there.

I've had good managers before, I'm not sure why you're saying I haven't, or
how that's related to my central claim.

Also "WYSIATI" is a misdirection. You could suggest that to anybody in any
argument (I could suggest it to you now). But without providing any evidence
of what those unseen factors are it's of no probative value.

I don't think you're trying to understand my point in good faith anymore so
I'll leave it here.

~~~
deleted_account
Sorry I lost you. I understood you believe titles rarely align with skill and
companies disingenuously use "leader" to justify a ratio of employees to
managers. A company is as likely to promote on the basis of "hire somebody
sexy" as anything else.

This mindset seems corrosive. I assume you had good managers, but I cannot
imagine a career in which that was the norm would result in such cynicism.

My point was only this: in my experience, healthy organizations have a better
value systems.

