Hello Taro community,
I hope you're all doing well. I have a question and would greatly appreciate your insights and guidance.
Background: I joined the company last year (ex-FAANG) as an L5 level and have been actively involved in developing internal tooling for a new product. Recently, while exploring our growth and levels documents, I came across our internal rubrics that outline the expectations at each level.
Situation: After identifying a gap between my current level and the staff level, I expressed my interest to my manager. As a result, I am now leading a team of five individuals in the endeavor of implementing automation tooling from scratch. This effort encompasses setting up everything related to automation.
While my background is primarily in development, I possess knowledge and experience in quality as well. Given the broad impact automation can have across the company, I am eager to leverage my expertise and make a significant contribution.
However, I am uncertain if my focus on quality within a developer role might put me at a disadvantage when aiming for a staff position as a developer.
I am seeking guidance on how to navigate the path towards a staff role, either by leading projects to completion (quality) within my team (& across) or by continuing to work on internal tooling rather than customer-facing products.
Or should I pivot to product development tasks - How do I navigate this conversation with my manager about this dilemma?
Lastly, how can I show metrics and impact?
Different organizations value different things: The main tension here is quality vs. velocity. You should figure out which one is more important within your org by:
On top of these, something you should consider is severity of failure. What's the damage if one of your products or services fails? Is it:
If it's more like #2, then becoming a quality champion is much more important and has better scope.
When it comes to a Big Tech company like Intuit, I generally prefer internal tooling + infra over product when it comes to Staff scope. Finding Staff scope as a product engineer (especially if you're front-end) is notoriously difficult, and I am speaking from experience here.
That being said, it all depends on your org and overall situation. I think when it comes to framing the conversation with your manager, I would do something like:
To help with #1 and #2, I recommend these:
Lastly, how can I show metrics and impact?
This will vary based on org/company (some orgs are more data-driven than others) but generally:
Internal tooling + quality improvements can be tougher to measure admittedly - We talk about this in-depth across these discussions:
@Alex, to add to the question
The user literally loses their $$$ (very relevant as you work at Intuit) -> This is the option, I have had several discussions with leadership on this.
This is the option, I have had several discussions with leadership on this.
If this is the case, that makes your life far easier! To measure your impact, just connect everything to revenue:
I worked on ads back at Instagram, and this was pretty much my life. I gave a case study about it here: [Case Study] Solving A Multi-Million $$ Instagram Bug
This is excellent advice, thank you!
I came across our internal rubrics that outline the expectations at each level. -> We have very clear guidelines on the expectations at each level.
Some other questions:
This quality project has buy in all the way till the CTO.
How can I tie this in the brag document?
There's nothing special you need to do here - Follow the STAR method. We talk about this here:
If a project has strong buy-in from the CTO (i.e. they mention it in company meetings and maybe even provide input on its technical direction/timeline), then you can mention that when claiming the credit for it in performance review.
How can I fetch the $$ amount to stability / users?
The basic answer is to run an A/B test of some sort - Meta had a bunch of core metrics (user time spent, ads revenue, etc) that you could easily add to any experiment's dashboard. I imagine Intuit has similar infrastructure.
The real answer is that this will vary a lot based on your organization, its culture, and the existing data tooling you have. You may need to run complex SQL queries to fully understand the impact. If that's the case, talk to your friendly neighborhood Data Scientist. 😊