Current Googler here; my solution to staving off complacency has been constantly asking myself if there are other problems I can and will work on - and they don't have to be problems on your team. (Although, I will say that at a certain point, if you're growing, I think your responsibilities should be shifting from solving problems to identifying/prioritizing the problems.)
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.
Current Google-ish company person here, and this can be just as dangerous as it is beneficial. I was on this team, more than once, where I’m complacent and no one is asking for more from me... so I started helping. I thought I was moving towards leadership because I was identifying and solving the right problems for others. I felt successful.
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.
2 problems that can cause that, the first of which is by far more common:
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.
It's amazing to me to learn that you can help other teams solve problems at Google.
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.
Having spent 7 years working in the Ubuntu community and another 5 now at Google, it's striking to me how Google is internally similar to an open source project.
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).
Those places are the ones who care primarily about tickets being closed, and you probably won't have much ability to be involved in the feature ideation process, and probably won't even have a real way to prototype things before they're all in JIRA.
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.
> 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.
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.
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.