[vp8989]

If I understand you correctly, I have felt similar angst before in this kind of role. Basically, you see "org-wide" work that needs to be done but it requires some level of "org-wide" alignment that doesn't yet exist. So you feel like you are twiddling your thumbs doing code reviews and making the tests faster while you wait to get the green light to "do your actual job".

At least for me, in hindsight, a lot of that was just in my head. It's fine once you earn the level to not always operate at it. Just as long as when that's needed again you are able to step up.

[Swizec]

> while you wait to get the green light to "do your actual job"

In my experience as a pre-staff – it is your job to create the green light. You’re director level, there is no-one to say “make it so”. You’re the one who’s supposed to do that.

Org-wide stuff not happening? Guess what, you have to go figure out how to make it happen. Even if that means getting buddy buddy with some of the other directors and building informal networks within the company. That’s the job. Making things happen. Poking the right person at the right time, cashing in favors, building a rapport, etc.

And yes, sometimes pulling a VP into a meeting and asking “hey can you pull a string”

[vp8989]

I am talking about non-technical roadblocks. Cross-team product engineering projects can sometimes involve ownership changes which affects the company in non-technical ways. Some influential product/design lead might lose some control of their UX, some engineering team will become "redundant" and need to be reorged or refocused to other types of work etc ...

You might be able to help with those politics but it's probably also not your job to do that. That's partly why actual engineering and product managers are on-staff to focus on things like that.

[Swizec]

I think it is your job to deal with those politics at that level. At the very least to bring them to the attention of the people who can implement a solve and to make a case for why your thing should be solved over other things.

If the principal engineer doesn’t champion technical issues created by org design, then who?

[vp8989]

Ownership disputes often stem from non-technical issues. Two orgs with different agendas might feel they require ownership of a given piece of tech to drive their own agenda forward. This can be expected to happen in firms that have multiple product lines but perhaps some shared functionality across them, as just one example.

I sense that we have different experiences and so can't relate to each other's points without getting more specific so I will make this my last reply.

I will just say that a common trope I've seen in online discourse on this subject is basically that you aren't a real <verySeniorIC> unless you are effectively doing the job of (or heavily carrying) your peers in the org chart who explicitly hold management roles. I broke my own back, metaphorically, trying to live up to that ideal with nothing to show for it and at the expense of the output that was expected of me and so I reject that notion. The <verySeniorIC>s Ive seen who hold those titles with longevity aggressively delegate politics to management and focus on the tech.

[timellis-smith]

I'm a principal engineer in a consultancy and can fully associate with this viewpoint.

The org wide work but not org wide alignment rings very true and it occupies much of my free work time trying to solve.