Explore Staff Engineer on Taro

I've been a senior engineer for a while, so I would like to start making real progress towards that level. I see a lot of other engineers in the company making it to Staff or an equivalent level, and I'm wondering what I can do to make that same level up.

I recently got feedback from my manager, and they mentioned that to start making progress to E6, I need to come up with new initiatives, which are big projects spanning across multiple teams. This is especially important for us as our team works in a way where we need to come up with the roadmap more on our own in a bottoms-up fashion.

This feedback is one of the core pillars I want to focus on going forward, but it's hard to make it actionable. What can I concretely do to start coming up with these projects?

I improved a complex library integration in our app, which reduced our amount of crashes and memory leaks by X amount. I can pull some concrete numbers from the Play Console and Firebase dashboards to back this up.

However, I'm wondering if the overall business even cares about these memory leaks and crashes. For context, the feature worked fine overall prior, evidenced by the fact that there were no real user complaints about it.

How can I unblock engineers on the team without getting into the weeds and debugging the issue myself or pair programming with them?

Right now, I create work tickets and add context so engineers can easily pick them up. Engineers will then come to me with technical problems as they get blocked on these tickets, which requires a lot of time from me.

Recently the app has been having navigation issues. An engineer picked up the ticket to fix these bugs, and I provided the context and starting point. However, they had trouble with it, so I’m checking out their branch and helping them debug. We just want to make sure it’s not broken as it’s a big change. Is this too in the weeds?

I’m not sure if I should be on top of everything - I don’t think it’s possible. Another instance is an engineer working on coroutine migration. Should I be working on it?

My team spends a good amount of time fixing random/recurring low priority crashes. The goal is to keep the overall crash rate under our agreed SLA. Crash rate naturally goes up over time, so we need to continually invest time plugging up these crashes to keep the overall metric below SLA.

Is there a way to quantify this in numbers. Maybe we can draw the connection between these fixes and a better user experience that ultimately affects the app users' ratings in the Play Store?

Since the engineer implementing the task went in a different direction from what I had in mind, now I feel like I have to dive into the code and explain the approaches I wrote, and also get involved in the code much more than I would like. How can I overcome this?

For purely technical projects/platform work, how do you convey the impact to leadership/performance review committee? During performance review, do managers care about the impact of technical projects?

One thing we try to do is treat platform teams as enablers of delivery teams, i.e any platform work should impact product work directly. Sometimes we can quantify direct impact, but most of the time the impact is indirect which is hard to back by data and quantify.

Another angle is that delivery team engineers are the customers of platform team - If we enable them to deliver valuable feature faster and cheaper, we succeed. Again, this is hard to quantify with concrete data.

So my overall question is: How do you link and quantify technical projects like app optimization and performance improvements to direct product and business impact?

One of the mobile platform projects I led was to improve X pattern in the app and then document best practices around it so engineers understood this new pattern and continued to propagate it.

My proposed impact is that this promotes consistency in the app's codebase which should lead to faster code reviews and enable engineers to deliver features faster. How do I quantify this?

We maintain a healthy suite of E2E tests, which does catch regressions sometimes before release.

It is hard to keep track of it all manually, but I believe that each time a regression is caught before release, it's overall positive on time spent. Each instance of this happening saves time which would have spent hot-fixing the issue in production if the regression wasn't able to be caught early by the tests.

How can I verify my hypothesis and make sure that this overall E2E testing effort is well-run, impactful, and net positive with engineering time investment?

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

I'm an E5 at a Big Tech company. My team's working on a very ambiguous project. 3 opinionated, vocal engineers (2 E6, 1 E5) tend to sidetrack our brainstorming discussions by playing devil's advocate to shoot down ideas. How do I drive these meetings forward with this dynamic? We often rehash the same discussions over and over. When we're close to reaching a decision, oftentimes someone would throw a wrench into things. Moreover, some engineers require upfront planning and want to finalize all the details before committing, while others prefer to defer the details to future milestones. Both my manager and team are getting frustrated, but are unsure how to fix this.

