Asking "How can I help?" puts mental load on your manager. Instead observe what's needed, assert what you'll do, validate you're headed right direction.
Operator 1 says to their manager: "How can I make your life easier? How can I add more value?" Operator 2 says: "I noticed in our Monday morning meetings we've needed to pull the X data and it's manual process. I'd like to create automated table tracking our weekly performance so we can see trends more easily. This should take half day to build. How does that sound?" Operator 2 adds more value. They noticed area that was lacking, then suggested how to improve it in way they could own fairly independently. That's adding lot more value than putting mental load on your manager to think about how you can help.
When you only ask manager where you can help, manager has to take multiple steps before they can accept your help. Manager has to consider: what are all things I need help with (there are lot of potential things), what's overlap of things I need help with that this person might actually have skills, judgment, and capacity to do, how long would it take to explain this to them (this might cost me more time to teach), how much do I believe in their ability to help, how much does this person already know (how much context do I need to get them up to speed), what's risk if they mess something up. These questions come down to ROI of accepting your help. Manager is responsible for deploying you as asset in way that will maximize your value to organization. Good manager won't simply dump stuff they don't want to do onto you.
Instead of only asking manager where you can help, observe, assert, and validate where you can help. Observing matters for simple reason: manager might not be able to articulate what they need. When you observe you notice what might be helpful for manager even if they haven't verbalized it. Observing isn't at odds with asking. You can ask AND be ready to observe. Look for clues, revealed preferences, implicit feedback, what's unspoken. Observing is something you can do without anyone's permission. You can start doing it today.
Asserting requires you to develop point of view. In this case you're asserting potential problem and what you could do to solve it. When you assert you can be wrong. But if everyone is scared of making assertions then there's no forward progress. Everyone too busy saying "Well what do you think?" and their peers say "What do YOU think?" No forward progress.
Validating: you do not need to fly blind. Once you assert you should validate whether you're going in right direction. It's like playing Marco Polo. At every step you're checking to see if your assertion is directionally correct. What's resonating with your manager? Where were you spot on? What else would they suggest you look into?
Structure to assert your ideas: Observe ("I noticed X. This is important because..."), Assert ("Here's what I think we should do... / Here's what I can do..."), Validate ("What do you think? / How does that sound? / Am I missing anything?"). You want to be type of person who takes work off your manager's plate, not adds to it. You can ask how to make your manager's life easier but don't only do that. Remember to observe, assert, and validate.
Check out the full stdlib collection for more frameworks, templates, and guides to accelerate your technical leadership journey.