Let's take a step back.
Unpack what's leading to the "stress" behind the question. In most cases I've come across, especially when your own goals aren't clear, this is driven by the guilt of not "optimizing your downtime" or "fear of getting left behind in tech." Block out all externally driven stressors first, then you can make a clear-headed decision on what you want, which is the only thing that matters.
With that out of the way, here's my standard approach to skill acquisition without knowing more context.
At my previous startup, I was in the same boat. I was constantly trying to learn and apply best practices because the codebase I was working on wasn't great and the engineers took a slower, more relaxed approach to development. Ultimately, close to zero attempts to change the culture happened and I ended up leaving for greener pastures. While my scenario might not exactly be the same as yours, hopefully bringing in some of that perspective will help paint a clearer path forward.
How I (as a tenured senior engineer) would approach a world where things aren't great is to identify the problem as 1 simple truth. When problems are identified as a single, simple truth, it's much easier to understand them and to align on them (less is more). If you provide a list, you will overhelm others. If you jump directly to executing this list of things, you're perceived as engineering for the sake for engineering (which reduces your social capital). From your description of the response to your changes, it's clear to me that you started with the list and not a simple truth. Develop the 1-liner statement first and get alignment on that statement. When asked to clarify, state both your perceived observations and the impact together. Bucket things into higher-level problem groups: again, simple truths are much easier to be understood compared to "here's a list of everything to fix". In your situation, you can try something like "Our legacy tooling and practices is slowing development down. I have observed x, y, z themes of scenarios in which this is visible".
Once you've aligned on the simple truth, then identify what is the single, most impactful effort you can do to mitigate the problem. This will narrow down the surface area of your changes, lowering the changes you need to make and how many new things other engineers need to learn. You also want to treat each effort as a risk. Every effort you attempt can fail by making it appear you made the status quo worse. If you reach a point where you've made multiple changes and ended with more unsuccessful changes than successful changes (your value is negative from making things worse more than better), you'll have no social capital and will likely get PIP'd/fired soon. Comitting to one thing also establishes focus: you won't need mental overhead to juggle competing priorities.
Once you're identified what effort to focus on, you need to minimize the blast radius of developers impacted by your efforts.
Once that individual is clearly sold on your changes, look to onboard their team. Work with this individual to help sell the team on the benefits of your changes and help onboard the team to them. As a member of the team, their team will trust what they say (and that includes their vouch for you). After some reasonable amount of time (up to your discresion, have them fill a simple survey with a single yes/no question: are these changes an improvement to your current workflow? If less than 67% of respondents say "yes", iterate on the feedback of people who said "no" until you have at least that 67% ratio.
After that, it should be a relative breeze: onboard more and more teams onto your chages and keep surveying them to make sure you maintain at least a 67% ratio for people who are happy with your changes. Once the majority of folks who benefit from the change on onboarded, work with management to put a date to delete the old stuff and to move everyone onto the new changes. At this stage, there will be little to no questions: there's clear metrics around the benefits your changes and there's people who will vouch for you. The worst scenario for people now is that they are bregrudgingly willing to migrate.
Finally, you're done! Now if people want you to keep going, pick the next most impactful change and repeat the process starting at working with 1 person.
To compress this down to make it easier to extract learnings: you are probably in the right for taking on efforts to improve tooling and infrastructure, but your gaps are around understanding the people around you and your standing with them. Given their responses to your effort, you tried to directly replace existing tools/processes without direct and thorough consulation with ICs to build clarity, empathy, and trust in your efforts. For me, your current approach would only work if you were a tenured staff+ FAANG engineer in a company with 0 ex-FAANGs (then it's inefficient for everyone/anyone to fight your efforts compared to unceremoniously complying). The key lesson is that social capital impacts your ability to execute: if your name or resume doesn't immediately demand respect, then you need to build up social capital. The larger the blast radius, the more social capital you need. To avoid efforts with larger social capital needs (like company-scoped infra migrations), break down the effort into an incremental set of small steps. The process will be slow, but that reflects on how we (as humans) are generally slow to change.
Employment gaps are like the proverbial elephant in the room during job interviews, aren't they?
But let's reframe this:
Firstly, ask this tough question: Are you feeling inadequate due to your layoff and inability to find the next role since April?
What if I told you many skillful engineers are in the same spot as you?
Give yourself a break and tame your imposter syndrome.
It's killing your confidence to secure the next role.
Secondly, this is a golden opportunity for you.
Remember the .com bubble burst? The 2008 financial meltdown? They churned out scores of professionals with gaps, yet many bounced back stronger. Why? Because a gap is not a full stop, it’s a comma in your career narrative.
Brian Acton was in the same spot as you before he founded WhatsApp.
Now, about the advice to pretend you were working on a startup - it's a tempting narrative, isn't it? The allure of the entrepreneurial spirit. But let's not forget: honesty has a charisma that no fabrication can match.
So, how do you make this gap your ally?
1/ Embrace the Narrative
Instead of a cover-up, own your story.
You were at Amazon, a giant in its field, and now you're on a journey of professional exploration.
That's not just a gap; that's a quest.
2/ Side Projects are More than Sideshows
You mentioned personal projects. Excellent start.
But don't just do them - dive into them.
These projects are your mini-startups.
Failed to monetize? That's not failure, that's an invaluable experience.
3/ Keep the LinkedIn Real, but Strategic
Still listed as employed at Amazon? Update it, but smartly.
Mention your role, and under current activities, list your projects, your learning journey, your upskilling.
Transparency garners trust.
4/ The Networking Edge
Connect with your peers, join forums, and attend webinars.
Be seen, be heard.
Your next opportunity might just be in the audience.
5/ Skills Over Titles
Focus on what skills you're gaining.
Mid-level isn't just a title; it's a skill set.
Hone it, showcase it.
Don't just fill your employment gap; illuminate it.
Make it a testament to your resilience, your learning, and your undeterred commitment to growth.
Because the right opportunity doesn't care about your gap; it cares about what you did with it.
Prepare for your behavioral interviews using my STAR+ method.
Having dived into this myself recently and been on the edge of a few different thoughts here I'd love to add. I listened to YCombinator's Startup School a lot, the Competitive series by Michael E. Porter, finding very experienced partners that I can work with, and even starting a Board of Directors education program that has me gaining lots of education quickly. Then when I go about making the business decisions, I'm still acting very methodical. Most choices like a pitch deck and technical due diligence will go through review with the proper colleagues before we even start working on the problem and we're also very specific about where we put the business to get the best tax advantages we can.
I find it helpful when engineers keep track of their goals and aligning them to company/engineering core values. Some companies have leadership principles and aligning them into those buckets based on the goals you accomplished throughout the year. Here's some examples I ask my direct reports to keep track of.