On Being a Principal Engineer
blog.dbsmasher.com
blog.dbsmasher.com
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.
Anecdotally, I was told that GitHub does not hire from the outside above the senior level. Going from senior to principal engineer is expected to happen inside the company.
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.
The bay area does have very big handcuffs, though.
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.
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.
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.
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.
Admittedly some org charts do grant "respect" - the same sort you give a rattlesnake.
How does that work? All the things you talk about are folded into my concept of "technical respect".
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.
A gem I've picked up from my experience in different kinds of tech companies: Never work anywhere where managers are the ultimate decision makers. At engineer-driven companies, managers are enablers.
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.
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.
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.
Isn't this "just" a matter of getting leveled at L6/65/etc as opposed to applying to an advertisement that's only looking for staff level engineers?
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'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.
That’s an incredible saying. It really encapsulates the “fall from grace” that a lot of celebrities experience. Never saw it put in a way that would relate it to my life. Thanks for sharing!
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.
Lesson learned : make a conscious and focused effort to acquire + maintain general skills and keep a visible portfolio updated!
But I feel more and more that growing in this company may be a trap.
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.
Part of being at the principal/staff level is the ability to effect corporate change for the good of the business goals.
If that isn't happening, you need to ask some very hard questions as to why.
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.
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.
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.
Please don't shoot yourself in the foot. There is nothing unethical about this.
Humans are a social species, you can't avoid this if you want to get far.
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.
Have you worked with people who you would work with again and vice versa? Congratulations, you are using your networking.
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.)
Any ideas for doing this other having a lot of public visibility? I may have answered the question already but there may be other ways .
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.
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?
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)
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.
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.
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.
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.
> Successfully transferring this to another company is an exercise in knowing how to demonstrate and sell those skills.
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.
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'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.
I keep a daily log of outstanding and completed tasks. It includes everything from high level sprint stories or tasks to setup meeting with such and such for some project or write status report for z.
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.
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.
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.
Sadly it’s often the opposite.
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).
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.
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 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.
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.
The only things that matter are really:
1. Whether you'd enjoy the work
2. How much you get paid
Titles are arbitrary and they don't mean anything outside a particular company. Even between otherwise comparable companies there are significant misalignments, see e.g. https://www.levels.fyi/SE/Google/Facebook/Microsoft
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.
These are folks who get hired by BigCos as "Evangelists". They're not gunning for the same roles that you are.
Oh hey... the system just works! : )
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.
Lesson I learned: I like small companies.
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’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.
Edit:
I usually don’t comment on downvotes, but I’m really interested in knowing what could possibly be offensive or disagreeable about this post.
- Technology/Career enhancement - where will this job put me in three years if I want to find another job
- Environment - I’ve grown increasingly picky about my environment and work life balance.
- Money - at least pay me the local median wage for what I bring to the table. Don’t insult me. But beyond that, money is the least important criteria.
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.
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.
What are some characteristics of a “expert beginner”? What did you realize you were lacking/weak points?
Unfortunately, you may not know until you get around people who have been developing as long as you have on paper but have learned from other people.
But this is my go to list of books.
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?)
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?
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.
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.
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:
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.
If they struggle writing code and don't know the syntax when given an IDE, why would I hire them?
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.
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.
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.
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.
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’?
Because you’re selling yourself. Interviews are sales. You are the product. Not your team, not your boss, not your company. You.
Yes they wouldn’t be possible without the inputs of others and yet you still did something. What was it?
If you can’t answer that question then this project shouldn’t be on your resume and you shouldn’t bring it up in interviews.
They're just saying: acknowledge team wins, but you still did something individually, be able to explain what that thing was in detail.
I am in support of this being the natural way of thinking. No one could do what they did without support.
I am also vaguely suggesting that maybe every company’s process of promoting, hiring or giving out bonuses is wrong.
If you think team dynamics just magically emerge that way around a complex technical project, you weren’t as senior as you thought.
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.
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.
He also asked me about my thoughts on hiring, mentoring, and testing strategies.
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.
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'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.
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.
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.
Also consider that at that point it's completely risk-free. If you just leave, you're not hired anyway, so regardless their response, you can only win from there.
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.
So far I've gotten pretty good and honest feedback from it. It also gives me an opportunity to explain myself and/or try to turn around any doubts.
I just accepted an offer at a great company, and I do think that it was in part because of the advice you gave me here, so I wanted to say thank you.
>> 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).
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.
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.
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.
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)
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 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.
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 i’ve never heard an understandable explanation as to why a company with 1 or 2 principal engineer level employees can have hundreds of VPs.
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?
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.
Jesus fucking Christ how is that even remotely acceptable as management feedback?
> 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.
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).
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.
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.
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.
PE 1: Complete fraud. He was also a people manager in addition to his endowed “expertise”. He oversaw an Outlook mailbox, and had a chokehold on any communication with the team. Any person emailing anyone in the team directly would be reprimanded that they should contact him instead. His primary job purpose was to read email, forward it, get reaponses, and then reply as himself. Doing this for about 20+ years makes you look like a 50x engineer. Especially when the people you forward to are other PEs and generally smart people.
PE 2: Was actual expert, worked for PE 1. This guy was humble, generally helped all the junior guys in the right direction, asked you how your day was, wishied you happy 3/14 (pi) day, and had rolled plenty of his own software to have cred. He made contributions that impacted 100s of millions if not billions of people worldwide.
PE 2 was sacked. PE 1 was promoted to Sr PE. Sr PE has serious employee retention issues, and is constantly on the prowl to sucker the next PhD grad into his honey trap. He has snaked his way into academic conferences with other people’s work. But who cares... I’m not about to get into a discussion about being morally righteous...
Context: large blue semiconductor shithole.
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.
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.
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.
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.
A senior IC that codes can stay relevant longer. The act of coding forces you to keep up.
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.
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.
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.
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.
There are many reasons you'd want more people (I don't know why you're jumping to the large number of 10... why not 2?) on this "core of the product":
* mitigating risk from the bus factor (https://en.wikipedia.org/wiki/Bus_factor)
* lessening the "information silo" effect (https://en.wikipedia.org/wiki/Information_silo)
* taking advantage of a diversity of perspectives/approaches
If these ideas aren't relevant, then you're probably not talking about a very important part of a company. If they are relevant and this is a critical part of your company, then it makes every bit of sense to build at least a small team around it, thus leading to the "principal engineer" earning his/her title.
What sort of 'guiding' others would he be able to do? He could spend 2, 3 years teaching a team of 10 everything he knows
You make it sound like he'd have to quit his job and become a professor. He would continue to work while teaching the people around him. They might never learn "everything he knows", but that's not a requirement. And there's every chance someone he trains might eventually surpass him. This is exactly what it means to be a Senior+ engineer.
(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)
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.
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.
The article is still good, but confusing names is a big problem for us engineers. "Senior", "staff", "principal" mean nothing if they don't mean the same thing cross-company
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.
You've made 4 other exact posts in the last 12 days: https://news.ycombinator.com/from?site=dbsmasher.com
Is it common HN practice to report the same thing until it finally gets attention?
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.
This is necessary because there are different grades of programmers. Frankly, some are better than others and social pressures force us to acknowledge it in some way.
It's been this way as long as I remember, one of the first things I was issued at my first programming shop was a chart that enumerated who was an entry-level 'E07', who were mid-level 'E08s and E09s' and who had reached the coveted rank of 'E10'. The groupings will probably be similar no matter where you go, though the titles will change.
I think it's a natural workplace dynamic.
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.
The answer for most people and organizations is no.
(Edited to fix typo)
I also think it is worth recognizing that the challenges of higher abstractions can be kinda fun. Different but fun.
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..."
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.
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.
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.
Disclaimer: I’m in my mid 40s.
We're struggling to formally define it, though. How much pure IC work do we expect of broad roles? How much coordination/communication do we expect of deep roles?
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.
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.
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.
That is unless you work for a company that is truly doing something unique or doing it at a unique scale.
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.
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.
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.
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.
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.
My only experience is with a full technical ladder being available, but the team technical leadership being the same as the team people management.
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 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.
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.
But generally once you start implementing your own ideas and stuff goes into production, it’s time to ask for a senior role.
Posted a related question here, if that's a better place to discuss this question: https://news.ycombinator.com/item?id=19130451
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).
What is the rationale behind a flat organization?
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.
Principle engineers are simply people who can design and build a major product, a major project, or even a company's technology by themselves, alone if needed to.
The labels are not at all important though (and can be fuzzy still - big companies use explicit numerical levels).
a project that could actually be built by a single person doesn’t have enough scope to warrant “principal”.
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.
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.
?
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.
To me this capture the right gist of being more valuable than senior eng.
Next for principal, it must involve business decision. Their work must noticeablely affect top or bottom line of the company.
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.
Of course that always starts with developing trust and belief from the engineers and probably even needs to be based on what they know and their experience.
That’s a separate issue from being a political lame duck hire who, even with engineer support, is blocked from being effective.
> 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?"
But hiring them into a position where they are automatically subject to pre-existing political barriers guarantees you won’t get value out of them.
Giving them autonomy means you could possibly benefit from their value-add.
The actual technical merit or cost effectiveness usually has utterly no correlation at all to how the business decision is made.
I thought you didn't want to be burdened with selling ideas, but just wanted authority to implement them without convincing people.
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.
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?
Even if you believe it's an accurate term, I find it a bit dimunutive or even condescending.
It solves for the decades-old "well now what?" mid-career dilemma where an engineer would have decide if they wanted to keep doing what they love (i.e. coding) or go into management for the comp but leave the work they love behind.
I found it freeing. Not at all condescending.
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.
On the other hand, one of my former coworkers when I was an IC is now my wife....
I've never heard of a principal or staff engineer before. I'm up on Twitter as @refactorkit, find me there, would love to chat
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.
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.
The progression is usually: Team, Cross-team, Organization, Industry. Competent technical decisions are table stakes. The real differentiator is at what level can they effect change.
"Leader" is one of the worst buzzword bingo terms in a company. It means nothing, it's just a convenient label to give people who you feel like promoting to maintain the 10:1 ratio.
You could argue Linus Torvald is an industry leader, or you could argue he doesn't show adequate leadership for cross-team.
Or maybe more succinctly: "If a great manager screws up, he should lay awake at night until he fixes it, just as a great engineer would wake up to fix a production issue."
These traits combined with a scope of influence is what I was referencing.
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 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.
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.
That's very basic design. System architecture goes up to: "how do we deploy 2 million hosts across 40 datacenters?"