I want to +1 Lee's

> lead” and “manage” are different.

Leadership is about "doing the right thing". You can absolutely lead without being a manager. And you can manage without being a leader, though that's usually a recipe for unhappy reports. In fact, plenty of tech leads "lead" multiple engineers on a project, all without direct authority, because they are able to convince other people to follow their direction.

> The problem is they don't listen easily get influenced by other engineers and frequently change what I've asked them to do.

I don't have full context here, but this sounds like case of attempting to **manage without influence**. You reports don't seem to have bought in what you are asking them to do, and they instead agree w/ some other engineers's proposals, so they just went ahead and did that. It doesn't matter how many 1:1s you've had with your reports, if you reports don't trust you and don't agree with what you are suggesting, they probably won't follow what you say. In other words, **despite being a manager, you are not actually demonstrating leadership.**

> Lee I’m unable to focus on my own learning goals, because I feel there is a lot of gaps of what an L5 engineer technically would need before they manage anyone else. I fear conveying it now will decrease my credibility as someone who can manage teams and projects.

You don't sound happy. Your reports certainly don't either. And I'm not sure your management is either. Sure, you might lose some credibility now by owning up to this. But it's likely better than 1 year from now when your leadership realize you aren't yet ready to manage and you didn't realize that on your own and then have to force you into a different position.

Ultimately, you are not happy. **Screw everyone else and just do the right thing for you.** You want to be an IC? Go be IC. Before you can lead others, you need to listen to your own feelings and lead yourself.

You might be surprised how often that's just what everyone else wanted too :)

Senior SWE, Manager at Google

Kuan Peng

Haha, I'm really happy you found it useful! The path ain't always straight :)

Feel free to reach out to me over slack or over LinkedIn if you want to chat more.

You sound like a multi-faceted, interesting person, with doubts about whether you will find your calling in a field that you perhaps entered on whim.

That sounds just like most of us out there, at your age!

