Tech Lead

My technical lead is excellent but not the best communicator, and by that I mean I don't understand what they are saying 50% of the time. I intend this in the most respectful way when I say that I don't understand the punctuation behind their comments and chats. I ask them about X and before I've even finished they shoot out with a response on Y. I don't think they have ever been able to explain anything clearly to me. It's getting to the point where my manager sees me as incompetent (I think) even though it's clearly a lack on their part.

I'm an L3 and they are a critical L5 so the team will never stand up for me but given this economy, I'm starting to get a bit concerned about my career. The difference between their language and others on adjacent teams is like night and day and I'm not sure how to bring this up with my manager without sounding prejudiced.

What should I do to help myself and navigate this situation?

I've never worked in big tech or Tier 1 companies but I'm aiming to grow as a engineer and would like to know and learn how different companies make such decisions?

1. Does it vary for startups and FAANG+ companies?
2. How do you answer such a question if asked during an interview?
3. How much autonomy each senior engineer (L5 or L6) has in such decisions?

Could you please share an example case study here? What does the entire process look like? Thank you.

I’m an E5 on a platform team at a Big Tech company. I'm under aggressive timelines to create a proof-of-concept (POC) for a partner team. My skip-level emphasized the importance of this POC as well as its timeliness to me.

Our team's E6 is coding our platform infrastructure and is slipping his dates. The E6 said his infra code should be production ready in 2 weeks, but claimed there should be enough there to unblock my POC. I tried to forge ahead, but my POC is now delayed because I spent so much time trying to work around the deficiencies in our platform infrastructure. I eventually decided to prioritize some other parts of the POC to avoid losing more time while the E6 is taking his time with the infra work. How much of this should I communicate to our partner team's stakeholder? I'm hoping that I'll be able to hunker down to get the project back on track without slipping our dates. Another E5 on our team told me that he doesn't like to air our team's dirty laundry outside our team, so he usually says everything is fine until the last week of the project when he suddenly flags delays. Is this a good strategy? Or should I be honest and upfront with cross-functional partners external to my team?

I have been wanting improve my technical understanding on what I am working on:

• Since there's so much happening in the backend, frontend and database levels, it can get intimidating to try and see how it all makes sense, when it all feels chaotic trying to put everything together.
• I feel that the one thing that could help me progress to the senior level is to better my technical influence, and I was wondering how I can improve on that.
• I have been proactively speaking with senior engineers and the architect involved with the new feature that's being worked on. That has really helped me better my understanding on what I'm working on. But when it comes to the code, it can be challenging since there are so many files that depend on one another, and I feel that I would need to spend a couple hours a day just understanding how each of those code files work.

What other steps can I take to enhance my technical influence, and then reach that senior level?

Working hard and staying on top of my sprints, I lead a team that focuses on developing tools for customer support to onboard our new features.

Though this work is consistently given priority in team meetings, it is often sidelined or perceived as less critical compared to other product-facing features.

Despite my efforts, I feel I am not acknowledged or seen as impactful and intelligent. I suspect biases at play but cannot substantiate them concretely.

How can I change this perception and ensure that my contributions are recognized and valued within the team?

How can I turn around the situation to be perceived as important and impactful, aligning my hard work with the recognition it deserves?

I am an L5 TL, of a team of less than 10 people. My manager very recently asked me whether I am interested in becoming an EM (managing most if not all of the people on my team).

I like coding and technical contributions, but I believe I like helping people succeed more, including having crucial conversations where things aren't going well. Those things don't come naturally to me, BUT I get great satisfaction out of those tricky situations. I would also like the opportunity to build a team of amazing individuals who come together around a central goal. Based on this I am leaning yes.

However, I know the EM path isn't all roses. What are the top 3 questions I ought to consider, before I decide whether I want to do this?

Hi all, I am going to transfer to Tiktok as a lead MLE next month.

I have 2 months notice period and I was wondering if anyone has any checklists on what I should do during transition so that I can start fresh and ramp up quickly.

I come from FAANG background and going to a startup-ish culture is an exciting but scary prospect for me (especially with the reduced work life balance).

Tips and checklists of links to Taro videos or other resources are welcome. Thank you

I recently became CTO of a small early-stage startup where I'm leading all technical efforts, including by still doing some coding, but am mostly managing other engineers and focusing on the broader technical needs of the company. Previously, I was a technical lead and IC at startups where I had led small teams of other software engineers on product development, but was more in the weeds technically/coding a lot and was not responsible for people management. I'd like to learn about resources I can utilize to further develop my engineering leadership and people management skills.

What resources would you recommend to learn more about the following:

• How to build people management skills as a first time engineering people manager? Are there open source or free trainings or resources that are good for this?
• The latest engineering leadership topics, especially in a startup environment (e.g. how other leaders are tackling common technical and leadership challenges)
• How to meet or connect with other engineering managers/leaders (e.g. startup CTOs, VP of engineering, or technical founders) outside my company to learn from their experiences or share lessons or knowledge with each other

Interested in any types of resources including blogs, podcasts, YouTube channels, or virtual or in-person communities or meetups (particularly in NYC) etc. I have some favorite resources so far, but it would be great to learn about what resources others in the Taro community find useful. Thanks!

What’s the best way to handle a situation as a tech lead when you are under pressure to deliver your tasks and ensure that the other team members are also on track? If one developer slacks and doesn’t meet the deadline, is it automatically the lead's fault, especially if the situation was raised well in advance. If the person continues to under deliver with poorly written code, is it okay to spend time and pair program and get work done just to meet deadlines? Keep in mind that the developer is a junior engineer and requires fair bit of hand holding.

I had to approve a PR, although I was not 100% confident, it wasn’t a breaking code and it wouldn’t have caused any backward compatible issues. I received extremely harsh feedback for approving a sub standard from a peer/colleague. Had I not completed the PR, my manager would have provided feedback on the delayed project, what’s the best way to navigate between two leads or managers who are not aligned and expect different outcomes from the same situation?

Please help.

I just joined a brand new team, formed 6 weeks ago. This job is a big step up in responsibility for me, and it's asking me to operate in a manner that I'm unfamiliar with, such as building OKRs and roadmaps for my team - these OKRs and roadmaps will then be used by our cross functional partners. I feel an immense sense of responsibility that I'm not sure I can uphold my end of the bargain, since I feel like I simply there's so much unknown around product requirements and technical constraints. I don't know if I just power through it by working more to discover some of these constraints (which is what I'm mostly trying to do right now).

For the record, my manager says I'm doing great having recently joined the team. However, I constantly feel like I'm behind because I think I should be giving everyone the feeling I've got things under control, but I don't think I'm giving that impression (because that's not true...). How do I deal with this feeling? I feel like I will be feeling this way for some time since I think I have a lot to learn...

Hi! I'm an L5 in a big tech company, tasked with leading a big org-level project that span multiple engineering teams, with lots of cross functional collaboration w/ UX and PM as well.

I'm new to my own team and I'm not the subject matter expert in the area of our work, which is around 8-ish people with about 2 other L5s. In order for me to successfully manage this project for our team, I am already involved in a lot of meetings and I have yet to set up recurring 1:1s. I believe I should set up some more of these 1:1s, but I can't imagine I would be setting one up w/ everyone I come across.

