Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On Being a Principal Engineer

blog.dbsmasher.com

Post reply on HN
Print view View original

181–190 of 337 posts

Re: On Being a Principal Engineer

#181

Post by imetatroll »

maxxxxx wrote: post #19
ryanong wrote: post #2

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 aro…

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

I 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.

Re: On Being a Principal Engineer

#182

Post by mturmon »

d4mi3n wrote: post #122
mturmon wrote: post #44

Earlier quoted context omitted.

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 p…

Hah, small world! My old man worked as a systems engineer in some of the spectrograph equipment on Curiosity. Did you by chance spend time at JPL?

Still do, but it’s a big place! Sometimes I get lucky and recognize someone, but your last name (just looked) makes that hard ;-).

Re: On Being a Principal Engineer

#183

Post by scarface74 »

OJFord wrote: post #116

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.

Re: On Being a Principal Engineer

#184

Post by Swizec »

chii wrote: post #166
Swizec wrote: post #150

Earlier quoted context omitted.

> 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.

Wouldn't that be just a round about way to lie about yourself?

No, don’t lie. Highlight your accomplishments.

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.

Re: On Being a Principal Engineer

#185

Post by scarface74 »

techslave wrote: post #107
jeffdavis wrote: post #43

This article uses "individual contributor" too freely. Many decisions even for small projects have long-term impact on thr team. Even if you believe it's an accurate term, I find it a bit dimunutive or even condescending.

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. stu…

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....

Re: On Being a Principal Engineer

#186

Post by roel_v »

solipsism wrote: post #106
nevir wrote: post #24

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 purel…

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/guidi…

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.

Re: On Being a Principal Engineer

#187

Post by solipsism »

mlthoughts2018 wrote: post #113
solipsism wrote: post #96

Earlier quoted context omitted.

I ... 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. How does that work? All the things you talk about are folded into my concept of "technical respect".

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.

Ah, so it wasn't that nobody cared about your perspective. It's that managers didn't care about your perspective.

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.

Re: On Being a Principal Engineer

#188

Post by jboles »

mac01021 wrote: post #128
ryanong wrote: post #2

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 aro…

Tangentially: anyone know where this use of the word "staff" comes from?

In some defence forces there is an NCO rank above Sergeant named Staff Sergeant, is my guess.

Re: On Being a Principal Engineer

#189

Post by D-Coder »

imetatroll wrote: post #181
maxxxxx wrote: post #19

Earlier quoted context omitted.

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

I 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…

"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.

Re: On Being a Principal Engineer

#190

Post by hoorayimhelping »

syndacks wrote: post #136
enraged_camel wrote: post #135

Earlier quoted context omitted.

>>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.

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

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.

Post reply on HN