On question #2, I'm not quite convinced of Gergely's reasoning for doing this before reverse interviewing. To be fair, I think the key point of that article is to do some form of reverse interviewing vs. none at all.\
\
*"**Negotiate your offer to the final offer, before reverse interviewing.** Get the money out of the way. This is especially true if you have multiple offers on the table. Negotiation has a bit of back-and-forth, and in this phase you want to still sell yourself, and make it clear how much value you'll bring if only they can move a bit more up on the offer."*

The reverse interview should give you more specific reasons for how your skills bring value to them, which is a key part of negotiating for better pay.

Question #3: It is totally reasonable to ask and even get a head start on relationship building.

Question #4: I don't think it's necessary to report it as such. I'd mention it only when someone asks.

Question #5: I wouldn't ask a friend to do too much investigation, but rather ask him what his opinion is on things such as: 

- the state and direction your project is headed
- if they treat contractors differently
- interactions with your manager, others on your team, and key stakeholders

---

Founder of Expanded Skills • Former Head of Engineering

Casey Dai

My crutch for problem understanding - ***"Can you describe the before vs. after state?"***

I've rarely seen things go wrong when all parties are aligned on the before vs. the after. 

The solution is the bridge we need to cross, which is usually relatively simple and obvious once the start & end are well-defined.

Illustrate the before-after, and present your understanding to your stakeholder BEFORE starting any work.

- What WILL remain as-is (forcing function to ensure the current state is fully captured)
- Specify what WILL directly change
- What MAY change as a second-third-order effects

I've been burned countless times in consulting when we don't do this. Simply listing out the scope and tasks you will perform to solve the problem isn't enough since it doesn't clarify expectations or what's actually desirable.

Reframe a question into something that's more declarative.

Example:

- **Question:** How does X work? Or, what do you think about X?
- **Alternative:** Hey everyone, I did these things with X the other day and here's what I found.

The alternative indirectly "asks" them -- what is your reaction / do you have feedback on what I did?

If what you did was thought-provoking, people can't help themselves and will engage. Once you get 1-2 people to break the ice, the others will follow.

It's unfortunate that the people are not comfortable leading and would rather follow, but this starts working in your favour once you push past the initial barrier.

> Is it a telltale sign if none of his teammates are talking to him anymore, except for his manager, and they are no longer reviewing his code? This started after the server crashed the other day.

Doesn't sound like a healthy work environment at all.

Like others have mentioned, the right intervention is a system level fix (i.e broken process without enough guardrails).

It is normal to be very stressed and worried in his situation. However, the right course of action for him is to have a very candid conversation that covers:

- Acknowledge what he could have done better and show the preventative measures put in place, so that it's unlikely to happen again
- Transition from the prior point to needing some help at the system/process level to make sure it's fixed properly

I wouldn't be opposed if he started looking for another job since the trust is completely fractured here and I personally wouldn't be comfortable working with colleagues that leave you to suffer just to avoid the blast radius.

I have a very strong take on this, so here goes.

The matchmaking experience to get good advice and coaching is ***one of the biggest crapshoots out*** there. The low barrier to putting content out there is a blessing and a curse. Sometimes "free and widely accessible" is one of the most expensive things if it's bad advice (e.g. if it changes your trajectory).

You can probably find 90% of what you need out there if you have infinite time digging or know exactly where to look based on your unique situation. However, there's probably less than 10% that is actually helpful advice for your specific situation, plus your situation and personal preferences evolve so what was good advice yesterday may not be today.

The volume of content online is rapidly increasing, but the ***signal-to-noise ratio doesn't follow suit***. Some days, I think it may actually be decreasing.

In practical terms, you need to rely on "filters" you can trust. As others have mentioned, carefully managed communities are one way and another through people (i.e. mentors).

I believe the truly complex problems need some level of interaction to solve properly, where consuming an offline piece of content simply won't cut it. Static, offline content is best when the problem solution is deterministic and the variance is minimal or even zero (analogous to a math equation).

P.S. These are some of the primary reasons why I started Expanded Skills -- to make the matchmaking experience better and improve the content signal-to-noise ratio. I could go on for hours about this topic, DM me if you wanna chat more.

I follow these 2 principles when it comes to promotions.

1. **Align yourself with their OKRs.** Basically, get an understanding of what your manager is expected to deliver to your skip level. It might be tough in your situation given there's minimal interactions, but I always target the part of their scope that's giving them the most headache, which is usually falling short of OKRs as well. Several benefits to this.
   - You will do them a favor and they will assign it to you as long as they trust in your abilities
   - By definition, it's next level scope and already on the company's roadmap
2. **Bring those below you up.** In parallel to taking on next level scope, it's important to elevate those below you as well. You don't need direct authority to do this while the company factors in your people development skills when you're moving out of the IC bracket. To get started, look for ways to scale your expertise and make it easier for others to perform their work (ideally both). Some examples include
   - Offer to run a training for something you have expertise in
   - Document how you solved a problem in a case study and share that
   - Find process optimizations in the SDLC that remove friction for others or raise the quality bar without sacrificing other parameters too much (e.g. velocity)
   - Do "[glue work](https://noidea.dog/glue)" 

I also have a 3 step promotion checklist that I run through before making the push. Here's the essence of it.

1. **Sponsorship:** do you have the backing of the right people? Work backwards from the year end performance review discussion and figure out who needs to give the green light? What do they need to see to give you the green light? Reverse engineer this process rather than working forward and hoping it works out.
2. **Scope:**  You need a scope that is impactful enough and aligned with what your sponsors from the previous step care about. It's usually tied directly to why they would sponsor your in the first place.
3. **Support:** Do you have the necessary resources to deliver on the scope? This can be help you get from other team members, the state of the code base/tech debt, timeline, and possibly funding. Based on these parameters, manage expectations accordingly and negotiate what will increase your odds of delivering.

From the things you listed, you're certainly on the right track in terms of showing SDM competencies. 

If you haven't spent at least a few months in the role, ***give it more time*** because it's a much ***stronger case if others naturally advocate for you*** to be an SDM due to the managerial impact you've had vs. making an explicit ask early on.

Most places have a "conversation promotion policy" where they'd like to see you operate effectively at the next level (or within a new role laterally) before giving you the title change. 

If you have the opportunity to do the work of an SDM, making an impact and gaining valuable experience while doing so, you're ***already achieving what you want other than the title itself***. Similar to not directly chasing compensation, the title is better achieved as a byproduct, especially internally (switching jobs warrants a whole separate conversation).

If you're looking for more acceleration, here are a couple of additional managerial-level things you can do.