Which 1-on-1s / relationship should I prioritize, how frequently should they happen, and how do I ensure these meetings are good use of both my time and the other person's time?

I work in as an iOS engineer. My current company is a startup that's scaling up fast. In classic startup fashion, testing was historically not a top priority here. As a consequence, we struggle with lots of manual QAing and low code confidence when modifying pieces of poorly tested legacy code.

This has improved in the past year simply by unit testing every new piece of code by default and by introducing unit tests in legacy code as we touch it, boy scouting style.

At this point, I think we need to step it up and I'm looking forward to formalising a testing strategy for our mobile team.

Here are some ideas I have:

• In the realm of unit tests:
  • I want to introduce API contract tests because our back-end API lacks documentation. In these tests we'd unit test the way we build our requests to API endpoints, and we'd have a sample JSON response from the server to test that the app can parse it into our data models as expected.
  • I want to introduce localisation tests because our app supports many languages but we are always manually testing localisation. In these tests, we'd assert that the outputs of our formatting logic are the ones we want for different locales.
• In the realm of user interface tests:
  • I want to introduce snapshot testing, because right now the only way we can test that our views are rendered as expected for different view configurations (for example RTL vs LTR, empty content, loading content, content in verbose languages, etc.) is manually.
  • I want to introduce UI tests (sparingly, only for key flows) because we have no e2e tests. Currently, key flows are tested manually and frequently to prevent regressions, which takes lots of time.

What other testing strategies can I propose to establish some standard we can use to further improve our code confidence, reduce bugs, and rely more on automated testing?

How do the top tier tech companies approach mobile testing?

Some engineers like to code, some like to manage projects, some like to stay close to the users. Software Engineers come in all shapes and sizes.

What are the major archetypes of Software Engineers and how can one identify one's own archetype to double down and improve.

Context:

(1) My team owns a service for which we're rolling out a new version with a big revamp of all the public interfaces and a ton of breaking changes.

(2) This is a legacy system that is being refactored to resolve some severe issues that its consumer systems have been complaining about for a long time.

(3) This service has many consumers in our org across multiple teams that depend on it for a lot of critical functionality.

(4) We need to migrate all consumers to the new service. My team cannot parallely support both the versions and the legacy system has to be deprecated before the new service deployment.

Challenges:

(1) Originally, the plan was for my team to roll out the new service and migrate all of the consumers to the new service as well.

(2) Now, we've had a huge scope expansion in the refactoring itself due to which the project timeline has extended massively.

(3) My team feels that working on such a long timeline project is risky and prone to further scope expansion if new consumers start using the old legacy system in the meanwhile.

(4) Another challenge with this is that my team has no context or understanding of all the consumer systems.

Questions:

(1) What approach can I use to now change the plan and convince the managers/tech leads of the consumer teams to own the migration of their consumers code to the new service?

(2) In general, what approach would be ideal for such a large-scale migration - Centralized migration by the service provider team vs distributed migration by all the respective consumer teams?

I've seen advices here in Taro that seniors should make themselves very much replaceable so that when this senior is away, someone is able to cover for them and the team could do well, which makes sense.

I thought the fact that people found the advice to be helpful, shows that making yourself replaceable isn't something that's very intuitive the first time. Like if someone didn't read the advice, they probably wouldn't have optimized for that.