I'm an E5 iOS at a Big Tech company. Our team's E6 backend and E6 iOS tend to dominate our team discussions, often talking over each other. I get the impression that the E6 iOS wants to be the smartest person in the room and enjoys micromanaging all the details, but the E6 backend enjoys challenging him. When I proposed a solution to one of our project's challenges, the E6 iOS quickly shot it down but could not propose any alternatives. The E6 backend challenged the E6 iOS to explain why my idea wouldn't work, but the E6 iOS just talked in circles. It seemed like the E6 iOS just didn't like it because he didn't come up with it himself. How do I avoid making the E6 iOS feeling threatened? I'm a bit hesitant to contribute to team discussions due to this dynamic, but my EM wants me to contribute more.

At a previous company, a friend had an exceptional mentor who helped him climb from mid-level to senior engineer in 1.5 years. I’ve struggled to find a mentor of similar caliber. What advice do you have for finding a good mentor?

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?

It's been hard for me to draw the line between work and life with their current involvement. Here's some examples:

1. They had a meeting where staff engineers (myself included) had to review a junior engineer's code.
2. They ping me at odd hours, sometimes after midnight.

I also have calls with a team in a very time zone, stretching out my workday and making it start pretty early and end pretty late. Any ideas on how I can improve this situation?

My goal is to level up to Staff someday, and I feel like I've gotten a lot of very high-level advice and examples that are hard to directly apply. What are some detailed examples of Staff level projects, and what about the execution/behaviors made them Staff?

1. How do pull requests and pull request comments look like with an increasing level of seniority?
2. Are pull requests for senior engineers not expected to have any comments for improvements? If yes, then what kind of comments should be there?
3. Also, have seen some principal engineers not sharing their pull requests as they are quite high in seniority and merging it directly. Do you recommend that? If not, who should review PRs for very senior engineers if the team does not have engineers at that level?

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 worked on backend for 10+ years and was a Tech Lead before switching to iOS for the last 10+ years. I was offered an E6 position at a Big Tech company, but I asked to be down-leveled to E5 due to imposter syndrome since I mostly worked at smaller startups and didn't know what to expect. When Leadership later found out that I have backend experience, they started pushing me to do backend. Is it easier to get to E6 doing only iOS or doing both iOS and backend? I'm much faster coding iOS than backend since I know the Xcode shortcuts, a lot has changed in backend over the past decade (e.g., AWS, Kubernetes, etc.), etc.

Any recommended resources that I should invest as part of my education budget?

I am Backend software Engineer and I am interested in moving to Staff software engineer role in future.

Often we talk about how, when getting feedback during a PR or Design Review, there are mistakes that I have seen, at least in my case, creep up repeatedly. Any tips to ensure that the learnings stick?

There's too much work on my plate, which is made worse by the nature of our team's product:

1. It's a black box, so it's hard to understand. There are very few Staff+ level engineers on my team to unravel this.
2. I spend a lot of time on proof of concept projects instead of core execution work.
3. The level of expectations are seemingly increasing every day.

What can I do to make things more doable?

I’m married with two kids. It’s important that I spend time with my family, while also doing well in my career. Do you have thoughts on growing my career without burning the midnight oil?

Hi,

I got promoted last half to IC5 and have been leading impactful work streams within our team. I am enjoying my new role and work. In our last 1:1, my manager asked if I wanted to lead a very high priority org level initiative that has impact across multiple teams and suggested this could be a potential staff level project. While this is a great and unique opportunity for promotion, I am also nervous about taking this up because:

1. I am scared this might be more challenging than I am ready for and failing this would put our Org's key launches in risk.
2. I just got promoted and didn't want to actively pursue promotion as I wanted some time to settle in and become a solid IC5 first.

Wanted to get your thoughts on this and what you would do in my position? And if I say no, should I be worried about my manager passing me up for potential opportunities in the future? Thanks!

Like a lot of E5s, I'm working on a piece of my team's overall project roadmap, which is set by an E6 TL. The piece I own is less technically complex than other parts, but it is quite XFN heavy (great for people/direction contribution). I was wondering if this is still enough to get to E6 or do I need the higher technical complexity as well?

It seems at Apple that getting promoted past ICT4 can take ages. My manager has 3x my YOE and many reports, but we're both ICT4. There is no leveling rubric that I can find, so it's unclear to me what differentiates an ICT5 from an ICT4 here. I'm thinking it might even just be worth abandoning the promo goal for the duration I work here, then aim to be hired into a promo at the next gig in a few years.

