[Case Study] Revamping Oncall For 20 Instagram Engineers - Senior to Staff Project

Related resources:
- ["How to form a healthy on-call rotation?"](https://www.jointaro.com/question/8OuTidxuVaeuQCV28IhD/how-to-form-a-healthy-on-call-rotation/)
- ["How can I improve the unstructured, chaotic oncall rotation I'm on?"](https://www.jointaro.com/question/ScxFpybXXC90qmnLEU7A/how-can-i-improve-the-unstructured-chaotic-oncall-rotation-im-on/)
- ["How can I maintain work-life balance with a hectic oncall?"](https://www.jointaro.com/question/WLqDVZQa8rAEmFEl15oA/how-can-i-maintain-work-life-balance-with-a-hectic-oncall/)
- [Presentation slides](https://docs.google.com/presentation/d/19PpKY5VoRAP8OMhu2shwhLthKiodw5cUruk6Lycelho/edit?usp=sharing)

[Case Study] Building A Meta Internal Tool To Empower An Entire Org: Staff Promotion Story

- Debugging was a huge pain point for the Facebook Portal org.
- To fix this, Rahul built a tool that made it far easier to debug tricky Android issues (Portal runs a fork of Android). It took all the crazy dump files from Android bugs and extracted the insights.
- Rahul started off the tool with an *extremely* simple interface: Upload the massive dump file and it would extract insights. He would improve it later by making it so the user only needed the bug ID.
- The tool started off with around 100 engineers using it and then grew to 250+! This massive scope was enough to get Rahul AE (additional equity) and a promotion to E6 (Staff at Meta).
- How you can incorporate these learnings into your work:
  - Look internally for opportunity. There are ways to have impact besides shipping flashy products, and in Big Tech in particular, improving engineering efficiency can be a *huge* win given how many engineers there are!
  - Understand the pain of your peers. Not only is this just a kind, empathetic thing to do that builds relationships, pain often comes with opportunity.
  - Think outside your stack. Instead of working forward from your stack of choice and what you can do with that, zoom out and holistically look at problems across your org in general. It's cheap to learn other stacks to build solutions - The main thing to do is identify problems.
- Here's [a link to the slides](https://docs.google.com/presentation/d/1Scxll_pApdPLXk42jSHcrZ4LaTE8_7BUjvB14z9-SgU/edit?usp=sharing).

Related resources:
- [In-depth breakdown on why this project was Staff-level behavior](https://link.jointaro.com/uLUXinMbCNkUFj9H7)
- [What's the Difference Between A Senior And Staff Engineer?](https://link.jointaro.com/BEM2RAjPFe8Pv7826)

[Case Study] How To Become A Data Guru As An Engineer (w/ Senior Director of DS Mo Shahangian)

Mo has had a successful career at the intersection of data science and engineering at companies like Pinterest, Meta, and Epic Games.

Mo talked about the biggest data mistakes and how the job changes as you navigate seniority levels. He also shared his contrarian approach to promotion that has worked so well in his career. 

## Data knowledge for engineers:
- Data science is an overloaded term. The high-level goal for anyone working with data is to surface insights that will inform decisions. 
- Being insightful isn’t enough -- you need to surface **actionable** and **causal** relationships.

Everyone needs a reminder correlation != causation. Have some tools to remind yourself.
- Which way does the causal arrow go?
- Remember [Goodhart’s Law](https://en.wikipedia.org/wiki/Goodhart%27s_law)

## Career growth
- At the most senior levels, leaders are business owners/product leaders, not functional leaders.
- At more junior levels, it’s the opposite, there needs to be order and a separation of responsibility. The best people learn how to work, not only within their lane, but across.

Career success comes from being deliberate:
- A career is a series of decisions
- These decisions come with tradeoffs
- Those best at navigating tradeoffs emerge as leaders
- "Deliberate" means that you are both intentional and calculated

Mo started out building data systems at UCLA, joined Pinterest during hypergrowth, and eventually became a Senior Director of Data Science at Meta, and recently joined Epic Games at the leadership level. Connect with Mo: https://www.linkedin.com/in/mohammad-shahangian-b040188/

[Connect with Mo](https://www.linkedin.com/in/mohammad-shahangian-b040188/)

More resources: 
- Another Taro Premium Session about [junior --> senior eng promos at Meta](https://www.jointaro.com/lesson/EX9563YnxcJb62cCmetg/session-5-mentoring-junior-swes-e3-to-senior-e5-in-just-25-years-at-meta/)
- [Why chasing promo could hurt you](https://www.jointaro.com/lesson/qj2kX94TfFPgBLlQZBtb/why-chasing-promotion-could-hurt-you/)

[Case Study] Hypercharging Your Growth At Early Startups (w/ Staff Engineer Seed Zeng)

[Click here for the presentation slides](https://docs.google.com/presentation/d/1ZocNUZJL-feWAKoucVLUcaVxix2Xa1udEL4KpgQRBTo/edit?usp=sharing).

There are a *ton* of great points covered in this session, so we'll only share our Top 5:
- **Startups have massive scope** - In an early-stage startup, there is always an infinite supply of hard, technically deep problems. This allows you to have a lot of freedom choosing an opportunity that works well for you and build up a wide breadth of important skills. This is almost always *not* the case in Big Tech - [Check out this expert career advice on the difference between Big Tech and startups when it comes to learning](https://link.jointaro.com/n57gbTWERveGTQuM9).
- **Don't say "I'm not qualified to work on this"** - The best software engineers are able to adapt to any situation their team faces and add value regardless of what framework or tech stack is needed. In order to do that, you must first flip this fearful mentality. [Here's our masterclass on how to learn quickly in tech](https://link.jointaro.com/S2h95sJvRU8Utjj6A).
- **Don't be afraid to make mistakes** - Recovering from a mistake is one of the most powerful ways to learn, and startups will generally have more tolerance for mistakes as stakes are lower compared to a more mature, massive public company where product issues can make the news. [Here's our advice on how to maximize your growth from mistakes](https://link.jointaro.com/THof1u97Z5t1ovCr9).
- **80% of the journey is just showing up** - Seek out important, complex situations and run towards them instead of away from them, especially with production issues. If you're earlier-in-career, you can learn a lot simply by being a participant in fixing these fires; from there, you can make yourself a core driver more and more. [Here's our advice on how you can be more independent debugging tricky technical problems](https://link.jointaro.com/xE8oMpCaDYjuMhCg7).
- **It's all about the people** - Your career growth is largely a product of the people you surround yourself with, and this is especially true in a startup where the team is small, bonds are deep, and everybody knows each other. [Here's our advice on how to network effectively within a company](https://link.jointaro.com/Hr1nr53D7sfQAEv3A).

To see (and hear) more from Seed:
- [Connect with him on LinkedIn](https://www.linkedin.com/in/seedzeng/)
- [Check out his podcast "Superposition"](https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkLnBvZGJlYW4uY29tL3N1cGVycG9zaXRpb25zaG93L2ZlZWQueG1s?sa=X&ved=0CAMQ4aUDahcKEwjot6up4Zf7AhUAAAAAHQAAAAAQAQ&hl=en)

Related resources:
- [Session #6 - Maximizing SWE Growth: Ownership and Specialization At Startups](https://link.jointaro.com/2ZevbN54MPZPTocH8)
- ["What's the difference between Big Tech and startups in terms of learning and growth?"](https://link.jointaro.com/n57gbTWERveGTQuM9)

[Case Study] Building XFN Alignment Across Multiple Orgs (w/ Staff Engineer Cat Chen)

[Cat Chen](https://catchen.me/) talked about his success building alignment across multiple orgs. 

Cat was working at Facebook as a Staff Engineer on the growth team. His charter to get the Android apps on app stores beyond the Play Store. (There were 10+ non-Google stores where Android apps get downloaded with some level of traffic.

Getting an app listed on a 3rd-party platform is simple – sign up as a developer on that platform; upload the Android app for review; wait for approval and launch it. Just as simple as publishing to Google Play.

**BUT it's not that simple at a company like Facebook.** Facebook lawyers wouldn’t allow Cat to accept the Terms of Service on behalf of Facebook the company. Cat didn’t have the privilege to bind Facebook into this contract and even if he did, the lawyers would certainly advise against that.

Instead of simply handing this problem to another person or org, Cat met with a director-level lawyer. Given he was on a different time zone, and in a different job function altogether, this took some legwork. The director explained the risk profile (Facebook could have unlimited downside by blindly accepting an agreement). Eventually Cat discovered a workable solution by using a contracting company to sign the legal agreement, which limits the damages that Facebook may face.

Impact of this work: 
- Successful launch of the existing Android apps
- Ability to launch other apps in the future
- Deep and positive relationship with the legal team, and Cat owned that relationship (which made him indispensable)
- **Almost zero lines of code written!**

[Connect with Cat](https://www.linkedin.com/in/catchen/)

For more resources on how to communicate, build alignment, and operate as a Staff Engineer:
- ["How do I sell the vision behind a large, org-level project?"](https://link.jointaro.com/NGCrB2ifkkpDaDe69)
- ["What's the Difference Between A Senior And Staff Engineer?"](https://link.jointaro.com/BEM2RAjPFe8Pv7826)
- [Guide to Effective Communication](https://link.jointaro.com/mP3WEd4zt5ecnupX6)

[Case Study] Maximizing SWE Growth: Ownership and Specialization At Startups

**Huge** thanks to [Henry Prior](https://www.linkedin.com/in/henryprior/) for joining us and sharing his perspective and insights!

This was a *massive* session, so here are just some of the highlights:
- **Henry's core learning**: Bias towards action. You aren't really going to truly understand what is and what isn't fruitful to you until you just start trying things.
- **Story #1** - At his first startup job, Henry found a project to upgrade from Tensorflow 1 to 2. This ended up moving the metric he cared about, but he found out later that the business impact wasn't great. The company's clients were non-technical and didn't really care about the company's model being ultra-accurate.
- **Story #2** - Found a reinforcement learning project at his next company where he did all the modeling on his own and worked closely with an infra engineer to ship. The work was very complex and had huge impact, saving ~25 hours per week in Data Scientist cycles. He got massive recognition from the company, and this project was a big part of his move to senior.
- You have a lot of autonomy in early stage startups. Take advantage of this and actively look for large problems to solve, doing so as early as the interview process. It's not like Big Tech where you are generally given a good amount of direction on what to do (at least until you get to staff).
- *It's in your best interest to be completely authentic when interviewing with a startup.* It's not like Big Tech where you're putting on a facade to meet their interview requirements. A startup might not be the right for you due to a lack of work in your interest area: Big Tech in contrast has a little bit of everything.
- *If you're going to get into machine learning, you should understand the underlying math first.* This puts you in a much better position to work on the modeling part of ML vs. the more tertiary tasks like data wrangling. The math is a combination of probability/statistics, linear algebra, and calculus.
- **You can't study your way to being good at system design.** Resources like books and blog posts help, but system design is something you very much have to get good at by doing. Instead of just leaping into the code, start planning out your tasks and doing technical writing. From there, share your material with your team and get feedback.

Related resources:
- ["What's the difference between Big Tech and startups in terms of learning and growth?"](https://link.jointaro.com/yzWgzTF4WFzfXjS29)
- ["Does it make sense for me to choose a specialization like ML? If so, what's the impact?"](https://link.jointaro.com/jV34Jz7cJqQv2MpD8)

[Case Study] Mentoring Junior SWEs [E3] to Senior [E5] In Just 2.5 Years At Meta

For the key points, you can find them in the slides (linked below), so the summary will be framed more as action items.

**If You're Pushing For Senior/Are Senior+ Already**
- Mentorship is a core part of healthy senior engineer behavior, so invest in it if you aren't already.
- Now you need to find good mentees. *The main thing to look for is their coachability, which largely depends on how smoothly they process feedback*.
- How can you tell if someone is coachable?
  - They go the extra mile making sure their code is clean.
  - They respond to code review comments (particularly yours) with enthusiasm and speed. They're hungry to learn more and go deeper into feedback on their code.
  - They go out of their way to help others as opposed to many people who just help reactively (or not at all).
  - They have a good cadence with you when you spend time with them (e.g. it's easy to have a fun conversation with them over lunch).

**If You're Mentoring Other Engineers**
- *If the extent of your mentorship is that you answer a lot of your mentee's question, you're not truly a mentor.*
  - True mentorship is being proactive and having a clear vision for what your mentee will become. Create a growth plan for them to get to the next level and outline deltas to make it clear.
- If you haven't already make sure that your manager and the manager of your mentee (if they're on a separate team) are aware of your involvement. This is vital for getting proper credit and not growing them incorrectly.
- Your mentality should be that you serve your mentee, not the other way around.
- To build a ton of trust quickly, tell your mentee this: *"No matter what happens, I'll do whatever extra work is necessary to make sure that you're okay."* You are majorly responsible for your mentee's well-being.
- Always call out when your mentee does good work, even if it's something small like a well-written commit. Do it in your 1:1 where it has more gravity. Showing appreciation as a trust/morale building technique is *severely* underutilized.

**If You're A Mentee Looking For A Mentor**
- Show strong gratitude for code review comments on your commits. Don't just give them a thumbs up or worse, silently make the change. For deeper feedback (often times coming from senior engineers who you want to mentor you), go the extra mile giving thanks.
- Put yourself out there: Don't be a hermit. Go to team lunch, offsites, coworking - Become known as a friendly face within your team. Strike up conversations with engineers more senior than you just to get to know them.
- Strive to write good code. It can scary as a junior engineer in particular and default to churning out tickets as fast as possible with bare minimum quality; avoid that instinct and try to spend an extra 30 minutes to 1 hour trying to build things out properly (and then talk about your thought process on your pull requests). You want to show senior+ engineers that your hunger to be an actually good software engineer instead of a commodity coder is there.

Related Resources:
- [Presentation Slides](https://docs.google.com/presentation/d/12OelIHF08oBZwe-TzVlz8fqp4WiOTem_e9KsGe7X8XA/edit?usp=sharing)
- [Meta E4 To E5 Growth Plan (Pretty Applicable To Any Large Company)](https://firebasestorage.googleapis.com/v0/b/tech-career-growth.appspot.com/o/articles%2Fmeta_e4_to_e5_growth_plan.pdf?alt=media&token=e13d88fd-9356-4c20-a229-cf0cad78a9af)
- [How To Get The Most Out Of Mentorship](https://link.jointaro.com/sobZVTxh3nvUFTnb9)

[Case Study] Effective Communication: Leading A Multi-Org Re-architecture At Meta

Here are [the presentation slides](https://docs.google.com/presentation/d/184dP9pi41lO5TlME4cn4fRblCPtKFdet7d5WmrpnbGc/edit?usp=sharing) and the [polished chat log](https://firebasestorage.googleapis.com/v0/b/tech-career-growth.appspot.com/o/tps_chats%2Ftaro_premium_session_4_chat_notes.txt?alt=media&token=ca1a199d-fe36-42bc-8d2e-fc91371e691f) from the session.

As an IC, you don't have authority over engineers in the way a manager might. So your impact is defined by your ability to have **influence without authority**. Influence comes from consensus + collaboration, which comes down to communication. Said another way: Communication is the foundation for trust. 

Rahul talked about 3 parts to effective communication in this presentation: 
- **Start with the audience**
  - Understand how much context your audience has, and connect the dots for them.
  - Your communication should be as short as possible.
  - Bad news should never be a surprise.
- **Choose the right medium**
  - Do some reflection on what your objective is: build relationships or efficiently communicating some info? Be clear the difference between verbal and written communication.
  - Evaluate the current processes for communication in your org: standups, team meetings, email updates, cross-org communication. 
- **Be consistent**
  - You should have a regular drumbeat of posts for your projects. If you feel like nothing happened, you should explain why nothing happened.
  - For long-running processes like brainstorms or architecture reviews, you should consistently message the timeline and milestones.

Related resources:
- ["How can I come up with big initiatives, especially those at a Staff level?"](https://link.jointaro.com/sm57uikgXJ3RRpTv8)
- [Writing is thinking](https://medium.learningbyshipping.com/writing-is-thinking-an-annotated-twitter-thread-2a75fe07fade) - by Steven Sinofsky (Former President @ Microsoft)
- [Be plainspoken](https://boz.com/articles/be-plainspoken) - by Andrew Bosworth (VP of Eng @ Meta)

[Case Study] Becoming A Tech Lead Again In Just 1 Month After Joining Robinhood From Meta

- The expectations for an L5+ (senior+ at a FAANG or similar company) engineer are high. You won't get 12 months or even 6 months to fully onboard: You need to start having huge impact and showing your depth within 1-2 months.
- After starting, Alex told his managers that he was happy to offload any responsibilities they had so they could focus on higher-level issues and expand their scope. As a tech lead, you need to view your manager as a partner, not just a boss. "Treat me as a resource."
- The project that Alex was first put on was to make settings more server-driven within Robinhood
- The most impactful thing to do was to add color to the project:
  - Stabilize and then drive the workstream meetings
  - Create a thorough tech spec
  - Align XFN to figure out how to treat each settings section properly, especially in places where there were inconsistencies
- How Alex added his depth:
  - Wrote a 5+ page Android spec for his portion
  - Manually audited all of settings and compiled a detailed spreadsheet of inconsistencies to fully capture impact
  - Thorough data analysis spec, doing complicated SQL queries himself
  - Mentored an L4 engineer in the process, giving them L5 scope
- Recap (how you can incorporate the learnings here into your work):
  - Earn trust quickly: Be "aggressively" nice. Find out how you can add value to others and be very sincere and upfront about it.
  - Fill in the gaps: View your projects holistically and figure out what's missing to move the project forward. This will often times be "less flashy" non-coding work.
  - Bring people together: Don't be paralyzed by your lack of knowledge. Especially if you're new to a company, you will be clueless in a lot of scenarios. If you're in a cutting edge company like Meta/Robinhood, there will be a smart person(s) somewhere out there with the answer: You just need to bring them together in a healthy way.
  - Go deep: There's far more to a senior engineer than their ability to code. If you're a new L5+ engineer, even the tenured L3/L4s at the company will code circles around you in the beginning. If you're an L5+ engineer, figure out what behaviors and fundamentals you have that more junior engineers don't and show those as much as you can. This generally involves shipping software in a much more holistic way.

Related resources:
- [Presentation slides](https://docs.google.com/presentation/d/1j5Lj_IGrtCRUpobj0f8k9egrBAej9apzikGp_V_iTCk/edit?usp=sharing)

[Case Study] How to Quit Your Job The Right Way (w/ ex-Netflix TL Michael Lin)

[Michael](https://www.jointaro.com/profile/Ab2xedZA7RhROW0wo9wBHIJbAsX2/) famously [quit his $450,000 job at Netflix](https://www.jointaro.com/blog/why-i-quit-a-450k-engineering-job-at-netflix/), and asked for (and received) a severance package in the process! If you're thinking about quitting your job, consider these points **before** leaving: 

### Timing is important
- It’s better to leave on the 1st of the month than the 31st because employee benefits renew on a monthly basis.
- If you leave on the 1st, it’s like getting a full extra month of benefits. 
- But if you leave on the 31st, your benefits may end the next day.

### Quitting is a trade-off
- You’re weighing that the negatives of staying outweigh the negatives of losing out on income.
- If you have to cut vacations, move away from loved ones, and say no to social events, then those negatives may outweigh the negatives of your job.

### Act with urgency
- If your career is not going the right way, take action quickly.
- If you stay an extra two years at a job you wanted to leave and did this over five jobs in your lifetime, that’s ten years of your life spent doing work you never wanted to do.

---------
- Connect with Michael on [LinkedIn](https://www.linkedin.com/in/michael-lin-tech/)
- Subscribe to [Michael's newsletter](https://michaellin.substack.com/)

Related questions: 
- ["Should I request a voluntary layoff to my manager?"](https://www.jointaro.com/question/FnInc1bJ3AUJBz0grFyj/should-i-request-a-voluntary-layoff-to-my-manager/)
- ["Should I quit to prep for interviews?"](https://www.jointaro.com/question/Cno3oaZkvUu7BPLhHB7g/should-i-quit-to-prep-for-interviews/) from a Data Engineer

[Case Study] Solving A Multi-Million $$ Instagram Bug

- A big part of moving from L4 (mid-level) to L5 (senior level) is being able to create your own scope. You can't just expect a perfect suite of projects to come from your manager.
- Like in this session's case study, bugs are a great source of finding your own scope!
- The bug was very slight: Instagram story ads started off on the wrong part when they were resurfaced to a user. As an Android engineer, Alex discovered this in IG Android initially. This bug had been in production *for over a year* at this point.
- How Alex expanded the scope after finding this bug:
  - Worked with iOS to see if the bug was there (it was)
  - Worked with PMMs to confirm that this violated the advertiser contract and merited a refund. This made the bug an immediate SEV.
  - Worked with a data scientist to figure out exactly how many times this bug occurred and calculate the exactly refund to advertisers ($2M+)
  - Put the fix behind an A/B test to measure impact and make sure it was working
- How you can incorporate the learnings from this case study:
  - Be detail-oriented. At Big Tech in particular, seemingly small issues can have massive impact.
  - Don't just silently fix bugs. Take the time to figure out its entire scope - It could be a SEV!
  - Understand the world outside of yours. Look for opportunities to bring in others (especially those of different roles) into what you're working on to expand scope for everyone!

Here's the [link to the slides](https://docs.google.com/presentation/d/1vPtelhi5caMsZNC-XFGhy1FtRveIbNxg0k3LZctRPOs/edit?usp=sharing).

For more resources around creating scope:
- ["How do I come up with innovative, impactful ideas and bring them to my team?"](https://link.jointaro.com/uBcb5LjZiD5DasfB9)
- ["How can I come up with big initiatives, especially those at a Staff level?"](https://link.jointaro.com/6MWig3VSr3nVo81w9)

Explore Taro Premium Sessions on Taro