[nilkn]

In my experience, many companies legitimately don't really know what to do with very senior engineering staff. And how many distinguished engineers or principal engineers or technical fellows do you really need for your relatively straightforward technical challenges anyway? The IC track often fails to work in practice for the simple reason that technical work at an extremely high level is just not needed at many companies as much as engineers want to believe. Very senior ICs are also difficult to manage in the sense that the more you pin them down to specific work or projects the less you benefit from their skills. But sometimes all you need is to be able to assign someone to a specific project that isn't all that glorious or interesting or hard but is valuable and needs to be done by a certain time.

[baron_harkonnen]

My experience has been that the value of very senior technical staff is not that they solve "extremely high level" technical problems but they are very easily able to see how what appears to be a complex problem is isomorphic to a much simpler, easy to solve problem.

The difference between expert and advanced/intermediate technical staff is that the advanced engineer has an understanding of complex solution and mistakenly tries to apply them everywhere, so the net effect is to increase complexity. The expert typically sees simple solutions and method of resolving complexity and has a net effect of reducing overall system complexity.

Believing that the value add of experienced technical staff is to only solve really hard problem is likely caused by having too many advanced/intermediate people playing the role of experienced technical leads. All of the great technical team member I worked with always make call solutions simpler and easier to implement by knowing exactly what doesn't need to be done and what is essential.

[MarkMMullin]

Much of the last 2 decades of my career has been as much principal work as I can get, and everything I know says you smacked this ball out of the park.

First, if the title is real, then the term Principal carries serious weight, and hews as closely as possible to the best definitions of Principal Investigator (yah, academia has been busy making a mess of that)

More often than not, a good PI knows that all problems don't need the most powerful solution, some just need to go away. If a claimed principal is always applying the most complex solution everywhere, then they're bad at their job.

A good 1/3rd of my benefit is not going 'zomg - a hard problem' to my co-workers, its the exact opposite. And even when it is a hard problem, at least half the time then it's 'Don't worry - here's what Djikstra/whomever did to solve it'

I love advanced algorithms, and relish the chance to actually go try and make ones - that said, my main value is not that, its that some horrible new problem erupts, my job is to say, 'no, calm down. That's an old problem in a new suit'

That said, switch isomorphic to homomorphic - I'll give the seniors credit, they usually tag the isomorphic cases . :-)

[rzzzt]

Solving NP problems every day.

[nilkn]

The fact that folks can't even agree on what constitutes a very senior IC is definitely part of the problem. I would consider what you describe here -- reducing complexity as opposed to increasing it -- a requirement of any senior engineer. I don't see this as the hallmark of a principal or distinguished engineer but rather one of the basic differences between a developer and a senior developer.

[cpitman]

As my employer has tried to define the principal IC roles, I've actually seen the perceived qualifications of the original roles go down. IE, what would have been consider senior qualities are now principal qualities, and seniors need supervision. I believe it extends from the same root cause: not knowing how to get value out of a more senior role.

[Normal_gaussian]

I had senior in my title at my previous organisation. Something I found hilarious given my years.

The reasoning seemed to be autonomy. Until they hired people who were senior by age but not autonomous.

Engineering titles are a mess and it causes real problems when moving to another organisation.

[ljm]

Something that explains this quite well (IMO) is the Dreyfus model of skill acquisition. You’re essentially talking about the difference between a proficient engineer and an expert, but I also think you’re suggesting there’s a 6th level: mastery.

The beauty of the model, to me, is in the separation of skills. Being an expert programmer doesn’t make you an expert in mentoring, or leadership, or architecture sometimes, and if the place you work has any flexibility with its career setup, there’s plenty of opportunity to branch out once you think you’ve maxed out your current tech tree.

... or you quit and get paid more elsewhere/go consulting/whatever ...

[oarabbus_]

Would love to hear some examples of experts decreasing complexity and advanced engineers increasing complexity.

[nilkn]

A hypothetical example would be one person spending a week or two setting up an extensive in-house Spark cluster to solve a problem that a second person in one day realizes can be solved on one machine using some clever shell scripting tricks. The former person knows a lot and may have been fully capable of the solution the second came up with, but they followed the wrong guiding principles in analyzing the problem and arrived at a solution of considerable complexity.

An alternate formulation of this would involve the second person above arriving at a new job, observing that they're using Spark on an expensive cluster to regularly perform a computation, and noticing that actually they could do the whole calculation on a single node using simpler tools.

[oarabbus_]

Thanks for the example. Once I did some analytics consulting with a stealth startup with some very talented engineers. One of them was usingusing rsync to replicate their data from their eng server to the analytics server, and I (not a software engineer, but familiar with shell) was initially like "that's it? You're just using rsync instead of <complex, paid replication tool>?" But it was the simplest and most straightforward tool for the job.

[saberience]