I would say that it's definitely worth trying out other careers and see what else you might be more interested in, but don't be surprised if you came back to software either (as others have said, it's a deep field). Definitely go out there and pursue your interests, whatever they may be. There's plenty of part-time gigs and volunteer work that you could do in your free time to explore how to provide value to the world while doing the things you already love.

Ultimately, you will need more than just "interest" or "passion" to be truly great at any profession. Specifically, you are going to need *personal dedication*. And you probably want to be great, not only because it gives us "status", but also because it deeply satisfies our human needs to be provide meaningful value to the world.

---

This is my story. When I was \~3 years out of college, I was contemplating getting into policy making and non-profit as I was kind of getting sick of the "tech bubble" and how insulated it felt to be surrounded by people who worked in the industry. I thought I was very "woke" at the time and just might have the keys to fix everything that was wrong w/ our society (or at least, with tech).

So I went and I tried some stuff out along these lines. I volunteered w/ a city board and joined a cross-sector immersion program. And through it, I realized that while I did care about these things, (1) I just didn't have a ton to give to the people there skillsets wise (2) I didn't actually care enough about the problems they were going through to dedicate so much of my personal time into it. I...would rather play games at home. So after several months of this, I knew, deep down, that it wasn't my calling.

I came back to tech and software and gave it one more shot. I did change my team away from Ads because I hated ads. I re-learned clean code and programming paradigms about \~5 years into my career, and I found the material finally making sense as I had experienced enough pain in my own life (it all sounded like a boatload of BS before). Coupled with an amazing manager that cared about me, coding actually felt fun.

I also knew that I had a strange tendency to react very strongly to bad management and bad teams. At almost every stop in my career (and really, in college too) I was always raising hell whenever things were going poorly, but I typically also never really saw my complaints through to actually fix the problem. So when I ended up on a disaster of team after another reorg, I realized I actually wanted to see if, this time, I could be the person that can turn this disaster around. And I did. This in turn helped me to realize that I loved building great teams more than building great software. Which has been key part of what's led me to Engineer Management.

I guess what I'm trying to say is, there's a personal timing to everything in your life. Maybe software just ain't it for you. Maybe it just ain't it for you, **right now.** You won't know, and that's ok. Go try some of the other possibilities, and take some time to look inwards to discover your own reasons for pursuing a career.

Good luck!

Fun thought, working 4-6 hours a week!

From what I’ve seen, a “Good” work life schedule for front line managers is around ~8 hours a day, with the occasional evenings overtime, and with most weekends off. 

You have your meetings with your team and your reports which takes a decent chunk of time. Then you need talk to relevant stakeholders of your team to stay aligned on your goals (this is especially more important at big tech, where there’s a lot of interconnected relationships). Lastly, you still need to find ways to contribute, whether that’s finding the right new directions for your team or creating new processes or planning career growth for your reports.

All of this is very emotionally taxing because you are dealing with people, and people aren’t predictable. It’s really easy for managers to overwork, but the best ones find the right balance for themselves as taking care of yourself is a key component of taking care of others.

That's great news! Glad this was helpful. Happy to talk more if you wished to reach out over chat / slack.

You are right, there is literally *nothing* a big tech manager can do, at the time of compensation discussion, to change your compensation package. However, these are not completely meaningless if you realize what's going on behind the hood during compensation planning process and ask intelligent questions!

In general, the comp planning process for you in big tech goes like this:

1. Everyone's performance rating is finalized.
2. Based on your rating/your level/your location, the company compensation model will output specific numbers.
3. Depending on the company/organization, your manager then can make adjustments to your numbers (salary/bonus/stock typically). They are typically given a "budget" to work with across their whole team. Generally, each of these adjustments needs to be "justified" with a rationale and there's a limit to how much managers can adjust.
4. These numbers (and the adjustments) then roll up the reporting chain w/ each higher level getting to make further adjustments with generally bigger budgets. Sometimes, higher level directors can reset all adjustments front-line managers have made.

In general, you can ask these following questions (your manager may or may not be give you a straight answer, but some may, so you might as well ask).

1. What was modeled based on my performance, and what was adjusted for me and why?
2. How much discretionary budget was available? How does this compare to prior years?
3. How much does my location/level/rating have to do w/ my compensation changes? How much higher would've it been if I earned XYZ rating or gotten promoted or changed location?

It is ultimately informational. But these could be useful information.

For example, a common adjustment rationale is "Retain Key Talent" alongside a small bump in your RSUs, which could mean that your team/org/product values your as a key contributor compared to your peers and willing to go the extra mile to make sure you are compensated above what the model gave you. Adjustment ***can*** be downward as well, and they could signal that perhaps you just ***barely*** got the rating you ended with.

One last tip, now that I'm on the "dark" side - **please be empathetic** to your managers during comp discussions. Especially during bad economic times, comp increases can be little, so these discussions can be difficult for both you and your manager. The budgets managers have typically are small compared one person's compensation, and they get even smaller during bad times. Overall, managers are just mostly messengers for the company "model" when it comes to comp, and so please don't shoot the messenger!

P.S. Feel free to have discussions about your compensation *outside* the regular comp discussion window. Most managers won't mind.

P.S.S. If you work at Google, one of the quirks of the system is that managers have no visibility into your initial join grant, which means that if you are facing a 4th year cliff, they have no way of knowing until you let them know. Perhaps this is true elsewhere too. Of course, telling your manager about it doesn't mean they will be able to make adjustments, but still.

I'm in the US (Seattle) and already work for a big tech company. Yet I'm still here! Here's my "insider" perspective on why I find Taro helpful. 

**1: Safe place to validate your experience.**

I had major gripes with my role / manager at the time I joined Taro. I had an inkling that they were legitimate complaints, but it was hard to validate this within my existing network; so Taro was a helpful place where I could validate my experience with a degree of safety away from the people I knew.

Difficult situations exist everywhere within tech. And on Taro, you can find the help you need, as long as you are brave enough to reach out. Which leads me to...

**2: There is no playbook within big tech either.**

Big tech might have "career" ladders and better career support, but the consolidated wisdom of those across the industry are extremely valuable.

For example, I once attended a learning session with other tech leads, to exchange tech leading best practices, where we were asked how many of us have observed a great tech lead in action. I was shocked to find out that I was the only one in the room to raise the hands, and that almost everyone else just said "isn't the tech lead just the most technical person in a team?" Later, I shared this [clip](https://www.jointaro.com/lesson/uHqZZ15SK19MatEvLSO6/what-makes-a-truly-great-tech-lead-a-vp-of-engineerings-perspective/) and many of my fellow leads found it enlightening.

In short, the principles of having an outstanding career in tech is no different whether or not you are part of big tech: write great code, communicate effectively, and build great relationships. Great mentors and wisdom are in short supply, wherever you go in tech.

**3: The best way to learn is to help someone else**

This might be the biggest reason I've stuck around. By participating in those discussions, I am able to learn and consolidate my own thinking on these topics by helping others. This community allows you to chime in w/ your opinion with very low cost, and get immediate feedback. That's very helpful, if you aim to become a leader of some form - I've repeated some of the similar advice I've given on Taro to my reports, for example.

IMO, these three reasons are good rationales for anyone, whether or not they are in the US, to engage w/ Taro. 

I type weird... my right hand covers 60% of the keyboard while my left hand sticks to asdf area. 

I remember hearing something like "average typing speed for software engineers when they are working is about 5 characters / minute" or something like that, because most of the time we are *reading* code rather than writing new ones. 

Who knows, maybe one day we can code w/ just a mouse, a voice input, and a AI code generator. 

🤣 I swear I've answered these exact questions for my past Google managers!

Jokes aside, I just want to note that you seem generally dissatisfied w/ your manager, aside from the fact they seem to recognize your ability to contribute. I think most of us can empathize being managed by someone who lacks the capability to understand deeply our work.

My $0.02 is that **you need to be clear with yourself about the outcome you want**. Do you hope for your manager to genuinely listen to your feedback and get better? Or do you just want to vent (anonymously)?

There's nothing wrong with wanting to just vent - after all, you may believe that your manager doesn't want to and/or doesn't have the ability to change. I've encountered managers of both types and have genuinely attempted to give constructive feedback to help them. Neither got better. In this case, resist the urge to unload on them and just write something vague and leave it at that - if you don't really believe in your manager, then you probably should just leave and find someone else to work with.

But if you do believe your manager is open to feedback and is willing and capable of change, then write the feedback as honestly as possible without being hurtful, *and* include examples of situations in which you think they could've done a better job at.

In fact, I would recommend going one step further and offer your manager an opportunity to discuss your feedback directly, one-on-one. Doing so obviously require you to trust your manager and for your manager to trust that you genuinely want the best for them. But if your manager is indeed able to absorb your feedback and improve, this will not only improve you and your team's wellbeing, but also earn yourself an extremely valuable ally and advocate. As a newbie manager myself, I cannot be thankful enough to my reports who are brave enough to tell me the tough feedback face to face, as I'm fully aware of I've got a lot of room to improve as a manager.

Wins

- Wrote code for the first time in 6 months. It was just adding some test coverage. It felt great because it's been really hard to find time to do stuff like this that isn't urgent or super important for the project, but really important for my own well being.
- Sun's returning to Seattle! 🌞
- Looking forward to hosting next week's office hour!

Fails

- Tried to give feedback to a report but it wasn't received well.
- I eat too fast. Which leads me to eating a lot. And since I'm under a reasonable amount of stress on work days, this leads to a lot of stress eating.

Yeah I definitely prefer camera on! I would even say in some instances, having everyone’s mic on is also good. It just feels more natural and help people get to know each other ever slightly faster. I have operated in an environment where 95% people turn on their videos, however.

> if your team is primarily a camera off, do you think its worth it to ask for camera on?

While asking about this openly might not be wise, I would say this is a case where you can definitely lead by example.

Just start having your camera on during 1:1s and team meetings even if no one else does. It’s one of those things where nobody is gonna tell you to turn your video off. You just have to be brave and break the norm. People will appreciate it when you speak, and you’ll be certainly be more effective. And others may start copying your behavior eventually. Be the change you want to see!

OP, feel free to ping me over slack! It does sound like you are on a path to introspection and exploration that could lead you to find something that will motivate you in this role. I hear there are also book clubs and other options available on Taro if you wanted to explore more technical depth!

**What did your younger self find so cool about engineering?**

**What's the coolest project you've ever done so far in your life? Why was it cool?**

I think a lot of us resonates with how you feel - about how your job isn't particularly exciting or you don't think you got the tools necessary to become a good software engineer. It's rare to find a job straight out of university that's an exact fit with who you are deep down or your current skillsets.

My advice for you is rather than spending time doing LeetCode, instead reflect on your past and understand what you really find interesting and motivating.

Software engineering (and really, any well-paying profession) is very deep, and wide. It's wide and deep because all software is an exercise in problem solving using tools and people, and I think there's room here for people of all backgrounds. The key is to understand what your own unique motivation is to pursuing a career in this field.

Some people find that the overall business problem is what draws them to the job. Maybe they are really drawn to solve climate problems, or build a platform to help fellow software engineers (cough Rahul and Alex cough).

Some people find the technology underneath interesting. Maybe they really want to be on the cutting edge of JS technologies, or use LLMs in helping the world. Some folks loves to nerd out with fellow enthusiasts about the latest java update, or some concurrency paradigm.

Some people find that their joy is solving problems for their fellow coworkers. Some people just want to help their team have a good time and does so by filling various roles that bring about more structure and clarity to their teams. Or address pains their colleagues feel, like start test automation efforts so people don't have to manually test their code. 

Some people find all of the above motivating. Or none of them but some other motivators.

Maybe, you don't know what motivates you today. That's ok, it does take some genuine effort in putting your theories about what motivates you to the test. I didn't know either at 26, but trusts me, it was not LeetCode and it will never be for me. But at least come up w/ a theory to test.

You can always change your specific job or employer or profession. But unless you understand to some degree what it is that you are looking for, you probably won't randomly find a new situation that fits your bill. Product Management and Consulting are certainly equally wide and deep disciplines and definitely not "easier" than software engineering :)

Out of the FAANG cultures I've personally experienced and heard/seen second hand, Meta seem to be the most aggressive company in terms of tracking engineering metrics. CL/Diff count tracking is nearly non-existent at Amazon and Microsoft from what I can tell. Google mostly tracks it as a proxy to inform managers of poor performers but explicitly tries to rule out bias for high cl output - we don't generally care about being top 5 in the org for CL output, for example. So while I wouldn't say it's industry standard, it's certainly common. My general thought is that the usage of these stats probably do more harm than good, but it is what it is.

**Having said that, I think these stats can be useful *personally*.**

It's meaningful to use these metrics to measure how you've progressed as a software engineer. While there are many ways to land impact as a SWE generally, 95% of the time, your work will result in some level of code. While not every company cares about code output in terms of diff count, every company cares about code quality, and good code quality inevitably leads to higher diff count. I've personally used the metrics to track my own productivity and code velocity, and they've helped me create a game for myself as I sought to improve as a programmer. So while these systems *can* be abused, I would advise you not abuse it so you at least have an accurate picture of your own work. Use it to help inform your own decisions around planning time for deep work, improving code quality, or whatever. If it's gonna tracked anyway, use it to actually help you.

**Organizations should use low code output to flag potential problems.**

I think the magnifying glass is definitely put on entry/mid level engineers in companies that do track the stat. The reasoning goes, as a entry/mid level engineer, you shouldn't have too many other responsibilities (glue work) as part of your expectations, so you should at least have time to output code. Glue work becomes part of the job expectation at higher levels so you can be "excused" from having to maintain code output. <https://noidea.dog/glue> for anyone curious. While I personally think people who do glue work regardless of their job expectations are awesome, I do think the performance system at big tech don't generally reward this, so it's at least a good idea to make sure you have cleanup projects to grind away on if you are blocked on a major project or something, for example.

Using code output to highlight high performers don't really make much sense, IMO. High performers generally will have very, very visible impact (maybe land multiple next level projects) that are far better justifications. High code output is just a byproduct of amazing delivery, at best it's just a pat in the back.

I feel anything beyond using code stats as a "smell" indicator is counter productive. Managers should always provide contextual evidence for good/bad performance. For example, had I encountered a performance packet that said the candidate wrote 3x the average number of CLs for the year and therefore deserved high ratings / promo, I would question the manager very hard to make sure these CLs actually delivered extraordinary value and that their technical influence was also next level.

As a senior engineer, you might be able to probe your manager/skip for how these metrics are actually used. Maybe bring this as a concern you see others have and hear what your manager actually says how they are used during reviews so you might be able to assuage others' fears. Maybe help your manager get better context of lower code output by highlighting other types of work that is being done, so they don't unfairly punish your teammates.

For what's it's worth, I did mention with my new manager when I joined the team for which I became an EM for, that I would be interested in exploring engineering management if the opportunity ever came up. I did not mention that I want to be the EM for this team. I frankly probably wouldn't have really considered it then. 

So I agree w/ Casey and Alex that it's probably not a good idea to go into this with the mindset that you are going to be the EM for this team. I think you could still discuss your career goals in becoming an EM, for them to keep in their mind. Definitely continue to show competency and just try to help the team as much as you can. Even if they end up hiring a new EM, the trust and reputation you build through this will help you regardless. Who knows, maybe the opportunity to lead a sister team will come up, and they will think of you!

I took the EM invitation 5 months ago, have 7 reports, and don't have a designated TL in the team so that sort of makes me a TLM? I don't code anymore though.

Joshua's answer is spot-on, especially about the difficult conversations. IMO, this is equivalent to CLs for EMs. Our job is literally to have (and get good at having) difficult conversations, so avoid these is like avoiding to write difficult code.

But at the same time, no one will expect you to be good at it immediately. I still suck. Hard. But I've learned to take it in stride and keep on moving. It's just like when we start out writing code professionally, our code sucks and it needs revision, and we need to learn from each instance and get better incrementally. The main thing, from what I've gathered so far, is that you can't avoid doing this and still be a great EM.

I don't think you need to worry about your technical contributions, especially if you are transitioning to EM in a familiar technical space. You will want to balance your time but I don't think you need to immediately drop all of technical contributions, especially those beyond code. Eventually, you may realize you don't have enough time as TLM is a transitionary role, so you end up finding someone else to really take on that role.

I think my biggest advice here is that management is definitely a different job, and one you should probably commit to for a year or so to fully understand whether you like it or not. The good thing is, if you decide that this is not the path you want to pursue, you can easily go back to being a staff swe (since you are already one). If you've always been curious about what it's like to be a manager, I would recommend you take the dip, see how you feel in a year, and go from there!

It seems you already have a job at Shopify as a SWE, so that should more or less cover for a lack of a degree. Very few companies in tech actually cares about your degree since most of our learnings happens on the job. Therefore, there's no material benefit to doing a CS masters. 

But, you wrote that you have anxieties around not having a CS degree. Sometimes our fears are irrational (my personal fave is "I'm not technical enough") but we need to address them in some way to be our best selves. If doing, say, a part-time degree ameliorates your anxiety, it could be worth it! But before you commit to something as time consuming as a masters degree, at least do some self-reflection to see where your fear is really coming from and whether there are other things you can do to help ameliorate it. 

Congrats on getting the opportunity!

> What's your thought process when deciding when to switch teams?

1. Have I been miserable everyday for like, the past 3 months? I'm leaving, even if the work is "important" and/or there's opportunity to grow. You can be miserable for many reasons (bad manager, teammates you don't get along with, or you just hate the work), but the exact reasons aren't important. Whenever you recognize that something is truly making you miserable and you don't see it changing soon, leave.
2. Am I growing in ways I want? If not, I'm looking for a new challenge. Unless stability is what you are looking for (e.g. when you have other big changes going on in your life), having the same challenge day in day out probably isn't good.

> What's your thought process to decide which team to switch to?

I would say, there's \~ 3 type of team switches:

A. To a different team within the same org / in-org transfer

1. Pro: allows you to leverage your existing reputation in the organization to acquire a new position and continue using your skills/knowledge. The better your own reputation, the higher chance of landing a role as orgs generally tries hard to keep their best contributors. This option is surprisingly effective especially if internal headcount is hard to come by, like it sort of is now. Your old work likely transfers better as well and your onboarding is going to be minimal since there's a lot of shared context. I've done this three times in my career (including twice in G) and this option is not talked about much but is better than most people think. Do this if you like the tech/product, but don't, say, have a problem with your manager or your specific team.
2. Cons: hard to try completely new things. Hard to know whether opportunity actually exist. Needs people to sponsor you. Same pay. Maybe, same cultural problems.

B. To a different org within the same company / internal transfer

1. Pro: depends on the company, but at G, no formal interviews are needed so you don't need to grind leetcode. Most big tech teams also preferential hire from internal candidates vs external candidates. Can interview your potential new teammates to get a sense of their team culture and how much they like their manager, which is ***critical to your future success***. In G, you used to be able to ask for a manager's GoogleGeist ratings in the past to get an "objective" rating on how good they are. TLDR: you are able to pretty reliably assess how good your opportunity is if you put in effort to investigate for an internal transfer.
2. Cons: Same pay. Usually new context and technology, so you have to learn a decent amount when onboarding. Need to build new relationships. At the same time, they also know a lot about you. So if you've gotten a bad rating in the past, your new prospective manager can ask about that.

C. Switching companies

1. Pro: Allows you to negotiate comp. Maybe even a level jump. Ultimately, experience a different culture and definitely a different group of people. 
2. Cons: Actually have to interview. Getting a good team is more of crap shoot, since you don't have access to internal info that will help you make a reliable decision. External candidates also typically gets hired to the worst teams (because these teams have a hard time attracting good internal candidates). I think notably Meta's bootcamp helps avoid some of this problem but that has its own set of issues.

I'm guessing you are about to switch internally at G. I recommend you search up "Demystifying Transfers" on Moma, it's got a lot of helpful tips.

> What lessons have you learned from when you've previously switched teams?

1. In-org transfers are underrated.
2. You can never ask enough questions about your prospective team. Even when you don't have multiple options, invest time and effort figuring out where you are going. Team switches are expensive so take advantage of any intel you can find.
3. Quality of your manager is probably the most important factor for an IC. Everything else - tech stack, work load, probably makes a smaller difference than most people think.

Good luck!

I'm gathering the following from what you've wrote:

1. One of your partner teams is in a disarray, due to recent attrition of their EM. The other team seem unresponsive to your requests for reasons unknown.
2. You've attempted to put pressure on your partner teams by escalating to their management, or pushing them during syncs to stick to their agreed upon timelines. This has not been particularly effective. 

I can't read your manager's mind, but I sense you are not acting with enough empathy toward your colleagues. I worry that you risk destroying your long term relationship with these partner teams over completing this particular project. 

Escalation is an important tool, but it must be used w/ care. You should only use it when you know the people you are escalating (1) can actually help solve your case (2) is willing / incentivized to help you achieve this. I've personally found it only useful in dealing w/ short term fires. Long term commitments takes relationship building, which escalations don't help with at all. Repeated and ineffective use of escalation will result in "boy who cried wolf" situation where no one really cares about you say anymore. 

Is the skip manager actually sympathetic to your cause? Perhaps they are aware of the disarray on the team, and would rather sort out the managerial issues instead of meeting deadlines for other teams. I don't know, but that's just one reason why escalating to them might not be effective. 

Instead, I recommend you to ask your fellow engineers ***why*** they are struggling to meet the timelines they promised. Is platform team 1 struggling because they have too many priorities, and can't prioritize properly because they just lost their EM? Or maybe they've lost engineers too, so they are trying to do 5 people's work with just 3? Why is platform team 2 not showing up to your syncs? Perhaps they never agreed to support your project as part of their OKR? 

You need to understand what problems they are dealing with in order to know what solutions (including escalation) are appropriate. If the team is suddenly understaffed due to attrition... there's little escalation can do. 3 people can only do so much work. Unless you are ready to pitch in and do part of their work, no amount of escalation can do anything about that particular problem. But perhaps the reason they are behind is because they somehow don't understand how their work fits into your design or some other technical misunderstandings between your teams. E.g. perhaps some of the reasons are in your control. Perhaps there's actually something you can do to help them, rather than add oil to their fire. 

At the end of the day, many timelines slip for reasons beyond teams' control. Good teams communicate these factors to their leadership as quickly as they discover them. This let leadership to make reasonable decisions that either pushes that timeline before it "slips", or find mitigation strategy (additional people? less scope?) that enables the team to meet the required timeline. Perhaps you can surface the problems your partner teams are facing and see if your own leadership think you should adjust your timeline?

Tech Lead, Manager at Google

Pretty cool you are moving the build infra from Buck to Bazel (or Blaze, as Google calls it internally). What's the main consideration behind the change?  

If you could give one advice to yourself when you first entered Tech, what would it be?

I can empathize with your *"don't work until there's a fire/my life depends on it"*. I used to do the same - especially when I was at college, where would literally wait until the night before to finish my assignments and/or study for exams. I used to think I was cool because I could get away with it - but at some point it all caught up w/ me and I nearly failed out of college.

Your situation might be different, but one question to ask yourself is "why do I keep doing this?" For me, I realized that I had internalized this behavior when I was younger in high school, since back then getting work done last minute AND getting a good grade was considered cool. I felt I could "cheat" the system and felt smarter than all the other kids who worked so diligently just to get a B. So it really felt good doing it, and it was at least comforting when I did it even when the strategy stopped working later. 

I didn't really change until I knew deep down that I hated this version of me. That it wasn't who I wanted to be. I think my biggest "advice" for you is actually to figure out with yourself whether you actually want to change your behavior, and by extension, your identity. None of the external structures and support systems can help you until you make that decision for yourself.  

Having said that, if there's one thing I could've helped myself in my own journey as I strived to change back then, it's that I wish I had more structure and support system around me. You don't have to do all of this using sheer willpower and determination. Still, I wouldn't stress as much about what's happening around you as much as what's happening inside of you. If you are able to set your intention on changing who you are in this aspect, other things generally follow. 

I'll share some things I've heard about in manager circles recently about how to think about projects complexity/difficulty/ambiguity with regards to levels.

- **L3**: Bowling with gutters.
- **L4**: Bowling, without gutters.
- **L5**: Golfing instead of bowling.

The interesting bits to highlight for me is that L4 projects **aren't particularly more complex or difficult** than L3 projects, but the most important distinction is actually the fact that you need to do it without anyone else explicit looking over your shoulder to make sure you do all the right things. The goals and success paths for both L3 and L4 projects are likely similar - the difference is more in your own execution.

L5 projects are different from L4 projects in that it's often not clear what the right path / solution is. Likely there are varying *proposals* but no clear winner. You need to genuinely weigh different options, whether that's balancing different stakeholders and understanding where they are coming from, or different consider technical approaches, etc. I have found this this [LinkedIn](https://www.linkedin.com/posts/ryanlpeterman_handling-ambiguity-well-is-a-key-component-activity-7108464481726337025-wL0H?utm_source=share&utm_medium=member_desktop) post pretty helpful in visualizing this.

And to continue the metaphor... (maybe...)

- **L6**: What's new sports can we invent with a ball?

I've worked colleagues who seem to have done this in two different ways:

1. Like David said, via internal transfer. Join a multinational company with good internal mobility and find a job via internal transfer at some point. Internal transfers are usually preferred over external hires for the big tech teams generally, so once in, you potentially have an advantage even compared to an external hire from the US. I've known multiple engineers who've used this path to come to the US from India in both Amazon and Google.
2. Do a tech-centric degree in an American University. This takes way longer, is way costlier $$ wise, but I've also seen many folks pursue this path because this enters you into the US talent pool post graduation.

Take your vacations. Companies that offer countable PTO like most of the FAANG companies *expects* employees to take them, and HR will nudge managers to tell their reports to take days off when it starts piling up (from what I understand, it's because PTO days are sort of a liability for the company).

Your manager and your organization should be accounting for all the PTOs and leaves you end up taking in your performance evaluation. In theory, the impact/contribution etc should be prorated for the time you actually are doing the work. For example, if you were on a 3 month parental leave this year, they should be evaluating your performance given you had only 9 months to complete the work instead of the normal 12. So no, in no circumstances should your performance evaluations be impacted by PTO (except situations where you abuse the policy, e.g. taking waaaay too many sick leave even though you weren't sick).

Rahul is right though about the fact that you should try to minimize the impact of your PTO on your team and project. Your longer PTO will probably impact some project timelines, but it is really up to your manager and leads to decide whether that's actually problematic and they need cover and adjust timelines accordingly. Most good organizations do this already and adjust timelines for times of year where many people take PTO, such as Q4 in the US or the summer in parts of Europe.

A good rule of thumb is to give the equivalent times amount of notice period for your team and double for your manager for long blocks of PTO so they can plan around it if needed. E.g. taking 2 weeks off? Notify your manager 4 weeks ahead and the rest of your team about 2 weeks ahead of time.

Lastly, for longer PTO blocks more than a few weeks, employ good practices like setting auto-reply for your email/chat app ("I'm out from x to y, contact zy@ if you need help") and potentially create handoff docs for your team in case they need to take over for you.

"Autonomy" is an interesting choice of word. I wonder what you mean exactly by this? Maybe, the ability to decide how design ought to be? Or how much input you need from higher level people to approve your design? Alex already gave an excellent answer overall but I want to dive into this a bit more...

I think no matter your level, designs are collaborative experiences where your most of your engineering colleagues needs to be convinced that you are proposing a good solution. Higher levels by no means enables people to dictate unilaterally what stack or what technology to use. See "Material but not magic" section of the [Staff Engineer Book](https://staffeng.com/guides/does-the-title-even-matter/).

I think the difference in levels at FAANG for design has to do the level of ambiguity and scope of the project rather than their ability to more unilaterally decide which direction to go. For example, at Google:

- L4: Generally gets projects with known problem and relatively obvious solution, L4s mainly just need to talk to the relevant people to find a reasonable solution that everyone agrees on and document it well in a design doc. The hardest things here are usually clearly describing the solution chosen and the tradeoffs. It's rare the decision is controversial.
- L5: Generally gets projects with known problems but **unknown** solutions. So the hardest part is usually finding the right solution (which can sometimes be entirely a new thing to the organization) and also convincing everyone that this is the right path to go. Decisions on the right solution might be controversial and require lots of consensus building. 
- L6: Projects with **unknown** problems. L6s typically handle projects where finding and defining the problem is typically the critical factor in its success (e.g. the organization knows they needs to cut cost and infra cost a lot, but they don't actually know whether that's a problem or the problem is elsewhere, so they task an L6 to investigate). So sometimes L6s don't even write design docs, they simply write problem statements or vision docs or something that becomes the core motivating force behind giant projects. Once they define a problem, they may delegate the finding of exact solutions to the defined problems to L5s. I see L6s reviewing more designs docs than they write them.

Having said that, higher level ICs do tend to have more ***influence***. But this is more of a result of their continued good judgement rather than their title or level - e.g. other engineers simply agree that the solutions they propose have been good and give the benefit of doubt that their new solution is going to be good. It's entirely possible for high level ICs to continually display poor judgement and propose bad solutions, to the point where they have no influence despite being at higher levels. Any proposal, no matter who proposes it, will be scrutinized at the end of the day, but having more, shall we call it, "street cred" can definitely help.

First, take a deep breath! Once This is largely positive news, especially if you goals are to grow. But I understand that it never feels good to receive feedback, no matter how well intentioned (I myself feel the same way). Ones we don't see coming can be ***especially helpful,*** because it might help us identify our own blindspots.

My main advice to you is to dig deeper into this piece of feedback. I agree w/ you that her feedback is vague (or a least, your understanding of it is). Best pieces of feedback are specific - they sound like "In this situation, you did x and y, and that result in this suboptimal result, and if you thought about A and did B instead it would've had this positive impact", etc. I would try to figure out answers to the following questions with your manager or your peers, in no particular order:

- Is this a developmental feedback or a performance feedback? (developmental = you are doing fine but you can optionally do even better; performance feedback = you are not doing fine and continuing this trend will result you in a PIP). You said she suggested the latter, but I would make certain which one of these it is.
- What specific actions, behaviors, or context made her feel like you need to improve on problem solving and asking better questions? The more specifically you can understand this the better. What is that you didn't ask enough questions at a specific junction of the project or meeting? Or is it you asked the wrong questions?
- Is the problem a one-time thing, or is it a pattern? Perhaps, she's been thinking to tell you this for sometime, but couldn't find a good reason? This will help you understand the magnitude of problem.
- Is this feedback coming from her or is she a conduit for someone else's feedback? If this is her feedback, you could for example ask peers in similar context to see whether they share her assessment.

Ultimately, for you to take actions and actually grow, you need to understand where the problem is and it's not clear to me that your manager or you have discussed this in detail.

A couple of tangential thoughts on what you shared with us:

> ...that is on me to come up with an improvement plan. This feels wrong to me, isn't that her job as a manager?

...And it's also the employee's job to own their own career growth. Look, your manager **can help you grow and coach you up**, but this is at least a 50-50 relationship where both parties need to uphold their end of the bargain. I think if you don't do it, your manager will eventually come up with a plan; you just might not like that plan. I know I would rather follow my own plan if given the choice.

Lastly, I would ask you to be empathetic to your manager - it's very hard to give feedback well, and it doesn't sound this one went well. But it's much, much better getting a piece of feedback earlier when you still can do something about it rather than late, say after a project is completed. So maybe at least give her credit for that?

> That means that I'm putting in more hours than I should frequently, and I'm starting to feel demotivated and depressed.

What are your personal motivations for taking on this project in the first place? And maybe, just maybe, this project isn't a good fit for you, and given you've done well (?) in the team for the last two years, you just need to find a new project? Maybe a vacation would help with a reset? In any case, don't underestimate the effect of not taking care of your motivation, energy, and mental health can have on your work and personal life.

Thanks for sharing your situation with us - I think this is a common situation we will all run into at some point in our careers!

It sounds like your manager and your skip aren't aligned on the team's goals as it's rare for skip managers to assign work to their direct's directs. I wonder how your skip talked to you about it - was it more like, "Oh, this XYZ project would be good to do?" If so, I wouldn't be too worried.

It's entirely possible your manager isn't even aware of this non-KR task and haven't considered it. Depending on how urgent your current assigned work from your manager is, you could easily switch over to doing the other work (either way, it doesn't sound this is your main deliverable, so the stakes here are fairly low).

If you feel comfortable, I would take the initiative here and just start a chat group with your manager and skip about this. Say something along the line of "Oh XYZ \[skip\] mentioned that project A is can be really good and be my second project, but I'm currently working on project B. Is A more important than B for me to work on?" Feel free to turn this into a meeting as well if that works better for your managers.

Once the relative importance is agreed upon, you can work w/ your manager to adjust team OKR and your own GRAD expectations if needed.

I concur w/ Alex and Rahul in that your manager exhibits **toxic** behaviors, seemingly ignoring basic well being of people on the team. It seems that you've only been here for a month or so, so I think the easiest course of action is to leave. I would want to see whether one of the other roles you turned down might still be looking and would be interested in re-offering you.

> I genuinely want to make the best out of my current role and contribute positively to my team. Your insights and advice will be invaluable. Thank you in advance.

However, it seems you want to stay and try to make this work. I've gone down this path before and I can think of the two outcomes that can be "good": (1) your manager is removed from their position as the team's manager, (2) your manager's toxic behavior improves for whatever reason.

The "neutral" and most likely outcome is (3) nothing really changes but you put your head down to work and protect yourself from as much further damage. However, this outcome is not something you want, because it forces you to be overprotective, is still going to be extremely stressful, and could traumatize you for future roles. So in my opinion, this option is actually a "bad" outcome - if you were thinking of going for (3), you might as well leave.

### First - take care of yourself.

No matter the outcome, your immediate concern is to make sure to take care of yourself. This means physically and financially - make sure you sign up for your health insurance, get any medical treatment you need, and properly setup your 401k or whatever other financial benefits you are expected to receive. Do not worry about contributing to the team until you've taken care of yourself.

And secondly, you will need to pay extra attention to your mental health for the duration of this... struggle. No matter how much you try to put your head down and work, it's going to be emotionally draining, and it's going to take a long time to resolve. I would advise against working any more than you need to - going above and beyond in this type of situation isn't likely to get recognized.

### Coalition Building Stage: Take care of your peers

No matter which of the "good" outcome you decide to go for, you are going to need allies.

If you've only been here for several weeks and your manager's already been this toxic, I can't imagine how much toxicity your teammates and peers has already observed.

I would proactively schedule 1:1s with your immediate peers and support them in anyway you can. Reach out to your team lead and designer - if they want to vent, just listen and empathize.

Your goal during this stage is two fold - provide care and psychological safety for your team, and to gather information. Specifically, you would want to have a pretty good grasp for the following questions:

1. How long has this been going on? Has your manager always been like this, or are there specific stress factors that's forcing out their worst behavior (it doesn't excuse it, but it could point to the fact that it may be addressable)?
2. Has anyone on the team had **positive** experience with your manager and would vouch for them?
3. Has anyone reported this up to the skip manager or HR? If so, how was this received? Are there company surveys that points the issues?

Even if you are planning to directly give your manager feedback, it's important you build allies on the team first, will at least have someone on the team looking out for you if your manager decides to retaliate.

### Giving Feedback to Your Manager

I think you only want to attempt this if and only if...

1. Your manager's toxic behavior are irregular - people say they are not like this normally.
2. You have somehow earned your manager's trust.

If either is untrue, it's extremely unlikely your direct feedback will have its intended effect. If your manager has always been toxic, it's unlikely that you are able to change something that's very fundamental to the way they manage - and you should be able to figure this out with Question #1 from above. If you manager is only occasionally toxic but usually very understanding and has expressed desires to improve (but just don't know how), there's hope.

If you don't have your manager's trust, they are likely to see your feedback as an attack and retaliate in some way shape or form. To know whether it's possible to earn your manager's trust, Question #2 is very important. If someone else on the team has managed to establish good working relationship with your manager, that means it's possible for you to do the same using similar methods. If not... you are going to be treading in unknown waters. Ultimately, people who display toxic behavior are usually scared, isolated, and distrustful - you are going to somehow win them over and have them believe that you are one of their allies in order for you to be able to help them improve.

### Getting Your Manager Removed

Assuming you can't safely give your manager feedback, the other possible solution you can attempt involves some aggressive action: find a way to remove your manager, or at least apply pressure to your manager from the top. Question #3 should inform you whether pursuing this path is worthwhile at all.

If someone has already brought this issue up to your skip manager / org leadership, and they haven't done much about it, then this path is unlikely to succeed.

If no one have, then there may exist an opportunity to bring direct feedback up the chain to compel a change. Personally I would prefer to raise those issues with your skip instead of HR.

To do this effectively, you are going to need a lot of evidence. A lot more than what you've presented to us so far. Further, what you want need to be able to do to describe the pattern of toxic behavior, and what the effect of that is on the individuals on the team. **This is also a lot more effective if as many individuals as possible speaks out at the same time.**

Note - after doing this, you may be asked to bring this feedback directly to your manager. At this point, you can do this, assuming that you trust your skip to support you. Even if your manager attempts to retaliate then, you presumably will have higher powers protecting you from harm. However, I think it's quite unlikely at this stage that your manager will change their behavior, and in fact quite likely to double down and try to defend themselves. Still, the same thing applies - you need to find a way to earn their trust that you are trying to help them, not to attack them.

### These "good" outcomes aren't very good.

I have personally contributed to an outcome where my toxic manager was removed. Was it worth it? No:

1. The whole thing took 6+ months.
2. The team was dissolved/absorbed as soon as the leadership found an excuse to do so; most of my peers left soon after.
3. The manager attempted to damage my performance rating and bitterly left the company.
   1. No one on the team gained anything from this career wise. It's almost impossible to earn good ratings during this type of chaos.
4. I still had to find a new team within the company to join for my own wellbeing and growth.

This is why **leaving a toxic situation is usually the best thing to do.**

If it helps, manager performance depends a lot on **retention**. So by leaving, you are signaling that this manager has a problem, and you are likely to have contributed to the final resolution without inviting open confrontation.

Tech Lead, Senior Software Engineer [L5] at Google

Melissa and Jonathan already did a great job (I’m especially a fan of small, atomic cl/pr/diff!) 

I would add that if your team has an agreed upon style guide or something similar, attempt to apply that onto your cls.
If you don’t really know how to do this or your team doesn’t have a style guide, try the following instead:


Look through your past changes and the comments your reviewers left. Do you observe a pattern of similar comments? (Is it… lots of naming adjustments, unit test structure, or something else?) Focus on getting better at a specific set of feedback and ask yourself if your new cl has similar problems to prior ones. In general, try not to have your reviewer point out the same problem 3 times in a row, and past comments are a great source of learning about what kind of mistakes you tend to make.

This really depends on the person... but in my opinion AMAs are places where you could ask some questions that are a bit of curveball and not really a tactical thing related to the current set of priorities. I feel like these questions give valuable insights into how the person thinks. 

1. Career questions. "How did you arrive at your position?" "What were the crucial moments in your career?" etc.
2. Why questions. "Why are we doing X project?" "Why do we have this particular team structure"?
3. Team/Org/Company questions. History of the team/company, if they are a long time member. Where they see the team and/or company in the next 2-5 years?

First, let me acknowledge how maddening this situation can feel.

> The biggest problem is that the reviews happen in person and the reviewer gets nasty and yells at times. He is extremely rude and after a few minutes he tries to explain that all the feedback is for my own good like am a kid. I expect some amount of professionalism but I feel disrespected because of the attitude.

An engineering lead shouldn't make anyone they are responsible for feel this way, even if reviewing their code can be frustrating. **You don't deserve to be yelled at, no matter what your code looks like.** Many people struggle at having efficient code review processes because code reviews are ultimate tests of communication and trust between people, and we generally suck at it.

It's quite possible your lead has a behavior problem, or there's generally a lack of commonly agreed upon standards like Casey said. 2-3 days is a long time, the general SLA for a healthy software team is 24 hours / 1 business day, and preferably much faster than that.

But who's at fault here isn't ultimately that important, because usually all parties contribute to the problem. As you can't count on others to change, it's important you to ask yourself this question: **How am I contributing to this?** Why might a code reviewer take a really long time to review my code?

A couple of reasons I can think of:

1. The reviewer is extremely busy and preoccupied with other work.
2. The reviewer isn't familiar with the particular code base.
3. The reviewer doesn't like to review the code for specific engineers, because historically these engineers' cls have required many iterations and many comments, which were (1) energy consuming for the reviewer (2) produced unpleasant human interactions.

If #1 or #2 is true, escalate to your manager and maybe get more help for your leads to distribute review responsibilities.

But it's also possible #3 is in play here. **As a code reviewer, I am partial to, and am more responsive to, certain code authors.** It's not that I want to be and I personally strive to do better, but I just know from experience that certain people produce code reviews that align better with the principles and styles of our code base compared to others. It's just human nature to delay activities that produce stress - and **both code authors and the code reviewers find lengthy code reviews to be stressful and frustrating**.

If your lead is otherwise pretty fast on reviews with other folks in your team, I would definitely try to understand if I have done everything I can to produce clean, easy-to-approve code reviews. I would recommend watching this [Taro Video](https://www.jointaro.com/lesson/fTnWHqkYCPuaGa9FqaDf/noob-software-engineer-vs-pro-software-engineer/) for some guidance, but one of the key there is that "getting the code to work" / "not have bugs" is merely the first and easiest step. There's usually equivalent amount work to get the code, PR/CL description, test plan, etc, to be sufficiently up to standard BEFORE sending it out for review. I wrote a quick [this](https://www.linkedin.com/posts/kuanp_softwareengineering-codereview-codequality-activity-7038275986999697408-EjB3?utm_source=share&utm_medium=member_desktop) to describe what code reviewers generally look in a code review and it might be helpful to you as well.

It's also not impossible that your lead feels guilty about being an a\*\* and would appreciate the opportunity to help you understand how to prepare such clean, easy-to-approve code reviews in your code base. Either way, a conversation would likely help, especially after reading this you would like to change how to approach code reviews in the future.

First of all, congrats! I remember when I got promoted to L5 at Amazon, it was extremely meaningful. So by all means please enjoy this time and make sure to thank the people that helped you along the way. And like Vaibhav said, please pass whatever wisdom you've learned to others, whether by finding a mentee or commenting here on Taro!

I will offer you one interesting question that people often think about when they get promoted.

**Is my work, my team, my org, and/or my company** **aligned with my goals and interests?**

I've often found that the same environment that promotes one type of growth isn't always good for another. While you don't necessarily want to jump ship right away after a promotion, I think you at least could to do some due diligence to ensure that it's still right the place for you. There also tends to be less self-imposed and external pressure to meet deadlines and such in the immediate term, so in my opinion it's a good time to explore!

Promo "resetting" is probably not the right way to think about it, but it's a common thing managers use to tell reports to be patient / that they are not yet ready for promotion.

Having said that, I do think it's true that moving teams, especially when those teams have very little in common with one another, will soft-reset your promotion progress. I think this is true across Big Tech, not just at Google - it definitely happened to me during my L4-&gt;L5 promo at Amazon where all of the promo artifacts came from the team I was on then and nothing from my prior teams.

But I think the main reason team transfers resets progress, especially for L5+ promotions, is that those promotions depends a lot on two things that definitely reset when you move: your reputation amongst your peers, and your relationship with key stakeholders. Ultimately, for you to get promoted, people other than your manager needs to vouch for you and put their own reputation on the line to advocate for you.

Okay, that's the "bad" news. Here's the "good" news.

Reputation and relationship can be built outside of project delivery timelines. It means you don't have to finish shipping a massive project to get promoted. These things are primarily built with the right set of behaviors. Basically, if you think and behave in a way that L5 would consistently, then people will take notice, and they will start giving you opportunities that together will help you get promoted. If you are unclear what this set of behavior means, then figuring it out with your manager is probably the first step, but there also exists plenty of resources here on Taro that should be able to help you.

If you are already behaving in a L5 manner, e.g. being a thought leader in your team both technically and interpersonally, then promo in 1 year isn't out of reach. But often it takes longer, because to behave at L5 level requires to change your mindset and how you approach your work more generally (maybe especially so at Google). The truth is, your own internal growth doesn't reset when you move teams (it probably encourages more growth instead!). When you've internally grown to an L5... often the external indicators such as promotion will follow.

==

A quick note about GRAD and Promo! From what I understand, these are now separate processes. You could easily get a S rating in March and get promoted in August, because the S band is incredibly wide (\~70% of people gets this, including some people that got SEE in previous perf system). It is useful however to discuss where in the S band your rating falls with your manager - for example, if you are getting near bottom of S, your promotion likelihood isn't high. 

Rahul and Michael have nailed it in terms of how to "succeed" as an intern.

The only thing to add from me is this - **use your internship and Taro to figure out if you actually want to pursue this career.**

The best way to do this is talk to a lot people, both here on Taro and at your work. Ask people about their journey and figure out whether you would like to spend a significant amount of your life tackling similar challenges.

As an intern you can still easily change course and do something else either adjacent to software engineering (PM, UX, Sales, Marketing, HR, etc) or pivot to entirely different industries. Doing due diligence now on how you feel about the industry will go a long way to keep you motivated, especially through the bad times!

Good luck!

This is actually a super interesting scenario, that tech leads run into all the time. I will offer you some potentially controversial food for thought.

As the tech lead, you have responsibility to 3 parties here:

1. Your engineering colleagues, for upholding the standard.
2. Your juniors, for teaching them the standard (and helping them deliver that standard).
3. Your superiors, for delivering the project on time.

The **bravest** thing to do here, in my opinion, is to uphold the standard, delay the project, and take the blame for the delay yourself on behalf of your junior, and promise to do better next time. 

Doing this isn't part of any job description nor is it part of expectation for a tech "lead", but it is a part of what a leader of people would do, if that is something you aspire to. Leaders take responsibility for the mistakes of those in their care.

To me, this code review issue is simply a symptom of how you may have run the project as a whole. I suspect you haven't really fulfilled responsibility #2 throughout the project, and this isn't likely the first code review this junior has submitted that's subpar in quality. Could you have helped the junior earlier in the project, and mentored them to the point where at least their code was not visibly below standard? Could you have sat down earlier in the project, and pair programmed with this junior engineer to help them understand what the coding standard was?

Again, I think what you did was fine and no one is expecting you to do the "bravest" thing here and most of us will probably choose the "easier" paths instead. But from what you've described, you essentially chose to fail responsibility #1 to fulfill #3. You can make that choice, but in my experience, your reputation with your engineering colleagues and how you treat your juniors is the thing goes a long way to help you have a successful career, as they are the ones who will voluntarily vouch for you come during performance / promotion / job switching times.

Hope this was helpful, and if not, at least thought provoking! I'm happy to chat further here or over slack if you want to continue this conversation :)

These sounds like great first steps. Please update us on how you feel in 3-6 months!

I totally get what you mean when it comes to wanting to reduce exposure to social media and content services more generally to facilitate deep work, and my own relationship with this has shifted over the years.

In 2017 I discovered and read Deep Work; and then I decided to go on a social media ban, in part to help me with deep focus, in part to help me feel more secure. I deleted all social media apps from my phone, installed newsfeed blocker on all my devices, with only Facebook Messenger available to talk to friends. I basically stopped consuming content entirely from social media during this time. The only form of career content I consumed during these times were... books.

I am now reconnecting with some of the platforms, like LinkedIn and Taro, and have a different appreciation of them than I had before. Here's my takeaways from this personal journey, but YMMV.

### Social media is a powerful tool for connection, not consumption

The 5 year social media hiatus I took taught me that the best part about social media isn't the **media** you get fed by the algorithm. Instead, it's the possibility you can form genuine connections w/ strangers - the **social** aspect - that makes social media platforms so special.

In my experience, social media is most useful for broadcasting the message of who you are and/or what you are all about to a huge amount of people, in the hope you find a fellow like-minded individuals with whom you can help each other achieve your goals. Those relationships are going to be meaningful to you even when you leave the platform.

So in my opinion, unless you are **actively** building relationships and are **actively** signaling your unique brand by producing content on these platforms, it's usually not worth using them **passively** just to consume content.

A cynical way of looking at this is that you are just consuming content, you and your attention span just being captured and sold to advertisers for $$ and you are likely not benefiting a lot from that exchange. Creators intentionally say things like "Join the XXX engineers getting exponential better than everyone else, subscribe to this newsletter!" to stroke your insecurities and make you think you need their content to succeed. It's part of the marketing. We obviously aim to create useful content, but content is really only useful to you if it leads to actual improvement.

The positive spin on this is that clearly other people think your attention is valuable! So, you can treat it like it is, and control what you spend it on.

### When you are working on self-improvement, taking action is more important than having more knowledge

Presumably, you are consuming content (especially on platforms like LinkedIn, Newsletters, Taro) to improve yourself. But too often, I have found myself and others are overwhelmed by the multitude of wisdoms that dot the internet. But there's no way I have the time to consume all of the good stuff and apply it too.

Ultimately, self-improvement happens via actions and consistency. Just reading and watching stuff is just the start of it. When we are taking action, more content telling us what to do is going to simply distract us from implementing change and reaching our goals. In fact... reading content is probably one of the best way to procrastinate on actually taking actions for self-improvement because it feels "productive".

You are probably going to learn a lot more applying every lesson from just one source (say, Deep Work) over the course of a year, than reading 100 books and thousands of newsletters. There's many ways to curate your sources, but **focus** is key in helping you translate what you consume into what you live and breath everyday.

> And can we switch and up-level internally?

At Amazon and Google, this wasn't possible. It wasn't even possible to try to negotiate compensation even if the levels stayed the same (I attempted it when leaving Amazon).

Having said that, you can switch into a role with more responsibilities internally, even if your levels stay the same. If you perform well in these cases, you may be able to get promoted soon after switching teams.

I have heard of one other example where the destination manager promised to promote the person switching team within the next promo cycle. I'm hopeful for this person but IMO this feels very risky.

Yes, I think it's possible, but likely harder; it will be especially hard if the internal tool you support doesn't already have a huge number of users or it's not very critical to the running of the company.

I worked on Google's Engineering Productivity (EngProd) org for a bit, whose mission is to improve the productivity of product engineers via better tooling and test infrastructure support.

EngProd definitely had room for L6+ engineers (most were managers), but they were rare, and were really only needed when the product engineering org they supported grew beyond a certain size.

Fundamentally, SWEs at big tech are usually evaluated similarly across the company. That means especially at L6+ levels, engineers need to find big areas of responsibility and do work that result in large impact. Doing this for an externally facing product (hopefully a "core" product of the company), compared to internal tools, is vastly easier, because you can usually find some correlation between the work you are doing and the bottom line of the company. For example, for a product engineer to justify their impact, they can say did project X that resulting in improvement Y for Z amount of users, which resulted in XYZ amount of additional revenue for the company; in contrast, an internal tool engineers would certainly have a smaller set of users and murky revenue impact numbers to go off of at best. As such, career growth on these external product tend to be smoother, though YMMV.

So, if you only look at career advancement perspective, externally facing product teams are better. But on the flip side, work life balance on internal teams are often really good and tend to be more stable.

This sound like a situation where the fit is poor from both sides. Unless your manager is able to provide a dramatically different environment (unlikely) when you discuss potential PIP recovery path w/ him, I think there's little chance you will clear the PIP. 

If you don't have immigration or other dependencies requiring you to hold a job, cutting your losses here would be the way I would go. Depending on where you work, HR likely will offer you a severance package if you choose mutual termination (and I would ask for a package if they don't offer it initially). 

You might not need this, but maybe Alex and Rahul's tips on [finding teams that fit you](https://www.jointaro.com/lesson/UGIUC9zaGccK0tOarBri/how-to-find-a-good-team-with-career-growth-opportunities/) could help you as well!

Great question! Rahul and Alex already shared some of their thoughts on location [here](https://www.jointaro.com/question/K35C2YRAXVZvj7t85ClU/how-important-is-location-for-software-engineers/) and [here](https://www.jointaro.com/question/ltyKjUmX0aWrJZjnEByD/does-not-being-in-the-bay-area-hurt-your-career-as-a-swe/), and I mostly concur with them holistically that Bay Area in a vaccum is better.

However, I feel that you've provided some good context on what you are considering, and since I lived in Bay Area for about 2 years after graduation and moved up to Seattle (mainly because of my partner started her job there), I'll try to weigh in on this with a bit of my own personal perspective.

### To learn the most, you need a good team.

From a professionally learning perspective, the most important thing is finding a good team for you to learn from and build your skillsets and perspectives.

With this in mind, the location doesn't matter as much as the composition of the team that's offering you a job. For example, in a situation where a team with most of its members in Bay Area and a minor hub in Denver, I would choose to be with the majority of the teammates in Bay Area, because **learning in person is way more effective in person,** early on in your carer.

Colorado is sufficiently big enough of a tech hub to have major companies like Google having dedicated engineering offices there. I think if you found a good team situation where most of the team is located there, you'll have a great opportunity to grow.

That being said, if you aren't yet at the stage where you are comparing offers, I would look at jobs at both location, if only to have potential offers from Bay Area as leverage.

### Support systems are tremendously important.

Your career will have a lot of ups and downs. It's inevitable. I remember being part of the best team and under the best manager of my life for about a year; and one day, that was over thanks to an reorg. If you and your partner are serious, I would discuss whether Colorado is where you guys want to be long term, and make a decision together.

That being said, Taro isn't a ... life or relationship forum, so I'm not going recommend you to do it one way or the other. So I would say that if you do decide to go to Bay Area, make sure to build up your support network there (friends, etc) and keep the connection to your partner strong.

### This decision is a 2-way door professionally

One more piece of perspective on this. Going to work at a particular location as a software engineer is a non-binding decision. In Amazon they call these "2-way doors". It means you can reverse the decision if you don't like the results, at least when it comes to your professional career. Going to bay area after 2-3 years in Colorado (or vice versa) isn't going to be very hard, and your software experience will translate no matter what location.

But some decisions are not. This includes decisions relating to your partner.

Personally, when I had to make the decision, I asked myself - if my partner and I were to break up because we didn't try to make it work being together in the same city, would I regret it? For me it was a resounding yes and that's why I moved.

First, I'm sorry you are going through this. It can't possibly be easy to motivate yourself to go to work every morning.

My initial gut reaction is that you should just leave. You are 8 months into this role, so it's past time I would shrug off the bad behavior you described as "miscommunication" or "unintentional". Removing people in power is quite hard for leadership to do, and requires a lot of explicitly terrible behavior for it actually happen - and it doesn't sound like that's a bridge any of the managers wants to cross.

I am a bit confused by the presence of two staff engineers on the same team - staff engineers generally oversee the work of 10+ people, so I presume there's at least 20+ people in the team. That's a LOT of people on a single team / feature. If not, it seems their titles are inflated - their behavior certainly doesn't indicate they know how to be an effective staff engineer. It simply seem like these two are monopolizing power and not actively sharing it w/ people on the team. In any case, you can elaborate more on the team structure and the operational problems you see, we may be able to help more.

Still, it may still be some time before you can leave. So I would still try to at least find one thing that you can do on your own (that doesn't need anyone's permission) to improve the lives of people around you in the meantime. Maybe you can start documenting all the learnings from your oncalls, eventually making an oncall handbook. What you despite unfavorable situatio will go a long way to boost your own confidence, (doing so did for me).

Maybe one additional thought:

Would your old company consider giving you a significant pay raise? They are reaching out to you, presumably, b/c they weren't able to retain some of the employees they didn't lay off or they messed up their $$ calculations. You have some leverage here that I would use to see if you can extract a better deal from your old company. I would entertain the idea if only for the fact that it would be an offer I can use to negotiate with all the companies you are already interviewing with.

Let us know how it goes!

Senior Software Engineer [L5] at Google

Hey there!

Rahul is spot on. Even if your specialize in a front end, the core software engineering competency is the same across most software specializations. 

I'm a web engineer without a ton of backend experience, but I've never thought of myself as exclusively web or front end. Being a generic SDE is much more liberating, both from a job search perspective and a compensation perspective. You can still do primarily front end work even if you transition to SDE.

Great question! I love how you've thought about this, and I agree, this seem counter-intuitive.

I have a few reasons I believe why this making themselves "replaceable" is good for the senior engineer / tech lead. I'll refer to this from a tech lead perspective as not every senior engineer is a lead and has to deal with this problem. 

In short, in making themselves replaceable, senior engineers / tech leads are able to lead less stressful lives, get rewarded in performance reviews for building great teams, and lastly helps them find more impactful problems to work on for staff promotion.

### Redundancy

The most practical and immediate reason is what you've mentioned - create redundancy within the team. Having other subject matter experts in the team means the lead isn't always being called into every important issue that occur. This is obviously good for the team, as single of point of failure is a big operational risk.

But for the lead, not being that single point of failure significantly reduces stress. This is especially true when the team has oncall - you don't want to be woken up at 3am or having to bring your work laptop on your vacation because you are the only person who's able to address urgent issues. In other words, building redundancy in the team helps leads to actually take their mind off work to recharge and avoid burning out.

### Scale yourself = Leveling up the team

Inserting oneself into every decision for the team (e.g. micromanaging) is exhausting and ineffective.

This is because when you are the only one making decisions, the team doesn't get better, as your teammates don't learn how to make the decision on their own.

It may even initially feel really good, as you feel huge sense of power and responsibility. But it gets really annoying really quick when you have to babysit everyone. And there's no one to blame as you didn't spend the effort to teach everyone how to make their own decisions.

Ultimately, **a gate keeper who doesn't share their secrets slows down their team.**

I experienced this when I first became a lead. I was quite nit-picky during code reviews and thought "upholding the standard" was what I should be doing. This turned out to be quite wrong, as this slowed down my team's delivery, and because I wasn't teaching them how to think about code quality effectively. When I decided to instead help everyone understand how how to think about code quality and start thinking as code owners together, it massively boosted the team's productivity as we simply spent less cycles on the code review process. It not only did not decrease our code quality but instead helped our code base become better as people proactively sought ways to improve the code!

[Part of the responsibility of a lead](https://www.jointaro.com/lesson/uHqZZ15SK19MatEvLSO6/what-makes-a-truly-great-tech-lead-a-vp-of-engineerings-perspective/) is to level up the team, especially empowering them with the knowledge and giving them agency to make their own decisions. A team that's full of independent folks who can make decisions on their own are extremely "agile" and effective. Building this type of team reflects very positively on the performance ratings of a senior engineer / tech lead, not mention how personally satisfying it is to work with independent people with whom you can bounce ideas off of each other.

### Free-ing yourself to do greater things

One of the biggest reasons, IMO, to make oneself replaceable, is so we can tackle bigger and more important problems. One of the hardest part of becoming a staff engineer from senior senior is to figure out what are the biggest strategic issues that your business faces, and then to work on these problems. You won't have the bandwidth to find problems, much less solve them, if you are constantly having to make tactical decisions every day. You need to be able trust that your team is able to run without your oversight while you dig into more important, long term issues.

You asked whether it's a good idea to make yourself replaceable is only good when the company is in a "hyper-growth phase". While I have not been part of a declining or static organization, I would argue that it's even more important to ask in these situation whether there are problems that aren't being solved today that, if solved, would dramatically positively impact the organization.

So, don't make yourself replaceable just so you can relax and chill; make yourself replaceable, so you can do even greater things!

If there are other folks with thoughts on this topic, I would love to hear others' perspectives too! 

Jordan and Jonathan's answers are both great.

I do want to put "strong opinions" in context. Strong opinions are vital in helping organizations make decisions. Correct ones steer the organization toward success, and well, incorrect strong opinions are often disastrous. So being cautious about having strong opinions isn't bad thing.

In a way, opinions are generally **predictions about what would happen if a particular action was taken/decision was made.** That's why, like Jonathan said, it's important to:

1. Logically think through why you arrived at that opinion/prediction
2. Be open to alternative predictions that could also be correct

To develop stronger opinions and make more powerful predictions, I would start with having opinions about your own work and your own ownership area first, before attempting to vocalize opinions about other people's work. This is especially true if you are afraid to be wrong.

So maybe right now you are taking a lot of opinions from others about what you should be doing in your space - but maybe you don't need to. Try planning for your own work. By doing so, you'll inevitably have to know what your opinion about what the biggest problems are, what you should be doing about it. You will even have to explain this to others, like your manager, and your act of presenting your thought process will demonstrate that you have at least some opinions.

Further, this will allow you to figure out whether your opinions are correct and gain the needed confidence. Repeat this and eventually you will have opinions about myriads of things, and you would also have done the work to back those opinions up.

Ultimately, if you find that your own opinions about your own work isn't correct, it won't be a big deal (the impact should be limited), and you can always strengthen your own understanding to make better predictions later.

Hope this helps!

Short answer, (1) is the way to go.

I know your projects are complex, because complexity is everywhere, no matter the stack and no matter the technology.

"Tell me about the most difficult / complex project you've done" is probably one of the most common non-technical questions we are asked about in interviews.

These questions are asked to college sophomores, some of whom have only taken intro CS classes. Do you think the college students' projects are technically complex, at least from an experienced interviewer's perspective? Likely not, but it doesn't matter - and it won't matter for your case either.

The reason the actual complexity doesn't matter is because the main point of these questions aren't to examine whether you had project with sufficient technical complexity, but **to figure out how good you are at explaining complex things.**

I think the reason this question is so popular, is because the ability to explain complex topics simply is indicative of how well a person understands a complex topic. And the ability to understand complex topics (and explain them) to paramount to collaborating in big tech. Ultimately, **they are looking to hear a story that demonstrate (1) your depth of understanding of a specific topic (2) how you overcome challenges.**

So, having said, that, here's what I recommend you prepare.

First, search through your past projects to find a project you really, really enjoyed, and one you enjoyed especially because it was complex and it took you a while to figure out what you needed to do.

Note down what was so challenging about it. Was it the multiple layers of abstraction? Or the fact the the dependent data arrived at different times?

Then try to remember the things you did to actually overcome this complexity, or if you didn't overcome it, how did you work around it? Maybe all you did was to actually fully understand the complexity and what it required of you. Whatever it is, note it down.

Finally, try to "explain to a 5-year old". Or your sibling/cousin/a friend who doesn't know a thing about your field. Can you explain them and help them understand that what the project was all about, and why it was so hard / complex, and how you came up with the ways to overcome that challenge?

If you can do that, you will do just fine when you explain that same project to an interviewer at Big Tech :)

Best of luck!

===

P.S. If you are applying to entry-level roles, you will be compared to recent college graduates, whose technical scope is very unlikely to be complex. Heck, it might not even matter which professional project you decide to explain, as long as you explain it well and crush your technical interviews (since that's where almost all of the weight is).

P.S.S. I would be a bit more careful about "coasting" at my current company, especially since you are going to need references to back you up. You don't need to acquire bigger scope projects for interviews, but your reputation, where you work at, matters. Tech is a small world and you don't know who will be running into down the road.

I love books. They can be transformative in helping you to see yourself differently and help you approach situations in our careers differently.

Though, like Alex mentioned, books aren't as useful as real practice for learning hard technical skills. Additionally, to really appreciate a book, you need to have had the experiences to relate to its message.

I shared about some of the books that spoke to me at different engineering ladder for me on LinkedIn - see the [post](https://www.linkedin.com/posts/kuanp_softwareengineering-careergrowth-leadership-activity-7063274576385888257-JdPu?utm_source=share&utm_medium=member_desktop) here if you want the full list. Not all books here will be useful since you are just getting started, but I hope everyone can find the right book for them!

A bit late to this topic, but I had a thought to add on top of Rahul's great recommendation, especially if you are not just trying to find a decent manager, but a great one.

To find a great manager, **interview their reports**.

You want to ask them how they feel about their manager and the culture. Go straight in with something like "How do you like X as your manager?" and you can dive into specific questions later.

You want to do this because engineers will typically give much more honest perspective and will try less hard to sell you on the team/company, and can potentially address your concerns about the PIP culture. But more importantly, you want do this because engineers generally can't wait to tell how much they love their manager if they've got a great one. 

All managers have flaws, but great managers are leaders who inspire loyalty in ways you will only know once you've reported to one. I've had about... 8 managers in my 8 years of being in the industry (wow I've gone through one a year 🤣), and two of them were phenomenal people I would work for again if given the chance, and I know almost everyone on the team felt the same way.

If the response you get is a neutral "meh" or a mildly positive "oh yeah, they are good, I guess", then it means the manager is not that good. Great manager will get you responses like "they are the best manager I've ever worked for", "they are soooo gooood!!", and the people will be able to tell you multiple instances the manager helped them when they needed the most.

Best of luck to you - and to anyone else in the search!

What a thought provoking question!

This questions gets into the psychology of self-improvement and I'm not sure any of us are really experts or have degrees there. What I can share is what I've learned through my years of being w/ a coach, reading various books, and applying the advice/lessons I've been given. So do take all of these w/ a massive block of salt.

And before I get started, Jordan and Casey has a list of amazing questions and resources. I would think hard about them.

Specifically, "does this habit make me feel worse?" is an important question. If reading those email headings makes you feel like a failure or somehow inadequate, then I do believe this isn't healthy.

Now, the second question is whether this behavior has actually achieve your goals. Have you taken more proactive behavior in social settings when you've seen those messages? If not, the habit is at best ineffective.

If a habit makes you feel worse AND doesn't help you achieve your goals and/or become the person you wish to be, then it's likely self-destructive.

From what I can tell, most of us have some level of self-destructive tendencies - for me, it's binge watching shows and binge gaming, and for some it's comparing themselves to others, etc.

However, from my personal experience and reading other psychology books, there almost always is a good emotional reason we are engage in self-destructive behaviors, despite the fact we know it doesn't help us achieve our goals.

A large part of that for a lot of us is the **feeling of comfort.** Loneliness, self-loathe, and other painful feelings are sometimes ingrained in us from our past experiences, and reminding us of these painful feelings can sometimes in turn help feel us feel more comfortable because they are familiar.

So maybe the question to ask is **what are you personally or emotionally gaining from this activity?** We humans are very bad at doing things that give us no incentives. There must be something you are gaining from doing this that you need. Know this will help in the case you wish to replace this behavior - you would probably have satisfy the underlying emotional urge some other way.

Lastly, resources!

If this piqued your interest in psychology of our behaviors, I've found "Maybe you should talk to someone" very informative and great read.

If you are looking for more proactive ways to become more proactive socially, there are actually social coaches for engineers out there. I've chatted with [Myke](https://www.linkedin.com/in/mykemacapinlac/) but never taken any courses with him, but this might be something you want to look more into.

I wrote about this somewhat recently: <https://www.linkedin.com/feed/update/urn:li:activity:7044932251666567168/>.

In short, I think code velocity statistics are valuable and worth working on, but **make sure you understand it's an imperfect metric and don't over-optimize for it.** Ultimately, your goal with code is to do something useful ("impact").  

Quality commits can be a few lines long, so I wouldn't index too highly selecting exclusively for those you mentioned that are between 100-200 lines in delta. It's best to just count the number of cls generally.

In terms figuring out what's "normal", the best way is to look around. Some code bases are much slower than others to develop in, often due to years of tech debt. If you can, pull up code velocity statistics from folks who code in your code base, who are probably going to be mostly folks on your direct team and adjacent teams.

Hope this helps!

Lastly, I have a theory about maybe one gap in your behavior. It's just a guess, so feel free to ignore this if it doesn't apply to you.

### Own the project plan

From what you said, like

> For now, I will just go through the notes over and over again and hopefully come up with something.

and

> in which I have to say there are many frustrating moments after my manager explained his plan and I still want him to clarify more.

It seems like you are relying on your manager to tell you their plan, and you believe you primary role is following the plan given to you by your manager properly.

And that your biggest problem is not understanding your manager's plan properly.

I would think about this a bit differently. Maybe, just maybe, you need to actually do more of the planning and less religiously follow your manager's plan.

If you were an SDE II at a big tech company, this would be the case.

SDE 2s are expected to independent come up with their own plan to make progress on projects and get **only assistance** on designs. That means you may have an advisor, like your manager in this case, but you would be expected to own the creation and the execution of the project. Issues come up all the time during execution of projects, and it's your responsibility to react to these changes and adjust the plan accordingly.

So what is your plan? Why should it be done that way?

Write it down in a doc, and use that document to discover parts that you don't understand. If you are too intimidated to share it directly w/ your manager, ask a teammate to take a look first and ask for honest feedback. Again, prioritize asking your peers to figure out the things you don't understand. 

It's entirely possible that your manager is wrong on some level about the plan - after all, they have to keep track of everything else that's going on in the team. It's your job to be the subject matter expert of the plan and know it better than anyone else on team.

### Figure out how well you are actually doing

One of the things I've noticed from your question (and this was also true of my own situation) was that your manager seem to be the primary stakeholder who is both responsible for guiding your work, and assessing your performance.

This can work, if your manager was previously a SWE in your team/org, is also the subject matter expert, and most importantly, is a good coach.

It seems your manager has technical knowledge but is not a good coach. A manager who's able to coach will recognize what you need and teach you to help yourself. Saying *"I can't show you everything."* isn't a sign of good coaching - in fact, good coaches don't typically give you the answer, but helps you to find the way. Your manager needs to help you by either (1) asking the questions to help you understand how to think about the project and how to execute it (2) find someone who's able to help guide you through the process.

Unfortunately, managers who are able to coach well is rare. In these situation, it's dangerous to rely on your manager for everything. I would try to find other sources of guidance.

Specifically, I would look for a tech lead or some senior engineer in the same technical area, and talk to them to figure out two things:

1. Am I really underperforming? What is the expectations for people at my level taking on similar projects? Did I learn all the things I should during my onboarding?
2. How am I supposed to execute this project? What question should I be asking but I am not? Who I should be talking to but I'm not? How would they think about the project?

Other experienced engineers are much more able to give you an objective perspective on what the expectations are, because sometimes they are closer to actual work than the manager is. The goal is to **identify the gap** between what you are doing and what other folks would do in a similar situation.

In short, I hope your manager is able to help you identify the gap and help you improve, but don't count on them to do so; proactively seek additional data to formulate your own hypothesis.

### Setting expectations w/ your manager

First, you do need to take actions on the relationship w/ your manager. I think it's important that you acknowledge that something is amiss and that you would like to figure out how to address this together with them. The best way to do this is directly talking to them about it.

Use something along the lines of this during your next 1:1 to start a conversation about it would be good:

> I noticed in our last discussions that you seem disappointed about the pace of my execution on the project. I am doing everything I can but I realize I may not focusing on the right behaviors. I would like to work on this. Would you mind helping me understand what I should be doing instead?

This shows to them that you have the desire succeed, you don't mind receiving feedback, and you want to be coached. It should set up your manager with a coaching mindset. 

Ask them to paint a picture for you of what they imagine your role in the project would be like, and how they would execute this project (after all, they did say "You know I can do this very quick" - okay, how would they go about doing this?)

The goal is for you two to agree on a subset of behaviors that you should exhibit, because behaviors leads to outcomes. If the behavior isn't something you know how to do, agree on that you would work toward it but that you would like guidance from someone on acquiring that set of behavior. 

This [taro question](https://www.jointaro.com/question/t8NzbavMpB1a8EC5Zt2B/how-to-define-a-yearly-performance-plan-with-manager/) might not align completely with what you are asking, but it contains multiple resources to expectations setting w/ your manager that you might find helpful.

Hmm, this is a tricky situation. I would agree with your assessment that the "trust" between you and your manager is "in danger". You offer some really good details here, and this feels like a combination of two separate issues:

1. I've joined a team recently and I seem to be struggling to match the expectations for my level.
2. Manager seem to be disappointed in my pace of execution and I'm worried about our relationship.

Please leave comments for additional details if this isn't the correct assessment.

First, if this is the case, know that this isn't saying a ton about your ability, but rather about the lack of infrastructure in your team around properly bringing people up to speed. But this likely will still require a lot of effort on your part to figure out what the gap is between what you are currently doing and what is expected, and how to bridge that gap.

I myself experienced this when I first came into Google and I had to switch teams to find greener pastures. It's unfortunately common, and this may end up being a route you take as well.

Having said that, there are a few things I would like to offer to you to think about. I'll split them into separate train of thoughts since there's a lot going on here. I hope these help you - best of luck!

> Software engineering is a team sport and I have never experienced such apathy towards the people I work with.

I love your self-awareness with this one - it's hard to admit that you feel this way! Awareness if the first step toward addressing this - and we all need to feel like we are part of a great team to excel :)

> Is this the default in remote work?

I don't know if it's the default; I do know that, even prior to remote work becoming more accepted during covid, remote work always had **extra communication challenges**.

For example, one of the core aspect of showing up in a team is **presence**, and while we have tools that allow remote folks to simulate in-person presence to a degree, nothing we have comes close to speaking to a person face to face yet. (Or even just watching a teammate physically come into the office, working hard on their own.)

You might want to check out this [question on remote communication](https://www.jointaro.com/question/Uh8AcxVnZkosgQBkTuSH/how-to-build-connections-and-improve-productivity-as-a-remote-engineer/) for suggestions on what you can do.

Lastly, if you are genuinely looking to build genuine relationships, the most important thing to focus on is getting to know the people on an individual basis. For example, do you know who on the teams shares similar hobbies as you? Or who has the most interesting side-gigs? Do you know what are the career goals of your fellow teammates? And what motivates them to work for the seed stage startup you all work at? You'll likely have to take the initiative to get to know them and ask them questions first before they reciprocate for you.

I think you are asking about the [pallet x taro](https://taro.pallet.com/talent/welcome?step=welcome&pallet) collaboration.

Brad did a great job already, but here's some more specific answers to your awesome questions.

> Let's suppose that I have submitted PR1 for review and that PR2 is now to be worked on. If I wish to start on PR2, do I need to wait for PR1 to be reviewed? If yes, then will I remain idle until PR1 is reviewed? If not, then do I not risk that I need to revise PR2 if the reviewer has blocking review comments on PR1?

No, don't wait.

Yes, you do risk having to rebase + revise your dependent PRs when you practice this method. This is typically a small amount of work, **assuming you have already vetted your approach with your reviewers.** Generally, blocking design changes during code reviews are extremely painful, since your subsequent PRs depend on the first parts of your chain. Watch [this video](https://www.jointaro.com/lesson/fTnWHqkYCPuaGa9FqaDf/noob-software-engineer-vs-pro-software-engineer/) (and the rest of the code review series) if you are not sure what this means.

> Should I in general, complete all PRs before asking for their review? Or should I ask for a review as soon as I complete a PR? What if I realize that PR1 has something missing once I start on PR2 and start using PR1 as a dependency? Do I then revise PR1 and ask the reviewer to review PR1 again?

In general, send PRs as soon as they are ready (and ready is not the same as the code being "functional" - [this same video](https://www.jointaro.com/lesson/fTnWHqkYCPuaGa9FqaDf/noob-software-engineer-vs-pro-software-engineer/) covers this). If you have modifications to PR1 that is needed later, can you make this modification a PR on its own? That way, PR1 can be submitted without blocking for additional review.

I find myself doing this all the time. I would plan a feature to be split into 3-4 PRs, but I end up with around 6-7, because there's sometimes suggestion of followups that I haven't considered that I work on and send for review later.

> Are [**stacked pull requests**](https://www.michaelagreiler.com/stacked-pull-requests/) a well-accepted way of handling such dependencies? Is it prevalent and accepted as a standard in the software industry?

Yes, I would say this is the prevalent best practice. Small CLs are not a panacea, but it's one of the most proven best practices in the industry. From what I can tell, almost all of the teams in big tech attempt to encourage this.

One thing I'll add is that you do want to keep the amount of PRs you have to in concurrent reviews small, likely to a maximum of 3. **Reviewers do have trouble keeping track of longer chains.**

So even developing a single feature, find a way to divide it such that not all changes needs to be in a single chain - as if you are dividing a single project for multiple developers to work on simultaneously. This will not only help you keep the number of concurrent reviews in a single chain small, it will also pave the way for you to handle bigger, more impactful projects with multiple developers.

If there's one thing I've learned over the years, it's that there's no one "best" schedule or one "best way to work", but there are "best practices" that help you achieve more. 

I think the key is at least trying out some of these best practices in productivity and see what you like the best and which ones you can stick with long term!

For example, I know some folks really like the pomodoro method and take breaks every 25 minutes. I've tried it, and it doesn't work for me - I just want to keep working and I hate context switching.

Some folks love early morning productive hours but your personal life may not be able to accommodate that, on a daily basis. I've tried it, and while it does work for me, I can't do it consistently. 

I've also had several days recently where I worked semi-continuously late into the night for 5+ hours, and it felt really good! 

There are no expectations at most workplaces on how you ought work, as long as you are upfront about how you plan to get your work done. If one day you just can't seem to focus and want to go for a walk, then by all means, do it!

So having all that, here's some of resources I can find on Taro about personal productivity:

- [Day in the life of a FAANG Engineer?](https://www.jointaro.com/question/sOoGZwl8fsQ3hq8yv10v/typical-day-of-average-faang-software-engineer/)
- [Notifications and focus blocks?](https://www.jointaro.com/question/wavBNFOwhWDRAssDmwcc/turn-off-teamsslack-at-work-to-improve-focus/)
- [SWE Burnout](https://www.jointaro.com/lesson/xsbM1ctL9HYa6d7E9ejh/the-silent-killer-of-too-many-software-engineer-careers-burnout/)
- [Uncle Steve's tips on productivity](https://www.jointaro.com/lesson/s9VPqSHk2EuK2xOaBqYq/getting-to-the-top-1percent-of-amazon-engineers-productivity-tips-from-a-life-engineered/) (YMMV)

Re: certifications, see this taro [discussion](https://www.jointaro.com/question/RtBvd9fF8MGUqct7eVOH/are-google-certificates-worth-it/). In short, they aren't worth very much if you already have a lot of experience with the technology, which you seem to have already. 

I also don't think coding for the sake of interviews is important. LeetCoding is NOT real coding, though real coding skills do translate somewhat to it. If you needed to look for a new job, you can probably get good at leet code fairly quickly that it's a non-issue for interviewing.

Instead, I would look at this question as what you imagine a day in your future dream job will be like. Will you be spending most of your time creating and managing cloud services, or will be it creating new constructs and models out of code? 

For me, I enjoy writing code and I am not a fan of managing and configuring cloud services, so the choice is clear for me :) If you want to code more, checkout the [side project discussion](https://www.jointaro.com/question/KORArGLRW6mNn47ddC1S/how-will-side-projects-enhance-my-skills-as-a-software-engineer-on-the-job/)!

<https://www.aboutamazon.eu/news/working-at-amazon/what-is-a-bar-raiser-at-amazon> aligns with what I know from my time there, but there actually maybe some folks in Taro who are / were bar raisers at some point in their career who can talk about it some more.

Interview bar raisers are basically experienced interviewers from outside the hiring manager's organization that help calibrate interview standards across the company. It's a high-demand, voluntary role on top of one's day job with a lot of potential impact.

Are you asking this question because you would like to be a bar raiser?

Burn out is very common in our industry, so you are not alone!

Like Casey said, we won't be able to offer specific advice without understanding your problem in detail, but there is a general tip I can offer as food-for-thought for you.

Fundamentally, burn out at work happens when your time working frequently leads to your mental, physical, and/or emotional energy being completed depleted.

There are many tactics to (1) reduce energy leakage (2) increase energy generation.

For (1), the fundamental rule is **establish your boundaries**. Finding your manager pinging you off hours? Finding yourself getting distracted with Youtube or other social media that's not helping to make you feel better? Establish firm rules around what or what you will not do. There's quite a few books on this topic, but I've [this one](https://www.amazon.com/Book-Boundaries-Limits-That-Will/dp/0593448707/ref=asc_df_0593448707/?tag=hyprod-20&linkCode=df0&hvadid=598354936952&hvpos=&hvnetw=g&hvrand=8190971527141964482&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9033257&hvtargid=pla-1655045528820&psc=1) to be quite insightful.

For (2), I would say there are two approaches to this. One way is to **establish habits that give you more energy** - for example, taking care of your physical energy will set an increased baseline for your other pursuits. The other is to **find your intrinsic drive** - do you know what you find meaningful to do, and are you doing those things? If not - do you know how you might figure it out or find a way to do those things in your life? Doing what you find most meaningful will give you a lot of energy and keep you going even when the work is hard.

This [Taro question](https://www.jointaro.com/question/iJpayIUPb3vo71fUFEAI/how-will-advances-in-ai-affect-software-engineering-careers-in-the-near-or-forseeable-future/) on the effect the recent breakthroughs in AI on Software Engineering, this [other question](https://www.jointaro.com/question/n2qq0tGjSTDu982KL3nL/what-are-product-skills-and-how-to-develop-them-in-the-age-of-chatgpt-and-copilotx/) on what skills to acquire are equally worthwhile to read, and [this question](https://www.jointaro.com/question/3xg5SvXnyTQ0mhNLfbK1/how-to-ai-proof-your-career/) addresses how to think about integrating AI into our workflows..

In short, I wouldn't be worried about it in the near future, from a job opportunity perspective. If you are good at your job, you are always going to have role somewhere. (Nevertheless AI and AI-based applications are an interesting field!)

Another question you might want to ask your leadership: why do you need to do this project, now? If multiple teams failed at in the past and the probability of success is low, why does your leadership want the team to do it? How long do you really have to do it? They may have very good reasons and it could help you evaluate your strategies.

I love that you are trying help address major issues for your team and are being ambitious about your own growth. 

If you are most junior member of your team, the priority in my opinion isn't so much to chart your own path, but to learn from the other folks on your team. 

One thing to note is that while there are many engineering practices that are helpful, few are universally helpful. Even "code quality" can have varying amount of importance depending on the stage of the product / team. So it's important to understand the situation well before proposing changes to the current way things are done. 

As such, I would try to really understand the perspectives of more senior folks on your team and ask them what they find really annoying, and start addressing some of these issues. 

Having said, if there's one area you might be able to help with is onboarding, since you probably onboarded the most recently. Maybe you can improve documentation or start a mentorship program?

I recently (starting this year) took @Rahul's advice to put myself out there and started writing content on LinkedIn, and here's what I'm finding out...

1. Your immediate network will only take notice once you've done it consistently.
   1. When I first started writing, there actually weren't many people I knew intimately that interested or comment. For better or worse, many of my friends and coworkers just don't care about of what I'm doing - everyone just got their own stuff going on.
   2. The goal of your content is likely going to be adding value to people at scale - and that means strangers outside of your immediate work/personal circles. Since they aren't your primary audience, don't worry too much about their opinions!
   3. Having said that, recently, I did receive a few in-person, positive comments about the content I've been putting out from my friends, and that did mean a lot of me. This felt even better because I wasn't expecting it.
2. You'll soon quickly bump into other creators with similar aspirations as you, and their presence will help support your journey.
   1. The platform does matter, but people in the content creation world are generally very uplifting and wants to boost each other's influence. No matter your niche, there's going to be fellow creators. Don't see them as competitors, but as collaborators!

Looking forward to that office hour Rahul!

> I want to network with more senior engineers, especially those in the Taro community and within the companies I intern at, but I am scared to approach them.

Don't be! We don't bite 😬

In terms of what I find interesting in mentees, in no particular order:

- Share your goals / dreams and what you are doing about it - I want to know that my help is going to legitimately help you, so knowing what you want to do is very helpful!
- Sharing your struggles and insecurities and being open to overcoming them - I want to help where you are feeling the worst about!
- Ask good questions about the careers/life of others and being a good listener!

Put it this way, one of the best way for mentees to provide value to mentors is give them the feeling that they were useful. So actually being able to use the advice and turning into something useful in your life will incentivize people to help you. 

Another way to inject yourself into a community like Taro is by helping organize things. Maybe you want to participate in "water cooler topics"? Go to #random in Taro slack and start a thread, every Friday! Maybe you live in an area with lots of other Taro people. Organize an in-person meet up! Maybe there's a cool hackathon going on at your college. See if folks are interested in coming and organize the logistics of it. 

First, to answer your question around whether there are negative impacts of taking a career break - I believe yes, there is to some extend. It will at minimum raise a question during interviews that you would have to address. 

However, 3-6 months career breaks are very common, especially in the current economy (people getting laid off takes about that long to find new jobs), and so it will not be a red flag. The amount of companies that reject you purely based on you having a career gap will be very small. Long term, assuming you find renewed energy and commitment to toward whatever career/interest you decide to pursue, no employer would really care for the simple reason that how you look on paper / resume is much, much less important than your ability to perform on your job. 

If you are mentally and emotionally burnt out, you won't be able to perform properly - so I would consider taking a break as a personal investment into yourself. Being able to take a step back and taking care of yourself shows a lot self-awareness, and when you manage to emerge out of it renewed and passionate about what you want to do, you will be much more prepared to tell prospective employers why you did what you did. 

> Are there any specific steps or strategies I can follow during my career break to make it a more positive experience, both personally and professionally?

Since everyone's needs are different, evaluate these tips for yourself:

1. Go into with the goal of increasing your level of self-awareness - it would be good to come up with your own answers to these questions: 
   1. Why did I feel so burnt out? 
   2. What behaviors/habits/self-narration can I change to prevent similar situations in the future?
   3. What things help me feel energized and committed? How do I invite more of these things into my own life? 
2. Seek out help proactively. There's plenty of professional out there - coaches, therapists, or mentors who are able to help you on your journey. You are still going to have find the answers yourself, but you don't have to do it alone. 

Best of luck! Feel free to PM me on slack if you need anything else. 

I can totally understand how frustrating this can be for you. I had this happen to a really good friend of mine who joined a startup early on (taking a paycut to do so), and then eventually finding out that later hires were getting paid way more. Unfortunately, this is quite common.

But I strongly advise taking a step back and looking at this situation in a different light, and examine the facts and your assumptions.

**Fact:**

Your company pays a new hire, who is at lower level, with higher salary (or TC).

**Assumptions:**

Your company/HR disrespects you or thinks you are not good or thinks you deserve to be paid less for some reason. E.g. they are trying to offend you personally by paying you less ("Play you" in your own words).

This assumption likely doesn't reflect the reality.

The fact of the matter is that each salary contract is an independent negotiation. And negotiation is all about leverage, and how you use that leverage. It's likely somewhere along the process negotiation, you handled it sub-optimally, resulting in a lower pay. No company will ever pay you more than what you bargain for.

**Now, this isn't all bad news.** Here's a couple good news:

1. Your company was willing to pay a lower level person higher salary. This means they are in fact very capable of paying even higher salary for you. (You likely need to force them to do this with leverage, which we'll get to in a second.)
2. You might not very good at (1) getting leverage in negotiation (2) using that leverage. This is a thing you can improve on! Getting good at this skill will boost your future earnings manyfolds.

At this point, I would ask yourself a few question:

1. Do you like your job and your responsibilities?
2. Do you like the people you work with?
3. Are you learning?

Based of these questions, search deep down to see whether you still would like to stay here.

If yes, your goal is to renegotiate your pay. This can be hard, because right now, you don't have very much leverage. The only leverage you have is that you are going to quit without an alternative. Unless you have a tremendous relationship and/or the company will go down the drain the moment you, I don't think asking directly will do anything. It doesn't hurt to ask though, just keep your expectations in check.

To increase your leverage, you need to a find another company that is willing to pay you at a level you believe you deserve to get paid. Then you need to bring that offer back and ask for a raise. In the process of finding a team that's willing to pay you what you want be paid, you might decide that a new opportunity is better anyway.

Lastly, if there is anything you can do that will decrease your leverage in these negotiations, it's this thing you said you are doing:

> Knowing this information, I avoid putting extra effort into the team.

Here's 2 reasons why:

1. You are taking out your own personal frustration on your teammates who depend on you and your effort, and who had nothing to do with your salary negotiation. When you need to find new offers for your leverage, someone will have be your references, some of whom might be on this team. Do you want references who loves working with you or those who don't?
2. You are senior engineer, and you probably know how important these people are to the organization. The more important you are to the company, the more leverage you have in forcing the company to do something you want, because it hurts more for the company to lose such important people. What you are doing is making yourself less important - how will that help you make a case that you deserve to be paid more?

Even if you are feeling vindictive, the best way to take revenge, is to become really really important and quitting at the top. I hope you don't go down the path of revenge though - it doesn't serve you. You can get easily get paid more by leaving and not hurt other people in the process.

> How can I best work effectively with someone like this?

Lee and Jordan's answers are both great, if you wish to work this out. But honestly, do you need to? Can you leave this situation? Can you find a way to not have to work with this person?

> Is it worth escalating to my skip's manager?

It doesn't sound like that this E6 is willing to change their ways (this isn't the first time I've heard about this E6, it seems.). The relevant people to this person's performance review already know about this person's behavior. I have doubts your skip's boss would appreciate hearing about a squabble happening 3 levels below. The ball is now in your EM and your skip's court to decide what to do about it.

For you, ask yourself, **what is your goal in all of this**? What can you accomplish that is within your control?

Getting this E6 fired isn't within your control. Changing the E6's behavior isn't, either.

But how you respond to all of this is. Will you try to ameliorate the situation, knowing what you do may not have an impact? (It's true that if you did manage to build a solid relationship with this E6, it would be tremendously helpful to both you and them). Is there something technical you can learn or an interpersonal skill you wish to pick up amidst all of this?

\
[**"The Four Agreements: A Practical Guide to Personal Freedom"**](https://www.amazon.com/Four-Agreements-Practical-Personal-Freedom/dp/1878424319) is a great book. From what I can tell, it's all about setting personal boundaries and having integrity, and is a great read regardless.

If you want to read a book that help with this situation, read [Leadership and Self-Deception](https://www.goodreads.com/en/book/show/180463) instead. It was tremendously helpful to me in understanding my own role in sticky situations like this.

I think there might be a gap here in your understanding about **hard work**, though you are definitely not alone!

Hard work does require time and effort, especially the latter. But rarely are time and effort the differentiating factor between those who work hard and succeed, and those who work hard and don't.

The reason is that most people don't find it that hard to put in more effort and time. Especially earlier on in their careers, most of us have time and energy in droves.

Instead, the hardest work any of us gets to do get to do in our lifetime is **changing ourselves**. Changing oneself requires us to be **self-critical** (which can be painful), **self-aware** (which require restraint), and **courageous** (doing what makes us uncomfortable).

You said -

> I'm sure there are people who don't work-hard and get promoted, but these people must have something that gets them promoted such as great communication skills and the ability to sell themselves, so at least in that sense, they are unique and productive.

It sounds like to me that you believe people are uniquely born with communications skills and ability to sell. No, not usually, anyway. Good communicator build trust, and building trust requires one to be truthful. And being truthful is [harder than you think (at least it was for me)](https://www.linkedin.com/posts/kuanp_lessonsandgratitude-softwarengineer-careergrowth-activity-7027901502123872256-tVMJ?utm_source=share&utm_medium=member_desktop).

Even being productive is hard. It requires learning about ways to structure your day and improving your energy levels.

Acquiring these skills takes hard work, and knowing that you need these skills AND taking actions to actually acquire them is even harder.

Spending more of your time, instead, is easy. It's mentally easier to stay put and put in a lot of hours, than spending effort thinking and working on getting more efficient. Maybe your project isn't going well, but talking to your manager about it is scary and hard. So you just take the easy path and work more hours, when instead you could've escalated it and gotten the help you needed in much shorter time.

Simply putting in more time is ***lazy***. It's almost as lazy as thinking one could "chill" and grow in one's career (though definitely better...).

If you truly want to work **hard**, put your effort into things that makes you **uncomfortable** and forces you to **grow**.

(Check out Phillip's similar but more [eloquent answer here](https://www.jointaro.com/question/nJ762p255cGyuth36H6w/whats-the-core-insight-behind-quick-growth/))

Building off what Steve wrote (drive long term fixes), perhaps you don't have to solve this problem entirely on your own either, but take a directive role instead.

You can work with your manager with come up a list of consistently recurring issues. You manager should really want to solve this issue as well, because they can't afford to have single-point-of-failure in the team. You may ask questions to yourself and your manager to figure out what is the main contributor and address it systematically.

For example:

1. Deployments of new code frequently cause outages =&gt; Are they catchable by tests? if so, maybe help focus the team on adding tests to their code changes. Is it more that the systems underneath are not decomposed well enough and thus are dependent on internal workings of each other?
2. Lots of false alarms =&gt; Are you alerting on the correct metrics? How can you tune your monitoring solution
3. Oncall engineers don't know how triage issues =&gt; have everyone been sufficiently trained? Is there an oncall playbook? Can you have someone shadow you every time?

Once you have a list of potential deeper issues and possible solutions, prioritize them. You can then either work on the priority solutions yourself, or delegate to a fellow engineer (maybe one of the recently promoted folks?) and you can guide their work.

Great question!

I want to note though that most of what you've mentioned don't ***directly*** help you be a better engineer. These simply lay foundation for you to have a healthy life, with which you can pursue whatever you want. ***Don't do these things to be a better engineer; do them because they make you feel better.*** As every person's body and mind is going to be different, you should try things out see what sticks.

For me, these activities help me feel better:

1. I exercise 4x weekly (HIIT/Crossfit). This is by far the most foundational piece of my routine. I couldn't do this without investing some $$ into PT in the beginning, however.
2. Having a coach and/or a therapist. Emotional health is severely underrated, and we all have some level of trauma from our childhoods.
3. Eating well - I tended to eat more when I am stressed, so being mindful while eating have been a welcoming challenge.
4. Journal frequently - self-reflection and the resulting self-awareness is key to growth, and you need to grow to be a better person if you want to be a better engineer. See Philipp Su's [incredible answer for this](https://www.jointaro.com/question/nJ762p255cGyuth36H6w/whats-the-core-insight-behind-quick-growth/).

For me, I've tried these and they didn't stick, but they work for a lot of people.

1. GTD or Second Brain - unfortunately, the cost to upkeep the system(s) did not equal to what I was getting out of it.
2. Meditation - I did it for about 2 month straight, every day, but I didn't feel any more clarity or peace than when I started. It may not have been the right time and I'll try again later.

> How does the 'one diff, one thesis' workflow looks like?
>
> Should i make multiple PRs each one of around 250 lines?

Tactically, there's a lot of tools, and we had a similar post for [Github](https://www.jointaro.com/question/xiPsx4LT8aKUuG3GAbry/how-to-apply-one-diff-one-thesis-via-github/) some days back that might help you. And yes, generally each of your PR should be smaller than 250 lines (250 is considered on the large end).

Having said that, in my personal experience, **it's quite time-consuming to break apart large PR/Diff/CLs**.

The main reason most people end up in such a situation is because **they try to implement a working, end-to-end version of the feature before they send anything for review.**

While this is understandable - I remembered being scared to send in something I didn't know whether it worked, this is also is counter productive. Don't do this if you can. (If you did, treat this as "prototype code", and rewrite it in a new branch with the following approach.) Instead, it's best if you strategize your implementation such that you don't end up in this situation.

To do this, you need to break down the feature into distinct chunks, each with a "thesis", such as "implement this button". A thesis should have enough function to be verifiable via manual or automated tests. Alex has [an amazing, in-depth example on the Taro blog](https://www.jointaro.com/blog/every-junior-engineer-must-learn-this-software-project-decomposition/) on how do this, I recommend giving it a read.

Once you've properly decomposed your feature into distinct chunks, then figure out what's the one thing everything else depends on. Start with that chunk. Spend time cleaning up your code in that chunk. As soon as you think it's good, send out a PR for that chunk. These PRs should be naturally be fairly small because they aren't trying to do too much (PR for "Make an API call in Android" is probably 100-250 lines code, depending if you have test coverage). Keep working on the next chunks while this is in review. Submit and rebase. Rinse and repeat.

Having language difficulties is very tough; I've seen many people struggle with the reverse where there's a ton of English. Regarding this, I think it's important you find someone who is capable in both English and the other language(s) to help you. You needs mentors who are core to the organization especially in situations like this. See this discussion for making use of [mentorship](https://www.jointaro.com/question/hzFDQkYySUfzxeivVcHC/how-to-best-utilize-11-sessions-with-tech-lead/).

> I asked her to assign me an onboarding buddy

Well, you don't need anyone to assign you a mentor! You can just ask for people's time. If people don't want to help you, they will reject, and that's ok!

This [class](https://www.jointaro.com/lesson/n384HdJuDgulSHbHQLnf/masterclass-how-to-succeed-at-a-new-team-or-company-as-a-software-engineer/) on how to onboard basically covers all the main points of effective onboarding. It's important to note that being independent and asking questions goes [hand-in-hand.](https://www.jointaro.com/question/cLsgiARaD5kVmV1BvdUi/how-do-i-balance-being-more-independent-and-asking-questions/)

> But I feel guilty about asking people for help. I feel it doesn't do much for them. As with most, I don't have a team meeting where I could thank them & their/our manager would notice it.

While relationships you build do need to be 2-way street eventually, it might help to realize that people who help you (especially those take extensive time to mentor you) will get credit for it during performance season, especially if you make a point of [giving thanks to them via their manager](https://www.jointaro.com/lesson/noWZaoGWlrYQxX2Vhigd/effective-communication-guide-part-31-the-power-of-thanks/) (who might be the same as yours). There's really no need to worry about it - some people also intrinsically like talking to and helping people. Additionally, remember those who helped you and (1) help them back (2) pay it forward by helping others.

First, I think the steps you are already taking are great. Most collaborative individuals won't be peeved if you assign them tasks like this, since you are clearly trying to help everyone be more productive. 

That being said, one thing you could do is to make this not *your personal* initiative, but your team or your org's initiative. So if the person isn't happy with it, it's on them to bring up with the org publicly. Maybe...

"@person, **I'm helping our org identify and improve test flakiness as part of the test flakiness reduction initiative \[Link\].** I saw this one flake a few times and noticed you were the original author. Would you be able to take a look when you get a chance?"

\+1 to giving credit to others. Lifting others up is the best way to promote "credit where credit is due" culture fairly and others will eventually reciprocate for you without you even trying. 

Having said that, it sounds like you asking whether sharing your personal experiences outside of work, at work, can be perceived as "bragging". 

It depends, but IMO, I would think about

1. Is it the right time to talk about it? For example, I would generally say "official" meetings are not a good place to do so, since it distracts from the agenda of the meeting and typically don't contribute anything meaningful. It's great to do so at an off site or a team lunch or a "watercooler" conversation. 
2. Are you being able to have a conversation around these type of topics? Is other people also sharing their experiences when you are sharing yours? A good strategy is to ask and listen to other people talk about their experiences instead of talking about yourself to first, and hope they ask you about yours too. 

If you are not the type of person who's deeply passionate about making development processes faster, I don't recommend this role. However, you could interview anyway for practice, just like Michael said.

Every company is different, but I can say that software development in Engineering Productivity (EngProd) is generally very different from that of an engineer that works on part of the stack for an external facing product ("product engineer"). I was on such team for \~1 year, and it wasn't a good fit for me at the time.

For anyone else interested in knowing what it's like to be an Engprod engineer, keep reading.

EngProd's goal is to help is to improve the the development experience of product engineers and speed up the delivery of product features. As such, a big chunk of your job is to figure out what are some of the issues slowing down the teams you support. It's rare you will be handed well-defined projects, at least compared to produce engineers of similar levels, because EngProd teams don't generally have PMs.

Usually this involves digging very deep into test frameworks, release automation, etc, tools that help your fellow engineers be more productive. You then would need to dig deep and figure out whether these tools can address existing problems. And yes, you would also have to figure out what these existing problems are in the first place. You are basically the PM, the TL, and the Engineer for the project, all at once. This can be tedious (you might have to dig into the internals of build tool) but rewarding work (can save lots of engineers ton of time).

As such, I find being an EngProd engineer really hard for more junior engineers, since it takes a lot of (1) self-driven product exploration and solution specification (2) an inherent understanding of what makes a "good development" process vs not. (2) is especially tricky because unless you know how to be productive already (or at least what productive looks like), it's hard to figure out where the problem might be for your fellow engineers.

But the role could be good for more senior people who already know the productivity bottlenecks and wish to have organizational impact. This would be especially good for those who love building tools for fellow developers more than shipping their PM's next priority, for example.

First of all, congratulations on making the onsite round!!

I'm assuming you are going do your due diligence to prepare your answers. Do you best. However, know that the information battle isn't in your favor - no matter what you do, as a candidate, you aren't likely to know enough insights about the company to "impress" them.

Instead, I would take a different approach. Impress them with your curiosity. **Focus on preparing good questions, rather than good answers.**

When digging through the official/public information available, jot down anything you don't understand. Don't see how their go-to-market strategy will work? Ask the interviewer to explain the parts you don't understand. Maybe the company has "published values", but not clear information on how this manifests day-to-day. Ask specific questions about it. What do people talk about during lunch in the office?

Ask each of your interviewer why they joined the company. If their reasons resonate with yours, dig deeper and see if whether they found their initial goals fulfilled. If not, also dig a bit to see.

I feel the goal of these rounds is to show you are genuinely thinking about the future of the company as a whole, and a big part of that is asking the right question and having in-depth discussions. It's also an opportunity to figure out if it's the right fit for you.

Good luck!

While sprints and agile frameworks are commonly used in software industry, not every team needs it. Can you provide more detail on how you your team's productivity/execution/teamwork is impacted by the lack of one? What do your teammates think? If your team / company is small, full agile-based sprints might be more pain than it's worth. Knowing these details might help you convince your teammates or your manager if it's necessary.

> I want you to know that I'm concerned about communicating this request for proper planning with my manager.

Hmm, this is a bit strange. What concerns you? It seems like you are looking out for the team as a whole, and you don't come off like you are here to criticize your manager. If you mention this as a personal curiosity like "I've been wondering why we don't have sprints/agile process" or an suggestion you want input on "I have proposal that might help the team and wanted your opinion on it", any reasonable manager would be happy to talk about it.

Yeah, your TLDR is pretty spot on.

The general idea for One PR/CL/Diff, One Thesis is that it should be smallest chunk that can be understood, tested, and rolled back. IMO smaller code reviews are designed to (1) lessen the amount of things the reviewer have to think about for each review (2) allow reviewers to spend less time per review, so they can squeeze time to review more frequently, leading to faster convergence on agreed solution. It's the more "empathetic" option. 

Option 1 of having a single PR with multiple atomic commits fails both above goals (though probably better than having a giant PR with single or non-atomic commits). Rebasing can indeed be annoying, but lengthy code reviews are worse.

Touseef is spot on with his suggestions. I'll add a few I've seen work well.

**Video Conferencing**

1. Show your presence and your focus. Turn camera on as often as possible. Unmute and speak as often as possible. Send emoji reactions or participate in chat as much as possible.
2. Whenever an async discussion is getting tedious, start a video conference call with the other person if they are also available. For example, if a code review is going back and forth a lot, message the other person to talk directly if possible.

**Text Communication**

Leave paper trail whenever possible. Investigating a bug? Document steps you take and your thought process in the ticket/bug tool. Have an idea? Put it into a doc. Slack/chat messages tend to be ephemeral, so prefer putting your thoughts in more permanent forms if possible.

Keep a running documentation of your work. Once a week, collect your accomplishments and artifacts into a block in this doc. They come in handy during performance and promo, and helps assess whether you want to change how you work.

**Caveat**

If you are the only one in your team working remote, and the rest of the team (and perhaps even the rest of your company) is in-office 5 days a week, be aware this will generally work to your disadvantage. This is especially true if you don't already have strong personal connections to your coworkers and leadership. While it's possible to do this (I observed someone doing it well prior to pandemic...), it puts onus on your in-person teammates to surface as much of the off-line conversation online. In this is indeed the case, be aware you will have to put in a lot of extra effort to make the arrangement work.

There's actually one similar thing getting kicked off where I am, where it's being called "TL Cooperative." It's not so much a forum for people to talk about work issues, but rather a place for people to discuss and learn what the Tech Lead role is like, how it is different from a standard IC, and what skills are needed and so forth. This is particularly interesting since at Google you could be a IC senior engineer or a Tech Lead senior engineer (neither has management responsibilities), and they are different roles with different expectations. 

I think if the goal of your round table is for learning and helping each other get better, then it doesn't need to be heavy weight, since people only come if they want to learn. If it's more of a work/project alignment related meeting, then maybe reconsider whether it's necessary?

I concur with Rahul and with Michael in the long term.

I think in the short term (\~5 years), we will likely have more need for software engineers than today. A couple of reasons:

1. A huge amount of our economy is still very much manual and analog and would benefit from automation using software.
2. It takes software engineers to build AI systems. They can't engineer themselves. (OpenAI culture famously [value engineers and researchers equally](https://blog.gregbrockman.com/define-cto-openai)).
3. It's very costly to run LLMs, and no one's figured out how to make this profitable yet. So it's not yet scaleable be used by everyone. Specifically, pure AI-programming today is neither cheaper than nor as effective as employing human software engineers. It's much more likely that we'll use LLMs to make human engineers more 2-3 times effective, like Rahul said.

Long term is anyone's guess, but here's my "science fiction" perspective...

Engineering of all kind, including software, means designing and building complex and automated systems using the tools available. LLM technologies like ChatGpt, and Bard will become just another set of tools in the wheelhouse. Chatbots based on LLMs may be able to generate code, but they can't engineer systems. That being said, using these tools effectively will be require a different way of thinking than traditional software tools and languages, such as "prompt engineering".

In the end, we humans still have to collaboratively design systems around these tools to solve our goals, so I wouldn't too surprised if 10 years down the road, here on Taro we are talking about "prompt reviews" or "prompt quality." I also don't think this timeline is a given, since internet took 10+ years until the 2000s to really take off.

I think as software engineers, we are always looking for new tools to use (for example, very few people use C nowadays...), so adding AI-based tooling to your toolset is very, very wise, but as with all new shiny tools and frameworks, do so wisely (advice from [this video](https://www.jointaro.com/lesson/P7OwweZWcyvb3Gz3bNOE/how-to-properly-learn-to-code-as-a-software-engineer-do-the-simple-thing-first/) applies here.)

First, I can tell this is a very stressful situation! Let me try to address a few of the context you've provided to see if they help you feel better.

> My manager has promised to find me a new task, but the problem is that I don't have any experience with the tasks he has suggested"
>
> "I am afraid that if I admit to not knowing how to do these tasks, I will appear incompetent in front of the company managers we are contractors of, and risk being laid off.

In general, it sounds like there's a misalignment between (1) what the team needs (2) and what you are able to contribute to the team.

My first thought is that there's no point for you to pretend to know. If you do, you'll likely just do a poor job, and be in greater risk of being laid off anyway. Maybe you don't need to say this at your standup, but you have to let someone know, at least your manager. 

My second thought is that your manager does not know what you are able to do, and you need to let them know. It seems your manager thinks you are technical program manager instead of a data engineer.

You need to correct this sooner rather than later. Start a conversation with your manager to create an alignment between what the team needs and what you can do.

For this conversation, make sure you brainstorm all the things you know you can do, with examples from your previous jobs if possible. Since your manager doesn't seem to understand what a data engineer does, explain to them if you can.

At the same time, observe and brainstorm the list of things your team is struggling with that you might be able to help with as a data engineer. Propose things that you can do for your team that you can see.

Hopefully your manager will understand better and give you things that's actually in your wheelhouse!

I was an SDE2(L5) at Amazon, and SWE2(L4) at Google, and I know of SDE2s at MSFT.

This is an interesting question, and I get the sense that what you are looking for is what kind of effort it takes to be "meeting expectations" to "exceeds" at mid level but not try so hard to get promoted. Note most FAANG expect promotions to senior, with Google being an exception, "try to not get promoted" isn't helpful long term.

In short, I don't believe overtime is frequent and isn't expected, but can happen from time to time. I'll split my answer into "what I've seen" and "what I recommend".

Sorry about the essay in advance 😅.

### Workloads

- The majority of engineers I've known don't work overtime, at least not consistently. I didn't and most of my colleagues rarely did either.
  - When myself or people I know did put in overtime work, it was generally due to (1) oncall / off-hour outages / executive escalations (I got a [Jeff Bezos "?" Email](https://www.quora.com/Whats-it-like-to-receive-a-question-mark-e-mail-from-Jeff-Bezos-at-Amazon-Inc) once.)(2) aggressive deadlines for projects, which would happen once in a while (a weekend every couple of months or so?)
  - Aside from oncall, I've only worked overtime for projects because I wanted to get them done by the certain date. No one's ever asked me to work overtime.
- If you are not oncall, you don't need work emails, slack, or any other communication on your personal device.
- Majority, up to 75%, of your time is tasks related to coding (reading code, debugging code, writing code, reviewing code) when not oncall. This can fluctuate, depending on the stage of the your project (you'll usually get 1 project at a time)... typically around the beginning and the end a project you spend a lot of time coordinating your project and talking to people. Then you'll have some chunk of your time (5-10%) taken up by team activities.
- When oncall, it generally takes 120% of your normal time, and you need to plan your personal life around it. Pages in the middle of the night happen. There's generally no time for project work when you are oncall either, but you usually can skip team related meetings if you got urgent stuff going on.
- You can generally work whatever work hour you prefer, but you won't have much control over the timing of your team meetings, and these tend to run 10am-3pm.

### Strategies to not overwork

Fundamentally, as an mid level SWE, you need to be (1) independent, and (2) effective, to get good performance ratings. You can do this without overworking most of the time.

- Independence
  - Know your people (Who knows what and who's helpful? Who is the gate keeper?)
  - Know your processes (How do launches work? Some processes are very LONG and you need to know to start them early.)
  - Know your system (How do you debug your system? Can you explain to others how things work?)
  - Fundamentally, if you are able to unblock yourself using these above knowledge for your projects, you'll be good.
- Effectiveness
  - Good time management matters. No one cares whether you work overtime, or when you do your work, but you need to get your work done. You need to know when you are most productive and manage your focus, see [this video for more tips](https://www.jointaro.com/lesson/uGdn2AiDfn3B07FkpIVR/a-powerful-tool-for-software-engineer-productivity-focus-blocks/).
    - Are you a morning person? Come into office early before anyone is there and crank out your work before your daily standup. You can "chill" rest of the day and head home early. I did this a lot.
    - Are you a night owl? Show up to work right before your first meeting and crank out your work in late afternoon or do it in evenings instead.
    - Additionally, establish clear boundaries between work and personal life. Turn off slack/calendar/email notifications whenever you are not oncall. Even better, don't have them on your personal devices at all (I don't!).
  - Good code quality and high code velocity matters.
    - If you are able to crank out good code, quickly and efficiently, and get them through review quickly, you'll rarely ever have to work overtime. This [amazing Taro video](https://www.jointaro.com/lesson/muNsq91JownUzDm7AxLX/what-software-engineers-dont-get-about-clean-code/) goes into more detail about myths around code velocity and code quality. This is by far one of the most important skills to have as an L4.
      - Most engineers that do work overtime do so because they struggle at code velocity (and in return code quality). It's a vicious cycle. Avoid it at all cost.
  - Being good at incident management matters.
    - Knowing how to handle pages is super important. If a page goes off in the middle of the night, you need to be able to quickly determine whether it's a real issue so you can go back to sleep. This requires a pretty good understanding of your team's metrics and how to read them. This shouldn't be hard to pick up (find someone to shadow) but might require 2-3 times oncall to get used to it.
    - You also need to know when to escalate - if you don't know what to do or you can't make the decision, escalate it to your management chain. Or if you need knowledge of a peer to address the outage, pull them in as needed.
      - I once had a partner team page me to try to get me do some work off-hour to unblock their release, which wasn't part of our team's protocol, so after some back and forth I just paged my managers and let them handle the discussion

Apart from focusing on behaviors, choose your team wisely - you can generally get good answers to these questions from talking to team members (beware, managers can give rosy answers).

- How healthy is the team's oncall systems? Do you have to be oncall at all? (Some teams don't have oncall at all!)
- Does the team historically been pretty good at estimating projects? Do managers and leads in the team proactively shield the team from external pressures?

Avoid some of these following L5/senior level work.

- Mentoring your peers. Keep relationships professional and help when you can, but you don't need to actively look for mentees. Limit regular 1:1 to those with your manager and your tech lead and formally meet your other teammates on an ad-hoc basis whenever needs arise.
- Multi-person projects when possible. These require more coordination. Prefer big multi quarter projects you can do mostly on your own.
- Getting interns and being the main person onboarding new teammates. Though be generally helpful when they do have questions.
- Being the main code reviewer your team. Prefer being an occasional / backup reviewer. Or being a primary reviewer for a sub system.

Please note that **these are all fairly natural progressions and are extremely rewarding**, so I don't generally recommend avoiding all of this. You need at least one of these to reach exceeds anyway. However, this is a possible way to reduce time commitments at the cost of career progression.

First, what does your heart say? How do you feel about this?

I personally would follow a manager I trust and rely on (it seems your manager is). They are extremely hard to come by. I would say if the manager has asked you about this, then they really are thinking highly of you. You've clearly got the chops to handle the work, and feeling "bored" about your current work isn't a good sign for your growth.

I would do some research about the target team though. Can you talk to the ICs on it? It might give you some peace of mind if you are risk-averse. Ultimately, it might not matter - for me having a trusting, supportive manager with whom I already have a great relationship with will trump everything else.

I have a couple of thoughts here, though they are based on my own time in Amazon as SDE1/2.

Generally, I would NOT worry getting the chance to work on new technologies or new tools. Instead, I would index on areas/packages that **(1) critical to my team's success (2) yet to be owned by another engineer**.

In Amazon (and other big tech too), the key to be a successful SDE1 on promotion track to SDE2 is **ownership** and **independence**.

That means, being the go-to person of a **high-impact** area that no one else wants to touch (maybe due to its tooling or technology) is extremely helpful for your own performance and career growth to SDE2, as that typically gives you the room to exemplify ownership and independence.

When I was SDE1, I was tasked to onboard onto a Javascript Library as replacement for the departing SDE2 who owned it. This thing was gnarly. It was written in vanilla ES3 javascript (this was in 2017 and ES3 was released in 1999), with no concept of classes, and most frustratingly of all, it was deployed to production by... manually issuing an update request to the server hosting it.

It was a huge source of pain for myself and caused sev2s frequently, and almost nobody wanted to touch it because it was vanilla javascript.

But I took it on and became the go-to person for it. It was really painful the first few months, and then I got comfortable with its internal logic and these helped me address some of the sev2s. Then I realized a huge problem was the manual, human-driven deployment process so I managed to fit the existing process into an automated release pipeline that reduced deployment outages to nil. Eventually a colleague and I migrated the thing to ES5 and even added unit tests! It was really easy to prove my impact during performance season because I became an expert of a critical system in my team.

The point here is that it's more important for you to find important areas to own rather than looking for the newest tech or tooling. Once you've spent enough time with it, find ways to solve the painpoints you are facing - after all, you will have become an expert, and your work will go a long way to helping others in your team.

Internal transfers are great! I've explored this process at both Google and Amazon and know of people who've done it at Microsoft. 

Internal transfers are typically much better than external transfers for the following reasons:

1. You get to leverage your existing knowledge of internal technology, tooling, and culture. At places like Google where there's a ton of internal tech and tools this is especially true. 
2. You can interview your target team much more rigorously, outside just the hiring manager. This gives you valuable perspective. (People are also much more willing to talk since you are a fellow Googler/Amazonian/etc and they won't fear saying something they shouldn't). 
3. You can stalk their team's projects, cls, etc, and can request things like previous google geist results to see whether the team is healthy or not. 
4. If you like the company benefits, you get to keep them. 

Having said that, regarding your specific case, here's my thoughts and tips in no particular order:

1. To find teams hiring, go to Grow, the internal tool. With the recent layoff, headcount is likely extremely limited. Don't assume a Grow posting equates to an open headcount. Ask the hiring manager for every opportunity you are interested in. 
2. It's better to have been in your current team for at least 1 year and not on Pip to do internal transfer. Seem like you've hit that. This allows you to transfer without your manager's permission (otherwise your manager has to click a button allowing you to leave). 
3. Generally hiring manager will not reach out to your current manager. You can discuss this with your prospective hiring manager to make sure they don't. 
4. You won't have to do coding interviews for internal transfers. Yay!
5. There are Googler coaches for internal transfers. Just search on Moma. 

And this is just from what I heard personally when I was looking during the 2020 headcount crunch: 

1. During headcount crunch, often hiring managers don't have an open head count but will ask for it when they have a good candidate. The higher your level, they more likely they are to do so. 
2. Just like you can "stalk" the team you like, the reverse is true. The hiring manager will want to see your perf history, cl history, project history, etc. If you have a list of your artifacts (like ones you might have for perf), prep into a nice doc and send it along. 

Best of luck!

I sense you are feeling very frustrated about this situation, especially since it seems like it's happening again. I empathize - this isn't easy to deal with, so kudos to you for posting this question and asking for help here. Your manager certainly won't be stalking these pages :D

My initial gut feeling is that you are doing well, and that your manager is indeed off the mark. Any project spanning multiple quarters is considered a L4 level project at Google, so if your last project took that long by design or difficulty, that demonstrates "exceeds expectations". 

That being said, it's important to figure out first what is your "accurate" rating and then to align with your manager about it if possible. 

Since your manager isn't really able to explain your company's performance system to you (this happens more often than we all would like, unfortunately), you need others to do that. 

Skip managers are generally great resources for this. Just don't mention to them that your manager hasn't done a good job with yours,  tell them that you just want to understand it better for your own career growth. They should be able to help you chart what it looks like to go to L3 to L4, and maybe L4 to even L5. 

Similarly, go to your fellow peers (especially more senior people) with similar questions and figure out what being "meets expectations" at L3, "exceeds" at L3 look like, and what "meetings expectations" at L4 look like, in your company based on their experience. Asking them career-related question is very, very normal and should never be looked down upon, it's a great thing. Of course, don't tell your manager about it if you don't feel comfortable. 

Once you have a more objective evaluation of these ratings look like, take a hard look at what you are doing, pretend to be your own manager and see which criteria you think you've satisfied. If you are not sure, keep going back to those other folks for more specifics. Again, just for your own curiosity, if you wish to not share your frustration with your manager. Did you do enough for L3 Exceeds? L4 Meets?

You can then put all your findings into a doc. You goal is first to find consensus with your manager about the criteria of evaluation. If you are able to do that, you can together discuss to how evaluate your past (and future) projects along these axis. 

If your manager still refuses to have a conversation about it then... it might be time to go. Having a manager that doesn't want to teach you the system when you've done so much homework seem very problematic. But at least by now you would've gotten a much better sense of how well you've performed. 

Best of luck!

Just from what I've heard from friends and coworkers (I've only worked in the US), among what you haven't mentioned. 

Tech friendly, in no particular order

1. Singapore
2. Tel Aviv / Israel
3. London / UK
4. Zurich / Switzerland
5. Vancouver+Toronto / Canada
6. CA, PNW, Texas, NYC / USA

Immigration wise I know USA and Canada have clear paths to Permanent Residency for tech workers. This sounds like the type of question that chat gpt could answer pretty well.

Agree with Alex, if you can find someone who is able to dedicate their time to be your mentor, that's awesome. 

That being said, I wouldn't underestimate relationships with peers or leads who are not officially your mentor (see this [Taro post](https://www.jointaro.com/question/8Q6snKStnebzvJvJtAxN/how-important-is-it-for-you-to-be-connected-within-your-org-to-move-up-as-an-ic/) for more context). 

Alex actually has a great talk about finding scope with an example from his time at Instagram: <https://www.jointaro.com/lesson/WYk4J05iBqOuPtD0CYKX/session-1-solving-a-multi-million-dollardollar-instagram-bug/>

I can't tell if you are looking for promotion into senior or staff, so I'll link this very recent question about [staff level promo here](https://www.jointaro.com/question/WfwnrBnTSTuZdLI2f1XL/how-to-work-on-a-promotion-plan-in-a-mid-year-review). [Rachel's discussion](https://www.jointaro.com/lesson/FzvHLUprcYonudsxnJc2/whats-the-difference-between-a-senior-and-staff-engineer/) on staff engineers literally discusses how at Staff, you have to find your own projects.

In general though, I think this is fantastic question because figuring out what problems exists and how to solve them are inherently important to your growth as an engineer. While there are top-level directives that results in big projects with huge impacts, often projects start with smallish estimates and become bigger projects and bigger impact, because the engineers on them are looking out for the correct risks and ways to leave things better than when they started.

There's a couple ways I've personally seen people of all levels find projects, and one key insight is that often people weren't aware these projects.

1. Pain points during development: the software we work on is never perfect, so as you execute, you are bound to find specific patterns that slow you down. Are there some much needed refactor, or re-achitecturing that needs to be done? Is there some tooling or patterns that you've seen and learned elsewhere that would help with the pain points you yourself have encountered? Start there - if you are feeling the pain, you (and your peers) may be more internally motivated to solve it.
2. Pain points for users: similarly, the products our software power are far from perfect. Are there some critical user scenarios or some obvious missing pieces that doesn't take long, but everyone has been moving so fast that this has never been prioritized? Is there a pattern within user feedback that the org isn't focused on? Figure out why - and maybe some of these require small amount effort but have decent sized returns. These high-leverage items are great things to focus on.
3. Pain points for organizations. Is your organization struggling to deliver because the lack of, or sometimes too much of, process? Do people in your team or organization trust each other? See if you can do anything here - potentially these things don't even involve any coding, but are extremely rewarding projects to go after.
4. Look consistent patterns of negligence. Have there been recently outages, complaints, lost deals or revenue to the company or product, due to internal or external factors? Are there things your senior people are putting off because there's other, more important things? Take a deeper look at those issues and maybe there's something you can do to help while your senior people are (maybe correctly distracted).

Lastly, you want to prioritize these projects by leverage - the impact the project would have divided by the amount of effort it takes. Impact doesn't have be material or necessarily measurable (it could be trust earned with important members of organization, more trust in the product or people in the org, etc), but it's good for you to have an expectation for what would the impact be if you invested your time and energy.

Another idea may be to have more individual 1:1 discussions with these individual engineers. Larger meetings with lots of strong voices tend to lead to chaos, and is costly for everyone involved. 

Focus these 1:1 meetings on (1) building trust between you and the individual, and (2) figuring out what is negotiable about their position and what is not. Do this for every strong opinionated stakeholder. 

Then figure out if there's a compromise in the middle. Pitch this to each person as your idea, priming them with "It's important we find a common solution" or something of the sort to remind them that you are all here to figure out a path forward, and refine it. Then finally bring people together at a bigger meeting to have this proposal approved. 

Alex covered in plenty of detail how to ask questions and that is by far the best way to learn things quickly, because it typically leverages other people's knowledge! Do this when possible.

That being said, I'm interpreting your question and followups as you being interested in how to better understand and learn about complex technical concepts (sometimes on your own). For this, I want to share some personal tips that might be able to help you.

### What does it mean to understand something?

Before we dive into how to better understand things, let's define what it means to understand things, and what it is not.

I believe that **understanding something means being able to describe it relates to everything else**. In other words, it's about understand the **relationships** between a concept and nearby, relevant concepts. This[ question/answer on Quora](https://qr.ae/prISjH) does pretty good job giving an example of what I mean.

Understanding is NOT having the memory of a fact ("Knowledge"), especially if you can't make use this fact to make any predictions. **You should never have to memorize anything you have understood.**

Understanding is NOT blind intuition either - how you feel about something could be totally wrong, especially when you have yet to study it in depth.

### How do you then gain understanding of something?

So if you struggling to understand complex technical system(s), I suspect you might specifically be struggling with **connecting what you are learning about with what you already know.**

I see this happen all the time when folks are assigned tasks about systems they are unfamiliar with. They sometimes jump straight into the code or detailed design documents of the target systems, gets overwhelmed by the irrelevant details, and end up feeling really bad about themselves.

Instead, I recommend doing exercise by listing (1) what you already know about the target system, (2) and how it is relevant to something you already know. Maybe the target system is downstream dependency that a service your know well call can via a certain API. Maybe the target system is very similar to something you've seen before, from another job or school. Start exploring from there.

People do this all the time. Sentences like "Lacrosse is like soccer, but with sticks," or "Typescript is like Java, but with functions as first class objects" help people position a system in relation to another system they already know. So as people learn about typescript, or Lacrosse, they will keep comparing/relating it to what they know and learn by applying from concepts from one to another.

Another way to visualize the process of learning as a graph search problem.

You are at node A, and you need to find the shortest path to node C.

Jumping straight into the target system's code or docs is like sampling random nodes surrounding C, and trying to figure out if it's part of your shortest path. Bad idea - you will probably waste a ton of time computing paths that doesn't lead you anywhere. At best, you will end up with isolated islands of facts about the target system that doesn't help you predict how it will behave since you are unlikely to understand the principles with which it was built with.

Instead, start with where you are - at node A, and examine every node related to it that gets you closer to node C. You may still dig into details of the systems along the way a little bit, but only pay attention things that gets you closer to your goal. Ignore everything else. (I think this basically A\* search, which is fairly good algorithm for solving this type of problem.)

I hope this helps. Best of luck!!

Would it be accurate to say that a huge part of de-risking is building alignment between different stakeholders in a project, especially early on?

What are some common risks engineers tend to ignore but tend to blow up on our faces later?

Google

Senior Software Engineer [L5]

It's definitely not disrespectful, in fact those folks may appreciate having someone outside of the company to vent about the layoff to. It's also important for you to get a sense of what the post-layoff culture looks like. At some companies there's very little change, others an 180 flip (e.g. Twitter 🐥), so as an prospect you would want to see if the culture is still a good fit for you. 

I can imagine this is very stressful situation for you especially amid the current tech climate. First, know that your situation is not uncommon and there's no shortage of contentious work (you may empathize with the [Taro post here](https://www.jointaro.com/question/laa5DS4dlZDLDcPFjJmz/how-to-manage-politics-from-more-senior-engineering-folks/\)), so learning how to deal with them is helpful regardless of the outcome of this one. 

### Find reliable help

The first priority here is definitely figuring out a way to accomplish your work. Since this SWE 2 is clearly of no help to you personally, find other peers that can help you. You said there was tech lead. Schedule something with them, so you can more accurately assess how difficult your task is. Do you have other SWE2 or SWE1 peers that you can rubber-duck with? I've added some color on [this post](https://www.jointaro.com/question/8Q6snKStnebzvJvJtAxN/how-important-is-it-for-you-to-be-connected-within-your-org-to-move-up-as-an-ic/) as to the type of people you need to have on your side during your career - can you find these people and can they help you get these tasks over the line? Does your team really need to blocked on you? Can someone else with more context do your task instead and you can contribute in other ways?

### Triangulate the truth

It's important you understand the situation from multiple perspectives, because what you are seeing might just one side of the story. Make sure you are able to collect enough "evidence" to support a particular story that rings true to not only you but everyone else who are involved. Acting on your own version of the story may alienate your peers, especially if you are incorrectly perceiving the situation.

Is the SWE2 actually correct in their estimates? Are they planning their projects properly (why is the most "blocking" issue being addressed by you and not them?) Are you the only one who thinks they lack technical depth (what does that mean, specifically?) Do they regularly throw teammates under the bus? How are you actually performing, in the eyes of your other colleagues? 

Talk with your tech lead and the senior engieers who helped already to understand both what they think of the SWE2's behaviors, and what they think about your role in all of this. Talk to your SWE1 peers to see how they perceive what the SWE2 is saying. Tell them that you want to improve both the situation for the benefit of the team and are just confused by what's going on. 

### Address this particular contentious relationship

Lastly, it's important to address this situation, either directly with the SWE2 or with your EM. To do this properly you are going to need (1) put yourself in the shoes of both the SWE2 and others involved (2) a truthful story about what happened. Whether or not you talk to the SWE2 directly, it's important that you share your concern about SWE2 and your project with your manager. Your EM may not believe you right away, so you need to careful about presenting your story as so not appear you are distorting the truth in your own favor, but if you've already triangulated your thoughts prior and they are still accurate, you should be able to back it up and convince your manager. 

Of course, feedback is best offered directly to the person, though only if they are receptive. Ultimately, the behavior you are describing will hurt the SWE2's career trajectory in the future as throwing teammates under the bus will not help them influence anyone. If they are in fact receptive to receiving feedback from you (which might be... unlikely given what you said), it would be good to do so. 