[jrochkind1]

In my early 40s, I am starting to reluctantly wonder if this is true after all. I don't like it, but that doesn't necessarily mean it's not true.

Another point is: In many/most actual organizations, it's the people managers making strategic technical decisions, not anyone on any other track.

[bluGill]

On the technical track your job is to get the management track to make the right technical decisions. This is hard: they have more power and don't have to listen, but a proven track record of good advice - combined with hard knocks when things didn't go well that you claim to be preventing gives you the power to give them the strategic direction they roll out.

Don't forget that there are more possible correct answers to strategy than there are people to do it. Should your company continue to update the current project, work on the big re-write to fix all the problems, or abandon current products for something complete new? All of these are valid answers for different situations, and some of the reasons to choose each are not technical and so you shouldn't influence them.

I have a dozen projects I'm thinking about at any given time. Some will never get more than thinking about. Some are in progress. Some I'm working to get into progress. Some are likely to be needed soon and are just waiting for the time of need so I can save the day with a plan (if the likely need turns to reality). Some are bad ideas that I need to prove are bad ideas so that we don't go down a bad route.

[chrisweekly]

IME skill-stacking (and including something rel to people / human interaction in your wheelhouse) is the best path to [power / authority / autonomy / clout / leverage]. It doesn't have to be binary "tech or mgmt". But you're absolutely right; companies are groups of people. If your role is such that your influence doesn't extend beyond what you can personally code, your sphere of influence (and career opportunities) will by definition be limited. This can be mitigated by eg explicitly developing skills of presentation and persuasion... but if you work somewhere that has other employees, and don't want to get stuck in a downstream role slinging code, there is no alternative to learning and mastering the [human] interface to the rest of the company.

[arethuza]

"it's the people managers making strategic technical decisions"

I'm 54 and I'm pleased to say that I've never worked anywhere where that was the general rule - I've always been on the "technical leadership" side of things (CTO/Head of Architecture) since my 20s and I pretty much see my job as ensuring that "strategic technical decisions" get made in the right way.

[ryandrake]

As CTO, did you have direct reports? If so, you were a people manager and:

> "it's the people managers making strategic technical decisions"

...was true in your case.

In my experience (over 2 decades now, wow I can’t believe it) the people making the broad, strategic decisions and influencing outside of their orgs all happen to also have direct reports and usually those reports are people managers too. They have titles like “director” and “VP” and “CTO”. How many of those people have you seen who are individual contributors?

[bluGill]

The obvious influence belongs to the managers at all levels. ICs have less obvious roles, but good managers look to their ICs for guidance on what decisions to make. Thus there is a lot of indirect authority in the roles that seem to have no power - for the IC that learns to use it.

[jrochkind1]

I'm jealous. I don't think your experience is typical.