Taro Experts

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.

• The problem you want to solve should always dictate what you should learn. If you're asking what technology you should learn first without a very specific problem in mind (i.e. specific as getting something from point A to B), go back and figure out what that problem is first.
  • Sidenote: The educational system unfortunately nudges us towards checking the box on various skills and technology in the hopes it leads to gainful employment, which is a big driver behind this confusion.
• Evergreen skills: when there's no specific problem, your best hedge is to learn a skill that has high durability and transferability in the long term. One way to approach this exercise is to look for a "fundamental" skill. These skills are never specific technologies, but usually on the abstract and meta side of things. Ironically, learning how to learn is probably the most important meta-skill, especially since the tech industry naturally rewards Antifragility.
• Tailor your learning around finding a bottleneck in your workflow. Having the skills to find the bottleneck is a meta-skill in itself, but working on solving what's specifically holding your team back from producing higher quality work, more consistently, and faster is guaranteed to have a high ROI. Personally, I had one of my biggest career breakthroughs (i.e. Manager -> Director+) by solving the data engineering bottleneck in the context of data science.

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.

• The first step here is to act as an owner. Do whatever it takes to make sure you don't break builds and you don't break/delete existing tooling and processes: whatever you do, make sure the boat doesn't rock. It's incredibly frustrating whenever workflows change while working on a timeline (the tighter timelines are, the more frustrating it'll be). Every single issue that is potentially related your efforts, you need intercept and resolve them as fast as you can. This will establish that you're proactive as an owner and that you're not a boat rocker.
• The next step is to start with 1 person. Ideally you want to start with who has the most trust in the company, but anyone who's willing to test your efforts will do. (Relative to more than 1 person) it's much easier to be attentive to one person and to get a commitment from management for volunteers. Your goal with this one person is to sell to them that your efforts will (without a doubt) benefit their workflow. Do as many walkthroughs as needed to teach them, write all the documentation is needed for them to reference, and address every question/comment/concern/feedback they have. If they are clearly sold on the idea of your changes and have mastered them, then you can move onto onboarding more people.

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?

Yes?

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.

Narrate this.

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.

Polish your resume with my tips on fixing your summary section and 5 erasers to stand out.

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.

• Create a comprehensive document such as "2024 Accomplishments" to systematically record every achievement throughout the year.
• Document each accomplishment with the corresponding date, emphasizing the impact for each and include even small wins.
• Attempt to quantify the impact of achievements, such as "automating X process," which resulted in a four-week reduction in manual workload for engineers or product team members.
• Collect feedback from peers, colleagues, and product managers, focusing on the value and impact you have contributed.
• Build a closer relationship with your manager to ask for feedback as much as possible
• If there's a provided engineering leveling guide, see how your accomplishments align with the next level (Sr. Software Engineer) description. If there isn't one, you can just check job postings on your company's website for the senior role or ask your manager about the job description.