None of this work contributed to my career path, although it was development work. I felt like a hero, but the people who respected my new work didn’t complete the feedback loop and/or my current leadership didn’t care.
It actually stole time from work that would have gotten me promoted/provided more challenges.
I felt like I lost my role as SME and instead became a jack-of-all-trades.
It was good experience and luckily did not get me fired. When I look back I realize that the problem was the team/leadership’s lack of growth-focus and support. If I had transferred teams or left the company I may have been better off. I say may have, because other than feeling like I wasted a few years learning this, I’ve ended up in roughly the same place I would have been.
1. You haven't developed the skillset to both track and evangelize your impact.
2. The company's review process doesn't properly value out-of-band contributions
I find that when I really look into it, #2 is actually rarely a problem if you are good at #1. As I've worked on getting better at #1 I've found I'm far more comfortable at work, it helps my career, and I still get to just do what my instincts tell me and what is best rather than shift that to what will look best.
Every big company I've worked for (none of them FAANG), helping another team is a recipe for disaster. You will get your hand slapped, punished, blamed, and basically make your life much worse. Each team is super insulated and tries their best to hide behind their management chain because of this.
It's great that you can feel bored and look for other problems to solve and not just teach yourself something new to stay challenged.
It's not uncommon to send patches to completely different teams because you need something to work a little bit differently. Or even just because you were there and noticed something fixable and are being a good citizen.
Some parts of the code are nearly abandoned and destaffed, but might still have some users wishing that weren't so. And some parts of the code are only used/improved by a very specific group of people.
Some of this is technology (the monorepo, lots of good infrastructure to base things off of), some of it is management (such as recognizing/rewarding contributions that have "wider impact"), some of it is culture (a lot of Googlers come from or still work in open source).
My place right now is in the middle where much of the absolutely most useful work in the company is getting done because people behave autonomously, but the formal review process has had trouble recognizing that work as it can be difficult to put a number to it. Not knowing the 2nd and 3rd order effects means you can't say "I went over and cleared up this team's misconceptions and saved them a month of work" isn't something you can say because you have no way to know you saved them a month of work, so you just say "communicated and collaberated" which sounds suspiciously like you did nothing if the process hard numbers to avoid things like favoritism.
This. More work, much of which won't improve your review or bottom line. You get a stack rank from your boss and your team, not the guys two offices over. Then, if your upgrades screw up its on you.
Apropos of a a saying I'm fond of: "not your circus, not your monkeys".
> Each team is super insulated and tries their best to hide behind their management chain because of this.
That's what Mgmt is for, and why things can be escalated as "Mgmt Issues" so that the leadership, PMs, etc. can figure it out.
For a specific idea, come help kythe team build out a new indexer (say, rust or maybe swift).
Every team has a looonnngggggg list of things that they want to do but can't because they don't have the people for it (even if they're not keeping track of it). Frankly there's also a non trivial amount of core language work that's done by people who don't actually work on any of those teams. Getting context can be hard sometimes, but I've done it plenty of times.
Am always happy to chat, my username is pretty obvious from my profile.