There are other paths at Google than upgrading to mgmt, but all of them involve "cross-team collaboration" and other quasi-political (with a small-p) aspects.
Actually just writing code at Google is, from my experience, a small part of the job and not rewarded. The faster you get out of writing code and get into designing and delegating it, the better you're off. Sucks if you don't like it.
Coming up with a way to reward and improve nose to the grindstone technical contribution seems to me key to having an effective organization.
EDIT: also consider, doing management or team lead at a company like Google is so different from, say, a small company, that the trajectory may make no sense for somebody. Before I came to Google I felt myself on a career track that was team-lead/architect focused, mgmt interest, etc. Once I got there, that evaporated. I just couldn't imagine myself doing that kind of work in this large of a company.
Over the course of a number of years and a few jobs at IBM starting in the early 90s, I knew 2 people on their "technical track". Their jobs involved huge numbers of airline miles, continual meetings, and essentially no technical work.
That was one of the primary reasons I stayed a contractor most of my career.
Interesting that your contractor jobs haven't also filled with non-technical, biz type work? Lack of desire to deal with accounting, client meetings, all the organizational aspects of running a business have kept me away from contracting or consulting.
Might be time for me to revisit that, this being the year when I really think I need to start something new. I have no idea how to make that switch though.
Are you contracting through your own business, or someone else's?
Typically, no. I almost always worked as an employee of a technical contractor---I was an IRS W-2 employee; they withheld taxes and provided (sometimes decent) health benefits (although I decided it was better to buy my own rather than changing insurance when I moved). I had no more than the usual accounting and organizational challenges.
For me, getting into it was easy. I packed off a resume to several of the local contracting companies. They pass the resumes to the ultimate company, who will do an interview (usually very low stress because it's easy to get rid of you) and then the contracting company and the employer work out all the details. (It may have changed, but at the time of my last such deal about 2005, the contracting company absorbed about 15% of what the end company was paying for you.)
Do realize that you need to keep at least 6-9 months of your income in a readily accessible account (savings, money market, or (whoo, I'm old) CD). I never went for more than a week before I could another job, but I have known people who had more trouble.
I have since gone into federal government contracting, which is another whole bag of stinky fish heads.
I've moved into contracting after being a software engineer/developer/team lead.
Essentially since you are contracting, you are outside of the "bubble" where decisions regarding business get made. So while you may have important work on the project, you are not there when they are deciding on business aspects of it, you are usually not invited to any type of sales meetings or meetings with the clients. This is reserved for company people.
Another aspect you can do is that you can outright reject that type of work or slowly move away toward a client that is not requiring that type of work. When you are working in a company, you usually do not have power to do that. Your only option in a company is usually to quit and then hope next company doesn't pull you into that meatgrinder.
The down side is that you don't have any direct influence on those business decisions. (At one point, I wrote about three different login/single-sign-on clients for a web app infrastructure (including Kerberos/Active Directory) before they finally decided that SAML2 was politically/technically the right choice. Frustrating.) You do have indirect influence if you have a good relationship with your team lead, who will likely be a "real person", a real employee.
If it's anything like my experience hiring contractors, it's definitely that they get the most "fun" part of the work. Most companies use contractors (in engineering) precisely for a well-defined tech work. They don't have to manage people or sit in meetings that are not relevant. We pay them by the hour and we try to get them to work on the stuff they can contribute the most - dealing with politics is expensive.
In the 2000's I did contractor work by myself (and occasionally hired a friend or two to get a project done). It was a disaster. I spent >50% of my time on client, non-technical work. I then joined a ~20 person firm in San Francisco and worked there for a few years purely coding. It was a joy. They had great business people, designers, copy writers, and then about a dozen great engineers, and I could just focus on the code and get paid for that. My hours went down, pay went up, and got to do what I love.
If you are thinking of contracting/consulting, I'd highly recommend joining a diversified team in the 10-100 range so you can do the parts of the work you love and rely on your team for the rest.
Yeah, I no interest in running my own consulting business.
In my case, it was usually a contracting company with 10-100 contractors working for one or more client companies, but the contractor had 0 day-to-day influence on the work I did. (I did try to pick up my paycheck in person and chat with the office staff.)
Personally I "think" I want to just code forever, but I migrated from coder to more of an architecture role. However, for me, the growth is just not there. It is in the cross-collaboration, mentoring and industry influence is how you develop. In some companies time in grade is a factor in layoffs. Due to ageism companies might not be looking for someone at a certain age and experience to just grind out code full-time, but to work on a product holistically.
I've seen people from small companies playing the tech lead or manager roles, move into google as "Senior Software Engineer" or whatever equivalent - basically writing code again. And the reason is in your edit. In fact a lot of the "hot shots" at small startups that play nice with the boss and can wrangle Jira but were actually excellent coders - can't do the politics at the big companies.
Part of that is that the big companies typically hire suits to do management - which were basically the jocks in high school that always got the girl... that type - they run everything in the world now. Loud mouth tech bro asshole types.
I think a lot of technical leadership is a side-effect of ability. People with a lot of technical experience are able to view projects at a high level (and judge other programmers accurately) as a side effect of being good. You want them cross-collaborating because they have better eyes than someone without experience. Whether they know to iron their shirts doesn't matter.
Actually just writing code at Google is, from my experience, a small part of the job and not rewarded. The faster you get out of writing code and get into designing and delegating it, the better you're off. Sucks if you don't like it.
Coming up with a way to reward and improve nose to the grindstone technical contribution seems to me key to having an effective organization.
EDIT: also consider, doing management or team lead at a company like Google is so different from, say, a small company, that the trajectory may make no sense for somebody. Before I came to Google I felt myself on a career track that was team-lead/architect focused, mgmt interest, etc. Once I got there, that evaporated. I just couldn't imagine myself doing that kind of work in this large of a company.