In my experience it’s rare for orgs to hire for principal/staff/architect roles. What I’ve seen instead is people getting hired on as senior engineers and get promoted up from there after they’ve settled into the org.
I 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.