What is "IC"? https://www.linkedin.com/pulse/acronyms-seriously-suck-lesso...
Individual contributor. i.e. Not a manager.
On Being a Principal Engineer
51–60 of 337 posts
Re: On Being a Principal Engineer
#52Earlier quoted context omitted.
In my experience it’s rare for orgs to hire for principal/staff/architect roles. What I’ve seen instead is people getting hired on as senior engineers and get promoted up from there after they’ve settled into the org.
I was hired into a company as a staff engineer, and I probably won’t consider it again. The existing engineers resented me for it, though it was super clear that the product was suffering because the existing engineers had serious skill gaps in critical areas. Meanwhile, to other managers & directors, I was just some new engineer they didn’t know, a political unknown quantity. I hit the ground running and earned a lo…
> The next time I will require the role to be some type of director or IC/distinguished engineer hybrid that is operating with an authority level above that.
I've seen this go roughly. A director who brings in a lot of new technical views, challenging the perspectives and opinions held by the team, might not have an easier time than a staff engineer. The director was largely right, but dealt not just with technical resistance but with more political fallout of having disgruntled employees reporting to them.
Forcing change isn't easy. It can pay well, when upper management knows someone needs to take on that role, and doesn't have anyone already doing it, but authority alone won't solve your problems. Especially if your management doesn't want to be seen as the bad guy themselves.
Re: On Being a Principal Engineer
#53Meh, 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.
Re: On Being a Principal Engineer
#54It'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.
Re: On Being a Principal Engineer
#55This 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.
In our org it just means "not a manager." We have two tracks in engineering, IC and managers. You can stay on the IC track and continue to be promoted to positions of higher responsibility, without your comp getting dinged because you're not a manager.
It solves for the decades-old "well now what?" mid-career dilemma where an engineer would have decide if they wanted to keep doing what they love (i.e. coding) or go into management for the comp but leave the work they love behind.
I found it freeing. Not at all condescending.
Re: On Being a Principal Engineer
#56Earlier quoted context omitted.
I think you are right that seniority at the specific company plays a large role. Anecdotally, I was told that GitHub does not hire from the outside above the senior level. Going from senior to principal engineer is expected to happen inside the company.
Which is interesting to me, because once you get to staff inside such a company, how would you move to a different company? Are you locked to the company because any other move would be a drastic reduction in comp (because it would be a drastic reduction in value)? Or are there transferable skills that are valuable enough that a transfer could happen at roughly the same comp level? I don't know but this is an interes…
Pay bands are usually wide. You might find a role that's a step down title-wise but a sideways step comp-wise, though of course that's less likely the more you have in current comp. The top companies like their golden handcuffs.
You have to think about what you want to be doing. I think a strategy that's (company) tribal-knowledge dependent is a risky one, since it's going to be very hard to transfer. Industry-level tribal knowledge can be much more valuable, since you could move to competitors. Technical domain-level knowledge can be even valuable still, but if you're doing more soft-skill architectural guidance and mentoring you might still run into a shortage of companies willing to pay the same premium you're currently getting for that. Some companies may not need it, others may need hands on speed more at the moment. But in that case, they probably do need soft skill technical expertise + management, which at a small, young company is going to be much different than big-co management anyway, so that's an option too.
Re: On Being a Principal Engineer
#57Earlier quoted context omitted.
"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…
> 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.
> networking, which I consider unethical and don't do it
Humans are a social species, you can't avoid this if you want to get far.
Re: On Being a Principal Engineer
#58Is 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?
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 y…
> 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.
As they should, IMO. It's about the value you bring to the table (in absolute terms and over a theoretical replacement). If you're doing senior IC work, there's a limit to the impact that you are likely to have and value you are likely to create (and therefore to the portion of that value that you will bring home to keep as your own). That can be an incredibly enjoyable work experience, but there's likely to be some kind of a cap on it.
I am not the only tech executive who has said, "If/when I get rich enough to fully retire, I'm just as likely to take an IC role somewhere and just code for the love of it..."
Re: On Being a Principal Engineer
#59Earlier quoted context omitted.
> 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.
> use your networking, which I consider unethical and don't do it. I don't understand the sentiment. Interviews are a proxy for how good you are. The companies hiring are very limited by what kind of information they can turn up about a candidate just through that process and for higher leveled positions like staff+ that might rarely be enough. Your network can speak much better about who you are and what value you c…
I have seen how groups of people with dubious ethical standards played whole companies, pushing each other forward at the expense of more capable people, later taking their cronies with them to whatever company they landed, applying the same strategy. One of them made it to a director position at Google, largely propelled by "great networking". I can't with clear conscience support cronyism that deprives others of their shot at greatness and don't do it myself (rejected a couple of CTO roles advised by a friend with contacts etc.). I decided that expert/meritocracy ideal is better than what I see throughout the industry and academia.
Re: On Being a Principal Engineer
#60This 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 aro…
"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…
I would argue that company-specific historical knowledge is not the value you (et al) are bringing. The value is the soft-skills of effective leadership that distinguish Principal from Senior (to use the article's parlance). Successfully transferring this to another company is an exercise in knowing how to demonstrate and sell those skills. And, of course, in finding a company and an interview panel that understands their value.
Anyone worth their salt should realize that the long-term value of technical leadership far eclipses the short-term value of knowing what happened that one time we tried switching from Technology A to Technology B. (And unless you've completely purged your engineering department, such institutional knowledge is there to be queried.)