- **Look for process optimization:** simplify workflows, cut out unnecessary steps, leverage frameworks & tooling to increase productivity, find a flywheel & double down / find a vicious loop and look to break it.
- **Find ways to align incentives cross-functionally:** this is where most issues happen, but not given enough attention (most people will focus only on their own domain) 
- **Bring solutions that don't involve engineering:** this is one of the most underrated strategies to build your influence. Be the trusted source that will aim for the best solution to the problem whether it involves engineering or not. This will also help resolve many of those cross-functional issues in the prior point. 

A lot of this traces back to **systems thinking** and is an increasingly useful skill as you progress on the leadership track. 

DM me if you want to unpack this topic more.

I find that the ***best managers won't take this personally*** if you give them a heads-up and do what's in your power to do a solid transition. The best ones I've had all cheered me on in my next step, and oftentimes, your paths will cross again, given it's a small world in tech.

At the enterprise level, it's very unlikely that any individual will take this personally, but a policy will likely put you on the "do not hire again" list due to the short tenure. 

**However,** ***individual relationships are far more important than re-hireability at a particular company***. It will be the individuals who will consider presenting you with opportunities down the road when they move to a new company (I've had this happen a couple of times in the past 5 years). 

Tactically speaking, do all the standard stuff to facilitate a good transition:

- Document your knowledge and share it with the relevant people
- Offer to run a training to help others internalize it better
- Make sure everything that you're responsible for has a new owner
- Work closely with your manager to manage comms to stakeholders who depend on you
- Make sufficient time for 1-1s with people to chat on a more personal basis (even if it's just 5-10 mins)

Good luck in your next role and try to unwind a bit during the Holidays!

**It comes down to whether you will bet on:**

- **The company's career model - largely driven by your manager**  
- **Yourself - what the market will give you for your abilities**

These past few years in tech should be quite sobering that betting on any one company's career model is a ***losing proposition in the long term***. Given the dynamics you described, it sounds like a losing proposition even past their promotion cycle because it's a race to the bottom. Bake into your expectations that you'll likely ***chase a moving target*** if you do ramp up your throughput, as that will become the ***new norm***.  

Personally, I've been asked to work weekends and even over the Holidays before and I set my boundaries for situations I will vs. won't. 

You'll ***require a fair bit of career capital*** to do this, which is determined by what actual impact you have during the hours you work and what your next best option to working there is. 

If side projects are important to you and you're able to find contracts that pay your worth, you should ***allocate a certain amount of time to continue to build that***. It is worth mentioning that doing contracts will build up your problem-solving competencies and will make you more effective at your day job, assuming you're working on the same class of problems.

> The project is still in its early stages so there aren't many features. But I'd still like to keep stakeholders updated and get them excited to gain some visibility into whats being built.

Offer to **host an event** to present some aspect of your project. It can be a training covering lessons learned that's applicable to other projects or walking people though the journey leading up to a milestone.

**Work on a 15 second pitch** to cover the gist of what you're working on and why it matters. Be prepared to go deeper if people signal an interest to know more (i.e. ask follow up questions). People will often ask in hallway conversations or at the start of a 1-1 meeting. This is usually overlooked, but adds up quickly over time.

> I obsess about the quality of the work / code being written that sometimes it reaches a point of decision paralysis, where I'm afraid to take action / build in new features. A lot of the uncertainty arises due to concerns about my lack of experience (which I sometimes fear could lead to sub-optimal work)

The mindset required is to **ship v1 as early as possible**. You want to fully **close the feedback loop** and the only way to do that is to put something out into the wild. If your confidence level is not too high, you can ask for feedback from others in a contained setting. Since you only have 1 reviewer just let them know which aspects you'd like them to channel their feedback towards. Proposing to get more eyes on it if it's unresolved after the initial review is natural and will get you more visibility.

Regardless you'll need a first draft to accomplish this (people are much better at critiquing something that exists vs. thinking about things in the abstract). 

I love the saying **"you can't steer a stationary ship"**. 

> Since I'm working on this project totally on my own, I feel things can get a little siloed (ie : I'm the only person writing code and working on this project and have just 1 person reviewing my code).

**Examine what impact your work has downstream and what dependencies does it have upstream.** Go 1-2 layers deep each way and you'll usually find something interesting, which is the starting point for an interesting conversation with whoever is working on that. It helps contextualize your work in the bigger picture, so it doesn't feel like you're working on an island. In an large enterprise, Big Tech included, **every small component is part of a larger ecosystem**.

Following your genuine curiosity and good things will come. 

As Rahul said, the key is to unpack the gap between expectations vs. reality with your TLM. Bring tangible work examples and tie them to progress metrics based on expectations at your level to make the conversation more concrete.

> The feedback is that I meet my delivery and impact expectations but only with a lot of guidance and help and at my level I need to show more independence.

Figure out what's bothering your TLM about the "lots of guidance" and "show more independence" part. 

- When you got guidance from others, what did it entail, and how was it perceived? 
- Did you actually need that guidance in the first place or could you have avoided it by thinking things through more upfront (or by asking the question differently)? 
- Is your TLM overwhelmed due to the new role? Could that be causing your TLM to be more impatient than usual? Can you do anything to help them offload/destress?
- Do your questions stump your TLM because he/she actually doesn't know what to do, but feels like they should because of their "seniority"? I'm hoping it's not this scenario, but it's actually quite common. I've encountered situations in the past, where they may take it out on you if it led to public embarrassment (don't assume the worst and only consider this after checking the other things)

> I'm ashamed because this isn't how I wanted my career to progress at Google and because my friends and family (and team) definitely expected more from me but at this point in the year there isn't much time left.

As much as we want to meet the expectations of others, especially those close to us like family and friends, your perspective of yourself is what matters at the end of the day. 

As brutal as it sounds, if other people's expectations of you are stressing you out and are at odds with your desires, you have to block them out. 

This is an extremely stressful situation, which I've encountered early in my career. Feel free to DM me if you need further clarity. Also do let us know how the conversation with your TLM nets out. 

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 -&gt; Director+) by solving the data engineering bottleneck in the context of data science.

Before writing up the promotion case, ***hunt down the OKRs for 1-2 levels above yours***. That will establish a baseline of what your org's overall goals are and how progress is measured.

Next, map your contributions to that baseline. ***Expand the definition of "contribution"*** to include what you had an influence on vs. only your individual output. If you can get feedback from stakeholders on initiatives and decisions you influenced, that would make your case stronger. 

You'll likely have a laundry list of things at this point. Aggressively ***synthesize*** this list to the most impactful things. Depth backed with supporting evidence is going to be stronger than breadth. You're trying to reverse engineer the process that gets you a strong rating, which is ***l*argely influenced by a 2-minute pitch** in most places, so you want to use this window wisely.