You could answer that example problem just by being someone who reads Hackernews a bunch, since the "replace spark cluster with random unix tools" article appears here regularly. IMO, that doesn't really define being a principal engineer, it's basic.

[foobarian]

Principal engineer: arrives at company, notices expensive Spark cluster, replaces with one server running shell scripts

Double digit-strong data science team: speechless

[nilkn]

I don't even agree that this is a defining quality of a principal engineer. This is part of our standards for a senior developer, and it's something we coach people on from the get-go.

[bsder]

Designing a delta-sigma modulator.

Team engineers: we need a high-speed design with advanced adders and someone who can do the difficult static timing analysis.

Expert: No, you need someone who actually understands VLSI design who can interleave time and space in an algorithm. At that point, you can basically use a single step up from stupid-simple ripple carry adders. And if you use non-overlapped clock generators you don't even have to do static timing analysis. The biggest wins are in architecture, not implementation.

Yeah, 33MHz design in 125nm means VLSI like it's 1999.

[inerte]

There's Juicero https://blog.bolt.io/juicero/

[Spooky23]

I'd say that 80% of the time, the IC track is bad for the ambitious, non-consulting engineer ultimately, unless your plan is to move around alot, which is a strategy that gets riskier as you get older and better compensated. Even for the consultant, the path to growth is... hiring people and leveraging their labors!

End of the day, the size of your tribe or budget is a physical manifestation of your power in an organization. Power is how you get stuff done -- all of the right answers don't matter if you cannot realize the outcome. IMO, it's critical to grow as an engineer to be able to get others aligned to whatever task is at hand.

My career is very much in the applied space -- my perspective is someone delivering solutions, not inventing tech. It may be different for different disciplines/scopes.

[pm90]

This is an excellent point. About 80% of the time, this is how it plays out in most larger orgs.

The interesting thing is what happens in mid size to smaller companies, where organization structures are not as well defined. You still need people here, however, if you know the stack very well or are a proficient IC, you can make contributions that can have a significant impact on the org, and gain the trust and allegiance of many engineers, albeit informally.

I've seen this happen a lot. A senior engineer will either create or integrate a new tool or process which makes life easier for other teams. They are grateful to the person and are much more willing to hear the engineer out for future designs and projects.

All that to say... just having a title doesn't get you anywhere. You have to build trust by delivering value, however incrementally. Maybe this is really trivial stuff, IDK.

[vkou]

You're not making a great case for senior ICs being impactful.

I mean, what you described is one way to deliver senior-level impact for a team.

However, this has a very important problem. Every time you join a team, you have to build up this rapport from scratch. If you switch jobs every few years, you'll find half your professional time consisting of busting your ass to build up rapport, only to have to start from zero at the next job.

When you're hired as a manager, you don't need to do (this kind of) rapport building. You just tell people what to do, and they will build it.

[pm90]

> If you switch jobs every few years, you'll find half your professional time consisting of busting your ass to build up rapport, only to have to start from zero at the next job.

Not half, all of your time will be busting your ass building up rapport.

Lets look at the alternative: you start a greenfield project with no understanding of what the rest of the company's stack looks like. Engineers know some person was hired to do something, and they may be interested in what you're doing, but they're probably not invested in it (the people who hired you are probably more invested, but they're unlikely to be the ones who have a deep understanding of the tech stack). You're facing an incredibly uphill battle here, as there are certainly going to be things that you will need assistance with (custom libraries, weird deployment frameworks, shitty deployment scripts that only one person somewhere knows how to get working etc.).

You may be a super genius, super hardworking person and be able to pull it off. For the average case, I am convinced this is a backwards way to approach the problem.

[Spooky23]

Not necessarily. Positional power is only one aspect of a managers capability.

It doesn’t prevent you from using personal power and influence, although most organizations are setup to purposefully make it difficult to function that way.

Usually your best managers do both. Think of the best people that you’ve worked for in any environment. Usually they are people from whom you’d seek advice and counsel.

[LordHumungous]

> You just tell people what to do, and they will build it.

That's a pretty simplistic idea of how a manager wields influence imo.

[vkou]

It is a gross over-simplification - but I've had a lot of managers, and not once have I seen one bust their ass for a year, and then take six months to gather feedback and peer support on their work, in order to get the rapport necessary to do the job they were hired to do.

I mean, they do this sort of thing, in order to show that they are superstar, and should get 2x the headcount they currently have, but they don't actually need to spend a year and a half convincing people with results, in order to be allowed to direct their existing headcount as they see fit.

A senior IC, on the other hand, needs to personally prove themselves at every workplace, before they are allowed to act in the role of a senior. You're expected to deliver the results of a manager, without the corresponding power. You're expected to exercise soft power, and you're expected to acquire this soft power on your own.

It is an incredibly inefficient way of getting stuff done, if you ever switch jobs.

