Interesting idea; more interesting if it was a robotic agent.

Could be viable, for specific occasions. After all, in Japan, you could hire someone to eat lunch with you or go on a date and forget it afterwards. Very niche but still some $$?

I think the fact that this thing is with you all the time isn’t actually good. You don’t want a friend to be watching everything you do in real life. We make time to do stuff together with our friends. So I feel like it should be a limited usage thing if it’s going after that angle?

A b2b angle: offer restaurants a tool that could talk to single-diners and talk to them about their day. Could be interesting for places like ichiran. The engagement is only for as long as they are there at the restaurant. 

Senior SWE, Manager at Google

Kuan Peng

Wins: spending a month in New York has been extremely refreshing mentally and emotionally.


Losses: haven’t been active on taro lately! Curious how I can be most helpful with limited time

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 :)

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).