I'm not quite senior yet but just curious to understand the situation (and people) better - was this thinking assumes that the amount of scope is in hyper-growth phase? Are there cases where it isn't really applicable / optimal for them to do so (and so they don't make themselves replaceable, and still do well) - then wouldn't they just continue doing it and we can't really blame them? I feel it's rare that people would change their behavior unless they really understand why.

I recently completed a project where I was the sole IC on the project. The project mainly involved migrating logic from a legacy service but involved integrating with a service managed by another team. I was responsible for the design of solution, estimating a timeline and delivery of the project (writing the code and testing).

Unfortunately, I ran into errors last minute and had to communicate delays a day before the expected completion date. We also ran into a tricky error post launch but I failed to communicate an expected deadline after the cause of the bug was identified. My manager and I have spoken on potential strategies and the need to communicate expected completion time.

My question here: What can I do a better in the future? When driving a project, how are you structuring your work so errors are surfaced as early as possible? How are you communicating risks and concerns that come up during a project?

What should I think about and focus my efforts on when I get a project and a role that's of (1) bigger scope and (2) tighter deadlines than I'm used to?

Context

A reorg has suddenly thrust me into the TL role for a very high-profile project on a new team. This project is part of OKRs 4 levels up the chain and has the eyes of several director level people across different functions. From what I've heard, this project already suffered from "too many cooks in the kitchen" syndrome, and on top of that, this project has delivery date set in Q3, which is quite aggressive from our org's standards.

I've landed in this position because I was transitioning to this team prior to the reorg, AND the EM/TL/PM/2 L5s has been reorg'ed out, and they needed someone who had previously TL experience and was willing to do it.

I've previously TL'ed a team of 4 people, with important but "normal" priority projects. This is clearly a great opportunity for me, but I am afraid I'm not ready to handle it and I'm at a bit of loss as to what I should be focusing most of my effort on. With the tight deadlines I have, I feel like every day will be a battle so any advice on how to approach this will be appreciated.

I have one other L5 supporting me who I trust very much and a new EM who's rumored to be very good. We currently have 4 SWE including me and we'll be getting more at least 4 more engineers, with lots of adjacent teams helping out. I do also have good standing and connection in the org overall and I know how to get a "normal" project in our org over the line (I did an in-org transfer).

What I'm thinking about right now

1. Knowledge Transition: since a lot of critical members of the team are leaving and I am taking over, I feel the biggest priority in the near term is to absorb as much knowledge from them as possible. So far, they have some prototypes, and I wanted to get my hands dirty, so maybe I should focus on is to understand the work that's been done really well, and the design choices that's been made already?
2. Gather support: I feel like biggest personal risk is that I don't know how to show up in higher-stake meetings with directors. Is it any different? Where do you all see the risk is?
3. Enable the team: I know the biggest responsibility I have, more than anything, is to make sure the team is able to work on the project and help us deliver this. Aside from the L5, I don't know a lot about the people. I feel I should putting my focus on ensuring they are as successful as possible, not focusing on my own technical knowledge as much, for us to succeed. Is that a good way to think about it?
4. Self-management: I anticipate I'll be very stressed and pulled in many directions. I already feel this way. What are some tools I can leverage in "crunch time"?

A teammate of mine has sometimes delayed tasks and informed about them at the last minute leading to us missing the delivery deadlines. As the tech lead, I've shared this feedback along with explaining the impact and suggestions to tackle the issue. I've encountered this situation a few times even after sharing this feedback.

What other steps can I take to help the teammate and minimise the overall impact on our delivery?

Context:

• I'm working on a project that is known and understood to be at risk by most tech and other XFN stakeholders. This project has been attempted a few times in the past but didn't succeed and is being retried.
• There are a few upcoming features having tech dependencies on the delivery of this project but I feel that the stakeholders aren't confident about the success of the project.
• The project might need some support in the form of reviews, brainstorming and stewardship from the stakeholders to succeed.
• As the tech lead, I want to create and maintain stakeholders' confidence in the project so that they're enthusiastic to provide us the support we need.

Questions:

1. What can I do to understand current expectations of the stakeholders better?
2. What communication (or other) steps can I take to create and maintain stakeholders' confidence in the success of the project?
3. Apart from generating confidence, is there anything else that I could be doing to ensure stakeholders' support?

Context:-

1. My team is going to work on a new project which involves upgrading a service and migrating/enabling all of the dependents to use the new service.
2. This service provides a business critical functionality for our teams and the new version attempts to solve a lot of high impact pain points with the previous version.
3. We have just inherited this service and none of us have worked with it or any of its dependents before. We have some support from the previous team that worked on this project but only in a consultation capacity.
4. This is a project that has been attempted multiple times by various teams over the years - unsuccessfully or with little progress. My perception is that it's going to be a difficult project with low-moderate chances of success.
5. There is a lot documentation but most of it is somewhat outdated. There are a lot of PRs as well but these are for the unsuccessful attempts so I'm not sure how impactful it would be to go through them.
6. The plans for the previous attempts only had internal milestones for the team and a single big-bang completion milestone for stakeholders.

Questions:-

1. How can I identify smaller, independent high-level milestones that are relevant for external stakeholders?
2. How can I come up with broad estimates and capacity requirements for the external and internal milestones if I'm not clear on what these milestones would require for completion?
3. How can I think about de-risking this attempt of the project and improving the probability of success?

What is the role of Staff Engineer at a early stage startup where infrastructure is on an average setup? In terms mobile application it is standard app with migration scope to react native but there are no takers for migration at all (only product release need)

Here how can staff engineer play a role and how to deliver product and engineering goals with awareness to large eng teams?

My team took over a system that we didn't write about a year ago, and it is the only system my team owns. It is a highly critical service in my org.

I was happily making changes to it all of last year, but I broke production twice in a few months, and then almost a third time, and now I have lost faith in my coding ability.

The benefits are that it prevented other teams from experiencing these issues and I took full ownership of resolving them, however, the outages seem to be something that is hanging over my EM's head in spite of it.

How do you get out of this rut?

I work as a mid-level software engineer. We have team channels where people can reach us on. But for some reason people always message me in a private message or they visit my office for team related tasks or product owner tasks. I keep telling them to ask the person in charge or communicate through our team channel, but they don't.

I don't want to be rude to them, yet I find my frustration growing. Sometimes I feel like they can't bother to formalise their requests, so they go to me to quickly mention whatever is bothering them, so they later can refer to our "discussion" if the issue is brought up again.

What should I do?

I would like to understand how can I drive an effective Tech discovery session (just had a PRD walkthrough) with the team (remotely working) before we start writing a detailed system design document. The engineers are mostly L4 and are still learning how to effectively collaborate instead of full blown meeting.

I'm a tech lead on a long-running project that has gathered momentum over the last couple of months after being in a slow death phase for a many months. Recently, a couple of senior engineers joined the team and we've gotten rid of a lot of things that were slowing down the project. We've managed to hit many awesome milestones on time as a consequence.

The project is nearing it's endgame phase but we've unfortunately hit a snag in this last leg due to which it seems that we'll be missing the last couple of deadlines by a decent margin. Due to the expectations that we've set by consistently delivering on time for all the previous milestones, our manager has suggested "pushing" to meet the last couple of deadlines.

I don't want to ask my team to work overtime or on the weekend to meet these deadlines (especially since we've been doing a great job of turning the project around and delivering on time). How can I push back against it in a manner that does not impact my currently ongoing or future performance reviews?

Say you want to research on a topic for resolving an issue and want to share with the team by creating a Google Doc. How does one master the skill of creating an high quality Doc?

My Senior team member, top performer, is super solid at creating Google Docs and churns out one great doc almost every week. He said he just focuses on just dumping out the thoughts in the first go and fixes them later on. But I feel his velocity in getting that doc out or completely the research on it is very fast. So clearly there is something that I am not understanding.

So I am looking for opinions from experts on Taro :)

Due to unforeseen circumstances from past 6 - 8 months, I've been the Senior most engineer in my team, (I have a total of just ~2.7 YOE). My team consists of ~12 SDE 1s (New Hires) and 2 SDE2s (The other SDE2 being promoted very recently). My manager does a great job filling the role of Senior Engineer which reduces bit of pressure off of me.

However, due to necessity in the team I've ended up being SME in all the services owned by our team. This leads to everyone reaching out to me to help them with their queries, I try to document some of these and add in the Wikis so that it can be easily accessible for others next time. However, when it comes to certain tickets and issues, I end up having to pick that task up myself (Manager does not ask me to, but at same time i know that for someone else the ramp up time required to fix the issue would be too high).

I recently tried to reduce this (2~ months ago), this led to our overall ticket health getting worse and I had to again start looking into them myself and guiding each on-call cycle with right action items for the tickets etc.

This involves me helping them to do the following :-

• Prioritize correct tickets to look into for the on-call cycle.
• A potential fix for the ticket so that they know where to look into.

Due to which it ends up taking 6+ hours weekly to keep this running. I don't really mind doing this; however, I don't feel like this is a scalable solution and would eventually want to slowly scale down from doing this and have my team being able to be self-sufficient.

What's the best way to go about this without affecting my team's ticket health?

We currently have a problem with test flakes happening very often.

Someone is currently working on a systemic fix, but in the meantime, I've taken it upon myself to be the leader in categorizing and assigning people to take on some of the existing flakes as they happen. I am assigning based on who has the most context or who wrote the original test.

My question is: How can I assign these in a way that doesn't cause people to dislike me? I ask as someone who needs to delegate in my role but also needs to get buy-in for various initiatives so its important that people like me.

A couple of things I've tried:

• Trying to be as helpful as possible, showing that as I'm assigning these I've done a little bit of investigation myself to try to fix it (even without much context) or give any info I can gather
• Asking in a polite way (maybe)? Here's a couple examples:
  • "@person, 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?"
  • "@person it looks like we attempted to fix this here (link to github commit) but it seems to still be flaking. If it's ok, I'm gonna assign this one to you."

Any better wording of the "ask" or advice around this situation would be appreciated!

Hello,

I am working as an Entry level engineer at mid size product based company. In my end year performance review, I got a feedback that I can work on improving my debugging and technical skills more. As well as, knowledge of other features and overall product as a whole would need to be increased as well.

My Tech lead has offered to mentor me by conducting 1:1 sessions to help me improve at debugging and help identify patterns and teach basic principles. 2 other senior engineers on the team also reached out and offered to conduct sessions regularly with me, for which I am really grateful.

For more context, all my teammates work remotely, so it is not beneficial to go to office. My question is, how can I best utilize these sessions with the senior engineers on team to improve more and skill up? That is, what kind of preparation/ questions should I have ready to make the most of these sessions?