[airocker]

Totally! I believe the debate can be rephrased in certain situations as : whether you want to always be the player or do you want to be a coach at some point. As coach, you remain relevant as you grow older and have a bigger impact on the team. And in tech, nobody stops you from playing as a coach.

[inerte]

When I was an IC wanting to be promoted ASAP I kept hearing from management "We need to see if the org needs this [particular high level] role"

Took me a while to understand this is true. You can't have an org with the wrong ratio of "architects/leads" and coders. Or tech leads and engineers, whatever terms you prefer. An org with 2 teams doesn't need 5 people coordinating cross-team work. An org with 40 teams needs more than 40 engineers, and so on.

[Ididntdothis]

It would probably work if the people managers stayed out of the technical side but in reality most managers like to make technical decisions so there is not much space for senior engineers.

[nilkn]

It's questionable to me whether an engineering manager can stay out of the technical side completely and actually be competent at their job. I think many non-managers underestimate how technical engineering management actually is. You often have to have a solid understanding of a very wide swathe of the organization's technology, including services whose code you haven't even had a chance to work on. In some ways it's not all that different from some of the expectations for very senior IC roles.

[sunaurus]

I always take it as a red flag when a manager wants to be responsible for technical decisions.

The best managers I've worked with have always made it their mission to serve technical teams by removing obstacles and making sure that the specialists have everything they need in order to create a high quality product. Managers who try to babysit developers and tell them how to do their jobs tend to just slow things down and lead to lower quality results.

[nilkn]

I think that being involved in the technical side and "babysitting developers" are two very different ideas that have little to nothing to do with each other.

> The best managers I've worked with have always made it their mission to serve technical teams by removing obstacles and making sure that the specialists have everything they need in order to create a high quality product.

I think you're underestimating the degree to which doing this requires a solid technical understanding when there are dozens of teams involved and interacting with each other. In order for an engineering manager to bring their team(s) a clear plan of what needs to be done with few blockers or obstacles in the way, often a lot of technical planning with other groups has to precede that. As always, management done right is the sort of management you don't notice -- but that doesn't mean a ton of work isn't happening behind the scenes to make things very organized and clear for individual developers. You could have ICs do that, but they wouldn't be writing much if any code, and they probably wouldn't want to anyway.

[tannerc]

Isn't what you're describing precisely what senior ICs should be doing more of?

I agree with OP, the purpose of a manager isn't to manage the technical side of things but rather the people side. It's why they have direct rapports: to manage the people.

A better use of the IC's time is to unblock them so they can meet with stakeholders and develop a rich understanding of the work in order to do it most effectively.

In trying to "shield" the IC from developing an understanding of the landscape they'll be working on, the manager may accidentally be preventing the IC from getting the information they actually need to do their job well.

[nilkn]

> Isn't what you're describing precisely what senior ICs should be doing more of?

Yes, and I think the point I'm driving towards is that if this is the stuff you want to do, you're really not an IC at all -- you're an engineering manager with zero reports who doesn't have any authority, so you're making life 10x harder for yourself.

[marcinzm]

Managers don't need to do that however someone needs to attend organizational meetings and deal will all the inter-team semi-technical stuff that keeps a company running. That person will tend to be involved in technical decisions to the extent that they have organizational knowledge and influence. You can have ICs do that however most would prefer a root canal and many lack of the soft skills for it.

[nine_k]

There is little point to be a senior engineer in a company which us not growing, or at least seriously changing their technology.

Once the technology works well enough, and the ongoing changes can be supported by mid-level engineers, and there is no big challenges ahead, it's time to move on.

No, this is not how you grow in power and importance for 15 years within the same company. If you want that, management is your path.

[shrimpx]

I think the important point that's being missed is that super senior ICs are usually promoted for specific reasons. You're making it sound like they are a disposable commodity. But in my experience someone is super senior IC because they have proven to add key value when it was really needed and nobody else was up to the task.

[LordHumungous]

> But sometimes all you need is to be able to assign someone to a specific project that isn't all that glorious or interesting or hard but is valuable and needs to be done by a certain time

There's a lot of business value in certainty. The value of the senior IC is the certainty that your business critical project will get completed correctly and on time. Sort of like how you want a good electrician to work on your house even if the job isn't technically that "hard".

[nilkn]

That's just a solid senior engineer, though. You don't need a Senior Distinguished Technical Fellow to come to your house for some electrical work. That's the person you have designing the electrical grid for a city of 5 million people.

I guess if you have a lot of title inflation things might be different. I've definitely seen places where a senior developer is pretty much anyone 2-3 years out of school who does a decent job but still requires supervision and oversight.

[LordHumungous]

That depends. For example my company we are trying to move all of our infrastructure to kubernetes, and we are trying to hire a very senior IC who can lead it.