Personal growth is often bound to the companies you've joined, the teams you were a member of, and the projects you participated in and led. This is the power of inertia. You learn (only?) to get the job done. Are you blinded by the "how"? Can you reach escape velocity when it comes to your personal growth? This post by Andy Matuschak will give you some food for thought.
Onboarding experience should allow significant context-gathering time and not only "getting things done". Be extra careful with experienced individuals who join the team - delivering value quickly without understanding the need is a dangerous pattern. Without proper context and understanding of the business, it will limit their potential long-term impact. It will manifest in the quality of ideas they'll bring, the decisions they'll make, and the trust they'll build with stakeholders around them.
This post by Keith Adams and Johnny Rodgers can help guide software engineers through a significant system change. Share it with your team, and consider where to leverage this framework for new and existing technological experimentation.
"what would have to be true in order for us to feel good about our progress at the end of the month?" -- this is excellent advice on how to pick goals or set clear expectations on R&D velocity goals. It's easy to measure meaningless metrics to feel good. Like "busy work," this can create the wrong incentives and optimize the wrong things.
Use these guiding questions and topics around 1:1s to introduce some more structure and go deeper. Bookmark it and open it once a week or two, and see which questions you wish to bring for your next meeting.
This post should be part of your recommended posts to Engineering Managers. One more I'd add to it as "treat them as if they're already there" - due to the high impact (and high friction) efforts senior engineers lead, there is a higher risk of causing significant damage. For example, they might express their opinion too strongly or miss critical feedback. It might reduce the morale in the team or force a substantial rewrite of a system. Try to write with them how the ideal execution would be like when they start. Be open about your expectations and provide them with constant feedback so they could improve.