Effective Communication Guide [Part 6] - Communicating In A Remote World

- What is lost in a remote work environment when it comes to communication?
  - **Volume:** A lot of ad-hoc communication ("water cooler chats") can't happen anymore.
  - **Depth of presence:** When you're on a video call, it's mainly just your face that's visible. In an in-person meeting, especially 1 on 1 meetings, your entire body is visible, which lets you express a lot more via your body language.
- **If you're comfortable, have video on during calls** - Use your facial expressions to really show that you're listening and truly hearing what the other person or people have to say.
- **Book 1 on 1s very aggressively** - 1 on 1 meetings are the core building block behind strong relationships. In an in-person environment, you will build relationships naturally through other means like team lunch, but since those are lost in a remote environment, you need to lean on 1 on 1s far more.
- **Get really good at technical writing** - In a remote world, especially with teams distributed across multiple time zones, a lot more communication has to happen asynchronously.
  - Project updates are very important in particular. It's much harder to stay aligned when everyone is apart.
  - If you aren't already, try to write a project update for your work every 2 weeks or more.

Effective Communication Guide [Part 5] - Giving Feedback

- If you're giving constructive feedback, try to pair it with something positive. In general, positives are good at offsetting negatives.
- Tentative language is also crucial, especially with constructive feedback.
- Example feedback around running meetings:
  - **Bad:** "You need to stop cutting people off in meetings."
  - **Good:** "You do a great job running meetings and making sure that they're on track, but I feel like in pursuit of that, you sometimes cut people off too soon and aggressively instead of letting their voice fully be heard. I think letting everyone get their complete thoughts out is important for our team, and we can always extend the meeting length if there's no way we can time-box properly while doing this."
- Your overall mentality should be, *"How can we all become better?"*, as opposed to, *"I need to tell this person why they suck."*.
- If you don't feel too close to the person you're giving feedback to, you can go through your manager to share the feedback with them or with their manager. At a high-level, you can see your manager as a "people API" to abstract away issues like these.

Effective Communication Guide [Part 4] - Resolving Disagreements

- **Your goal with a disagreement isn't to prove that your side is correct; it's actually the opposite - Try to tear down your own argument.**
- Don't view the situation as a "Us vs. Them" mentality. It's not a debate that you have to "win". If you come in with this mentality, the other side will respond in kind, and you will never get anything done.
- Acknowledge the operating principles and incentives of the other side, and try to weave them into your approach as well.
- Example: Your designer proposes beautiful but overly ambitious design that cannot be done on the current aggressive build timeline.
  - Bad: "We don't have enough time to build these designs, so let's toss them out."
  - Good: "These designs look amazing! However, the timeline is pretty tight, so we may not be able to get everything within them. Can we get the low-hanging fruit with this intermediate state design to hit the ship goal, and then we can get the remaining design extras as a fast-follow? I really want to bring all these aesthetics to life, but I want to make sure we hit the deadline as well."
- Be comfortable with compromise and reaching a middle-ground that imbues something from both sides. It's possible that the other perspective is completely incorrect, but this will be very rare as people in tech are generally pretty smart. *You should very rarely treat your approach as one where compromise cannot be made at all.*

Effective Communication Guide [Part 3.2] - Deep Listening

- *Communication isn't just how you share information, it's also about how you take in information.*
- It is crucial to listen intently, especially during 1 on 1s. A lot of people don't realize that there's a large skill range when it comes to listening.
- How to show that you're engaged:
  - Lean in
  - Nod to acknowledge core points
  - For something heavier, you can say "Mmhmm".
- A very powerful way to gain trust is to listen to people's problems and acknowledge them. A lot of people when they're faced with a problem, their initial goal isn't to actually solve the problem: It's just to find someone who will listen to their pain and feel less alone.
  - Just saying something along the lines of "Dang, that sucks" can go a long way.
  - Letting someone know that you have also faced this problem is also very effective. It builds solidarity and can help combat imposter syndrome as a lot of people are afraid that they are the only one facing the problem they have due to their own lack of ability.
- Revel in people's wins with them! Respond to people's excitement and positive energy with your own.

Effective Communication Guide [Part 3.1] - The Power Of Thanks