A lot of examples of growing to Staff are more oriented around less technical fundamental/soft skills, including the examples in Taro. However, I'm unsure how to find this scope in my team, and I don't think that kind of behavior works to get to Staff at Apple overall. I spend ~90% of my time coding, and the culture is more top-down at Apple compared to a company like Meta.

Given all that, how can it be possible for me to grow to Staff? Are there paths to Staff that are heavily technical?

Knowing that, how should I tailor my career path - What companies should I work for and what skills should I get to set myself up for success against this goal? Should I continue working at Salesforce or should I go work for a different company?

I'm looking to get promoted as fast as possible, so I really want to understand how very senior engineers think. Here's some additional questions to add more depth:

1. If you were to backtrack and retrospectively analyze the careers of the engineers who reach staff level at Big Tech, what's the common thread with all the projects they've worked on?
2. How were they able to land themselves on those projects?
3. What allowed them to put themselves in a position to contribute to such high impact projects?

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?

I have realized that I need a very high level overview of the current system and what other systems it communicates with. I have no idea on how to do it; I'm currently planning to have a meeting with my EM.

I have access to the Quip, Google Drive, and some brown bag sessions. I have watched a few of them, but it all seems very fragmented. After I figure all this out, I plan to create a doc which can help others better in the future.

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.

I'm a relatively new engineer at Salesforce (been here just ~4 months), and I'm having trouble clearly understanding my expectations.

What's the ideal ramp-up/onboarding strategy for a Staff engineer at a Big Tech company like Salesforce; in particular, what should the first 3-6 months look like? Are there any specific artifacts you would expect such an engineer to have produced during this time?

Part 1: Before Joining an organisation

1. How can one identify the best kind of organisation to join at different point in one's career? I understand that the advice to this question may not be a prescription for all, but how can one identify places that would help them to maximize their learning and growth. For several other people, different parameters may be important for them as well such as work-life balance. Personally, I feel that WLB is dependent on a person more than that on the organisation. Thoughts?
2. Quite often we feel that growth may be fast paced at startups, but there can be startups that do and don't promote the growth of a person. Given that there is no list out there to check, how can one make the best suited decisions for their career, not landing at a place they should not be at? What kind of research can a person do before joining an organisation?

Part 2: After joining an organisation

1. Given that a person has joined an organisation, what are the kind of signals that they can identify to see whether the organisation is supportive of their career growth and is indeed the right place to be, for them?
2. On several anonymous portals, there are people from the organisation that will talk poorly about an organisation when things are not going good for them. Managers can quite often paint a really rosy picture about the place. How do you identify the honest signal from the noise all around?
3. If you find an organisation not good for you after you join there, how quick is it too quick to leave? How much time should you spend there before you can make a judgement about the same?

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?

A fellow senior engineer on my team is leading a large multi year project that involves rewriting a significant portion of the codebase. He came up with the proposal, design doc, everything. A couple of team members are already helping him in the project, but since the project's scope is so big, he needs more help.

There is also a backlog of other projects that haven't been prioritized for several quarters. These include stuff like migrations, enabling CD (we still deploy manually taking up plenty of oncall engineer's time everyday) for our service, etc.

I feel like I would get more credit and build trust towards moving to E6 by leading one of the projects in the backlog as opposed to helping out the other engineer in his project. What do you recommend?

I’d like to be a very senior research engineer in a FAANG company. I’m currently a senior engineer at my medium-sized company but I want to move closer to the research side as a more senior IC. What does it look like to be Staff+ research engineer vs software engineer? How can I build those skills now?

For example, this week I was told to work on adding a field to some legacy entity which is not recommended (i.e. you need to have a solid business justification). The whole process is very lengthy, requiring many layers of approval just for this single field change. How can I find the scope appropriate to my level?

Before I was at Amazon in Cambridge, England. I came to enjoy the quality of life there, but recent changes made me switch to Salesforce in India. The work-life balance here is good, but even as a staff engineer, I’m having trouble finding scope - I own just a small piece of the overall system my team’s responsible for.

I was able to recently get an offer from Spotify for a UK office, which expires in a month. However, it’s for Software Engineer 2, a level below their senior level. This isn’t ideal as one of my goals is to be a Staff engineer at a reputable company.

Should I stay at Salesforce where I’m already a Staff level and have solid work-life balance or move back to the UK to work for Spotify?