We use JIRA for writing up tasks, which the respective engineers always make, but there is no sprint. So, we need more sprint retrospection.
All communications are done very vaguely via a Slack message, sometimes a word with little but no context or a screenshot.
I want you to know that I'm concerned about communicating this request for proper planning with my manager.

Hello everyone,

As a senior engineer L5 in my company for 1 year, I recently found myself in a new team with a new direct manager but report to the same Director in the same Org due to the recent company restructure/company reorganization as part of layoff changes. My Director and I are the direct responsible individuals for the Backend Platform System for the last 1 year. However, I am finding that a significant portion of my time is being taken up by "glue work," such as onboarding new teammates, updating the Wiki, documenting On-call Runbook, mentoring cross-functional team members, providing code reviews for new developers, and unblocking people in their code development. While these tasks seem important, they are making it difficult for me to focus on my own projects.

In my first one-on-one, my new manager expressed a desire for me to take on new initiatives. I am eager to do so, but I need to be able to focus on my own work to make this possible. My manager understood that the frequent on-call support was a blocker for me and asked me to train and onboard a new teammate to take over the on-call support, as well as field requests from users and help others with their work. However, I have still found myself doing a lot of training and providing support even two weeks since my last meeting.

I would like to hear from others who have found a way to balance these responsibilities effectively. How can I prioritize my own work while still contributing to the team's success? I know this will be a difficult decision, and I'm not sure how to approach it. I'm worried that if I stop doing some of these tasks, it may impact my relationship with my manager and team.

If anyone has faced a similar challenge, I would appreciate hearing about how you approached it. Did you stop doing certain tasks and responsibilities, and if so, how did it affect your relationship with your team? Any advice would be greatly appreciated.

Thank you.

I'm an E5 at a Big Tech company. My EM's pushing me to lead projects on our team so I can work on getting to E6. This is challenging when the E6 on my team tries to micromanage everything. How do I lead when I keep getting overruled? The E6 usually makes good decisions, but oftentimes struggles to articulate his rationale / justification.

hi all,

I am a tech lead for my team of 5 engineers. I am also a senior eng intending to climb up to staff level.

My manager is not very vocal or supportive and seems reluctant in terms of helping out a plan for myself. I have been working hard though. How can I work with my manager to create a promotion plan for myself and get buy-in from them?

I am not sure if I should move up the eng ladder or transition to management, but are there any guidelines for creating a written promotion plan and manage up so to speak?

I am mentoring juniors for the last few weeks. In the past, I've been mentoring people with some professional experience but this colleague doesn't have any. Now, after these few weeks I am wondering:

1. How much time should I spend helping them? Currently, I have to spend 2-3 hours for person per day otherwise they will be blocked for days. Even though I am trying to explain that they can ask other colleagues as well, they are not asking anyone else.
2. How can I be sure what are they suppose to know and what's not? For me, I have my own understanding of what they should know but I know for others may differ. In my country the juniors must be part of an academy before applying for a job. I know what they learn there, so I know what hthey should know and what not. Now, after these few weeks I realize they have gaps which they shouln't have. On the other hand, the academy is typically more than an year and it makes sense many things to be forgetten with the time.
3. How can I measure properly their performance since they are just starting? What is a normal performance?
4. How deep should I go in explanation of his questions? I believe this is where the high quality questions will help them, but I believe they have a lot of gaps to make a quality question and give the proper context.
5. How can I help them to improve their questions instead of having to explain for hours one topic and then another, etc?
6. When should I say I give up on him? I really want to try everything before giving up.
7. How to stay less emotional when explaining the same things for hours to the same person?
8. How can I help them to understand me better? Sometimes, no matter how am I explaining specific case/topic and no matter what examples, nothing helps.

I think the colleagues are really motivated and this is one of the reasons I want to help them. I want to be sure I did everything I can.

I joined my current company a bit more than a year ago as an L4. Within 4 months, I'd launched a high stakes project, and after some churn in the team leadership, I was put into the role of being a tech lead to my remaining team of L3s.

As a pseudo TL, I did well in the mentorship and technical guidance responsibilities, but my code output dropped drastically (due to my projects being in the design phase which were being done by my juniors with me providing high level guidance).

In the last three months, I suffered some mental health issues. My work productivity dropped significantly during that time. I've been very open with my manager about my mental state throughout this process, and they've been very supportive of the things I need to do to recover. Around this time my team also hired an L5, who is now officially the TL.

Due to my drop in performance in the latter half of the year, I'm afraid my manager won't trust me with important projects. I wonder if I need to again prove my credentials to keep me on track for L5. I feel very low about my software development abilities.

This has made me demotivated and disinterested in my work. I took a couple weeks off, yet I don't feel like going back to work. I'm not considering changing teams due to immigration issues. I also don't want to leave a team on a low.

Any tips on turning around my motivation, and trajectory on the team? What can I change in my mindset and working style to overcome my struggles?

For context, I work in a tech lead role where I am often making recommendation to my manager regarding the projects coming down the line. The EM has the final say on this, but they respect my opinion on this matter so I don't want to mess this up.

I also have 1:1s with my teammates whom I am responsible for about their career growth goals. My teammates are all the same eng level, but have different levels of competence and desire to learn.

Additionally, I also know it's important for me to leave some room/ambiguity in project investigation stages to allow folks the space to grow, while it's also important for me to take on some challenging work and help our team deliver more quickly. I guess my question is really 2 parts:

1. How do I choose what to delegate?
2. How do I choose who to delegate the work to?

Over the past year, we've focused on developing our product quickly, which has led to a significant amount of technical debt in our codebase. As a result, we've shipped applications without proper architecture and planning. However, when I suggest refactoring or re-architecting to my team, many of the senior developers and the engineering manager are skeptical. In my opinion, I am not just offering refactoring for just sake of refactoring; it's necessary because our current code base lacks abstraction and separation of concerns and has slow development times.

Examples:

• Adding a new column to the database takes 1-2 days
• Or changing some code breaks another part of the application(lack of separation of concerns and abstraction)
• Another example, recently I introduced integration tests to our team because we manually tested a lot of stuff on staging before deployment, in that case, my EM's argument was integration tests are very slow to run on every build.

In those examples, how can I reduce skepticism in my team and bring more productivity, and more good code quality, and best practices to my team?

As a Senior software engineer working at a mid-size tech company, I’m still learning how to properly push back when others Sr SWE & managers or Directors from Web or Mobile team tried to get me to do tasks that do not match my own priority.  As much as I like to be nice and support others, I agree that I can only do so much.  I brought this up with my direct manager and my Director (L7 Senior Manager & L8 Director), and they told me to loop them in when I face overwhelming pressures from other engineers/ cross-functional teams. My direct manager also told me they wants me to be able to focus on big project initiative, and they see that I am on track to be the Tech Lead given my current trending.

While I do appreciate that my boss gives me words of assurance and direction and offered to step in to fend off those pressures during my one-on-one call, I recognize that I would have to be the person who is good on establish priorities and be able to push back on people. I cannot really rely on my boss to do the push-back to fend off the pressure given that with the recent layoff, we are short on staff.