***Unfortunately, most managers are not good at delivering a 2-minute pitch*** (or don't care as much as you do to refine it). You want to make it as easy for them as possible. Ideally, work with them in a 1-1 on how to ***translate the BRAG doc into a 2-minute pitch to reduce the margin of error.***

This may be an unsatisfactory answer, but I wouldn't base too much of your game plan on how the FAANG team matching process works. It's based on talent demands at a point in time alongside social factors / personal preferences of the decision-makers leading that team. 

**It's a crapshoot on a good day.**

**Instead, you'd want to design your career profile in a way that is optimized around solving problems that fit these 3 criteria.**

1) You are or can get ***reasonably good*** at solving them (at least in the top 25% of people)

2) You have an ***intrinsic interest*** in solving that problem, which will give you a sustainable long-term edge in #1

3) There's ***sufficient market demand*** for that problem domain. Doesn't have to be the hottest problem (e.g. AI / LLMs or blockchain ecosystem). In fact, what's generally considered boring by most is great for higher pay and less competition (as long as it still checks off criteria #1&2).

If you follow this game plan, you ***reduce the odds that you'll be mismatched in the first place***. You want to state your intent and what you bring to the table extremely clearly, so you won't get the wrong type of "buyer" (i.e., employer).

Don't overthink it.

***Ask yourself what the top 3-5 problems that MLE managers deal with on a regular basis.***

