How To Influence Your Team Without Authority

Huge thanks to [Ryan Kuck](https://www.linkedin.com/in/ryan-kuck/) for leading this session!

Have you had amazing idea with clear data to support it, but it was rejected? In this event we will talk about why that might have happened, and suggest alternate strategies for next time.

Spoiler alert: We use computers to reach millions/billions of users, but we are very different from computers ourselves. Presenting the best data to another person can actually backfire, unless it is coming from a place of shared goals/values and trust. It isn’t logical, but it is human nature. If you explain a better idea than I presented, and you even have rock solid evidence, I no longer am thinking about the user or our business impact but rather about how I just don’t want to “be wrong”.

Come to this event with your stories of challenges and successes of influencing your engineering team!

To dive deeper, check out these resources:

- [**"How do I lead without authority?"**](https://www.jointaro.com/question/BWv3hFSELbn59mXJbkNB/how-do-i-lead-without-authority/)
- [**\[Course\] Effective Communication For Engineers**](https://www.jointaro.com/course/effective-communication-for-engineers/)

Negotiation Course: Don’t Overshare (Level, Passion, Timeline)

Understanding your emotional attachment to the offer is even more important than the data. Ideally, you want low emotional attachment and high data (as explained in [this Taro blog post](https://www.jointaro.com/blog/the-5-lies-that-too-many-people-believe-about-negotiating-a-job-offer/) by Rora).

For example, don't reveal that you're only talking to a single company, or that you're talking to 30 (either extreme can hurt you). Sample dialog: 

> If anything changes on my end, I’ll let you know, but for now I’m eager to learn more about your company

(There's a whole section dedicated to helpful phrases later on.)

You can share information with the recruiter, but be mindful of what and when you share. How much PTO or signing bonus you want are topics that should come up before (if it's a blocker) and after the interview, not during.

**If in doubt, don’t share it**. Just be positive and non-committal to pretty much everything the recruiter says. Answer questions with vague responses and be confident.

Negotiation Course: How This Course Works

Your ability to negotiate is undeniably one of the highest-leverage skills you can learn. But tech workers are notoriously bad at negotiation. Based on discussions with 100s of tech workers, there are 2 common reasons for this: 

1. They choose not to negotiate. They somehow view negotiation as a perverse 'badge of honor' that they simply accept the first offer they receive and they don't want/need to ask for any adjustment. 
2. They try to negotiate but are ineffective. They don't have leverage or cannot defend why they're asking for certain things. 

This course is designed for tech employees who are exploring job opportunities and will receive a job offer in tech (and ideally multiple!). My goal is for you to feel confident and strong in discussions you have with recruiters and hiring managers.

This course is broken down into 3 major parts: 

1. **Principles** - How does negotiation work and why is it worthwhile?
2. **Planning** - What should you do (and not do) before and offer you receive an offer?
3. **Tactics** - What is the best course of action for various scenarios?

If you get more than a $10K increase in your compensation by following the tactics outlined in this course, send me an email at [rahul@jointaro.com](mailto:rahul@jointaro.com) -- we will celebrate together!

Nail Your Promotion As A Software Engineer [Part 21] - Attribution

The best software engineers don't need to be told what to do; they're able to come up with impactful projects on their own. This lesson teaches you:

- Why ideas are worthless and how engineers can come up with great ideas and get 0 credit for them
- The hard work you need to do to convert an idea into an actual roadmap project
- What it takes to get massive credit on the attribution axis for projects

Here's the case study Alex referred to in this lesson: [\[Case Study\] Revamping Oncall For 20 Instagram Engineers - Senior to Staff Project](https://www.jointaro.com/lesson/esVxIGXYC5BdgxXUkO6H/case-study-revamping-oncall-for-20-instagram-engineers-senior-to-staff-project/?playlistId=EWIo3USNcsgXbCs5PS0h)

Nail Your Promotion As A Software Engineer [Part 19] - Depth Of Contribution

Just because you got a meaty, high-impact project doesn't necessarily mean that you'll get rewarded a lot for it when it comes to your promotion case. This lesson teaches you:

- Why volume of code contribution often doesn't correlate with the depth of your contribution and the credit you receive
- How to figure out if your project contributions had lots of depth
- Concrete examples of hard tasks that have great depth and are greatly rewarded for in promotion cases

Failure Mode: Excessive Handholding

A common failure mode of onboarding is that, even 6 months into the job, the engineer still needs support to make code changes. Either with their workflow or a technical question about the code.

The sign of progress as you ramp up is if your questions and code reviews are evolving over time. The types and depth of interaction you have with coworkers should change.

The key to doing this is to reflect:

- Look at earlier code comments you received
- Write down questions you’ve had
- Don’t make the same mistake twice
- Ask your onboarding buddy to look for patterns

Reference question: [What does it mean to not require handholding anymore?](https://www.jointaro.com/question/5vEWajcZlSi7nlohTGtJ/what-does-it-mean-to-not-require-handholding-anymore/)

Ace Your Tech Interview As A Software Engineer [Part 21] - Recruiter Screen

Having a recruiter talk to you is one of the most common ways tech companies start the interview process for software engineers. Here's the thing: These recruiter screen ones can be surprisingly tricky for many software engineers. This lesson teaches you:

- When recruiter screens happen
- How difficult recruiter screens can be, how often software engineers fail them, and why many software engineers are terrible at them (when they really shouldn't be)
- What to expect in a recruiter screen so you can pass it with ease

Ace Your Tech Interview As A Software Engineer [Part 13] - Cold Messages

You're applying to tons of software engineer jobs, and it's not working out. In your desperation, you come up with a genius idea: You'll reach out to company employees directly with a cold message. That'll work right? Guess again. This lesson teaches you:

- Why cold messaging isn't as effective as software engineers think
- How a reliance on cold messages often mask a deeper personal problem for the engineer
- The necessary conditions for a cold message to have a high likelihood of working
- Why cold messages are far more effective with startups and near useless for Big Tech
- How to write an excellent cold message, demonstrated by a thorough example of a bad cold message vs. a good cold message

Ace Your Tech Interview As A Software Engineer [Part 10] - Order Matters

We all want to speed run our way into FAANG. The bad news is that this is almost never pans out for software engineers, and aggressively pursuing this strategy can easily lead to your downfall. This lesson teaches you:

- The true way to actually get better at interviewing and why it can't be avoided (no matter how painful it is)
- How to properly structure your job search when Big Tech is one of your goals
- The general approach you should take when it comes to applying to jobs and sequencing your interviews

Level Up Your Code Quality As A Software Engineer [Part 23] - Everything In 1 Place

Monoliths and god-classes are 2 of the most common code anti-patterns, especially in Big Tech. They're extremely easy to fall into, and monolithic infrastructure is actually the right call for the vast majority of software as 99% of software is nowhere near the scale of FAANG. This lesson will teach you:

- Why the "Everything In 1 Place" anti-pattern is so damaging, not just for readability but developer productivity as well
- One of the most powerful clean code techniques: **The delegate pattern** (this is how Meta referred to it). It can go by other names, but the core concept is to understand how an interface works. Once you master this pattern, you'll be able to break up any large codebase into readable, focused, modular components. Delegates were easily the most commonly used clean code pattern back during Alex's time at Instagram. Alex goes through an in-depth example from the Taro app itself to walk you through exactly how this technique works.

If you want to learn more about Instagram's stellar engineering culture around code quality, check out this in-depth discussion: ["What do mobile testing strategies look like at top tech companies?"](https://www.jointaro.com/question/fpySzIO02aQ0sCz5N6dP/what-do-mobile-testing-strategies-look-like-at-top-tech-companies/)

Level Up Your Code Quality As A Software Engineer [Part 20] - Code Comment Caches

Code comments can be immensely helpful, but they can be incredibly damaging to a codebase if used incorrectly (which this course will cover even more later on down the line). This lesson will teach you:

- Why engineers will try the very weird "code comment cache" anti-pattern
- The importance of Git, GitHub, and version control platforms in general
- How to not be lazy and properly deal with code that isn't necessary now but may be useful later

Principal Engineer (L8) Describes Most Important Skill - Pong Eksombatchai

Pong is a Principal Engineer at Pinterest.

- **Most important skill**: technical communication. As a Principal Engineer, you can't have sufficient impact on your own. Effective technical communication enables you to work through others and advise other teams on the recommended technical path. 
- **Advice**: model the behavior and culture you want. A Principal Engineer is, by default, a role model for the team and org, so their actions set the tone.

Here's the full playlist asking engineers what the most important skill is for their level: [Asking 7 Levels Of Engineers The Most Important Skill](https://www.jointaro.com/playlist/J9Io5lDGaYUpI8vGrUyI/)

Helpful links:
- [SWE2 --> Principal Eng in 4 years](https://www.jointaro.com/lesson/Lvf1TDKt1R4ZJSCr9BVv/rockstar-software-engineer-story-sw2-greater-principal-in-just-4-years/)
- Taro's top 10 to get promoted from [senior to staff engineer](https://www.jointaro.com/playlist/YD8LMCSlE71VUGUbNAWM/)
- [David Pan on what makes a great tech lead](https://www.jointaro.com/lesson/uHqZZ15SK19MatEvLSO6/what-makes-a-truly-great-tech-lead-a-vp-of-engineerings-perspective/)
- [Pong on LinkedIn](https://www.linkedin.com/in/chantat-eksombatchai-268142b8/ )

[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

[Part 2] Software Engineer Onboarding: Learn the Workflow

To make the hard work easier, learn the workflow and process first.

**A big mistake new engineers make**: they dive in directly to a project and start landing code/landing impact. You goal is be curious about the testing and deployment procedures, along with the workflows and processes. One way to do this is to deliberately pick the simplest possible bugs and code changes to make, so you can exercise the workflow. 

- [Use Code Review Feedback For Hypergrowth](https://www.jointaro.com/lesson/aBRgdYpUfnUpoyWG4qZC/use-code-review-feedback-for-hypergrowth-meta-prodigy-engineer-story/)
- [How To Write Better Code Faster As A Software Engineer](https://www.jointaro.com/lesson/iYpRj8XfyzCSaTYnce3y/how-to-write-better-code-faster-as-a-software-engineer-11192022/)

This is part 2 of a 4 part series from Daniel about how to **most efficiently** and **most effectively** onboard into a new team or company. What should you spend your time doing in the first few months of joining, and how should that change based on your level? 

This masterclass covers this topic from the perspective of Daniel Tomko, a 20 year Big Tech veteran. Daniel spent 11 years at Microsoft and 8 years at Meta in various senior IC and management positions. 

- [Go to part 3 of the masterclass here](https://www.jointaro.com/lesson/7l4Nr4hQf8Pv8zfGZwh4/part-3-software-engineer-onboarding-understand-tactical-decisions/)
- [Go back to part 1 of the masterclass here.](https://www.jointaro.com/lesson/IYZRmwp33E3TBeFQFr9c/part-1-software-engineer-onboarding-embrace-your-lack-of-knowledge/)

System Design Series: Taro Playlists [Part 6] - Overall Approach And Tradeoffs

You can [find the full system design doc here](https://docs.google.com/document/d/15WaM8Ojan82g0m2mtz6kC2Hiyj0Q6VbjfqRmVNDI3qw/edit?usp=sharing) - Feel free to use it as a template for when you're designing systems at your job!

The tactics are covered in the doc linked above, so this summary will focus on the "meta" context behind this part and additional commentary:

- When it comes to determining your overall approach, it's important to understand the priorities and values of your team/company. You can't have it all when building software; when you invest more in a certain attribute, it will generally take away from others. Here are some example attributes:
  - Execution speed
  - Feature robustness
  - Code readability
  - System scalability
  - Design and aesthetic
- Taro and very early-stage startups in general will make warped decisions as the prioritization leans extremely heavily towards execution speed. The goal is to 80/20 as much as possible when it comes to all the other attributes surrounding quality.
- Since this case study is a pretty basic CRUD play building on top of an existing model, there isn't too much complexity around the approach. However, you generally want to propose 2+ concrete approaches and the tradeoffs behind them, especially at a Big Tech company where you often have many, many options.
- Here are the technical design principles covered in the video:
  - **Single source of truth**: This is a very easy way to systems to break and have inconsistent experiences. Let's say your content object has 2 fields, a boolean of "hasLikes" and then an array of users who have liked this particular piece of content. You can either check the emptiness of the array to see if the object has likes or consult the boolean. It's extra work maintaining these 2 different representations of this information, and if they fall out of sync and 2 services/surfaces each read from a different one, things will get weird.
  - **Smart server, dumb client**: You cannot scale the user's device unless you ship them a new computer or phone. However, you can theoretically infinitely scale your server-side. This is why clients (i.e. usually front-ends) should be as dumb as possible with the back-end abstracting away as much complex logic as possible. This is especially true when your product is a mobile app as there will always be users lagging on older versions of the app - You don't want to have to make a mobile update every time you have a basic product logic change. Make your back-end protocol generic, flexible, and powerful.
  - **Be additive with data model**: This is primarily relevant with mobile apps as you will have users on older builds. If you change or remove a field, older builds will break. You can't count on your users to all update to the latest version of your app immediately.

Make Sure To Set This Up With Your Manager To Ace Your Performance Review

- Work with your manager to figure out which peers you should request feedback from at the end of the cycle: They may already have a bunch of peers in mind!
- Once you figure out these key peers, talk with them upfront about your goals, especially if they're ambitious and you're gunning for promotion. Work with them early to build this relationship, especially if they're more senior.

[Part 3] Meta Intern Success Series - Onboarding Efficiently

- Onboarding is arguably the most important part of your internship as it sets the foundation and tone for your entire software engineer internship.
- Set up a 30 to 45 minute meeting with your intern manager (IM) ASAP, so they can explain the codebase to you at a high-level (i.e. a component level).
- Make sure you have a recurring 1:1 meeting with your IM, which should be a weekly 30 minutes. Your IM should set this up for you, but in case they don't, you can work with them to set it up.
- You will get 2-5 onboarding tasks to work on across the first ~2 weeks. The purpose of these is to familiarize yourself with the codebase.
- Aim to put out your 1st diff by the end of Week 1. If you're doing this around the end of Week 2, you're really behind.
- Ask a ton of questions and learn to ask high-quality questions. Don't be afraid of "over-asking" questions: If you're polite while asking questions and attaching great context to them, you will be fine no matter how many questions you ask.
- Use Work Chat DMs to ask for help aggressively during this period as it's vital for you to become productive within the codebase very quickly

Related resources:
- [Asking Effective Questions That Get Great Answers Quickly](https://link.jointaro.com/E8eaKmMpZcKWNGkbA)
- ["How can I learn a large codebase fast as an intern?"](https://link.jointaro.com/L8tXjWah6ycdNpNf7)
- [There Is No Such Thing As A Stupid Question](https://link.jointaro.com/F4p3fL4eHqp5GXti7)

What To Do If Your Manager Pings You Too Much

Receiving tons of interruptive messages or "can you take a quick look at this?" pings is something that every successful engineer must deal with.

The underlying cause of getting pinged too much by your manager is generally an indication that you're not effectively guarding your time.

A few options to consider:

- Understand the demands on your manager. Why do they feel the need to ping you so much? Do they not understand what you're doing, or perhaps they're facing a ton of pressure from their manager about high-pri bugs?
- Document how you're spending your time, and how that is making it harder for you to do the higher priority work.
- When you talk to your manager about the issue, bring up a proposed solution along with calling out the problem.

Related resources:

- ["How does one effectively handle pressure especially when the stakes are high?"](https://www.jointaro.com/question/Bxle0iRRpQXJV88KTpn4/how-does-one-effectively-handle-pressure-especially-when-the-stakes-are-high/)
- ["How to figure out what the most important projects are?"](https://www.jointaro.com/question/CgCPA60bDDHoOteN7Lmb/how-to-figure-out-what-the-most-important-projects-are/)

Performance Bonus Explainer With Meta Senior Software Engineer [E5] Example

This video breaks down how **performance bonuses** work in the tech industry, focusing on their structure, key variables, and real-world examples—especially from companies like Facebook. It underscores how these bonuses are a significant portion of total compensation and are both performance- and timing-sensitive.

- **Performance bonuses are calculated using a base percentage** tied to level and salary, and then adjusted by two multipliers: individual performance and company performance.
- **Company performance multipliers vary**, often based on metrics like revenue or stock performance. For example, Facebook’s company multiplier was 90% in late 2017, despite its historically strong track record.
- **Individual performance multipliers** reflect how well someone met expectations (e.g., "meets all" equates to 100%), and strongly influence the final bonus amount.
- **Bonuses are only paid if still employed at payout time**, meaning even working a full half-year won't earn a payout if the person leaves before the bonus distribution date.
- **Payout examples help contextualize the numbers**: a senior engineer at Facebook with $62K eligible earnings, a 15% target bonus, and multipliers of 1.0 (personal) and 0.9 (company) would receive about $8,300—paid out roughly two months after the performance period ends.

20 Years Of Fighting Procrastination [Part 14] - Reflect

Reflecting regularly is a powerful habit that can dramatically improve your productivity and self-awareness. Here are the core points from the lesson:

- Daily micro-reflections and bi-weekly deep dives help you identify patterns in when and why you're productive or struggling
- Documenting reflections as written artifacts (e.g. notes or voice memos) forces clarity and gives you useful data over time
- Review both the nature of your work and the relationships that support or hinder your progress—productivity often depends on collaboration
- You can keep reflections private, share them with a manager, or even make them public to foster accountability and gain feedback from others

Tech Career Growth Videos

Our instructional videos provide software engineers with insights needed for career growth. Masterclasses go incredibly in-depth on a specific tech topic while case studies are real examples from established engineering leaders.