Wanted to get some thoughts and suggestions on "How can I push back diplomatically against an overwhelming amount of tasks"?

How does it differ from an entry level engineer to the head of engineering level at each of the levels, given the scope grows as well at each level?

• Software Engineer
• Senior Software Engineer
• Tech Lead
• Staff Software Engineer
• Principal Engineer
• Head of Engineering
• Director of Engineering
• Vice President
• CTO

How do each of the levels ensure they are onboarded as quickly as possible to have maximum impact ?

My manager suggested that I work on the skills below to advance my career. Do you have any masterclasses or other resources to develop these skills? I added links to the resources that I know about.

* Stakeholder management
* Project management
* Design & architecture -
* Communication -
* Leadership -

Even though starting to work for a big company like Meta, Amazon, Google, etc. I believe is a hard to achieve (I haven't work for) somehow it looks pretty straightforward. Learn for interview, get the job, level up. Yes, I am sure it's hard and not many will do it but still you know what should be done (yes, may don't know how). But let me tell you a different story:

I work in a not that famous country in the EU and non of the top tech companies is there. Actually 90+% of the companies are outsourcing companies. As a SE with 10 years of experience in the outsourcing world I can tell you how it works: you work on a legacy code which is so old and so bad (hundreds of people have tried write code there) you can't see good practice at all, no code reviews (sometimes there is bad it is very rare), no unit tests, performance review is only about client's feedback and so on, you got the point. It's about the money only and nobody cares if you are good or not if the client is happy. In very rare cases I have started something from scratch but all of my colleagues were so bad progmmers like myself that we messed up all. It's a deadlock. After 10 years I realized I am a bad programmer and I've seen so many bad practices that I have no passion to do anything anymore. Now to the questions:

1. Is it possible to apply best standards in an outsourcing company like those in FAANG and if yes, how?
2. How can I fill all the gaps I have at the moment? Can I fill all the gaps with side projects only? How can I fill them when nobody will teach me anything new. Nowone will review my code and like @Alex said, they are the main source to learn :) How would I know is the code good or not? Could it be better?

The ultimate goal of my career (and maybe in life) is to fill the gap not only in my skills but to create a company (product based or outsourcing) where everyone who join to have a chance to become a great programmer. But before helping others, I need to help myslelf. This is how I found Taro.

This quarter, my skip requested/ gave me an opportunity to lead an org wide efficiency initiative as we are at risk of hitting quotas for some internal services (he mentioned potential IC6 scope) and it’s quite urgent to act on it. My role is to start and lead a large team of engineers on this initiative which involves tons of direction to ensure our org isn’t over quota. I would look my role as a hybrid of TL+ TPM with following responsibilities: analyzing data to find opportunities, creating roadmaps for the program, supporting engineers for execution to reduce usage, project management, understanding and enforcing processes, building knowledge on internal services, coaching engineers, setting Eng excellence culture within the org. All that to say, given limited time and a need for someone to lead, I will be focusing on direction and delegate all of the execution work to the squad.

1. How risky is it to have low code output as an IC5? Given the year is just starting, does it make sense to explicitly discuss this with my manager and skip that my code output will be close to zero in Q1?

I did read some accounts (anon post on WP) where EM and skip aligning on low code out out but the IC5 still got MM at the end because they had only 10 diffs for a half. I don’t want to be in that position.

1. Should I deprioritize some direction work and allocate some time for coding on my timeline through P2 projects? This will increase diff count but that just seems not a great usage of my time. TIA!

Recently my company has split up a core team into two teams. One team is to keep on building the core infrastructure for the product and the other team is supposed to be working in an advisory position with other web applications teams that depend on the core infrastructure. Without dwelling into more details, this core team builds, and maintains datastores, that other web applications consume. A big part of the job is to build google search type infra (on a much smaller scale of course) and data processing pipelines.

Now working with other teams is exciting. But just focusing on one task that is doing tickets/changes/investigations that help them implement some specific features w.r.t to core infra, is kinda troubling me. As it puts me in a passive position and does not clearly define metrics for success. It also puts me on the borderline as I am neither doing core infrastructure-related work nor I am completely part of the other team. The idea is to imitate how Staff engineers work across teams. But I am a Senior engineer (just recently promoted).

Though this is clearly a growth opportunity for me, I am a bit worried about falling behind and not meeting expectations. Any advice on working with cross-functional teams?

What I've learned over the years is that the most important thing to do when I realize a project is late is to:

1. Come up with a revised estimate of the task
2. Notify all relevant parties with #1 (E.M., PM, x-function partners, etc.)
3. Tell the people #2 "I messed up, here's what I will do in planning next time to avoid this planning mishap next time". This step especially builds a lot of trust

What other tips do you have?

Hey folks,

I don't know how to contribute to our team's monthly planning. How should I come up with ideas for things that the team should work on and contribute to our team's road-mapping meaningfully?

Currently, we have tech debt mainly discoverable via a custom annotation in the code.

Some examples are:

• Break complex features into separate manageable flows
• Split large classes or controllers
• Feature/part refactoring tickets with linked ticket numbers.

The core tech debt is easy to address and manageable via project boards, but the problem is the rest (product related) often gets out of date and never gets resolved, for which there are some reasons like:

• The product team has been disbanded.
• Feature no longer a priority for the product.
• The part of the code has not been touched for some time but could come into active development again.
• Find better implementation of X

I believe the product-related tech debt should be owned and tracked by the product team but often there are some tech debts left in favor of speed like - breaking complex screens, and classes, and find better approaches etc etc

What's the best way to promote ownership and address such tech debt, so that they are addressed during code reviews and not left in the code as comments indefinitely, nor as a ticket in some project board which never addressed?

An E6 and I recently joined an existing team and are working with an E6 who has all the historical context on the project's requirements/limitations in his head. The PM is brand new to the team and the company. The EM and designer are also fairly new. The newer E6 often proposes architectural directions that the more tenured E6 shoots down due to this context. Is there a good way to extract all this context from the more tenured E6? I feel like we're often throwing things on the wall and just seeing what doesn't get shot down -- things get shot down more often than not, unfortunately. The more tenured E6 said it'll take too long to document all the context.

I’m given a particular problem that has been estimated during a sprint planning meeting by the team.

Halfway through the sprint I find that there is a lot more to the task than the team had initially predicted/estimated and I raise this concern in the stand up

If the “extra work” is out of the scope of the initial task, a new task can be added to the backlog otherwise we generally maintain the estimate and let the team velocity adjust accordingly

Curious as to how other teams handle these situations ?

Apologies in advance for a long question. Not sure how to ask this question without providing deeper context.

I’ve been working with my current manager for the last 1.5 years. While they have recently helped me get promoted to Senior, it’s been a constant struggle. I dread our 1:1 almost every single week because it always run overtime and we are often still not on the same page. 

I see two major issues that haven’t notably improved in the times I’ve reported to them.

(1) My manager isn’t able to coach me, or any of the SWEs on the team. My manager doesn’t seem confident when we have career discussions - I recently asked them what they thought was the difference between good TL and a great one, and they struggled to coherently answer this. Instead, they said they would know better after the next performance calibration.  Additionally, none of my teammate has gotten proper coaching either.  For example, a teammate struggled to submit code due to their poor code quality and thus had low CL velocity, so my Manager simply told them to submit more CLs, which only made them more stressed without a legitimate way to improve. 

(2) My manager lacks technical understanding of our projects and constantly pushes for speed. My manager was externally hired, and to this day, they don’t really understand the complexity of the work our team does. I understand EMs don’t need to contribute code directly, but my manager almost always underestimate how complicated the projects our team takes on are. As engineers, we frequently have to defend our timelines, which is not only frustrating but also pressures some teammates to favor suboptimal design or hastily done CLs that just causes even more churn. 

The weird part is, my manager often seem unaware of their own actions, and when I talk to them about these issues, they are always receptive to feedback and seem willing to improve. However, I simply haven’t seen enough improvement in the last 1.5 years. 

I could leave, since this is having an impact on my emotional well-being. But I do have good standing w/ my own team and the overall org, and I want to use this situation to learn as much as I could. I know that I myself have a lot to learn as a tech lead (Thanks for , it’s really helpful), and I know I can probably get a bit ahead of our projects and start estimating/de-risking earlier, so my Manager doesn’t get overly aggressive with timelines. I know I can also take this chance to more closely mentor my teammates and help them succeed, since they aren’t really getting it from our manager. 

I want to stay, but is it the wrong decision because I have little career support from my manager? If I do stay, what should I focus on so I can really help my team and at the same time learn something valuable for my career?

I worked on a large org-level, cross-functional project led by a TPM and an EM. Since there were so many engineers on this massive project, we were organized into smaller pods/subteams with pod leads. The TPM had standups 2x/week, and my pod had standups the other days of the week. My pod was loaned out to help a stakeholder team from another org. The TPM only attended his own standups and sometimes missed some. The EM attended most but not all my pod's standups as well as most but not all the TPM's standups. My pod lead attended most but not all of those same standups as well. The POC from the stakeholder team was not invited to any of these standups. Since the TPM's standups had so many engineers, we only gave high-level updates in that meeting.

In such a situation, how do you keep all the stakeholders (TPM, EM, pod lead, stakeholder team's POC) aligned and up-to-date with any challenges such as scope creep, bugs, delays, etc.? There was a slack channel for the overall cross-functional project and a separate one for my pod, but none for working with the stakeholder team's POC (all such communication was via DMs). When the stakeholder team's POC dropped the ball on things, how do you escalate in such an ambiguous situation? The TPM sent weekly "Weather Reports", but those emails were very high-level.

At my startup I was asked to deliver feature after feature + bug fixes by PMs as fast as possible without much time for proper refactoring work or engineering initiatives. Also it was pretty individualistic where you get assigned a task and only work with other engineers during a tech spec review meeting, code review, and syncing with a backend engineer (as an Android dev).

From Alex’s video on getting promoted to tech lead, I saw how you can 1) drive projects as an L5 engineer (vs a PM putting that together with designers) 2) Not have to know how to implement everything yourself for a project, but work with many others and facilitate the team. This sounds 100x more engineering driven and collaborative than at my start up with few developers. Is this common to many people’s experience of the norm in FAANG?