Based on your answer to that (it doesn't have to be 100% accurate), build your profile around being a solution provider for those problems. You'll soon realize that to have a very well-thought out solution takes a lot of work, which is a great forcing function to narrow things down.

***As a former hiring manager, a track record and verifiable expertise in problem solving is by far my #1 criteria.***

After getting clarity on that you'll realize what the best "medium is to communicate that message". Your intuition is correct that publishing papers and getting advanced degrees are ***very expensive and time consuming options*** to achieve what you want.

***Start with easier options*** such as writing up a blog post vs. publishing a paper. Getting a cert is generally not needed IMO since it's a proxy for you having certain knowledge. A better way is to showcase you have that expertise by building a body of work (ideally discoverable online).

Blogging and posting on socials are good accessible options. Getting speaking gigs is great, but it doesn't have to be at a major conference at the beginning. It can be as simple as picking a topic and putting together a 30-minute presentation with a 30-minute Q&A on Taro. For example, [I did one earlier ](https://www.jointaro.com/lesson/z8y2iA8VnzKVhxBASO9w/how-to-navigate-pivotal-points-in-your-tech-career-by-casey-dai/)this year to get some of my ideas out there.

Like others have mentioned, don't worry about someone taking your idea and more importantly, letting your title limit yourself.

You want to enlist others for this project vs. working on it in isolation. Your leadership team is looking for someone who others are willing to rally around. That's actually one of the most important criteria to meet before putting someone into a leadership position in the first place (way more important than functional / technical proficiency). 

To change gears a bit, if I were you, ***I'd focus way more on the PROCESS you took to find this opportunity in the first place and replicate it to find even more opportunities.*** 

If you can recognize the characteristics of a high-impact opportunity, you've solved for at least 30% of the engineering leadership puzzle, which will pay out way more than any credit your receive for leading a single project.

***You'll operate at a much higher level after transitioning from a scarcity mindset to an abundance mindset.*** 

To make this transition, the key is having the skillset to find more opportunities any time you want, so the one you have doesn't feel make or break.

> Q1- should I look out for new teams now. have chats with them and switch by next year once ratings are locked? Would managers wait?

It's always a good time to ***build relationships*** outside of your core team. Even if you're busy with your core work, I always suggest setting a biweekly target for the "number of interesting conversations you have with new people". The term "networking" is a bit overloaded and carries a transactional nature to it -- reframe it in a way that works for you.

Avoid making the first encounter transactional in nature where you are trying to broker a team switch right out of the gate. Take a ***genuine interest*** in what they are working on and if the opportunity comes up where you can make a contribution offer to do so. If there's a natural opportunity to keep that going, the conversation around a team switch will be smoother.

> Q2 - when is the good time to let my manager know that I will be looking for new teams?

The "when" part is highly dependent on your relationship and trust with your manager. 

I'll give two extreme examples from my past to illustrate the point.

1. **Very close relationship & trust:** we were both transparent that we wanted to move out of the company, not just the team. I had major quitting anxiety early career and my mentor (and project lead for a period of time) helped me evaluate the situation rationally. This is ***extremely rare*** so I would dial it back a few notches in most cases.
2. **Pure working relationship, neutral level of trust:** I hold off until I've not only made my decision, but also worked out a transition plan to mitigate the damage. There's not much of an advantage to you when doing this in steps ***unless there is a high degree of trust*** where you foresee a scenario where they will ***reward you*** for working to find a backfill for example. 95% of people won't, but ironically, the 5% that do, you probably want to keep working with them for as long as possible. 

> Q3- If I let my manager know now, will it impact my psc results negatively?

See my second point of Q2. Most people will unfortunately have a negative reaction. I've had situations where the manager actively blocked my internal transfer. I still got a good rating that year, but that more due to the fact I was running 80% of her org, so it's more of an incentive vs. a reward.

> Q4 - how to make the best use of time till psc results are locked?

See Q1 on relationship building, which will yield a lot of opportunities if done correctly.

Try to have a lot on your personal development backlog at all times. You can always fill it using these two brainstorming techniques to guide what's worth learning. It's actually a complex topic around building your skills portfolio, but here's the gist of it.

1. Pick a problem you don't know how to solve and learn how to get v1 of the solution up and running. 
2. Alternatively, pick a problem you already know how to solve and find better solutions or introduce variants.

Sounds like there's a lot on your mind, DM me if you're looking for further clarity!

Many great points have been raised already, so I just want to highlight one thing in particular.

**If your primary contributions are "disambiguating stuff," treat alignment as your "deliverables" rather than landing code / creating technical artifacts.**

Given that "alignment" is not as easily observable as code, here are some things you'd want to consider putting into practice.

- Document all the ambiguity you currently observe and what's required to resolve it (stakeholders, data, etc.)
- Pull your TL into alignment meetings that you are driving or at least CC him on the meeting and the notes sent out afterwards.
- Update a running doc to show the ambiguity getting resolved weekly (maybe more frequently at the beginning until the tension resolves)

I would caveat that there's a decent chance that your TL expects you to focus on contributing more code vs. resolving the ambiguity. In this case, you should present a clear case for how investing time in alignment upfront will save time overall, which sounds like you already have evidence for. 

You want to shift his focus on solving the problem vs. blaming you. After resetting expectations, the best person to step in to resolve the ambiguity becomes more of a tactical matter.

Don't try to overoptimize your time allocation on this one, especially if you think this new project won't deter from your main project. If it does, it's totally valid to bring up options to navigate this with your manager in a 1-1 and jointly problem solve.

From the manager POV, I've always been super grateful to those who stepped up when we were shorthanded. If you feel like your manager is a conscientious person overall, it will benefit you disproportionately in the medium-long term.

Personally, I'm always curious and deliberately try to get exposure to projects that I'm not directly on. It's a very useful muscle to build since I've unlocked many hidden opportunities through surfing other teams' projects in my spare time even at Director+ level.

It's hit or miss, but the point is to not bake it into your expectations.

In situations where I've seen it lead to a pay bump (all else being equal), it's primarily driven by the company's (rigid) hiring policies where they auto calibrate Masters+ at a higher band.

If your concern is navigating a salary negotiation, your degree shouldn't be something that is proactively brought up, as it's not relevant at offer stage in comparison to other factors centered around what value you can contribute.

DM me if you're curious and want to go a bit deeper on the salary negotiation topic.

Hey there, fellow non-CS background also in Toronto here.

If we take a step back, a **CS degree is merely a proxy** for knowing certain things that may or may not be useful to being a competent SWE. Unless it's pin-pointing to something specific that is holding your back or your intrinsically care about knowing more/getting better at, **ignore it.**

In practical terms, **I haven't seen a case where having a CS degree turn a "no" into a "yes"** in the recruiting lifecycle (CV or interview stage) for when I did hiring and the other cases I've observed. Anyone who bases a hiring decision based on this is either downright lazy or an unclear thinker, which you should look to avoid if possible (I get the fact that there's a non-zero chance recruiters may screen this way).

This last part is more personal (and perhaps controversial), but I'm even **MORE impressed** by someone who knows their stuff in a technical domain in spite of not having a CS degree. It at least proves that they can learn things without being forced to do so in an academic setting.

It core issue sounds like it's ***misaligned expectations*** caused by a ***broken feedback loop*** (with some stack ranking toxicity happening in the background).

Here's what I'd do to ***tighten that feedback loop***, so there are no surprises.

- Assess the ***OKRs 1-2 levels above yours*** and map your contributions to those. If this feels hard or there's misalignment, you'll know which efforts are likely not perceived as 'valuable'. The more specific and quantifiable, the better.
- Take an example of your best contribution and one that was subpar from awhile ago. Do an ***honest diagnosis*** on both in terms of what improvements can be made. 
- Show the work you did in the prior two points to your manager in your upcoming 1-1. Give your manager a heads-up prior to the meeting, so they come prepared. 
- Come to an agreement on what the gaps are together and more importantly, ***an action plan bounded by a timeline to close these gaps***. Ask to see a concrete example of what "good looks like" if you feel the feedback is too vague (it's easier to do here since you did the work to analyze 2 examples of your past work)
- ***Put EVERYTHING into writing as a "recap email".*** Do not neglect this step if you feel a PIP might be coming and there are subjective factors/biases at play here.
- Track your progress rigorously against this action plan and ***provide a written update each time you make tangible progress.*** *Even better if you could keep it in the same thread as your "recap email". 

Subjective factors suck and will exist to some extent. However, you can mitigate that by putting more of your contributions in writing and aligning to higher-level OKRs. If you're getting good reviews on 360s, you should capture those as 'testimonials' (while it's still fresh in their minds, not last minute before year-end) and include them in your perf review doc.

DM me if you'd like to chat further.

Tech Leadership Coach • Former Head of Engineering

I'll attempt to probe a bit deeper with a few questions. 

1. What happens after those timelines are missed? Does the team have a ***retro or sweep it under the rug*** as a "one-off" and move on? This is a very good indicator of the culture, especially how they act on the learnings.
2. If there isn't a robust process for #1, I would do a lightweight version of this exercise for yourself. ***Observe and document the characteristics and false assumptions made*** that led to the project not being delivered on time. Equipped with this information, you'll be in a better position to push back on unreasonable timelines. For example, "***this project has characteristics XYZ similar to this other past project*** that took longer than we anticipated. Let's recalibrate accordingly, so we don't overpromise and underdeliver. What do you think?"
3. What did the ***dialogue*** look like during performance feedback with your manager? Was more of the conversation around how you operate or how the project was run at a macro level?  

Even if you don't have the answers, it will give you a productive path to go down.

The default path is to continue working on engineering problems except with increasing levels of scope and complexity. If you decide to climb the management ladder, your work will diversify into other disciplines outside of engineering in order to make engineering more effective. Having a stronger alignment with Product and business functions will progressively increase as you get more senior (i.e. you'll be expected to play on the intersections of domains more).

Outside of what's on the corporate ladder. There's always another "game" you could start playing once you feel like you've actualized what you can do in the "engineering game". 

Personally, I like doing this where I can feel like a beginner again and resume the climb. Entrepreneurship will certainly do that, but it's certainly not for everybody.

I would not factor in the state of the market in terms of how you approach an interview. Sure it's not a favorable market for candidates, but a good approach to solving a problem doesn't change.

The same principle applies for people. The principles around relationship building and having a health interaction doesn't change. Reciprocity will always play a factor, where open-mindedness and making a genuine effort will be rewarded while hostility will likely be met with hostility.

I think you're overall approach is good where you validate at a high level before diving into details. The improve is not agonizing over small inaccuracies (especially live during the interview), but having a calm, measured response to it. Don't beat yourself up over an edge case, instead be glad you discovered it and make the most out of this new information.

Journal on your interview after it's done. Go into detail about what you think when well vs. not play-by-play. I find the more detail you put on paper, the more objective you can be about what's actually happening.

Alex hit on a lot of really good points, especially around building around your skillset and preferences vs. external factors.

I've always leaned very heavily towards Product and spent my first 6 months in a managerial role a Product / Strategy role. You are **much closer to revenue generating activities**, which make your progression, especially at very senior levels (i.e. Director+) much easier. However, don't make your decision purely on this since I've seen it **backfire pretty hard** for people who don't like solving problem in this space (e.g. user interaction, studying purchasing behaviors, surveying market trends, etc.).

You can always move between the two as it's **not that permanent of a decision**. I'd actually strongly recommend getting at **least one role in each** to make the most informed decision. 

Personally, I moved back closer to data platform / infrastructure after my brief stint in Product since my primary goal at the time was to drill deeper from a technical POV. You can still make a huge impact from a **cost-takeout and productivity standpoint**, especially if the infrastructure already handles a lot of traffic.

I highly recommend leaning into no-code / low-code solutions.

The main benefit is it frees up your attention to focus on the non-engineering aspects early on in your project. Especially in early stage, your bottleneck is usually somewhere along with lines of client acquisition/lead generation (i.e. getting users) and finding product-market fit.

Time to market is extremely valuable and anything that can remove friction is worth serious consideration. From a skills perspective, your gap is unlikely anything to do with engineering. Unless you want to pick up parts of the web-dev stack coming from a data background as a goal in itself (regardless of if the project does well or not), then feel free to spend some cycles.

If your **primary** goal is the finding traction around your solution, feel free to skip custom code for now.

Let me try to deconstruct this piece by piece as there's a lot going on here.

**Work-life balance / burnout:** It comes down to putting your own boundaries in place. I think you diagnosed it well in the closing paragraph of your question. It's very easy to use work to "fill the void" when there are no personal commitments / hobbies you're looking forward to. It took me awhile to adopt the idea of "scheduled fun". Take your personal commitments as seriously as you do a serious work commitment. People will respect your boundaries, only if you respect them first.

**Assess opportunities you like:** I sense you like SRE work. Let that be the north star that guides what you do and how you evaluate opportunities. Make a list of all the SRE problems you like solving and document your past experiences, good and bad while solving them. When you have a clear understanding of this, you'll naturally develop a filter to categorize what opportunites are a good fit vs. bad. Making an ideal company list is OK, but what and how you contribute at that company is much more important.

**Finding ways to grow:** I strongly believe TC is a byproduct of having strong alignment between what you are good at vs. what the market needs. Prestige is not that important, especially when you already have a big company brand on your CV already (i.e. TikTok). I encourage you to brainstorm a few ways you can grow outside of the metrics associated with a corporate ladder. This is a forcing function that will push you to think more about skills and relationships (which matter way more in the long run) vs. compensation, title and prestige (which are all very fragile).

Go in and follow your curiosity. When treated as a min/max optimization, things usually fall apart (speaking from experience from my early career). 

Don't try to force things and 'sell yourself'. The companies there are trying to promote awareness and let other know what they do (and why they are a desirable employer). Go with the flow and seek out information. 

I find that when I go in with an open mind trying to learn about what they do, the conversation will naturally flow. After awhile, it's natural for them to reciprocate and ask about you. This is when you can give them a quick preview into your past experiences and skills. 

Towards the end, offer to connect and thank them for their time. 

Like others have said, finding your own scope is the way to go here.

One undervalued opportunity is to r**esolve problems that sit on the intersection of domains**. This means not limiting yourself to the engineering org, but look for where engineering interacts with other orgs such as Product (or infrastructure/platform in other places).

Usually the **most problems** exist here with the **least number of people** paying attention to them. Resolving the tensions between data science and data engineering was where I made most of my impact in my first Head of Eng position. A close second was resolving issues between with our security & compliance teams (data privacy, data residency issues, etc.)

TL;DR - look for opportunities to influence cross-functionally or at least let the issues that occur cross-functionally guide what you could work on. 

The short answer is don't sweat it since it looks like you've taken the necessary learning out of the experience already (i.e. things that are in your control that can be improved). 

It's ok (and human) to feel bad about it for awhile, but don't let it consume you. Give yourself the next thing to pursue, which is likely generating more job opportunities after you've plugged your known leaks in your interviewing skills. Turn your focus to "input driven goals" as the results are a lagging indicator of what you put in.

I wrote a [LinkedIn post](https://www.linkedin.com/posts/caseydai_jobsearch-activity-7086761719376609280-peMs?utm_source=share&utm_medium=member_desktop) on job searching in a tough economy awhile ago, which may help. 

It's pretty hard to answer this in a way that would generalize well to a specific staff+ role without more specifics. 

Staff+ is expected to have a huge amount of impact, but how you achieve the level of impact varies, which will be directly related to work-life balance.

For example, I've seen SVP / VP level people operate without much stress when they have high degree of alignment with their leadership, an exceptional team and solid workflows/processes in place. However, I've seen the opposite happen to someone 2 levels lower than that where everything was a dumpster fire.

Zooming out, I don't think burnout and mental health occur from a couple extra hours up to a certain threshold (let's call it 50-60 hours a week). It arises more from not liking what you are doing, lack of progression and dealing with toxic people / environments.

One of my mentors was known to be a "fixer / turnaround specialist" and he thrived off of broken, chaotic projects while working 60 hours+ a week. Point being, everyone is wired differently and most of the work is introspection vs. anchoring on external reference points.

**Therefore, I'd focus on finding something you like and can contribute value to first vs. the other way around, then the rest will naturally follow (pay, mental health, etc.).**

Hope this helps add clarity. DM me if you have further questions.

I'm assuming tech entrepreneurship means you'd like to build a SaaS. The overlap in terms of developing the product will always be there unless you branch out from web dev into an AI/ML product where there will be a learning curve.

As an early stage entrepreneur myself, I think it's important to call out the common gaps that typically occur from those coming from an engineering background.

- **Marketing and sales.** Generating leads and converting them into paying customers is one of the most critical aspects to make it as an entrepreneur, but is also something that most engineers dislike and are not very good at. Regardless of the type of business you're in, the fundamentals around marketing funnels, sales copywriting, nurturing leads will apply.
- **Offer creation.** In simple terms, it's articulating exactly what problem you are solving, the value created from the solution, and who is a good fit for this solution (and who it isn't a good fit for). Understanding how customer make purchasing decisions will help a great deal here to make your offer as attractive as possible.
- **Mindset shift.** The rules of the game are different in entrepreneurship vs. a corporate job. You have the opportunity to play for huge upside, but there is predictable stream of cash coming in at least in early stage. Additionally, a helpful mental model is to "think in terms of bets". You are constantly making "bets" with your time (which you do to some extent in a corporate job), but also your own money now.  

**One final thought:** It's common to go through a period of learning to not directly trade your time for money as well as decoupling your efforts vs. your rewards. In corporate, it's by in large fixed time for fixed pay. The whole point of entrepreneurship is to use your time to build assets that give you earning leverage (i.e. the SaaS in your case) and your pay if generated through the asset (not directly 1:1 through your time).

I think deeply about this topic on a daily basis now that both my wife and I quit our corporate jobs for entrepreneurship. 

DM me if you'd like to chat, happy to pass my learnings along.

First, I'd ensure everything is the same in test vs. prod environments. Ensuring parity at the infrastructure, environment level will ensure that your efforts at the software level don't go to waste.

Document all the paths you've already explored to reproduce the bug. Create a document capturing 1) what you tried 2) what you expected 3) what happened. This will make it much easier to rally for help from others. 

It sounds like you've given this a fair shot and as long as the document capturing what you tried so far reflects that, any reasonable person won't fault your for that. Like Alex mentioned, focus the discussion around "what else could I have missed" vs. worrying about the perception of others. 

It's a signal of maturity to not throw endless hours at it. A couple things are likely to happen.

- If they struggle to come up with another idea to try, you'll know that you've coved a reasonable enough surface area to re-evaluate if they task is worth throwing more effort at. Either deprioritize or come to an agreement on what's needed to bring this to closure (i.e. who else to help, more time, etc.)
- In the off-chance someone points out something obvious that you missed, that's OK. Acknowledge it, thank them, and update them after you've executed on the idea. Add it to your playbook, so you'll catch it next time.

Final thoughts: don't worry about the PIP, we'd all be on one if it's handed out every time someone can't fix a bug.

Interested to hear how this pans out. DM me if you'd like to chat further.

I'm pretty sure this is a case where **something went wrong with expectation setting and skill calibration out of the gate.**

I would approach this issue head on rather than getting them to work 'regular' hours. 

If someone's skills are subpar, but have good intention to deliver, you'll typically see **working long hours as a coping mechanism**. Taking that away will only lead to more stress and slow down delivery.

Here's how I would approach this:

- **Review the interview notes** to see if there's any issues with the initial assessment / calibration. No interview process is perfect. Use this as a way to not only see where the candidate skill gaps are, but also what can be improved in the interview process.
- **Examine the work they've delivered so far.** The scenarios drastically differ if it's only a output velocity issues vs. if there are quality issues as well. If it's pure velocity, it would suggest that given enough time the velocity will go up. If there are quality issues, they may not know what something that's acceptable quality looks like, so they would need more reference points.
- After performing the due diligence from the prior 2 points, I would have a **formal, structured meeting to go through what you've been observing and where you think the gaps are in a 1-1** with your direct report. Have a candid conversation and don't sugarcoat. It's better for both sides to get everything on the table since aligning skills vs. expectations is most likely the core issue here.

DM me if you need you'd like to go over the situation and game plan in more detail.

If the only thing that you're not 100% happy with is compensation, I would strongly lean towards staying. 

Switching companies whether it's FAANG or not is rolling the dice on all the other factors that come with the job. Ironically, the only guaranteed thing is the comp you sign on at. I tend to advocate for switching when a new role offers something materially different other than compensation. 

As an example, here are two inflection points where switching made sense in my career:

1. Moving into people management with a chance to scale a team. The role also let me branch out from AI/ML into Data Engineering.
2. Moving back to tech consulting in a leadership role where I had country-level scope and shifted focus from managing the work to selling the work to clients.

All that being said, I think you should try a few things to increase compensation without switching jobs.

1. If you've had a strong track record so far, you can work towards building a case for promotion (only if you desire) or a pay increase at the current level (may need to demonstrate lateral growth into a new domain or scaling your impact in other ways).
2. Hunt for a side gig. This is doable, especially if you have a great work-life balance and are willing to exchange some of your spare time for more income. I did this for several years teaching at a bootcamp and career coaching.

\*The extra comp at FAANG has a good chance to eat up your work-life balance, so net you might not be gaining anything vs. the side gig route.

If you'd like to explore any of these paths further, feel free to DM me on Slack or LinkedIn. I'm happy to help you lay out a gameplan.

In the grand scheme of things, I think you handled it pretty well.

If you haven't already, I would send a recap email on everything that was discussed. Capture things that are beneficial for you in writing and put the onus on them to reciprocate. You'll find that people are much less likely to actually document "reasons why you're not a good fit for mid-level" when doing it through email. 

I would lay out all the components of the offer package that HR said they would get back to you early next week. Don't need to offer any specifics since it's still open-ended.

If you have other job leads in the pipeline bring that up to drive urgency. Keep it abstract, but apply pressure if there is a particular date you need to make a decision by. Center it around them providing you a specific offer (i.e. all the components you laid out in your email) so you can **make the most informed decision**. 

Realize this was awhile ago, but happy to help if you still in the middle of the process. DM me on Slack or LinkedIn.

If it's in a casual setting like a company event or passing by each other in the halls, approach it like any normal interaction -- don't overthink it or make adjustments just because they are more senior.

The same principles apply such as finding common ground and taking a genuine curiosity in the other person. 

If they ask you about something work-related, lean towards being direct and concise. This might lead to some follow-up questions, which is generally good since it indicates that they are engaged. If you don't have an answer on the spot, say that and let them know that you'll dig into it and get back to them.

One final thought.

Remember execs are humans and once junior employees as well. The good ones have a lot of empathy and want to interact more with people outside of their direct reporting line.

"It's lonely at the top" is cliche, but very true. Sometimes they just want to have a nice social interaction that is not politically charged (I can personally attest to this from both sides).

Feel free to DM me if you have further questions. Interested to hear how it goes once you've put the suggestions into practice.

Very interesting interview format. 

Generally, when approaching cross-functional interviews, it's important to gauge within the first 5 mins which of the following 2 things they're primarily evaluating you on.

1. Whether you speak their language and have at least a working knowledge of Product. Like an interaction, people want to be heard and understood. At a minimum, they'd like to see if you can see things from their perspective (making collaboration easier). 
2. Whether you are a proficient engineer. This one feels a bit weird since you'd only expect this from your engineering counterparts. However, given your scenario, it's quite possible that the decision maker (likely on the Product side) may not solely rely on the one SWE for this part of the evaluation. 

I've personally experienced #2 in a cross-functional interview where the Chief Revenue Officer wanted to go into my engineering competencies even after passing the CTO round.

In terms of mentality and nerves, I would focus your prep on knowing the value you bring to the table in the context of their company and not too much beyond that. Go in with an open mind to adjust your approach based on a live read of the situation. It's counterproductive to draw up every single scenario beforehand, as that will likely add anxiety and mental clutter.

Feel free to DM me if you'd like to chat further on interview prep strategies.

Hi there!

The limiting factor is usually your energy levels and the amount of focused attention you can dedicate to learning after 6pm. I've had times where I tried to 'squeeze' 6pm-11pm to learn new skills (out of necessity usually early career), but that's a **surefire way to burnout and resentment over the long haul.**

**Here are a couple of alternatives that have worked well for me and others in my network who tested it out.**

- If you're an early riser, aim for a 30-60 min study block before heading off to work. Pre-plan what you're going to study the night before and have all the resources open, so you can dive right in without any friction. Going to sleep an hour or two earlier in exchange for a more productive hour in the morning is well worth it.
- Prepare playlists of audiobooks and podcasts to consume while commuting, exercising, walking, etc.
- Carve out a 3-hour block on the weekend to tackle topics that require more focus. Do this sparingly and with intent, so you don't cut into personal time too much.

**Here's one that's undervalued and where I got a lot of extra mileage out of.**

\*\*\*Maximize those 5-15 min blocks at work. Here's the gist of the idea (I'm writing a LinkedIn post on this on Friday this week)

Open up ONLY ONE piece of content (to minimize distractions) in your browser window related to the concept you are trying to internalize. This eliminates the "startup friction" preventing us from using those spare 5-10 mins scattered throughout our day.\
\
Examples of content I keep open:\
 • 1 impactful quote.\
 • 1 article/blog post\
 • 1 chapter/subsection of a book I'm reading\
\
As a bonus, this method helps retain concepts in the longer term based on the principle "seed the idea early and revisit often".

If you want to explore more learning/study techniques, DM me on LinkedIn or Slack. It's a passion topic of mine that I can talk about all day.

Alex hit on a lot of great points in his post. I'll add a few more from my POV.

**If you're looking to advance your career:** Treat your post history as your personal content library. It can be extremely powerful when job searching or making new connections. Relying purely on your LinkedIn profile and CV is difficult to properly showcase all your expertise. For example, you might only spend one line on a CV on an accomplishment, but the journey you took to attain that accomplishment is better expressed through a series of posts or newsletter articles.

**If you're running a business (especially in career services):** LinkedIn is one of the best ways to generate leads and nurture them over time. There are several mid to high 6-figure businesses where LinkedIn is their primary channel.

A good rule of thumb to balance the two is to only consume when there is a clear intent on what you're looking for. Otherwise, build to find out where you may be stuck (and keep going until you are).

You'll feel a noticeable difference when you're in "hunting mode" when consuming vs. passively taking in information. One very clear pattern is you'll skip many parts of the content when "hunting" vs. consuming linearly from beginning to end when passive.

Building in public is huge, especially when part of a community where others are doing it as well such as <https://buildspace.so/> will organically get you a lot of traction, but also exposure to the work of others. 

Taking the time to find private Discords and Slack communities is a great return on your time. 

Of course there is doing warm outreach and putting it in the hands of family and friends, which is a great way to start. I would suggest taking a few hours to put together a consolidated list (almost build a small CRM on a spreadsheet) vs. reaching out ad-hoc when a person comes to mind.

Like others have said, don't force it.

One of the easier ways to get started is to engage with what other people are posting.

- Add a few examples or use cases where their idea / solution would apply
- Build on the idea. Add a few more to an existing list.
- Share good ideas with others (i.e. repost and give credit). 

There are a lot of parallels to how we engage on social media that can be applied in a healthy way to the workplace.

Most of the time when you ask for a pay raise based on an outside offer and accept your company's counteroffer, it usually doesn't lead to a good experience afterwards. Getting back to back raises in the same 12 month cycle is also very difficult, especially in larger companies where there's more red tape. 

Agree with Alex here that my gut feel is to explore external roles. Whenever I feel there is a big imbalance between my value internally vs. what the market will pay for, I will go validate that for myself on the market. 

Unfortunately, initial impression are hard to change, where if you got under-leveled, it's hard to change that perception in a short period of time, especially when the main rationale is other offers on the market. I had similar issues when starting out early career as an ambitious high performer. I'm glad I chose to quickly move on when a new opportunity came up.

I tried a couple times myself to get the role I wanted where I am, but it's usually not worth the time you have to wait out due to how promotion cycles work vs. if you can jump straight into an external role that needs someone at the level you are aiming for.

I would suggest branching out from the apps, systems, and projects tied to your usual routine. Digging into other repos can help build your perspective on projects you otherwise wouldn't have exposure to, but can be draining if that's the only thing to fill the time.

Instead, here's are 3 things you can consider investing some time in, which in my opinion are well-worth it and should be done even when you're busy with OKR work:

1. **Relationship building:** connect with anyone you find interesting both within and outside of work. Private communities like Taro are great to extend beyond your immediate circle. People who publish content share their ideas in the open, making it even easier to find something interesting. 
2. **Mentorship:** This naturally ties to relationship building and is basically offering to help others in any way you can. It goes hand in hand with #1 since there's always some way to help others if you keep a lookout for it. You may even find a mentor for yourself.
3. **Productize your expertise:** I wish I knew the importance of this and did it way earlier. It's the best way to scale yourself. Additionally, it forces you to internalize concepts more deeply and clarify your thinking. Writing is a way to check clarity in your thinking. Once you've productized your knowledge, it can turn into guides and trainings you can share with others. You'll be expected to do this more as you get more senior, so it's best to start practicing early!  

Contracting, especially in the same domain as your full-time employer can get you into a sticky situation and is honestly very stressful.

There are other side gigs you can consider building that can make you v**ery decent income (extra $500-$1,000 per week)**, which won't put your full-time job at risk (and without that much stress either). Two things that I've done over the past 7 years while in corporate is **teaching at a bootcamp and career coaching**. 

If you don't want to find your own clients, teaching at either a bootcamp or a university is great. Bootcamps tend to pay more and has less red tape, so that would be my preferred option. The hours usually don't conflict with core work hours since most (part time) bootcamps run their courses on evening / weekends since that's when the students are available as well. 

B2B advisory / strategy consulting is possible as well, but harder to do until you've hit around Director level and involve a much longer sales cycle. 

Happy to point you in the right direction if you want to pursue either of these paths. 

DM if you want to chat.

It's quite timely since I just put my 2 cents on this in a [repost ](https://www.linkedin.com/posts/caseydai_techlead-softwareengineering-tech-activity-7109896924467535873-5BNs?utm_source=share&utm_medium=member_desktop)on LinkedIn today regarding continued progression as an IC without getting into management.

Here's the crux of it.

\+----+

*There are many options available to you that can bring you greater earning potential, personal growth and better alignment between what you are good at vs. paid to do.\
\
Here are couple examples I've seen:\
• Moving into independent consulting / subcontracting / side gigs\
• Moving into a different job family such as architecture or platform\
• Staying at senior engineer and continuing to crush it\
\
Taking on interesting new projects and expanding the breadth of your skills. Not all growth is tied to a company ladder.*

*\+----+*

Personally, I enjoyed the "Right Hand" archetype quite a bit and it's one of the most underrated ways to accelerate your career growth if you have the right executive sponsor. 

I think it's the **perfect time to diversify into non-tech skills**, especially as a "Right Hand" type of role. Like you mentioned a lot of time is spent playing on the intersections between various functions. Some common intersections I've had past success playing the "go between" are Product x Engineering, Architecture / platform x Engineering, and overall Business x Tech. This puts a high ROI on your skills outside of engineering. 

One extremely undervalued skill I've noticed over the past 3 months is "sales copywriting for engineers". If you **learn to master sales copywriting**, you'll find most written forms of communication a cakewalk and thereby gaining more visibility in the workplace and scaling your input.

DM me if you'd like to explore any of these paths further. Happy to pass my learnings along.

P.S. I would focus less on the medium the education is delivered through whether it's university, MOOCs, bootcamps or books, but rather the content you prefer and need. 

Former Head of Engineering

I would preface and say that there's still a big demand for DBAs within the tech industry overall. It's not as high as 10 years ago before the rise of managed services and cloud, but I would still consider it a viable career.

Now to answer your question, I would lean towards Data Engineering. As a DBA you are naturally exposed to a lot of queries and interact with the data model on a daily basis. Plus you understand best practices around "operational excellence" such as performing backups, IAM, security, ACID properties, etc.

All these skills are highly transferrable to data engineering. To make things easier, you could even niche down to a particular area such as performance tuning queries or data modeling. When I was in tech consulting, there's a huge demand for these roles, especially in large enterprise. I haven't met a single company that is really happy with how performant their queries are or their data model design.

Data integrations should come naturally as well since the DB is usually a data source or the destination itself.

To get a 30K overview of data engineering, I highly recommend [Joe Reis' book "Fundamentals of Data Engineering"](https://www.oreilly.com/library/view/fundamentals-of-data/9781098108298/). You can find it on O'Reilly platform.

Hope this helps you make a more informed decision. DM me if you'd like a quick POV on the other career paths (I've spent some time in each and hired lots of people into these roles).

Here are some negotiating levers to consider:

- See my [response ](https://www.jointaro.com/question/rcwT67yqlKex0tvzoYsN/dealing-with-this-offer-is-the-best-we-can-do-for-this-level/)to a similar question here on how you can articulate the value you bring rather than only focusing on the components of the offer
  - Base pay is often the toughest lever to negotiate, especially in larger corporate environments
- Ask for a signing bonus, especially if you are walking away from a bonus in your previous workplace
- See if you can squeeze something out of the benefits package (e.g. L&D budget)
- Leverage the start date - if they want you to start earlier and you want a break, you can make some compromises here in exchange for something else

Outcome-Based Career Coach • Former Head of Engineering

> My manager has been at this company for a little over a year. Before this, I had 5 managers in 5 months (my current one being the 5th) as we went through a reorg and a lot of leadership departures.

Zooming out a bit, I think the overall company environment/stability is the primary concern here. I'm not sure a promotion to E6 would be favorable here given the churn at the leadership level.

If I were in your shoes, I'd try to wait it out at E5 until things stabilize while keeping a close relationship with your skip level that asked for your feedback (this is typically positive and a sign of trust). This is one of those rare instances where you don't have to 'push' for the promotion since there's a high chance you'll get it once the turmoil is over. When things are chaotic, I've seen many organizations try to stabilize things by promoting a consistent performer from within vs. hiring externally (especially since your manager appears to be an external hire from a year ago).

Staying at E5 also gives you some breathing room to calmly tackle E6 problems gradually rather than being under the gun to solve for what looks like a blazing fire if you're promoted to E6.

At a tactical level, make sure you thoroughly document your accomplishments and get feedback from others in written form, especially when they may get laid off or voluntarily leave. Having your name as a contributor / author on critical artifacts such as design docs for major projects help as well.

Feel free to DM me if you want to chat further.

Here's a checklist to go through to increase your impact and/or visibility.

- Draw a connection between your work and the OKRs of your management
- Actively help others and elevate their work. It's only a matter of time before reciprocity kicks in.
- Document and publish your accomplishments in written form. Don't purely rely on verbal communication during live meetings. 
- Seek out some higher visibility tasks such as running a training, leading new hire onboarding/intern program, presenting a 'win' / topic at townhall or even participating in the company's ESG initiatives. No need to do everything and don't force it, just do what works for you. 
- Leverage your 1-1s to get your manager's support to find more impactful work and make it easy for him/her to share your accomplishments with other (i.e. I always do a full writeup that they can simply hit 'forward' and share with the broader organization)
- Expand your network to those beyond your immediate team / project. This can lead to finding a new side project or even a new sponsor/team altogether.

Career Coach • Former Head of Engineering

Very rare, but I've seen it happen a few times. It's not something you can actively aim for since the dynamics of internal transfers are pretty unfavorable to begin with (they are usually blocked, take a long time, or at best land at the same level and pay). It mostly depends on how much pull your sponsor has.

My friends and I used to joke that it's easier to get promoted by leaving for a few years and applying to a higher level position at the original company. Unfortunately, it's closer to the truth than a joke.

I would start steering the conversation away from career levels since the impasse here is getting stuck on salary bands by level. It's a bit difficult when there are rigid corporate policies in place, but as a hiring manager, I know there is room to extend unique offers for top talent. For example, at Director+ level the "best" offer vs. the "standard" offer can as much as 2X, but the concept still applies to level below as well.

Articulate what you bring to the table and the value that unlocks for the company, especially if it is unique vs. most other candidates. Here are a few examples.

- Strong network filled with engineering talent. Most candidates miss this point since it's too much focused on what I can personally do vs. what other talented people I can pull in as a "talent magnet".
- Industry knowledge and deep understanding of their business. Personally, I managed to negotiate at least 20% when moving back into tech consulting based on my understanding of how the tech consulting business works, particularly the competitor and customer landscape.
- Anything you can link directly to enabling their marketing / sales cycle will **ALWAYS** get attention. In the B2B world, if you have some clout with a key decision maker on the client side, this will turn the tides in your favor (well beyond the HR recruiter). B2C is trickier, but even small things such as you teaching a bootcamp/course on the side may garner some attention if your former students align with their customer profile.

Depending on your relationship with the hiring manager and rapport built during your interviews, you can consider dropping them a message. It's hard to advise how to do this tactfully without more context, but most of my previous jobs has been a verbal with my future manager and the recruiter is only there to complete the process.

Since you're covered on the two biggest short term issues (Visa and Finances), I think you can be more selective about where you invest your time. However, the opportunity in front of you doesn't sound that bad from my POV though. 

- Learning to prototype quickly can give you a huge advantage as many early stage companies are in need of MVPs to gather data and validate. Large companies have R&D arms that need this as well. Of course, it would be a big asset if you choose to build your own SaaS in the future.
- If JPL is missing those core capabilities, you essentially have a greenfield to play with. Sure there might be some red tape that won't let you stand up CI/CD on day 1, but you can easily demonstrate value of doing it since the baseline is essentially zero
- Don't worry about career progression / career model if this is not your long term gig anyways. As long as there's enough for you to do and learn within 1.5-2 years, that's more than enough. Although 2 years seems long given it's double your entire working life so far, but on a 40 year time horizon, it's only 5%.