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.
The challenge I have interviewing people for very senior engineering roles is how to tell the difference between somebody who was nearby when some interesting work got done, and somebody who made something interesting happen. What I’m looking for in a principal engineer is someone who turns good teams into great teams; who steers the organization away from disastrous mistakes; who enables the business to accomplish things that, without them, would not have been done.
It’s something that comes hard to senior developers, because we’re all aware that every result is a team win. So when you’re asked about a project you worked on, you’ll tell the story all in first person plural: ‘we had to solve this problem, so we decided to use this approach’.
When telling that story in an interview for a principal engineer role, make sure you clarify your role. What was expected of you, and how did you knock it out of the park? What parts of the problem did you have to take personal ownership of? Which decisions did you have to go to the mat for, and why were you right? Convince me you are a differentiating factor in successful projects and we’re going to be interested in hiring you.
As an interviewer I try to dig towards these things but it is hard and honestly I need some help from the candidate - and at this seniority level I don’t think that’s unreasonable (the candidate should know how interviews work because they’ll have been in the interview chair themselves, right?)
That's the challenge in all engineering interviews - determining weather they did anything useful or were just on the team. I've had to tell people to stop telling me about "we" and tell me what "you" did. Some people are so caught up in trying to be a team player that they hide their contributions. Others use it to hide their lack of contribution. It's not hard to separate these once you're aware of the issue and start asking the right question "what did you do?"
I personally always talk about what "we" did because it helps me get out of my own way.
I worked at a company for like 6 years, and for almost 4 of them i was the sole engineer tasked with designing a database for the data, creating and deploying/maintaining an API server, and creating a handful of react frontend applications. The last 3 years we expanded into a "team" that I led and scaled it up from there.
I never talk about what "I" did because I'm always afraid it will come across as lying or exaggerating, and at the same time I know that I didn't do all that alone even if I was the sole contributor for the vast majority of it. I had managers that helped carve out time and lay out requirements, I had executives that were willing to let me make multiple mistakes as I found my footing, I had devs focused on other areas at the company that I could bounce ideas off of and learn new skills from. And to be honest there were some months that I was SO productive that I genuinely don't think I could ever do it again, and I don't know exactly why it happened.
I'm currently looking for a senior/lead job, and writing about what "I" did and what I feel i'm capable of is by far the hardest part of it. I feel like I flip flop between basically saying "I was part of a team that did awesome things" and "I did all this awesome shit all on my own", and in both cases it feels like i'm lying.
Once I'm talking to someone I feel i'm really good at talking through the choices and tradeoffs made, the mistakes I made, the parts of the job I'm good at and the parts I feel I'm not. But I can't seem to write that down well, and I think i'm throwing away chances because of it.
Frankly, what you just wrote is what I want to hear in an interview. That you were first and the team grew around you and if mistakes were made how what would you do differently. To me, the company/team talk eats away at the limited time in the interview and doesn't generally matter since we are not hiring your company but how you helped is very relevant.
I will slightly demerit people if I have to resort to asking what they individually did as opposed to the team and a lot if I still don't get a good feel for it. I realize at large companies it can be hard since you might be the guy that maintains a small section of a website but I prefer upfront honesty to having to sort it out with more questions.
I feel I do great during the interview, it's just getting to that point is where I'm struggling. Writing that out seems to really bring out a part of my brain that makes it always feel braggy. (I really think it's the fact that during a conversation I have realtime feedback on what the interviewer wants and what parts I should focus on)
I'm "full time" looking for a job at the moment, and it's rough with how much of "nothing" you get back. A lot of no responses, no way to gauge how i'm doing, and even when rejections come in there's no information along with them to help me understand why or how to improve.
I'm trying to learn to write about myself more and feel more confident in writing about what i've done and that I really feel I was an integral part of the success of the things i've been a part of, but without any kind of feedback I'm constantly second (and third!) guessing literally every word.
A recruiter I respect said that the interview process is the most egotistical, selfish thing we do as professionals and it does the process a disservice if you do not follow it as such. Selling yourself to your peers and to those that want to hire you is important for the accuracy and precision of the hiring process if your contributions are not self-evident.
Getting good feedback is definitely one of the hardest parts though and thus makes getting better at interviews tough without good mentorship / network. Heard of a guy that was one of the top n TopCoder engineers and was having trouble landing a solid gig. Turns out he’d just zoom through the whiteboard problems, hardly talk, and interviewers were just weirded out. When he started slowing down and explaining his thoughts better to the panels he finally got the offers he deserved.
> A lot of no responses, no way to gauge how i'm doing, and even when rejections come in there's no information along with them to help me understand why or how to improve
If you don't come out of an interview and know you have an offer coming your way: assume you have no offer coming your way. It's usually very obvious and both parties are trying to say your hired without actually showing your cards. It's kind of a funny dance.
Your problem, where you feel you have no feedback is a problem but it's most likely a problem with you.
You need to be asking for feedback if you're not getting it. Get blatant if you have to.
What do I need to show you to get an offer today? What are you looking for? Your job ad didn't clarify on this this and this, can you spell out exactly what you're looking for in me today?
You're not really responding to my answers, is there something I'm not explaining well enough? Feel free to interrupt and get me to clarify, this point is important to me because it illustrates this skill which I think is important as a developer, do you agree, disagree or don't believe me? Why? What facts do you need me to spell out?
If you think it's on them to figure out how to be good at interviewing, you're right, it is, but that doesn't help you get a job offer today.
I appreciate the advice, and i'm going to try taking this to heart.
It's funny how i've been on the other side of the interview many times, and all the advice I'm hearing here rings true, and I know it is, but I just seem to have this blocker where I'm judging myself too harshly in all the wrong areas.
Regardless, I really do appreciate it, and i'm going to try and be more blatant and firm in this process.
One of the other posters here responded to you with:
>> Frankly, what you just wrote is what I want to hear in an interview.
I completely agree. Look back at what you wrote here. The word "I" appears plenty of times in your post and is very appropriate. You're talking about your experience so it makes perfect sense to mention yourself in that. You also mentioned the team and "we" a bit. Good. There is a lot of space between talking about your experience and being an egotistical jerk. Talk about your experience just like your post here and you should be fine.
When I interview I'm primarily looking for 3 things on the technical side:
1) Can this person DO things?
2) Can they learn things?
3) Are the interested in doing and learning the kind things we need done?
In that short post you've demonstrated #1 and #2. You also covered some of the non-technical stuff. If you showed experience or interest in embedded C on micro controllers I'd be telling you to apply here (Detroit area).
>It's not hard to separate these once you're aware of the issue and start asking the right question "what did you do?"
Another useful technique I've developed for interviewing senior folks is to probe them for details about important technical or other decisions that were made related to the things they say they did. I'll then challenge those decisions and make them justify and explain.
> The challenge I have interviewing people for very senior engineering roles is how to tell the difference between somebody who was nearby when some interesting work got done
When I was a technical recruiter, I could probably have faked my way through some technical interviews without much understanding of how to code. Now as a senior level engineer, I could probably do a pretty good job of sounding like I was the one who did the work that I saw someone else do.
> When telling that story in an interview for a principal engineer role, make sure you clarify your role.
> Convince me you are a differentiating factor in successful projects and we’re going to be interested in hiring you.
> As an interviewer I try to dig towards these things but it is hard and honestly
I haven't tried to hire a principal engineer, and I don't consider myself to be one, but if I had to guess how to interview one, I'd probably try something like this...
- prior to the interview, prepare specific reasons why we need a principal engineer in the first place, including answers to questions like "what do we expect from a principal engineer that we don't expect from a merely senior engineer?"
- I'd budget enough to time candidly talk with the principal engineer about what we're trying to accomplish, especially getting into details about what sucks & where we're lacking principal level help
- I'd ask the principal engineer for their thoughts on how they might be able to help, including how they'd go about establishing themselves as someone who could be successful in the role, asking them to go into as much detail as possible
- After that, I'd ask them whether they'd even enjoy doing that kind of work, to share some examples about having done similar work previously, and ask what they'd need to be set up for success
- I'd ask them to think about the position I'm in, and whether or not they'd recommend I hire them, and why they feel that way
Basically, I wouldn't try act like I know how to spot a good principal engineer. I'd do the work to communicate my needs for one, and let the principal engineer candidates help me understand what I'm looking for. If I didn't find a principal engineer amongst the people I'd interviewed, I'd have to trust that I'd have a way to feel that.
> It’s something that comes hard to senior developers, because we’re all aware that every result is a team win. So when you’re asked about a project you worked on, you’ll tell the story all in first person plural: ‘we had to solve this problem, so we decided to use this approach’.
As you said, good outcomes are team efforts. Even your best developer is not going to do anything great if he’s fixing bugs. Less senior developers prop up the senior ones. So why would we talk as though our specific roles were ‘special’?
> Even your best developer is not going to do anything great if he’s fixing bugs.
Honestly, I wish this mentality would go away. Maybe software in general is so "barely shippable" shitty because 95% of everyone's engineering effort is spent on cranking out features rather than fixing bugs and improving stability/performance. Somehow, feature work is glamorous and gets you promoted and quality is seen as boring, dead-end work. This really needs to change.
The best developers are the ones you can give the hardest bugs to and trust they get them done. The ones where the principal engineers see someone heading for your desk and jumps up to figure out why - stopping your interruptions is far more important than anything else! (You can't give these to the principal engineer because his job is to be interrupted)
I sort of hate the idea that senior people design and write stuff, while junior people fix bugs. In my experience this leads to developing code where "someone else will fix it up if there are problems" and in the long-run, is not good for the senior people (they get sloppy) or the junior people (they're not happy fixing others' crappy code).
I think a lot better model is ownership of code. If you write something, it's yours. If it breaks, it's yours to fix. If someone wants to change the design of it, they go through you first. Maybe eventually someone changes it so much that they own it.
What about the idea that senior people design stuff but then hand it off to junior people to write and then coach them through the bug fixing and refinement? (Honest question; doesn't seem like there's much of this where I work and I'm considering trying to introduce it because it seems to me like a good way to leverage the senior folks' skills while also transferring them to more junior folks, but I'm wondering whether there is some kind of taboo against it or something else that I'm missing)
Just curious, in addition to looking for those things do you do all of the same types of technical interviews for a principal engineer as for other engineer roles?
I would imagine a lot of principal candidates are older, maybe a little rustier at the rote algorithm type questions than a sharp new college grad. Do you expect a principal engineer to be along the lines of the best you've ever seen in every category, or do they just need a passing score in the various technical sessions and the differentiating factor is more of these leadership type questions and convincing you about their past successes?
Would love an answer to this question too. I effectively find myself in the role of a “principle engineer”. That’s exactly the reason why I was hired - with the expectations to be a “force multiplier” in the organization, which means I end up getting involved in many non-technical activities.
My actual job title is just “software engineer”, but title’s don’t mean too much where I work (a mid-size bank in Europe).
If I had my choice I would be spending 80% of my time writing and reviewing code, not just because I enjoy it but I feel like my coding skills are below what they should be and I want to spend more time improving them.
I struggle in programming tests. I find them pretty daunting. The value I can bring to a company is well known within the circle of people who have previously worked with me. From job to job, as long as I am touching that circle I can charge a premium. But the skills and experience I have are ones that rarely appear in a job description, and if they do they are usually under valued or the interviewers have no idea how to interview for such a position.
It’s a continual dilemma for me in my career now as I hit the big four-oh this year, and trying to figure if there is some way to be just a regular “software engineer” without taking a big pay-cut.
Even though I still have plenty of interests and drive to learn, the normal situation 10 minutes into any discussion with a recruiter is “here is a technical/programming test...” at which point I get defensive and say “I’ll only do it if I think your test is interesting.” But I’m half covering up for my terrible ability for performing tests like what you see on hackerrank.
It’s a continual dilemma for me in my career now as I hit the big four-oh this year, and trying to figure if there is some way to be just a regular “software engineer” without taking a big pay-cut.
Not that I’m looking to leave the company I’m working for now anytime soon, but I’m in my mid 40s and I think whenever I do leave, this may be my last full time software development job unless I find another small company I like as much.
My next job will either be an overpriced “digital transformation consultant”/“cloud consultant” or just a W2/1099 contractor where I come to work get paid and move on when the contract is over.
Luckily, I never have to worry about health care coverage again in 6 years since my wife will have guaranteed life long health insurance with her job after 10 years.
I’ve been working 20+ years and have been on the job market 7 times and dozens of interviews. I’ve only been asked algorithm type questions twice. The first was back in 1999 at my second job where I would be doing a lot of complex cross platform C and the second in 2016 when I was asked to write a merge sort.
I turned down the offer in 2016 to work as a dev lead at another company even though the company doing the algorithm interview both paid slightly more and was a permanent position and the other was contract to perm.
It told me a lot about the maturity level of the company that they would ask a senior developer algorithm questions and not architectural questions.
I’ve had my share of pair programming interviews and online multiple choice assessments but I’m okay with those.
I'm on the fence about that. Interviewing a senior developer, my experience is that it's still necessary to gauge their ability to code. Some can barely do it, I kid you not!
An if you claim seniority, I expect you, if not to know merge sort, then to understand it quickly and make a simple implementation and assume boring stuff like the length of the array ect. It is not difficult. It would be a great example to demonstrate programming proficiency and if you didn't know merge sort, how you grasp new problems.
I would put more weight on architectural discussion though.
Notice I said I have no problem with pair programming type interviews.
When I interview developers, I have a simple skeletal class based on a real world problem we’ve had with failing unit tests. They have to make the unit tests pass. Then I give them another set of requirements and unit tests they need to make pass without breaking the first set.
When I interview QA people, I give them a version of the FizzBuzz test. I tell them they have
a website that implements FizzBuzz. How would they test it. I want to see answers like this:
That works too, but the means to the end is less important than the result. I'm sure I would get the same from your approach, as I would with a simple programming problem question - algorithmic or not. Most of all it's a litmus test to see that they in fact know how to think in code. I really don't care if it's in C#, Haskell, or pseudo code - that's their tool of choice as long as they show the ability to solve a problem logically in code.
I purposely try to make it less dependent on environment and syntax because it's not important for the candidate to show that they can. I always interact with the candidate and try to get them to implement enhancements or edge case handling that's missing.
It's a minor part of the interview we get over with in the first round. But if they asked you that and nothing else I would've walked away too - no one with a clue have been involved in that process anyway.
I very much care that they know the tools and are not just a good developer. I need someone who can hit the ground running using our choice of language. Learning a language is easy. Learning to use the tooling efficiently and learning the ecosystem takes time. I'm not hiring developers to write algorithms. I'm hiring developers who know whatever language we are working in. I'm not going to hire a PHP developer no matter how good they are if I'm running a C# shop. Why would I? I can easily find C# developers.
If they struggle writing code and don't know the syntax when given an IDE, why would I hire them?
I'd rather have a developer with a solid understanding of FP, CI, integration testing, good programming practices, structure, refactoring ect., than one that knows the tools and tooling inside out. Ideally I want both, but if I have to choose it's the former. We have other developers that can get them up to speed relatively quickly, and they'll start with established projects anyway.
So now you’re wasting money on not only the new hire, but also taking time away from your existing employees.
Besides refactoring is a lot different and the tooling better for statically type languages. Good programming practices is also about idiomatic programming that comes with experience in the chosen language.
If I had to choose, the former is more important to me, and it works for us, I've not had a bad hire yet in a market where getting new developers is difficult.
Refactoring with or without tooling in static or dynamic languages, is about recognizing a piece of the code base that should be refactored and what the goal is. Tool and language can make this easier or harder, but that is again, something you can train them in and all new developers get a mentor for as long as they need, even senior developers.
In a similar vein: As a principle engineering manager, I feel awkward doing my “what did you achieve” write-up come review time, as it feels like I’m taking too much credit for what my team did - even though probably the biggest part of my job is defining the work and making the team productive.
I was asked a few question when I interview for my job as a dev lead: The one I remembered most was after he told me the current sad state of the department he inherited (not the people, the process) he asked me what was my 90 day plan if so sdrs hired.
He also asked me about my thoughts on hiring, mentoring, and testing strategies.
I absolutely hated my job as the dev lead for a medium size ($1 billion in revenue) non software company where we were a “cost center”.
I liked helping smart developers who wanted to learn, I liked having a seat at the table to decide my own destiny and the level of autonomy to decide the “how”. I didn’t like the red tape, the political jockeying, meetings and more meetings etc. I wasn’t really learning anything that could keep me competitive in the market.
I finished the green field project they hired me for initially, put it on my resume, quickly moved on to a small company and negotiated not to be made a dev lead and said I could help meet their objectives better by being a free agent and moving from team to team as needed and mentoring the younger leads.
I absolutely love my job. I have far more influence, autonomy, and a larger voice than I ever did at the larger company I left. I still mentor and advise, but I only have the responsibility as an individual contributor. I also get paid more because everyone including the CxO knows what I bring to the table.
I was in a similar position at the first place I worked for after the company I was at for 10 years. I was just a developer but I carried the weight of their biggest customer by myself as everyone else was trying to create the next project. I survived rounds of layoffs until the company folded.
Promotions are just a form of vendor lock-in that (especially) small companies employ to keep people longer. I’ve seen barely two years out of college non cs majors promoted to senior engineer based on finishing some “large project” which anyone else in the engineering team could have done.
The real sleezy thing is that by promoting someone to senior who isn’t nearly qualified at all, the company has now made it exponentially more difficult for these engineers to switch companies. Esp funny is the promotion of unqualified individuals to “project lead”.
I’ve seen many of these individuals move to next companies and revert back to standard level software engineer.
It’s never about titles - you need to be aware that companies are using the titles against you rather than for you.
Also it pisses off the engineers in your organization who do deserve a raise to see unqualified promotions. Its a one way ticket for a small company to very quickly lose its true talent (80/20 rule) and talent follows talent. Once you get a few supporting cast leave, even the actually qualified senior engineers won’t want to stick around longer because they will feel intellectually isolated as well as feel like the engineering management are inept.
I wouldn’t even go that far. The dev lead over one of the teams is far more qualified to be the lead over that team because of his company knowledge - he’s been there for five years. He’s a smart guy but I don’t know how well he would fare outside of our company. This was his only job out of college.
I’m one of the three oldest developers - two of us are in our mid 40s and one in his mid 50s. The “architect” is well qualified but he has a lot on his plate. The other dev in his 50s also fought against being made a lead.
I usually don’t comment on downvotes, but I’m really interested in knowing what could possibly be offensive or disagreeable about this post.
Yup, that was my last company . Had a bunch of inexperienced devs getting promoted to "Senior" all the time. I think I counted once and
figured out that we had more people working there with the title Senior Software Engineer than we did regular Software Engineer's.
After one year of moderate effort I too got the promotion, with almost no pay raise. The problem of giving everyone a certain title is you basically completely dilute any meaning or status it conveys.
I soon went on to FANG and am now a regular ol' Software Engineer again. But I'd much rather be bottom rung at a top company than a "Senior" whatever at a company where it means nothing.
I'm super appreciative of my current role for this and other reasons. I'm the sole software developer on a team of 6 people in a mostly isolated corner of the code base. I'm getting a ton of experience making calls and collaborating with non-engineers, while still getting to be involved in some broader discussions.
A company of 20-50 programmers seems ideal to me now, with an overall company size of <300. I feel larger might require too much bueracracy and smaller might lose out on QoL and scale of work that can be accomplished.
I wouldn’t go that far. Being the sole developer you risk becoming an “expert beginner”. I know that held me back for over a decade, being the only developer for three years and working with two other developers who never worked at any other company for 9.
"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.
I'm in exactly this situation, at Senior Staff level. It is quite possible that a person is actually getting paid enough to make it hard for them to leave, which seems strange because it's not not the norm. The company may want to keep them because of what they can do for that company, not because of their potential market value to another company. They may know things about you, that are hard for you to communicate in a job application situation, such as how you work with people.
I've decided to adopt the attitude: Enjoy it while it lasts, but don't count on it lasting forever. Live a lifestyle consistent with your market value, and squirrel the rest away. I'm also conscious about keeping my tech skills up to date.
I'm reminded of an old saying among people in the entertainment business: Think about how you treat people on your way up, because you will meet them again on the way down.
> I've decided to adopt the attitude: Enjoy it while it lasts, but don't count on it lasting forever. Live a lifestyle consistent with your market value, and squirrel the rest away. I'm also conscious about keeping my tech skills up to date.
Same here. Its kinda easy to be fooled into feeling complacent when you get compensated very well and are respected for what you do and have done so far. But it will never be enough to keep you around forever; there are so many failure modes that you have to think about the possibility of being on the job market again.
Which is another reason why (apart from plain old human decency) I do make it a point to reply to most of the recruiters that try to recruit me with a polite explanation that I'm happy where I am currently but please lets stay in touch so in the future if things change we can try again.
I can really relate to this. I 'climbed the ladder' in company X and thereby acquired a lot of company-specific domain knowledge that didn't really have much value outside the company. I realized what kind of a fix I was in years ago and started to lay some groundwork for moving to another firm, but it took until this year to find a company that would place enough value on my [opaque] work at X to hire me at a salary that was comparable.
Lesson learned : make a conscious and focused effort to acquire + maintain general skills and keep a visible portfolio updated!
Great tip, I feel more and more that my company has ancient tech that they still adhere to (basically as massive VM riddled with third party expensive proprietary software making it impossible to eat our own dog food even) and I now have three choices 1: Learn it and grow in this company but get stuck, 2: Force modern scaleable ways upon them (I've seen people try and fail but I hear more and more employees complain, perhaps I can be the one to lead change) or 3: Leave. I think I'll make this decision within 1 or 2 years (still a lot to learn).
But I feel more and more that growing in this company may be a trap.
I'm in the same boat. Funny how many people here are on the same boat. So many smart people but they feel like they can't prove themselves to land a job at another company. I feel that is one thing that stinks about our industry. I think option 1 and 2 are difficult..it takes a talented leader to pull off, but it may not be appreciated by people who haven't been there.
Meaning, it's easier to create a new project using x,y,z new tech. But to transform a company and bring business value from old tech, is more difficult.
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.)
Managerial principles also state that your value to a company is also partially based on the relationships and good will you’ve built that enable you to be more affective when you need something from another team or department and even the relationships you’ve built with vendors and customers.
I am believer in promoting from within for the most part.
At the companies I have worked at, hiring people directly into principal roles hasn't worked well. Invariably, they struggle to fulfill that role because they don't have enough knowledge about the inner workings, code base, etc.
It usually takes them at least a year before they contribute at their level.
Learn to talk about your accomplishments like an entrepreneur or executive would: impact with quantified customer and company value. Not “I switched our development from Java to Go” but “improved time to deliver new customer functionality from 8 weeks to 4 weeks through new platform choice. Improvements in agility yielded $8 million in revenue growth.”
Another thing I don’t see enough in this thread is emphasizing software you managed to avoid writing. That’s the real secret of being a 10x engineer: telling your organization when building something expensive is not necessary, either because you don’t really need it, can use something simpler, or can adopt something that already exists.
> Not “I switched our development from Java to Go” but “improved time to deliver new customer functionality from 8 weeks to 4 weeks through new platform choice. Improvements in agility yielded $8 million in revenue growth.”
This is important for any level job. Java to Go by itself is really only interesting for a low level position. 8MM revenue growth is a person that will almost always get another look. In general, using exact numbers that can be backed up is better because they tell the why.
Using the Java to Go example. Sure, the work was done but why was it a good idea? What did the company receive out of the change? How did the interviewee think about and mitigate the risks?
How does anyone quantify the value from something as generic as switching programming languages/frameworks to a number as specific as '8mm'? It could just as well have grown by that much even if there had been no switch. When I see formulaic nonsense like that in a CV, it better be meticulously sourced and they better be prepared to defend such a number in a potential interview, because usually I'll bin them with the other bullshit artists straight away.
> How does anyone quantify the value from something as generic as switching programming languages/frameworks to a number as specific as '8mm'?
In addition to what pm90 already said, if you can't quantify the value to the business on some level, then why are you doing the work?
My comment also said to back up the numbers. If I said I wrote a little utility and it saved the company 8B/year I better be able to explain how.
Also, the numbers do not have to necessarily go directly to revenue. Less bugs, faster feature development, less server resources, lower costs, better estimates, etc... are all quantifiable on some level. Is this an exact science? No, but this is what any engineer above junior (even they should be asking why are they doing something), should be asking themselves about every single engineering task. Because something is new and shiny is generally not a good answer, yet these types of migrations still happen in companies and waste large amounts of money.
One of the best things I've see engineers do to get their team the resources it needs is to spend time on modelling the value that they generate for the org. Speaking candidly... this could be any number at all, but most teams try to make it quantify the value generated in some meaningful way at least (even if that may not be admissible from a purely accounting/GAAP perspective).
e.g. it could simply be how much client data is processed by your system everyday, how many clients use it, what is the ultimate value the pipeline generates (even if that may be the cumulative value generated by the entire software pipeline)
Oh man, I see so many resumes littered with these kinds of statements. I totally gloss over them as they generally read like BS, and are formulaic enough that they just represent another "how to sell yourself" job-hunting checkbox point. Lots of devs would love to have some way to quantify our impact in monetary terms but the reality is that "process/tooling change X -> $Y ARR" is basically always hand-wavy made up math.
Sure, but most business decision making is based on hand wavy made up math. Like, how do you decide to build a feature or switch programming systems? Does it not relate to customers or revenue?
Also, yes, don’t have the numbers be BS or fail to include other useful narrative in your resume. But I so often see none of this, and leaving it all out is a sign someone hasn’t had to justify their decisions at that level.
In addition to tibbett's point (expressing technical accomplishments in terms of their value to the business), do some honest introspection on your value to your peers. I'm really just elaborating on Ms. Botros' article here, but for example you want to ask yourself these kinds of questions:
Do you improve the skills of the people around you? Do you identify and help resolve barriers faced by your peers? (This doesn't always mean fixing things yourself!) Do you improve the environment and culture where you work? Can you work collaboratively to establish a vision for change? How do you gain the buy-in of your peers when it comes time to implement change?
Internalizing these answers will prepare you to steer the conversation onto the skills that you know are important for the role.
I think you are wise to worry. Last year I was laid off from a company whose technology I helped build for years. I was promoted up to the position of "CTO"... with no team below me. It was a very small company working on email archiving and encryption that still runs today. As the system admin and solo developer I was spread thin, working on a system that now processes anywhere from 80 to 120 (150?) million emails a month. In the last several months I sent out my resume to at least 40 different companies, but the only offer I received was through someone my previous boss knows. It isn't a CTO level position.
To be clear I was let go because the company ended up having financial difficulties. It is a strange story to tell and sometimes I wonder if people think I am weaving it as I go. I'm not. It did leave me severely burnt out and I find the question "what was your biggest accomplishment?" to be a frustrating one during interviews because I did so much for that previous company that I almost don't remember any of the subtle details. I thought that the numbers would speak for themselves but nobody seems to care. I find it bizarre.
The other thing that might be fascinating is that the technical portion of interviews seem to be where things stall out for me. I would never claim to be an incredible programmer, but my previous companies system was not a trivial piece of software. I am probably going to give my one and only job offer a try and see how that goes. shrugs
Finally when I say build I mean to say that there was a PKI api + c library for interfacing that layer when I started. The website, the inbound/outbound email processing, the ES portion of the service etc were all built by me. So the parts that brought the actual customers were built by me.
"I find the question "what was your biggest accomplishment?" to be a frustrating one during interviews because I did so much for that previous company that I almost don't remember any of the subtle details."
I've kept a daily work log at my last few jobs -- just a line about each significant thing I made progress on, so usually one sentence a day (and often the same sentence for several days). This could be helpful.
“The other thing that might be fascinating is that the technical portion of interviews seem to be where things stall out for me. I would never claim to be an incredible programmer, ”
The interview process filters for coming up with solutions quickly. My strength has always been that I worked through a situation even after the initial or obvious approach(es) didn’t work. A lot of people give up quickly but I keep going and solve it. You sound similar.
Unfortunately the interview process doesn’t filter for that.
Yes we probably are. I don't usually walk away lightly from a problem that initially gives me difficulty, but the speed with which I can execute just doesn't seem to satisfy the hiring process. It is frustrating.
Market forces can be tough to predict. There was a dearth of software engineers in the last 8 or so years and many of us have reaped the rewards. The hacker news articles used to be about switching jobs every 1-3 years to advance your salary and career. I don't see so many of those these days, which makes me suspect that many have found themselves in senior-level or managerial roles that they find satisfying, and maybe some found themselves in architecture roles that are very difficult to advance from (but still pay well).
I think it more likely companies adjusted their salary bands to be at least in the ballpark of each other, so you either need to move locations or take a “riskier” job if you want an automatic large bump in salary. There are clearly exceptions to this, but in general, companies have started to wise up.
I’ve seen this happen even within the same (large) company. Someone is a director level who has maybe 100 reports. The entire product gets cut. The IC’a find other jobs within the company. There are only so many Director level positions around and many of them are achieved organically. The ex-director then goes somewhere else as a regular engineering manager unlikely to ever have such a position again.
Three of my former managers “self demoted” to an IC because they didn’t really enjoy management. Including one of my former managers who is in his late 50s who self demoted after his kids graduated. Now he’s a full stack React/C#/Azure developer and said he threatened to quit his job when they tried to promote him.
Yeah this is pretty common in most large enterprises. If your company is not in a hyper-growth stage (i.e. its a cash cow) then upper management positions become a game of musical chairs and political infighting as some leaders try to promote "their" people to top positions to hold on to their power and status.
I guess there are certain folks who find this enjoyable. Personally I find it a massive waste of really good talent and perhaps the single biggest reason why I enjoy the dynamism of the SV startup ecosystem even if I don't directly participate in it.
Yes, this situation also make uncomfortable.
My company needs me to create new features and design implement the framework, but those managers always get involved with me.
I known I can create more technical new features as competitive-advantages for the company at this stage.
That sounds like a liquidity problem (not enough positions opening up, and opening up infrequently) rather than a qualification problem (not qualified for director positions elsewhere.) Presumably, if the ex-director waits long enough they may find another director position (or not...)
> 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.
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.
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.
> 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 can bring to a company. I don't understand how giving a hiring company better signal about your value is unethical.
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.
> 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.
So says you. This can also be thought of more charitably that someone hires people they know because there is much less risk. I've been working in software for ~20 years. I have a decent list of people who I would work with again, know what they bring to the table, and their strengths and weaknesses. If I had to build a new team tomorrow, you can bet I would be calling the people I know first.
When I was a dev lead, you better believe I pulled in my former coworkers as well paid contractors because I trusted them. There was nothing underhanded about this. I let my manager and his manager know that they were friends and I had them go through extra interviews with my manager even though I usually had the final say about the contractors we brought in. I needed someone I could trust.
I just think you're over fitting to that sample size of one. It's like saying you're never going to talk to another human because two people once plotted a crime by talking to each other. You're conflating the ends with the means.
An exception to this is the "boomerang" engineer, who leaves the company as a senior software engineer and is hired back as a principal/staff engineer. At my company, there is a belief that it's easier to become a principal by leaving than by going through the rigorous promotion process.
There’s a five level ranking at my company, and I applied for a level 4 position (I’ve been in level 5 equivalent positions before).
My boss somehow talked me into hiring in as a 3 for some reason that I no longer recall. I should have listened to the alarms in my brain. I started mid-year so around 18 months I had to wait for a promotion. My boss quits a couple months before that.
3 years and still a level 3. Gave my two weeks and people high in the pecking order are sad to see me go because I’m good at what I do. Well thanks for the complement, but how about a promotion instead of a heartfelt goodbye?
Sometimes it’s not the bureacracy, it’s a boss who either isn’t good at bucking for promotions or burns all their political capital on other things. Other groups get people promoted. Everybody but my boss thinks I’m a level 4 and has for years. That’s how you lose people and never get them back (I wouldn’t want to work for this manager again, not for reasons of aptitude, but simply because he doesn’t prioritize things that I care about).
> there is a belief that it's easier to become a principal by leaving than by going through the rigorous promotion process
That's because in most places it is. The whole construct of "work above your pay level for years on end, and MAYBE one day you will be paid accordingly" is fundamentally flawed and will always foster an environment of low morale. That's a sucker bet, and is why people job-hop for meaningful career advancement. Promotions are little more than popularity contests, not unlike a beauty pageant. And much like a beauty pageant, they don't reward those who answer the judge's questions the most elegantly, they reward the ones who attract the most attention. If you want to know what a company values, pay attention to what it rewards/incentivizes, then ask yourself if you share those same values. If not, bounce. You'll likely make more money doing so anyway.
When you are employed they demand you show up every day and you supply yourself. There isn't an expectation that you wont supply yourself. After you leave but before you are hired back then there is demand but no supply. Leverage I guess. Makes sense to me.
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.
That happened to me, and in my opinion and experience:
. Now you're competing with other managers for managerial roles
. The way you sell yourself for a managerial role is different, and in some ways a lot harder, than an individual contributor
. You have the option of gunning for 'lead' roles that aren't necessarily managing staff. That's what I do.
. You also have the option of architect roles, which is also what I do.
You're a higher tier employee now, and you're now competing with others of that tier level. While for most of us it's actually harder, not easier, to find roles that match, the plus side is there's a reputation and comp upside.
The exception to the last paragraph are those that constantly broadcast on social media and make a name for themselves that way and doing presentations at conferences, etc. Not my cup of tea, personally.
> The exception to the last paragraph are those that constantly broadcast on social media and make a name for themselves that way and doing presentations at conferences, etc. Not my cup of tea, personally.
These are folks who get hired by BigCos as "Evangelists". They're not gunning for the same roles that you are.
https://levels.fyi is a good resource to understand where you stand laterally across many companies. Title inflation definitely skews a lot of this. Leveling nomenclature like “principal” and “staff” don’t necessarily correlate across other companies (for example, a senior engineer at Google could come in as a staff engineer or even higher at LinkedIn).
But even outside of titles, it’s difficult to become a new player and start from scratch on learning the inner workings of a company. I think the first step is establishing the confidence to make that move if it is going to be better for your career overall.
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 lot of technical respect from my teammates, but nobody cares at all about my perspective on architecture, scoping, technology investment, tech debt, etc. They had decided merely by the manner in which I joined to give no credibility to my ideas.
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.
> 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.
The difference is usually in terms of negotiating details about the budget & resources you’ll have when you join, your own much larger severance package or equity package with acceleration provisions, etc.
Based on the degree of resources they put into you at a director level, the option is disallowed for other people to fail to work constructively to onboard your new ideas / approaches.
Definitely still may not work out, but it’s a different ballgame than a high level engineering hire, which (however foolish) many companies will still view like they are sweetening some pot just with the title and don’t have any plans to honor the agreed nature of the role.
In fact they are not at all related. The engineers on my team bought into the ideas I was bringing as I rolled out implementations that proved the value.
Management however was less interested in increased value and more interested in entrenching their existing status and authority levels even if it meant torpedoing obvious and proved-out value-additive / cost effective engineering projects.
That really is a good heuristic. Managers at these companies should be asking, “what do we need to be doing?” and “what do you need to get it done?” If instead they are dictating what to do or only telling you what you can’t have, that is big trouble.
This probably had more to do with the org and the role than the title. Management probably recognized the gaps and shortcomings of the team, but never had buy-in from the team that these are problems and more senior people can help with them.
I think a director should only kind of "put value" to tech debt, making the mid-term and long term choices and assessing the risks. How to do the actual tech debt emission and how to deal with it when it hurts is more of a staff engineer thing.
If you think that as a director you'll have "power" to make actual week to week or month to month architectural or technical decisions you are thinking more of micro-managed projects and not of serious mid-sized or bigger engineering organizations.
I mean the general prioritization of tech debt as a continually worthwhile time investment / required basic hygienic activity necessary for product health.
As a staff engineer, I provided inarguable evidence that tech debt had been ignored to the point of extreme risk of product failure and revenue loss, along with well-scoped and iterative approaches to pay down the tech debt with ideas and creative effort from the existing tech leads and experienced engineers.
It was just squashed for political reasons. In this case, product management happens to be the part of the hierarchy with all of the “the buck stops here authority” and since tech debt did not contribute to visibly obvious progress on vanity features and cosmetic product changes (that had not been rigorously derived from product feedback, expertise or needs), then tech debt was disallowed from entering any quarterly goals, etc.
Director or certain “org wide” IC roles could plausibly have authority to stop that.
Sorry if I have the impression this was about micromanaging weekly tech debt stuff... definitely not.
I mean I'd consider myself somewhat experienced with the tech I have. But practically speaking, if you have a company with a somewhat established technology stack - or 2 or 3, commonly called legacy of some degree.
How would you have a thoroughly constructive opinion on moving the tech stack away from legacy and towards a more productive situation, without understanding the needs, situations and interactions of a company? And this takes time to learn.
In fact, even just learning the needs, goals, capabilities of different teams in an org just takes time to learn. Sometimes the path forward is to tell everyone to just do it. But no one talked with each other and thus, this never emerged.
Company size seems to (rightly) play a role in how many levels there are in the career track. Part of the mentality that the business needs to take off before titles are concerned. However, this would most likely apply to <20 person engineering team. If the engineering team is bigger than that, I'd question why the org structure is flat.
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 interesting question in terms of human capital and labor mobility.
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.
This is not true in engineering contractors for aerospace in Europe or the USA, and it's also totally not true in the oil industry worldwide and in some of the big manufacturing firms. You can get double digit percent promotions by getting into roles that require a lot of travel, dealing with big outsourced contracts, have cross-country responsibilities, or other particular skills or layers of hardened skin that are hard to come by and at a premium.
Tribal knowledge is good to have, and inevitable, but it is also a blinder that tends to limit people to a particular set of architectural assumptions, and this gets worse the older the company becomes. It’s also an obstacle to bringing in new people.
Some people are able to join a company and expand/modernize/build on the tribal knowledge to make things better. It’s a rare gift but I’ve seen a few people do it. People like that could be a principal engineer at almost any company.
I've seen engineering leaders at companies with lots of tribal knowledge who have been there so long and are so committed to and defensive of old decisions that they're net negatives to the company. They're like helicopter architects.
>> I am not sure if the title of "staff/principle" can be transferred
It usually can, actually, assuming you're going to a company of roughly the same stature. I.e. if work at a small company, your title doesn't mean much when going to a large company unless you're otherwise known in your field. And if you're a Staff engineer working at e.g. FANG, you can demand the "God Emperor" type title at a small company and you'll probably get it if they feel they need you.
>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.
Outside of the politics and trust portion, most of this should be well documented and not something that relies on a person being around. What's been tried, and why, should all have documentation around it - what worked, what didn't, how the decision was come to, what data points were considered, etc. All of that is valuable, and it should have all been documented along the way to help back up the decision making process to begin with.
When the time comes to make decisions in that same vein, people can review the previous process. Maybe they have new information to bring to the table. Maybe they didn't account for something that was considered last time. Maybe the "you" of whatever process is no longer with the company.
I'm in a similar position to you. I've made it a mission the past couple of years to try and eliminate myself as a single point of failure for this sort of information.
To the second point, just because the job posting isn't there doesn't mean the job doesn't exist. Companies might not be looking to necessarily hire a staff engineer specifically, but could see the value in one if the right candidate appears.
I am a Principal Architect/Engineer at a mid-size company (~200-300 engineers, 1500 total headcount).
I would consider myself a Principal Architect, Senior Engineer, Senior Implementation Specialist, Mid-Level Product Owner/Manager and Junior Account Executive when it comes to actual job breakdown on a day-to-day basis.
I'm fielding important sales calls with the team, help troubleshoot important implementations with clients, and design systems and generally try to lead the Seniors/Leads across teams towards a common goal.
That said, if it really comes down to it, I can also roll up my sleeves and sling some code - usually as effectively as the Seniors/Leads.
I actually think the above skills are as transferable as the raw tech skills. At the end of the day, we all have to actually _sell_ software that is useable/valuable to our customers. If you're in the position to prove/demonstrate that it really doesn't matter the stack.
Plus, all the failures spanning the XXXXX teams you assist are sure to teach you _something_.
(FWIW, the actual teams I interact with are not the original team/product I started at with the company - we were a startup that was acquired)
> I am not sure if the title of "staff/principle" can be transferred
It depends on how you got to be a principal. If you fell into the role because of accumulated knowledge and promotions, probably not. If you are self-driven, work to achieve complete knowledge of your company's products and technologies, push for high standards, and can transfer knowledge well to others...yes.
> 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.
I can confirm this; about three years ago, I was in a position that was similar to this post's description of a principal engineer - doing a lot of code reviews, meetings across teams, interviewing, etc. I haven't had a similar position since; it's a very er, opportunistic one? In that you need to be in an environment where there is a need for a role like that. It's a role one needs to grow into.
With every organization, once you are part of a product initiative for a few years, this question of "how transferable are my skills to a different domain or company?" is a valid one to ask oneself.
Also, it is easy to get so involved in the daily busyness, that your skills might not be transferable.
I think spending some time in being curious and learning/investing in transferable skills, and building a "brand" of helping others(either online or in person) helps significantly when it is indeed time to pursue that next opportunity.
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.
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.
I left my previous company before their ladder (~14+ months of work) was finally released so I'm not sure how it has worked out but one of the first drafts I saw had a rubric for gauging your growth / fit for the roles.
One of the biggest things I took issue with was that you had to have some sort of "community involvement" but management had to approve your speaking engagements to some degree (be it time off, messaging approval, etc) so it was quite easy to put up a lot of blockers to achieving that. Who knows- they may have dropped that part.
The most striking thing to me, between this article and what happened in my personal experience, is that I was told "your technical skills are senior level" "but you are too emotional" to promote. I don't deny being emotional but as a reason to deny promotion on a tech track? Would they have said that to a woman or is OK since I'm a man it's not an inappropriate comment?
>I was told "your technical skills are senior level" "but you are too emotional" to promote.
Funny. I got a direct opposite experience. Being told that I got technical skills, but I focus too much on the technical side and don't consider other engineers' emotions. The team was pretty toxic though and I'm happy I left as soon as my lock-in expired.
That seems like fine feedback as long as it was coupled with further specific and actionable feedback. e.g, "You yelled at Alice and Bob in the discussion about project X, rather than helping build a consensus about the right solution." Senior engineers should be solving problems in the org, not causing them.
The VP/DE ratio just reflects how likely it is to have that level of impact. A VP is typically not just "a great manager", they drive the product vision and ensure you're building the right things. A great engineer can produce similar impact but it's a lot less likely.
> if you actually want to have a chance of moving up to those levels of pay, you had better go into people management
Your own strengths and weaknesses as an individual are are much more important part of this decision than the baseline probabilities of becoming a DE or VP.
I know a (non tech) VP at a FAANG, his base salary is the same as mine and I am nowhere near SV/West Coast/NYC salary - he will get an extra $70K a year between stock and signing bonus. He asked me would I be interested, I told him that the pay difference wasn’t enough to make up for the cost of living difference. He then told me that most of the software developers make more than the non tech/business VPs.
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).
This sounds like standard title inflation, and it's not restricted to just technical ladders. It's certainly a problem, but I don't think we should discount the idea of principal engineering roles just because job titles can be misused or abused.
The company I'm at has a single principal engineer. He was hired externally. Within a year of starting, he'd had a bigger impact across teams than the CTO in the same time period. He doesn't necessarily write tons of code, but he's also not sitting in an ivory tower telling other developers what to do. Rather, he very quickly got in tune with the sorts of technical problems being faced by basically every team and developer at the company and started introducing various techniques and technologies to resolve pain points around the organization. Before long, we were doing things that wouldn't have even been possible before.
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.
I don’t get that but it does happen. I don’t want to be stuck working on the same project forever and the only ways I can avoid that is by documenting everything, using off the shelf widely used frameworks where documentation is available and cross training.
I do agree with your sentiment and I am always genuinely curious about whether an organization chart would stay the same if the whole team was fired and re-hired. If not, then how can you counteract this organizational-rot problem. Also how to understand if you yourself is the part of this problem.
Interesting. At both Amazon and my current employers, engineers at that level have to be able to both talk-the-talk and walk-the-walk. No resting on laurels and being buried in the past.
Anecdotally, one of the distinguished engineers at my current place came from a similar role in Google. They left Google because they kept putting them and a number of other distinguished engineers on products and projects that would never see the light of day, or be turned in to an actual project.
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.
> 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.
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?”
> 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?"
It might be just me but I think a lot of people read "Selling ideas" as "demonstrating the technical merit of ideas".
Unless the requirements are brain-dead simple, you'll need to sell at the very least the criteria on which you're measuring technical merit: is a latency number a hard requirement, will it scale for x of years, will it be buildable in y months or years.
At least some of that is going to come to convincing someone you've done your homework even if they couldn't make a better decision right?
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.
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.
>>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.
I didn't say they can't function as an individual contributor. I said they can't function efficiently as one. Meaning: the opportunity cost would be too high, since the alternative is that they help their more junior team members grow and also help the company make the right decisions when it comes to things like system architecture, tech stacks, features, etc. Those types of contributions can be several times more valuable to the company.
Maybe what John is getting at is while a Principal can do that for a while, at some point their tech chops will get out of date and rusty, both in terms of industry knowledge and the company’s internal stack and best practices. At that point they may lose the respect of more junior engineers, which is a poor sign for company culture.
A senior IC that codes can stay relevant longer. The act of coding forces you to keep up.
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.
They multiply the skills of the people around them. They make everyone else better. It can be via a tool, a process, good code review, opening a path of knowledge, being supportive, giving confidence, listening well, or any number of other things.
Gandalf in the battle of Minas Tirith is a huge force multiplier. He embiggens the courage of everyone near him and makes them fight harder and better.
In my experience a 'principal' security consultant (I'm in infosec) is the same as the principal engineer you mention. They talk a lot but are so busy, they delegate everything and are very out of practice. If any actual work needs doing, they delegate not only because they don't have time but also because they would need to relearn and look up a lot of things. The junior and senior roles, however, are often pretty accurate descriptions, though the biggest difference is often in management skills and not in technical skills. Some juniors can't do anything and some are as good as some seniors will ever get, but in terms of talking to higher ups or negotiating between companies, there is usually a clear difference. And if a principal consultant still has technical skills, it's not noticeably better than a senior's.
I see a lot of ridiculous titles, too. I think he addresses that in the "myth of a flat org" section. To continue his "all databases have schemas…even the ones that say they do not" metaphor: over-normalization is bad, too. It's hard prevent muddying titles with things like vanity, but a well-named title gives shorthand in large orgs or when new people come on.
Of course knowing everyone individually is best, but that doesn't scale.
Most of the places I've worked are small to medium. Titles don't matter all that much. One place tried to develop a technical ladder to coincide with their management ladder. I don't think it worked out too well, but they did establish "leads" that were more likely to hop around and mentor. It didn't really change their responsibilities. It just formalized and endorsed what they were currently doing. It really helped to narrow down for people who to go to and allowed those leads to spend time on those kinds of issues.
Unless all your company's projects are uniform, there's probably some informal ranking of who can be trusted with the biggest and gnarliest objectives. For us, the title Principal just formalizes your position at/near the top of that ranking for the entire engineering organization. For a division it may be Staff. For a line manager it's Senior.
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...
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.
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.
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.
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":
* 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.
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)
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.
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.
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...
This is an unfortunate consequence of the stair step approach to salaries most big and medium sized companies use. A L4 person makes this much (or within that narrow band) and if you want more, you need to get promoted to L5, at which point you make a lot more rather than just a little more.
If we didn’t tie comp to a small number of discrete “levels” an instead made it a smoother slope, then people wouldn’t be so focused on levels and titles.
Additionally, it doesn't help that some customers of consultancies ask for senior consultants. Surely the consultancy firm wouldn't label some semi-juniors as senior just to be able to put them on more projects and/or sell them for more money?
> "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.
Yes I have seen Principal Engineers with <6 years and >20 years of experience. And no it is not a coincidence. Those who stay put tend to get promoted earlier because of tribal knowledge they have. They may be lacking in core tech skills but they are still more valuable for management than people hired from outside due to their insider knowledge esp. if the work is not that technically challenging (crud apps/some business logic)
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.
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.
I think it is just the opposite. Principal engineers are PEs because they don't want to manage people but instead be responsible for technical systems. That said, I've seen PEs be managers of small teams (~4-5 engineers) for short stints when the org had a need and there wasn't anyone else to manage.
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.
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.
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?
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.
> 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..."
I would call it more of a plateau than stagnation. The senior title is a pretty beautiful spot, well paid and always more to learn but the value to the company is limited to the work you get done. You may be able to get it done faster and better than anyone else, but there are diminishing returns on speed and quality of an individual. I miss being a senior sometimes. Being able to go heads down and pair with someone all day on a problem was a great feeling, but I enjoy how much I help my coworkers/friends.
I agree with what you have to say about it being a plateau... but what are these companies where a senior engineer's impact is limited to the work they get done as an individual?
Part of the definition of "senior", everywhere I've read it, is that your impact has started to spread outside yourself and to the team level. If you're a "strong IC", you're not a senior, in my reckoning. You're a senior when you're pulling up those around you.
There are at least a some people that are so amazingly good at e.g. optimizing assembly routines that they have a very high ceiling on their comp even if all they ever do is that and maybe an occasional talk or blog post. But as you go further and further out on the definition of "very high" it gets rarer and rarer.
The bigger issue, in my opinion, isn't the ceiling on comp. It's the job security as you get older. A lot of the people in their early 30s thinking "the senior engineer role rocks, and $250k total comp is more than enough" aren't thinking through their plans are for their 40s and 50s. Some are, a fair number with that mindset I've meet are into the early retirement / financial independence thing, but many aren't.
Yes, cranking a lot of quality code still gets rewarded in most companies. Just don't expect to reach the highest levels of seniority with regular promotions, or say, a fat bonus/RSUs, since your impact is smaller than the type of engineers the article mentions.
In this current market I would say there's absolutely a stagnation if you are not finding other ways to provide value. There are others coming up from behind who can arguably provide the same value of just coding without thinking much about strategic decisions down the road, and they might be cheaper to boot. And those people might be more willing later on to take on the mantle of these decisions.
> code without getting to design and architectural space
Then your impact is limited. Truth is, you need to do high-level thing to influence more people because that is more efficient and valuable use of your time. Implementation is fun and useful and all, but it can't scale beyond certain scale.
I always felt the higher the level the less the impact but the bigger the credit one will take.
The CEO sets the goal of more mobile connectivity this year. The VPs come up with high level projects. The managers assign the work. The programming team does it. The higher up the lesa the real impact.
These companies usually expect advancement, and advancement requires participation-in/production-of higher and higher level design/architecture. You can hang around for a few years, but eventually people are going to ask why you're not progressing. Depending on the FAANG you'll either be stack-rank laid off, or put on a PIP and pushed to voluntarily leave.
EDIT to add: On the contrary, non-FAANG is where you want to go. At many non-FAANG type companies you advance based on a combination of success and tenure. You'll accumulate raises and promotions just as a function of sticking around doing your job.
I know, because at such a company I became a manager and then was made aware that a person reporting to me was making twice as much as me. Because he had been there 10+ years, just producing code.
Are you sure he wasn’t making twice as much because he brought more value? There is no reason that your report shouldn’t make more than you. In fact I’d love to manage a team where everyone makes more than me. That would be amazing!
What I meant to say by "just producing code" was that he wasn't having much of an impact on people around him. He was producing a regular amount of good code. He just had been there forever.
I agree completely that there's nothing wrong with managers making less money than people they're managing. The only reason I mentioned that he reported to me is because that's the only way I became aware of his salary.
You can do that...work at a company and just make more money without learning anything new. But more than likely your job will end before you are ready and you will find it impossible to get another job. While I do think ageism is overblownef for experienced developers who have kept their skills current, it’s almost impossible for an older person who hasn’t kept their skills current to find work even as a junior developer.
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.
The senior/principal distinction is relative, of course. At my org, there are two flavors of principal (when the justification memo is written — the final title is the same.)
First, “state of the art”, with publications and recognition by professional societies. This is relatively easy to distinguish from a Senior, because the publications mount up.
Second, “state of the practice”, with extensive influence on major products/outcomes. The justification in this case usually comes in the form of testimonials like “X led the design and delivery of Y, and without him/her Z, for which Y is critical, would not have flown.”
This kind of person is harder to distinguish from a “solid Senior”. There is some resulting soreness among seniors who haven’t climbed to Principal. There’s a committee of Principals that gives recommendations but management makes the final call. Sometimes retention and organizational strategy are in play, besides just on-paper accomplishments.
Hiring directly into Principal does happen. The committee above makes a special out-of-cycle meeting to review such cases.
So, the difference between Senior and Principal can be in the visibility of the results and level of difficulty. The principal can still be the motor of a relatively small team - as small as 4 or 5 people - if the scope of the accomplishments is enough.
Specific numbers may be helpful. There are also two levels above Principal, Senior Research Scientist and (highest) Fellow. There are about 40 fellows in an org of 6000. There are about 250 principals. One of the fellows is Adam Steltzner, who designed the sky crane landing system for the Mars Curiosity lander.
I think it depends on the organization. But I think the distinction made in other comments is a good one. You can't really be a "principal" until you are familiar with the organization, the products, the people. And in reality, while most every engineer can become a "senior" contributor, only a few senior-level people can have the impact being described here to truly be a "principal".
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.
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.
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.
I guess this is off-topic, but this is hitting a chord for me. I've been fighting with HR for quite some time about this. Over the last 2 or 3 jobs in fact. Yes it's great to hire the miracle senior guys that'll fix everything. It just doesn't happen.
In my book, it's beneficial to stop thinking in titles, and start thinking like trades, in tasks. As a team you have to execute a number of incoming tasks. Tasks collide with a team member, and they can either handle the task or they can't. If they can't, they can ask a more experienced member to split up the task into more manageable pieces.
This has a powerful effect - you can usually add less experienced people to the system to get more throughput. As long as someone can split their own time consuming tasks into simpler tasks they can delegate, there is more throughout to be had.
And this in turn teaches people about the technology involved. Yes, you're just following instructions, but you should be picking up knowledge about configuration management, application management, databases, terraform, and so on along the way.
And with that, it's a lot easier to find people, because we can hire people directly from education. And I'm ethically fine with hiring people from education, because we're teaching them a broad set of valuable skills.
Sorry for the rant. I've been discussing the whole senior shortage for far too long.
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.
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.
Orgs than blend people management with technical management seem suspect to me. You need to get elbow deep in problems to maintain the technical leadership and it doesn't happen often that you can do that if you're also in the middle of recruitment and communication and 1:1s and all the other machinery of management. Further, the authority of people management conflicts with technocratic leadership, which should be much more meritocratic.
People management requires a different set of skills to technical leadership. Looking to the same person to provide both is unlikely to be successful, IMO.
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.
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.
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.
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.
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.
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).
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.
This is definitely the case of different organizations having different labels for the same thing. Going by the article, "senior engineer" would translate to "engineer" and "principal engineer" to "senior engineer" in our company.
The labels are not at all important though (and can be fuzzy still - big companies use explicit numerical levels).
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”.
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.
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.
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.
My name is Molly Grice, I live in Las Vegas. My old friend of mine referred me to REPAIR WIZARD, He could assist me with boosting credit score. I contacted him and we proceeded. After 5 business days, he help me increase my credit score to 800 excellent plus. He help me clean up DUI report and Chexsystem on my credit report. His service is fast with a specific service charge. Contact details :
REPAIRWIZARD4@GMAIL.COM+1 520 441 6516
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.
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.
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....
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.
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.
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...
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.
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.
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.