What I liked about Alex's story is also how he had the time and space to do things like document the differences between iOS and Android, as well as go all the way through to making a data analytics plan for monitoring it himself. Seems like a lot of freedom and ownership which I didn't feel I always had the time for personally. Being able to not have to spend 80% of your time coding but rather doing deep work thinking, planing, designing holistically sounds extremely satisfying and rewarding as an engineer. Maybe this also comes with experience at startups as well?

Hi all

I recently joined an organization as a senior where I was made tech lead within 3 months of joining. This was somewhat related to recognition of my work among product and my peers.

I advocated for good engineering practices such as automated integration testing and established projects for cross org collaborations to help deliver whats important for the organization.

All of this was quickly realized as a super critical projects by the organization. I created tech specs and prototypes for these projects.

However recently the organization hired a principal engineer.

since he was new I volunteered to help him onboard and asked for his advice on the new super business critical project that was next in our todo team pipeline. He is an ambitious guy so he wants to create his mark in the organization.

But for some reason the way he is approaching it doesn't seem right to me.

He plans to create a new team taking over the business critical project while splitting the newly formed team I lead on the same project that I helped him ramp up on.

I opposed to this asking for rationale for a new team.

there seem to be now two impressions of my work:-

1. held by my peers, folks I lead and product manager of good business delivery and product timelines. I am respected among both.

2. the principal Engineer tries to devalue my work in front of senior engg. Leadership saying things like I am overcommitting and under delivering if I do this project with the existing members of my team in public and in front of senior engg leadership.

The automated integration testing project which no one was doing before and we were starting from a basic version to iterate on. This is now communicated to engg management as every team is trying to do their own testing.

My engg management for some reason is siding with him since he has 15-20 years of experience and i have 5. He also is principal and i am 2-3 levels below him.

for some reason I am being micromanaged with no fault of mine.

From engg management perspective I have been just told to lead the project that I am currently leading and just help the team formed by principal engg to start the project.

I have communicated my expectations of being able to continue leading the project. Product is in support of that but engg managment isnt.

I have also tried giving feedback to the principal engineer that his actions are disruptive to the team and becauase of what he is doing he is slowing us down and blocking us from doing critical projects.

My worry is despite doing the hard work the project I have the most context on and I worked on for a while is being given to someone else and second i will not be given credit for the hard work I am doing.

Should I just change teams. I dont want to leave my existing team because I do think they need me but I feel I would rather create more impact where I dont have to swim against the tide. I may also be suffering from sunken cost fallacy here where I knew I led the development of a new critical project

Tia for your help.

When I've been helpful in the past, word quickly spread and a bunch of random engineers started pinging me for help, sometimes aggressively. Sometimes people would delegate grunt work like asking me to test their PRs that do library upgrades instead of testing them themselves. Or asking me to debug their dev environments because they heard I fixed another engineer's dev environment. Sometimes it'll just be asking for expedited code reviews even though I have no domain knowledge on their PRs. We work on the same platform, but are not on the same team or often even the same org. There are only so many hours in the day and I need to get my own work done as well. How do you decide who to help and under what circumstances? Advice on how to push back without damaging the relationship? As far as I can tell, it looks like anyone from E4 through E7 are the ones making these requests.

I'm an E5 iOS engineer at a Big Tech company. I'm struggling to understand what leadership means. A Director told me Leadership means making sure the project is successful no matter what happens. As a result, I often end up doing other people's jobs for them (e.g., when a backend engineer struggles to get their piece working, I often hand-held them and have even created backend PRs to unblock some projects even though I'm an iOS engineer). However, a mentor told me that E6's don't do the work themselves but delegate it to others to scale themselves. If this is true, then what does an E6 do when working with engineers who are either unwilling or unable to complete their deliverables in the expected timeframe and quality? This becomes even more challenging when working cross-functionally with engineers who are not on my team. Also, how do you lead when you're not the DRI (Directly Responsible Individual) / tech lead for a project (e.g., when the tech lead is an E6 on another team, but is not setting up the team for success by refusing to communicate requirements clearly)?