- Alex's story:
  - At Meta, there was a tool called "Thanks Bot" where you could publicly thank a coworker, and it would alert them, their manager, and your manager.
  - Given that this tool was more "heavy", people at Meta tended to use it for thanking fairly large efforts.
  - Alex had a great coworker back at Portal who would use it to thank people whenever they just spent 5-10 minutes helping him with something. This took people by surprise as they weren't expecting such a thanks for something relatively minor.
- Thank people for small and medium sized good deeds, whether they helped you or just did some really good work. Thanks is cheap - You always come out hugely "on top" in interactions where you give thanks: Giving thanks takes a few minutes tops and receiving helping often requires 10+ minutes of the other person's time.
- If someone really went out of their to way to do something great, reach out to their manager and thank them there as well. This really deepens your thanks, and it helps them receive proper credit, which could even be reflected in performance review.

Effective Communication Guide [Part 3] - Building Relationships

In order to succeed as a software engineer, you need people to like you. So how do you make that happen quickly? This lesson teaches you:

- **Relationships are all about trust** - The more someone trusts you, the more they will share with you, and the more effective your collaboration can become. The 1 on 1 meeting is the most mechanism to earn this trust.
- **Trust by default** - Trust is extremely hard to earn and very easy to lose. The best way to earn someone's trust is to give them a lot of your trust. This will trigger a response where they will strive to follow The Golden Rule, giving you more of their trust to make things balanced. For an example of trusting by default and earning trust lightning fast, check out [our deep dive into great mentorship here](https://link.jointaro.com/YdUM4JP89Sjh7ruv5).
- **Make small talk** - 2-5 minutes of small talk per 1 on 1 can go a long way. By talking about things outside of work, you are showing that you truly care about them as a person.
- **Be honest** - Tell it to people straight, and don't mince words. By showing that you're comfortable sharing what you're genuinely thinking, people will want to do the same. This is especially powerful when talking about problems.
- **Use humor and self-deprecation** - Everyone likes to laugh: It's a very human thing to do. Crack a joke here and there when you can. Self-deprecation is effective as it's safe (you are poking fun at yourself instead of someone else) and shows your humility.
- **Show thanks** - Don't take your colleagues doing great work for granted: Doing great work is always hard. There is really no such thing as giving too much thanks and making people feel too appreciated. *This is a severely under-utilized technique*. Giving heartfelt thanks is supremely powerful - You can turn someone's bad day into a good one.

Effective Communication Guide [Part 2] - Basic Tactics

Most software engineers are socially awkward, and they perceive communication as this mythical skill that is impossible for them to master. Well, it turns out that there's quite a lot of very easy things you can do to become much better at communication. This lesson teaches you:

- **Use tentative language** - You can always be wrong, and you should acknowledge that in how you communicate:
  - Bad: "Your code isn't performant."
  - Good: "I think this code may have performance issues."
