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.
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.
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 . :-)
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 ...
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.
Double digit-strong data science team: speechless
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.
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.
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.
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.
That's a pretty simplistic idea of how a manager wields influence imo.
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.
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.
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.
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.
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.
> 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.
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.
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.
In these cases, the manager relies on the team, and the IC to get a clear understanding of the root of problems. You don't need to be super technically proficient to understand constraints, but understanding why those constraints exist requires a deep technical understanding, which is provided by the IC and the team. Using this knowledge, the manager has a perspective of the system and how to improve the system, and the manager tries to reason with the organization, trying to share that perspective with them.
The manager also relies on the IC to do spikes or POC's (or relies on the IC to select a crack team which have a good chance of success).
Most often, the IC has no interest in being in non-technial meetings all day, but the manager does. The manager loves working with other managers + product and helping them understand the issue, while the IC doesn't. The IC wants to spend most of their time on resolving technical issues, thinking deeply about the future and upcoming projects.
All of this to say: they're not exclusive, and both are required for successful teams. BUT, the idea that a technical manager needs to be super technical is not something I agree with.
As an engineering director, I have an entire organization of teams I'm personally accountable for, and I have to make sure the work that's being planned out meshes well with what all the other teams are also planning. I cannot constantly be pulling in a dozen senior developers into every meeting every day to help me figure things out. I also have my own technical objectives I want to achieve for the company that cut across multiple teams or the entire engineering organization. Most of these considerations are technical in nature, and while a senior IC on one team can help they frankly don't have time to be involved in the whole process -- that would prevent them from succeeding as a senior engineer in their current role.
Under discussion is not the role of a senior engineer, but rather the technical track beyond that point -- roles commonly termed staff, senior staff, distinguished, principal, fellow, or even senior fellow. My core claim is there's more in common between engineering management and these roles than many folks tend to believe and/or realize.
Often an engineering manager is just someone at this level of seniority who also has rock-solid people skills and has been empowered in the organization to actually get bigger things done that cut across teams, though they may not themselves write code anymore.
Certainly I agree with you that not every manager needs to be deeply technical, but I think that for someone who is deeply technical, engineering management can actually be a much more powerful and interesting choice vs. trying to expand your impact without taking on formal leadership responsibility on an IC track.
This might come down to cultural differences between companies. At Amazon leadership responsibility is formally baked into the upper SDE roles (Sr and above), literally in the role descriptions. There's definitely still value in being a technical manager, but that's not the only way to get formal leadership responsibility.
The other big disconnect is in the size of companies in question. At the larger companies, you can have a clear separation of roles, so that some people are almost exclusively managing resources, and trying to match resourcing to business objectives, while other people are much more exclusively focusing on technical issues and how they can achieve business objectives by making the right technical decisions.
In these larger companies, the issue of people on "The Technical Track" not having the "muscle" of people in management is really not true, or at least, heavily over-simplified. (And this is another definitions question; at IBM and Google, Staff, Senior Staff, Principal, DE, Fellow, etc., were all considered as on the Technical track and were considered very senior engineers. Yes, they generally aren't coding much by the time they hit that level; although you might be surprised how much Fellows are still coding.)
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.
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".
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.