I have realised over the years that I have gained good amount of technical knowledge but I lack great communication skills (in terms of expressing my thoughts). This was okay till I was working as software engineer as my task involved more of coding work which does not require explaining things to large audience. Now as a Senior Engineer my task revolves around making design choices, explaining pros/cons of selecting an approach etc. I realised that even though I am confident on my technical approach, I sometimes fail to express myself and the approach in the right way during the discussion which led to times when my approach is discarded and others as selected as they express themselves better. I need some suggestions on how to improve on this aspect as this will be crucial part going forward in my career.

How to best answer this question in quarterly discussion with manager? Things are looking good on personal level. On team level also project plannings are seems to be aligned with team goal. How can I add value to this question?

I watched the video I am particularly interested in the point: "Great TLs sequence their project in such a way that all the highest risk things get knocked out first". Can you please give examples of doing that in a real life? What are some examples of activities that you found higher risk than others and therefore you decided to do them first to minimize the risk?

I'm working on a cross-functional project with a backend DRI (E3) and Android engineer (E4?). I'm iOS, but have a backend background so I could easily code the backend portion if I needed to. The DRI reports to a different EM, who was on vacation for the first few weeks of the project. The DRI was struggling to get the backend piece working, so I spent extra time hand-holding him on how to debug it. I even researched how another feature in the iOS codebase used similar API calls and created a Postman collection for him to troubleshoot his APIs more easily. Is this a good use of my time? What percent of my time should I spend on helping others versus doing my own work? The Android engineer did not help the DRI because he doesn't know backend, so there was no one else to help the DRI.

I recently started at my new gig as a remote tech lead. While I am on the West Coast, most of my team is either on the East Coast or in Europe (+11 hrs). Meetings start at around 7 AM PT and go on until 11:30 AM PT!

Here is my challenge: I am a morning person & like to do more deep & undistracted work during the morning hours (Coding / Reading / Writing) . Screen time in the mornings usually drain me out & my productivity dips post multiple zoom / G-meet calls. What are your thoughts on how could I balance my sacred morning hour time between meetings & impactful work?

Thanks!

The setup on my team is pretty standard: There's an E6 tech lead that has broken up a big project into multiple pieces, and I own one of those pieces (and the rest of the pieces are owned by other E5s). I'm leading a couple engineers (<5), and I think they're E3/E4.

Zooming out, this seems like decent E5 scope, but I'm sure there's some gaps to turn it into E6 scope. The tricky part is that my org is pretty XFN heavy, so it's hard to get things added to the roadmap, and with the hiring freeze, it's hard to get more engineers onto my team to lead.

All that being said, what are some ways I can find staff scope in this situation?

I've grown to be more of a "tech lead"-style E5, which leads to a lot of time spent roadmapping and talking to people instead of actually executing on the project and being more hands-on. My team is heavier on the E3/E4 side, so I'm able to delegate a lot of the coding work away. I was wondering if this was normal for Meta and whether this is an okay way to operate as an E5?

I'm a new staff engineer at Meta, and I know that the bar is high for E6. In particular, an E6 needs to be able to have a large influence on the roadmap and team charter, leading and creating very substantial projects.

All that being said, I want to start crafting and executing that vision as soon as I can to hit the ground running, but I'm unsure on exactly how to do that with Meta's more bottoms-up culture. At my previous job, things were more top-down (i.e. leading with authority, where software engineers work on things because their manager/leadership tells them to). How do I lead the team with this almost opposite engineering culture?

So, a new situation has come up at work. My lead let me know today that he/she is going on a parental leave around October last week. I did ask them to let me know if I need to step up and need to prepare anything before they leave.

Question is How do I handle this situation and work with my directors to get prepared for it. I don't feel prepared to replace them for the next 3 -4 months nor I think I'm expected to do that but the question here is how can I proactively reach out, prepare and help the team in this situation.

1. What are the things you can suggest to reduce the turnaround time for onboarding a new engineer within the team?
2. What are the things that can enable them better?
3. How does this differ based on the stage of their career at which the new hire is in?

In fast-paced organisations that launch a lot of features on a quarterly basis and teams with large sizes, how should a tech lead or team members ensure that everyone knows about everything or is enabled to get to know about it?

Quite often, whenever a new feature comes in, it could be repurposing technology built for other features as well. But, given the pace at which these are developed, it is often hard to know what everyone is working on. Sometimes, each of these features may have idiosyncracies that may be getting missed out by new joiners, especially due to the volume of information, especially for teams that have been in existence since a long time.

I recall once when changes for a new feature done by a developer reverted some conditionals for an older feature, thus causing an outage. How do you prevent this and ensure knowledge of everything is available to all, especially to people new to an organisation?

Also, are there some general practices to ensure that these are easily discoverable? Video recordings are time consuming to go through, and wikis though they exist, are sometimes difficult to navigate, when you don't know what you are searching for? I am thinking of something like a mind map could help here, but what are your thoughts?

I am trying to get promoted to Lead Software Engineer, which relates to an E5 level at Meta, if I am not wrong. I have seen several engineers in my organisation coast at the current level I am.

I wanted to understand if there are some key things I should be doing in order to perform at a Tech Lead level, so that I am promoted to one as well. This would be a bit long question, but please bear with me.

Following are some of the things highlighted in a few discussions:

1. Should have demonstrated complex backend system designs - How do I create this opportunity to build a complex system for myself? Often, the projects we are a part of don't require complex solutions.
2. Have a very strong code quality
3. Mentor other engineers - I started having 1:1s with Junior engineers on how to grow. Have not been doing this with Senior Engineers, but I try to jump in calls with them whenever they need some help. Often, the credit goes hidden, and sometimes it does bother me, but not sure if there is some way around it. What are your thoughts?
4. Handling production outages and incidents - Trying to be on top of it. Recently, have been putting out short term fixes, but alongside working on some libraries to fix it in an extensible way and have a larger impact with other teams as well. Sometimes, having visibility for my work in other teams seems to be difficult, but trying my way around this. If there is something you can recommend, that would be great.
5. Should I mention in my skip levels that this is something I am targeting for myself? - Right now, my focus is to try to uplift the code quality, work on larger designs (a question mentioned wrt this), trying to uplift the team (I have created a channel where I share stuff that can help the team upskill, brief nuggets of information on how to write good code etc. Doing this almost twice a week for around 2 months now), trying to mentor engineers within the team.

Another aspect is that my team would be getting changed soon due to organisational requirements. Given that, How do I make sure I am on the right trajectory to getting promoted ? (One thing on top of my mind is that I would be asking for junior engineers whom I can work with and try uplifting, alongside asking for opportunities/projects that would have large visibility and impact.)

Do you have any other advice for me?

My goal is to get to this level someday, so I would love to understand more. In particular, how does this dynamic play out at Big Tech/larger tech companies?

At Microsoft, basic criteria for promotion is to deliver at next level consistently. Example: At L62, i need to work and deliver at L63s work level standards.

Crux is when you’re learning and digging deeper technically. How do you approach taking ownership and growing your impact on not just the project but across the team and larger axis?