- **Body language matters** - Communication isn't only the words you say or write, it's also how you express with your face and body. This is something that is biologically wired into humans: Put your entire self into it when you are communicating, especially when you're listening! This is covered more in the part of this course: [Effective Communication Guide \[Part 3.2\] - Deep Listening](https://www.jointaro.com/lesson/q1UyjOoZ2pud9IdmXlVJ/effective-communication-guide-part-32-deep-listening/)
- **No leading "hello" for digital communication** - When asking for help digitally, don't do a greeting and then wait for a response greeting before jumping into your ask: Just attach your ask from the get-go. Software is all about efficiency and waiting for this round trip makes things less efficient. For more advice around asking for help effectively, here's our in-depth video about it: [Asking Effective Questions That Get Great Answers Quickly](https://www.jointaro.com/lesson/HV8sq75WxM9VhK0dhUun/asking-effective-questions-that-get-great-answers-quickly/)
- **Lead with the core point** - Think of a "tldr" when it comes to long articles. This also applies to how you talk: Start with the main idea, and then go into the details. When you start by going into the weeds (very common for earlier-in-career engineers), it's very easy for people to be uninterested or get lost in what you're saying. For an example of how this applies to technical writing, check out this Q&A from a Meta engineer about it: ["How to get more visibility on work?"](https://www.jointaro.com/question/XA0X51AypDLCeVeleJv4/how-to-get-more-visibility-on-work/)

Effective Communication Guide [Part 1] - Core High-level Principles

Software engineers are notorious for their poor soft skills, often thinking that being able to write decent code while isolated in a corner is all they need to succeed. This couldn't be further from the truth. Communication in particular is crucial for software engineer career development, especially to senior and staff level. This lesson teaches you:

- **Communication is fundamentally an exercise in empathy** - The entire goal of communication is to align with or win over another human being in some way.
  - Strive to put yourself in the shoes of the person you're communicating with. Try to see the world through their eyes.
  - What are their values? What makes them happy? What are they struggling with? What do they care about? What's their background?
- **Understand others' incentives** - This is especially important in a corporate environment where every employee has some incentives they're pursuing. This will often times manifest as what are the values of the other person's org and even more concretely, *what they get rewarded for in performance review*.
- **Over-communication &gt;&gt;&gt; Under-communication** - Under-communication's downside is that people are not aligned, which usually leads to lots of thrash and wasted work. That is much, much worse than the failure mode of over-communication, which is that you're a bit annoying (and this can be easily toned down and fixed). If you're trying to get better at communication, push for the over-communication extreme: Chances are, you will never reach it. It is *very rare* for someone to be communicating too much - Most people will appreciate the increased availability of information.

Related resources:

- [The Crucial First Step To Building Relationships That Everyone Misses](https://www.jointaro.com/lesson/YPniDFNQqoHEpYHC9JEq/the-crucial-first-step-to-building-relationships-that-everyone-misses/)
- [Stop Getting Ghosted With Your Reachouts - How To Write A Great Cold Message](https://www.jointaro.com/lesson/eZRHXEpxdJjcxK2aQTWl/stop-getting-ghosted-with-your-reachouts-how-to-write-a-great-cold-message/)
- [I Sucked At This For 25 Years As An Engineer – 8 Tips For Communication](https://www.jointaro.com/lesson/s0vZkFtwe3x4tALbdbEr/i-sucked-at-this-for-25-years-as-an-engineer-8-tips-for-communication/)

[Masterclass] How To Be An Amazing Interviewer In Tech

For all the core points, you can find them in the slides below. For this video summary, we're going to share our Top 5 insights from the session:
- The tension of being a great interviewer is that you need to balance getting signal of the candidate's ability while maximizing candidate experience.
  - Can you make it so that the candidate had a good time even if they failed?
- Getting signal happens when the candidate has to figure out a challenge. *This means that you need to be very careful giving hints*. If you give too many hints, you are solving the problem for them.
- **Never ever end an interview early due to poor candidate performance, especially an onsite round**. Turn the interview into a fun pair programming exercise where you build cool stuff and help them become a better engineer.
- If you're the candidate, communicate as much as possible and don't fish for hints. This gives the interviewer more opportunities to help you out. Doing the opposite can doom your chances.
- At the end of the day, the interview process is made up of people on both sides, interviewee and interviewer. Let's all make the world a little better by striving to be good interviewers!

Related resources:
-  [Presentation slides](https://docs.google.com/presentation/d/1oBNstU-3TJlPGc8Rc5K7AfUUdr7OUo1ADT3JPa4ecSk/edit?usp=sharing)
- [In-depth session on acing your DSA interview](https://link.jointaro.com/cponWycMZZfkRNBW8)
- [In-depth session on acing your system design interview](https://link.jointaro.com/FWp3fithS4xzp3dx7)

[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 do you get the most out of mentorship?"](https://www.jointaro.com/question/IbuZydz0QzsVVqESVaxQ/how-do-you-get-the-most-out-of-mentorship/)

The Silent Killer Of Too Many Software Engineer Careers: Burnout

Burnout is a form of exhaustion caused by constantly feeling like you have too much to do. Most software engineers will encounter burnout at some point in their career. Four reasons you may hit burnout, and how to mitigate: 

1. **You can do your job anytime + anywhere.** Try to create some separation between work and home, or set deadlines for yourself. 
2. **Unlimited complexity.** A typical codebase will have too much complexity for one person to understand all of it. Instead, share with coworkers where you feel lost, and start small.
3. **Unclear roles.** There’s often ambiguity around things like handling support requests or maintenance. Try to create structure around this, and acknowledge that this work does exist. 
4. **Unclear communication.** For your work, over-communicate the bad news and refer to [this Taro session about communication](https://link.jointaro.com/6jdUd3ucPprEEVog6).

[Masterclass] How To Build And Grow Tech Products To 500k+ Users For Free

Here are our Top 5 points from this session:
- **Side projects are incredibly powerful** - They improve your portfolio, increase your coding velocity, and give you holistic experience around building products end-to-end.
- **Care deeply about quality** - Users notice when your app or website is buggy. Strive to cover all edge cases and provide a truly polished experience.
- **Eat your own dogfood** - The best way to know how to improve your product is to use it yourself. This was a staple of Meta's engineering culture.
- **Least clicks design** - At the end of the day, it doesn't matter how "pretty" your product looks if it isn't efficient. Think about how you can have your "hero flow" take as few clicks as possible.
- **Understand SEO** - Work backwards from what people will be searching for when they need a product like yours. Then have those words in your product title and relevant metadata.

Related resources:
- [Presentation Slides](https://docs.google.com/presentation/d/1lfSCWI_OUtchWpIEKwG8JkII8IUvBeACRqEJlnTErjU/edit?usp=sharing)
- [How To Come Up With Product Ideas That Get 100k+ Users](https://link.jointaro.com/7Q8cDrda23zv2omU9)
- [How Side Projects Make Recruiters Come To You](https://link.jointaro.com/rxqDDu4sgMQbP6LT8)
- [Why Side Projects Are So Powerful For Junior Engineers](https://link.jointaro.com/cFo3doiWDeE5dpa67)
- [How To Split Your Time Properly Between Work & Side Projects](https://link.jointaro.com/YFCmNrsdqhuMSeUw5)

"What does your day to day look like?" - 8/19/2022

- *In short, it varies a **lot**.* Startups are extremely unpredictable, and the biggest problem facing the company will change every month or even every week.
- However, there are 2 constants:
  - **Talking with new Taro Premium members** - We chat 30 minutes with every new member to get to know them, make sure they're set up properly within the community, and understand their job and career goals. These meetings add up, and we have a decent amount of them every day.
  - **Talking with Rahul** - There's always a ton going on, and we always have a bunch of ideas on how to evolve Taro, so we need a lot of time to talk each day, usually 45 minutes to 1 hour. According to YC, cofounders falling out is the #1 reason startups fail, so we really want to make sure that doesn't happen.
- We try to get a decent amount of code in every week, but it's hard to find time for it and the company's top priorities are often times not build related.
  - On a side note, the highest build priority for us right now is to really make the Taro web app silky smooth.
- We are fundraising right now, so that's dominating our lives.
- We have a lot of meetings in general as networking is crucial for startups.

"Is Taro hiring?" - 8/18/2022

If you're searching for a job, check out [our in-depth video on how Taro can help you do just that](https://link.jointaro.com/e5Swdksn8886KrQs9).

- **Not right now, but hopefully soon** - We want to make sure that when we do hire a full-time employee, we treat them very well and pay them top-of-market. We also want to make sure we're running as stable a ship as possible, especially in this economy - We don't want to hire someone just to lay them off within a year. This requires a lot of capital, more than we have with just the YC investment.
- We're raising our seed round now, and if this goes well, we should be able to hire a full-time engineer, maybe 2.
- Our dream is to turn Taro into a huge, financially sound company and then hire folks who have been supporting us for a long time, all the way back to the Tech Career Growth days.
- If you want to help, continue using Taro, letting us know how we can improve, and sharing the app with your friends and colleagues! The more we grow, the faster we can scale up Taro and achieve our vision of empowering every software engineer in the world to be happier and more effective in their careers.

"What is the growth plan for Taro Premium?" - 8/18/2022

There are 2 core areas at play here:
1. Empowering Taro Premium members to share their diverse wealth of perspectives and wisdom
2. Tactical areas of improvement

**Communal Sharing**
- Right now, Rahul and I are doing the thing that doesn't scale in true startup fashion: Providing the vast majority of career guidance ourselves.
- However, not only does this not scale, we firmly believe that this isn't the right thing to do long term: Our perspectives are only 2 out of millions of incredible people working in tech.
- Let me be frank: While we've had a diverse range of experience and pushed to understand as many angles of the tech scene as possible, our perspective is narrow. We've only worked in the Silicon Valley. We're around the same age. We spent the lion's share of our careers working at Meta. We're both Asian men. Because of this, there's a lot of stuff we don't know and aren't well equipped to talk about.
- This is where the community comes in. At the time of release of this video, we have ~170 members in Taro Premium, and I've been blown away by the diversity of backgrounds present. If we can enable, reward, and empower all these incredible folks in tech to share their perspectives and help one another, we can create what is truly the greatest repository of tech career advice on Earth.

**Tactical Stuff**
- Our main priority right now is opening up the Q&A career advice platform, so that all members of Taro Premium can easily ask and answer questions.
- While this was recently made possible, there's still a lot lacking. There's no notifications to know when your question has been answered, and we all know that the UI/UX has a ton of room for improvement, especially on web.
- We're working with a contract designer right now to completely overhaul the look and feel of the Taro web app.
- Another thing we want to figure out is member matching. For now, we're mainly matching folks of similar level as the incentives get wonky when you pair folks of different levels. However, this "algorithm" is still quite naive, and we have a long way to go before we can sustainably have folks network with one another in a way where all parties feel like they got value.

[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)

The Hardest Part Of Peer Feedback: Giving Them Constructive Criticism

- When the feedback prompt asks you for what your peer can improve on, it is *not* asking you what your peer is doing poorly. If you see your peer doing something toxic/negative, you should give them that feedback *immediately*. Don't wait 6-12 months until performance review season to drop this giant ball on them.
- The *real* question behind this prompt is: "How can your peer expand their scope?". This often times involves something they're already doing well that they can do even better and expand to achieve even greater impact.
- This question will be much easier to answer once you have a deep understanding of engineer levels as a lot of this feedback will be around what you think your peers can do to reach the next level.
- Example: Your peer is very passionate about automated testing and always pairs their landed code with robust test coverage. You suggest that they push to spread this behavior across the entire team with an overall testing initiative.

How To Maximize Your Peer Feedback Impact And Build Stronger Relationships

- Like everything else in life, peer feedback follows The Golden Rule: If you want good feedback from your peers, you should write good feedback for them.
- If a peer feedback request doesn't have a specific ask, proactively ask your peers what they want your feedback to focus on. This really shows your peers that you care deeply about them as performance review is such a core part of every employee's life.
- Writing very powerful, salient feedback for your peers on this crucial stage of performance review is one of the effective ways to build immense social capital.

Claiming Full Credit For Your Projects On Performance Review

- What is the project: Which features did it compose of? How does it work?
- Context behind the project:
  - Why was this project hard/interesting: Complexity of projects is especially important for more senior engineers.
  - What was the business impact: Did it lead to more revenue directly? Did it improve user experience? Was a core KPI increased?
- Role you played in the project: What value did you specifically add to the project, especially that of the deeper kind? For Big Tech companies, this is very important as projects can easily have 15+ people working on them.

Making The BEST Case For Yourself In Performance Review: The Self Review

- Your self-review is the most important feedback for you come performance review season: Ignore the weirdness you may feel hyping yourself up and take it very seriously.
- The onus for representing yourself well falls mainly on you, not your manager or peers. Nobody knows you better than you. It's your job to make sure that none of your awesome achievements fall through the cracks.
- Start your self-review early and refine it across several iterations with your manager.
- Use [your brag journal](https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/brag-journal/) to seed the self-review.
- Show the impact. Attach links to proof as much as you can (e.g. linking a dashboard with positive metrics to show that the project you launched added business value).

Related resources:

- ["How can I most effectively talk about my projects?"](https://www.jointaro.com/question/c0CDYi5VCRXz0gHHLiGP/how-can-i-most-effectively-talk-about-my-projects/)
- ["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/)

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.