I'm driving a project with ~5 engineers. Even though we're on track to make it now, the initial road was somewhat rocky. We had to go through a lot of conversations to get execution started, spending ~50% of the allotted time on planning and alignment. This led to scope being reduced for v1 and us building less features that we would have liked.

As a startup, I know that we should be moving faster - What's the best way to handle the project from here and how can I improve in this area in the future?

I'll be going into Amazon as a senior engineer leading a team of 6-7 engineers. I have some anxiety as I have never worked in a FAANG company before, and I imagine the bar is high. Things are also trickier as I'll be in a different time zone from the rest of the team.

How can I make a stellar first impression after I start?

The business side of my company is constantly asking for data queries. I want to take this on and become the "data guy" for the company, seriously helping everyone with analytics and user understanding.

We're using Firebase, but the company wants to move off of it. I'm considering building a custom solution using something like D3.js, but I feel like that would take too long to learn.

How can I best navigate forward achieving this result?

I was curious to learn your take on strategies to push back when the expectations are not realistic. I want to expand my scope and feel that there is lot more scope for me to learn and navigate better. According to me, data and communication plays a major role here.

More specifically in my case, I am wondering how to account for me not being well versed with tech stack and constant context switching between clarifying requirements as they keep changing with each question of mine. How to politely and effectively communicate that although this may seem like a small increase of scope, given that I have to figure tech stuff it will be stretch.

Adding more context: It's trickier as I'm pretty new to the team and tech stack. I feel like I'm discovering a new requirement with every question I ask. I've set up recurring pair programming sessions to increase my velocity, but I'm not sure if that's enough.

Follow-up question: What research should be done before establishing the conclusion that expectations are not realistic?

An XFN stakeholder came up with a last minute requirement for a big project I'm working on, which will probably slow down the launch by at least a couple days. I already made promises to other XFN about the launch date.

What's the best way to mitigate the heat on failing to launch on time and zooming out, how do I deal with last minute launch blockers in general?

I'm more of an extrovert, while my tech lead is more of an introvert. I feel like our relationship isn't as open and honest as it should be, particularly around sharing feedback. They often times have major feedback for me, but it will come too late, either deep into project execution or as late as performance review.

How can I make this relationship more fluid, so I can get feedback to improve earlier?

As an E5, I'm switching to more of a tech lead role, and one of the engineers I'm leading has had consistently poor code quality despite being at Meta for a few years now.

I've asked my manager for feedback about this, and they say that we should come up with a plan to improve the situation. I've already invested time in this, and I'm not seeing results. How can I get the code quality feedback to fully land and improve this engineer's code?

I've hit a lot of issues pretty deep into the project's execution that hold it up. It can come as late as running the A/B test where we find a big problem that delays everything and takes weeks to solve. This messes up the initial estimates I set up.

Part of this is because I transitioned between teams recently: On my previous team, it was easier to set up components and test them early, but in this current team, it's hard to get real signal until everything is set-up and we run a full end-to-end test.

Lastly, if I hit an issue like this, how can I minimize its effect on my performance and restructure the timeline in an acceptable way?

How do I get better at technical design review and presentations? I go into these tech review meetings and get a ton of questions from senior engineers that aren’t directly related to the project and the raw volume of questions derails the whole thing. It always feels like something is missing. What should the preparation phase of a project look like?

Adding on to this, I do go into these meetings with a technical design document. Ideally people will comment on that well before the meeting, so we can get more of the discussion done async. However, people often don’t have time so they don't do this, making the tech review meeting the first time they see the tech planning materials, hence all the questions.

I've done various presentations throughout my career, and I always get stressed out doing them. I'll make slides/a script beforehand and pull all-nighters the day before. I'm okay presenting in front of smaller groups, but it's hard in front of larger groups.

How can I get more comfortable with this, especially with higher stakes presentations like those trying to get buy-in from a large group of senior+ engineers and tech leads?

I learned that my whole team is kind of new (Salesforce acquired this product), and they have just started contributing to the core platform. There are currently a lot of approvals necessary to merge front-end code into the system. This is rough as there's many epics connected to front-end work, and there is not a single senior person in the team which can take charge of looking into the high level architecture, following best practices, and doing better planning to release the code to prod.

I am the only full-stack Staff engineer here, and this is why my EM wants me to create a master front-end tech spec for the team. As an example of something this doc can cover: At Salesforce, there are multiple ways to communicate with the back-end API, each of which has their pros and cons but that information is scattered - We can consolidate that info into this doc.

Given that I haven't written any front-end code here at Salesforce, this task seems hard and I'm unsure how to do this without looking stupid.

I was assigned a P1 bug, and when I started to dig deeper into it, I found out that actual code was written by some other team and we have just used that code/object to build a small feature. I got a bit lucky that someone in my team told that the team ‘A’ owns that code/object. I was given a POC, but it turns out that they have left that team. I would like to have a POC to close out this bug.

For additional context: It is still not clear if it's the feature or the bug that's broken, that’s why we need to get clarification from the other team. Here's a high-level example to make things more clear: There is an object named "Product" which is a generic one, team ‘A’ built another object called "Product Category", and we added a field to that object. Now unless I ask some senior folks in my team it is really hard to understand who owns "Product Category".

Given all these unknowns, how can I navigate this situation and make sure this bug is resolved properly?

My sub-team was 3 people (an L5 tech lead, an L4 engineer, and me), but now it’s just me since the others left. My manager is hiring other people in the coming months.

How can I best onboard the new people and set myself up to lead the team?

I just got promoted to senior engineer level (E5) at Google and I just switched into an infra team 2 months ago. In order to succeed as a senior engineer, I know I need to mentor and influence other engineers, specifically helping newer and more junior folks on the team.

How can I do that quickly, acknowledging that I’m not their direct manager?

Here's the experience I have so far with leadership:

• I schedule meetings between teammates to clarify things for everyone when people seem to be lost or start asking a lot of questions in a trend. This usually helps unblock them.
• Most of my success comes from cross-team communications in terms of knowing and finding the right people for local tasks. I also jump on opportunities myself which usually end with good results. But I haven't yet been able to make a significant impact within my own team.

And here's more details about my current team:

• My team is myself, a PM, one full-time developer, and two other developers/Solution Architects that juggle other responsibilities part-time.
• I've had issues with a particular person who leans too aggressively sometimes questioning the impact of the work items I'm proposing. I'm able to work it out with them, but this relationship could probably be improved further.

I am the only experienced Full Stack developer in the team and I felt that the management got a bit excited when they found out. For the first week I was asked to represent my team to the UI review committee to get the UI approval, I had little or no background of the feature but it was kind of rushed out.

Second week, I was told to write the design document of a feature which I was not aware of. I started digging deeper into it, but after 3-4 days I was told there is some other team who is working on something similar so I should stop working on it.

Third week, I was told to again start working on it but then was told to put it on hold. Within the same week I was also told to write the Engineering document for the FE development for the team, this was a bit surprising for me seeing there is almost everything custom at SF, I felt I needed some time to understand the ecosystem, it is the work in progress.