As a Staff Engineer, I have often helped my teammates when they encounter impossible-to-root-cause issues. In doing so, I’ve observed common roadblocks that often trip engineers up. Whether it’s getting lost in a sea of logs, misinterpreting error messages, or simply not knowing where to start, many engineers find themselves stuck in a loop of frustration. What separates those who struggle from those who succeed is not always context or experience but the debugging mindset and process they employ.

Today, I will share my high-level steps so that you can skyrocket your debugging skills.

WorkOS: Start selling to enterprises with a few lines of code (Sponsor)

WorkOS is a modern identity platform for B2B SaaS. It provides flexible and easy-to-use APIs to ship user management, SSO, SCIM provisioning, and fine-grained authorization in minutes instead of months.

WorkOS powers some of the world's hottest startups, including Perplexity, Vercel, and Webflow.

Get started today

💪 Step 1 - Don’t give up!

Believe in yourself, and don't give up on investigations without trying. Many people think they are not experts and hold back, but it's important to be curious.

However, remember not to be over-confident. You should understand where your knowledge is lacking and be open to seeking help.

📚 Step 2 - Learn the basics

If your foundation is weak, being productive in your debugging sessions will be hard.

You should invest in the following upfront:

• Know where to find the logs, process cores, alarms, metrics, dashboards, runbooks, etc.

• Have a reasonable grasp of how various components interact with each other.

• Know how to search the codebase - not just your team's but also your dependencies.

Remember, it's okay if you don't know everything.

Subscribe now

✅ Step 3 - Validate your understanding

You can’t make progress if you don’t understand what the bug is. Sometimes, people don’t realize they are stuck. They cannot articulate the problem to themselves and look at too many logs/charts in a haphazard order. The best way to get unstuck is to explain the problem to a four-year-old (metaphorically, of course).

Here is what works for me with an example situation (Imagine there is an active Service Overload alert)

• What is a brief description of the problem?

  • "The alert for service overload fired for all of production or scoped to X regions."

• Look for metrics that prove the problem. Even better, use the timeline view to understand when the issue started.

  • Look at the single "overload" metric that is over the threshold.

  • Maybe you will find out that it started happening at 10 am today.

  • How is the "overload" metric calculated? Is it a derivation of different resources or something artificial?

• Do the metrics show more sub-problems?

  • Are the requests failing due to server overload? If so, by how much?

  • Are the requests taking longer to complete?

  • Are there more requests coming into the service?

  • Which customers are impacted? If so, how badly?

• Ensure you are not distracted by unimportant and unrelated problems.

  • Don't focus too much on the outliers. For example, some requests likely took longer, even before the overload occurred. They may not be interesting to look at.

  • Don't focus on customers who are sending a handful of trivial requests.

  • Filtering noise can be hard for someone inexperienced. So, rely on your runbooks or previous investigations.

So, my point is to be curious and ask “why” at every step. When you try to understand beyond just the surface-level concepts, you will get closer to the root cause.

🔍 Step 4 - Scope down the problem

It is easier to go in circles when you only look at macro metrics. To get to the root cause, you need to narrow it down to something scoped and smaller.

Using the same example of service overload:

• Can you find a single instance?

  • Is a specific kind of request taking longer?

  • Is a downstream dependency taking longer?

  • Can you enable high-fidelity logging to find out more about this single instance?

• If the number of requests increased, can you narrow down which customer sent them?

• Did other things happen around that time?

  • Was there a config change? New code deployment?

  • Has your rate limiting or autoscaling stopped working?

• Can you issue dummy requests to see if that reproduces the problem?

Don't get stuck trying to tackle the behemoth. Instead, break down the problem into smaller, manageable issues.

🤝 Step 5 - Ask for help

So, you have validated the problem to a certain extent and have scoped it down. But you are unable to make further progress. That is fine, and naturally, you should ask for help.

One of the hardest things to do is ask for help the "right" way during an intense situation. Try these:

• Give a brief description of the problem with supported metrics.

• Articulate your understanding of the situation and your working hypothesis.

  • Explain why you believe your hypothesis is likely true. Provide supporting metrics and logs.

• Clearly state what you do not know and the gaps in proving your hypothesis.

  • Many engineers can explain what they understand but struggle to identify what they don't understand.

  • Your peers should not have to play a guessing game while trying to help you.

    • For example, others can provide concrete guidance when you say that you don't know how to find downstream latencies or are unaware of all downstream dependencies.

• Don't share information piece by piece.

  • Provide a bird's eye view of the problem while asking for specific things.

  • The worst thing you can do is ask overly specific questions that help you prove your hypothesis. Your peers may not have the context and cannot correct you if your original hypothesis is wrong. This will lead you in the wrong direction.

  • Treat your peers as a brainstorming resource rather than a Q&A bot.

    

🔄 Continuous improvement

Don’t expect to be great at debugging during your first major issue. One of the best ways is to learn from what you missed this time:

• When you seek help, don’t just seek the answer. Understand how your peers got to the answer.

• Make a note of the shortcuts others took or the context you didn’t have

• If the quality of the logs is poor, then improve it for the next time.

These steps serve only as a template and must be converted into actionable items that apply to your software and problem. You also need to practice them a few times to see results. Lastly, debugging is a great strength for any engineer who wants to rapidly grow in their career. So invest in this essential skill today.

If you enjoyed this article, then hit the ❤️ button. It helps!

If you think someone else will benefit from this, then make sure to 🔁 share this post.

Share

Today we have a guest post by a Director of Engineering, , that will help you find the answer. Over to Anton.

A lot of engineers are promoted based on their coding skills.

While I believe engineering managers must be strong developers with a few years of experience, it has almost no indication of success in a management role.

A short quiz to determine if it’s a good fit for you:

WorkOS: start selling to enterprises with a few lines of code (Sponsor)

WorkOS is a modern identity platform for B2B SaaS. It provides flexible and easy-to-use APIs to ship user management, SSO, SCIM provisioning, and fine-grained authorization in minutes instead of months.

WorkOS powers some of the world's hottest startups, including Perplexity, Vercel, and Webflow.

Get started today

1. Do you like to code?

A LOT: 0 points

I’m a big open-source contributor, writing code is the best part of my job.

Yes: 1 point

I enjoy creating things and solving problems.

Coding is a means to an end: 2 points

There are some tasks I enjoy, but I don’t mind reducing the time I write code.

No: -1 point

I prefer to avoid code if I can, management sounds like a great escape path.

Why is it relevant?

⚠️ When you are promoted to an engineering management role, you’ll code less, no way around it. If you try to squeeze in coding tasks anytime you can, you will neglect important parts of your job. You should be able to let it go.
If you have a small team and enough time, it’s always good to stay technical.

🚫 Why -1: The promotion can’t be an escape from code. You will be an engineering manager - you’ll need to lead engineers, make technical decisions, and influence the technical roadmap. People will have a hard time following a manager who doesn’t care about what they do.

If you don’t care for any of that - that’s ok! Consider the PM career.

Subscribe now

2. How do you deal with focus changes

Very badly: 0 points

Ahh I hate it! It takes me time to get into the zone, and an annoying meeting in the middle of it can ruin my day.

It’s distracting: 1 point

It sucks when people distract me all the time, but I can live with it.

It can be refreshing: 2 points

It’s nice to have a diverse day, I don’t mind doing different things.

I love chasing shiny new things: -1 point

I have severe ADHD and I enjoy every moment of it!

Why is it relevant?

⚠️ Say goodbye to the good old days, where on some days your only meeting was the daily. You’ll have to get used to smaller chunks of focused time, and to being distracted. Part of your job will be to help your people and be available for their needs.
This one is not a mandate from heaven, you can create processes to make it easier for you, like specific availability hours. The more senior the team, the more free time you’ll have. You should definitely avoid being a bottleneck.

🚫 Why -1: engineering is a discipline that requires focus - whether it is for the sake of your people (who can’t be distracted by you every 5 minutes), or for your tasks (technical designs can take even more focus than coding). If you like being active and jumping around, consider a career change (maybe operations?)

3. Do you like talking to people?

It’s a necessary evil: 0 points

COVID was a present from god to me. I prefer working alone from home 100% of the time.

Depends on the people: 1 point

I don’t enjoy meaningless small talk, but I can hold a conversation with smart people.

Mostly: 2 points

I’m not getting tired from 1:1 conversations, and I’m ok with having a lot of active meetings.

Absolutely!: -1 point

The best part of my work is the kitchen-talks! I can talk for hours, it’s so much fun!

Why is it relevant?

⚠️ A lot of engineers are introverts, and that’s fine. Introverts can be amazing managers. The question is how exhausted are you from talking with people. You’ll have many more interactions which you can’t ignore. If you prefer solo work, you might suffer in a manager’s role.

🚫 Why -1: Having a manager who just talks all day is hard. Your employees will still be engineers in heart, even if you might not be… This is not a criticism - you might be a great manager in other disciplines (like sales, product management, marketing).

4. How do you deal with chaos?

I hate it: 0 points

I like to receive my tasks in organized Jira tickets, with clearly defined steps.

I’m ok with it: 1 point

I prefer clear instructions and goals, but I can manage without them if I have to.

I enjoy creating order: 2 points

Some chaos is good. I just need to know the end goal and the reasons for it, and I’ll find a way to get there. I enjoy helping others figure out what needs to be done.

I’m the king of chaos: -1 point

I prefer to work on a day-by-day basis, who knows what the future will bring. Plans are useless.

Why is it relevant?

⚠️ You are used to most of the things being organized for you. Once you become a manager, you will start to notice all the problems in the organization. The VP R&D might bombard you with strange requests, and the PM might change his mind 5 times in a day.

🚫 Why -1: You need to be able to organize that chaos in the context of your team. You cannot be a ‘free spirit’ anymore.

Subscribe for weekly articles on leading a software development team.

Pledge your support

5. Can you be decisive and stand your ground?

No: 0 points

I always struggled with it, it’s easier for me to follow someone in authority.

If I have to: 1 point

I prefer someone else to show me the way, but I’ll not stay quiet when I think they are wrong.

Yes: 2 points

I don’t mind some conflict. Sometimes I’m a bit stubborn, but I make quick decisions and listen to feedback.

I’m like a rock: -1 point

If I know I’m right, you’ll never be able to convince me otherwise.

Why is it relevant?

⚠️ As a fresh engineering manager, you’ll be pushed around. Your manager and PM will have their own agenda. Other managers will try to sneak in tasks for your team. Being able to confront others and stand behind your decisions is critical to inspire confidence in your people.

🚫 Why -1: there will be cases when you are completely right, and you still have to give up. That’s life. If you are very hard to work with, and never willing for others to take the lead, everyone (including you) will suffer.

Understanding the score

<4 points

The engineering management path is not for you - you’ll probably end up suffering (and your team too). Depending on your answers - consider the IC path, or switch to a different discipline (PM/CS/sales/marketing)

4-7 points

It’s a tough decision for you. I suggest to give it a try. Be open with your manager, and monitor how you feel. If after a few months (or a year at most) you still suffer through every day, it’s time for a change. Read ‘Why team leaders give up’, and ‘Why managers have more bad days’ to see what you should expect :)

8-10 points

Go for it. There is never a 100% chance you’ll enjoy the job (it depends on so many variables - your manager, your team, the company itself), but I would bet $100 that you will, with time.

Last words

PLEASE don’t take this test too seriously 🙂 It’s not scientific by any means, it is solely based on my experience and the experience of those around me. The goal of it is to give you some materials for thought, in case you are considering that promotion.

It’s Raviraj again. Thank you, Anton, for sharing the nuances that engineers should consider before becoming managers.

For more articles from Anton, subscribe to the Leading Developers newsletter.

Leading Developers

Join 15,000+ software leaders for free articles that'll help you jump from being a good engineering manager to a great one.

By Anton Zaides

Shoutout

1. The Art of Influence: A Staff Engineer's Playbook by and

2. How I got 27 hours in a week by installing one tool by

3. Why and How to Build Your Personal Brand on LinkedIn by

If you enjoyed this article, then hit the ❤️ button. It helps!

If you think someone else will benefit from this, then make sure to 🔁 share this post.

Share

When you encounter silent disagreements often, critical concerns will surface later, resulting in wasted efforts. That can also get you a lower rating and block your promotion. So, don’t let silent disagreements linger.

It can be hard to identify them early (well, they are silent, so they are hard to detect!). However, there are some signals that you can watch out for that hint at disagreements. Today, I share five signals I look for to spot these hidden concerns before they derail projects and damage team dynamics.

WorkOS: start selling to enterprises with a few lines of code (Sponsor)

WorkOS is a modern identity platform for B2B SaaS. It provides flexible and easy-to-use APIs to ship user management, SSO, SCIM provisioning, and fine-grained authorization in minutes instead of months.

WorkOS powers some of the world's hottest startups, including Perplexity, Vercel, and Webflow.

Get started today

🤐 1. Low Participation

Are the key stakeholders just responding with “okay” and seem disengaged? They are neither asking questions nor vocalizing any disagreement.

This could happen either because they have vague disagreements and are unsure how you would take it or because they haven’t had the time to think it through. Also, some people like to disagree 1:1.

What you should do:

1. Watch out for low engagement, especially if it comes from many stakeholders

2. Create smaller discussion groups where people feel more comfortable speaking up

3. Meet 1:1 and be curious about if they see risks with your proposal

4. Ask specific questions instead of general ones like "Any concerns?"

5. Pay attention to who's quiet, especially if they're typically vocal

Subscribe now

🚶‍♂️2. Verbal Agreement But No Actions

Everyone agrees during planning, but you get to the execution and find a teammate who isn’t acting like they agree. For example, if you proposed a new API as a replacement for the existing one, but you find that a teammate is still adding new features to the existing API even when there is no urgency.

In this example, it is possible that this teammate feels this new API will take a long time to become “reliable.” Until then, they will continue adding features to the existing one. So, while they agree with the proposal, they may not be on board with its timing.

What you should do:

1. Ensure your proposal discusses the execution and its timeline

2. Discuss this proposal's relative priority against other work to ensure you have a shared mental model for prioritization.

3. Set milestones/timelines and get your teammates to sign off

🔄 3. Never Ending “issues”

Every time you are about to make a decision, your teammate finds yet another gotcha that needs to be addressed. While thorough analysis is good, endless concerns can be a sign of deeper disagreement.

Your teammate might be sensing risks they can't fully articulate yet. Or they might have experienced similar failures in the past that make them extra cautious. Sometimes, it's also about broader concerns they're uncomfortable expressing directly – like worries about team dynamics, resource allocation, or political implications. They might find raising technical concerns easier than discussing these sensitive topics.

What you should do

1. Don’t meet with this person once a week; you need multiple brainstorming sessions to wrap up the concerns in a day or two.

2. Help them find more gotchas upfront.

3. Create a structured list of all potential issues and tackle them in focused sessions.

4. Be available to discuss sensitive topics.

5. Set a deadline for raising new concerns to prevent analysis paralysis

🗣️ 4. Complains To Others

You thought your teammates agreed with you, but they seemed less confident about the proposal with others. Your manager or a peer tells you that people are not sold on the proposal. However, from your point of view, there were no disagreements.

This may stem from power dynamics or past experiences. Maybe you shut down their ideas before, and now they fear confronting you.

What you should do

1. Make it safe to disagree by acknowledging and rewarding constructive criticism

2. Address concerns publicly to show you're open to feedback

3. Build trust through consistent follow-through on feedback

⏳ 5. “Let’s Take It Offline”

Multiple discussions and brainstorming sessions culminate with “Let’s take it offline.” Every time you come close to making the hard decisions, the decision-making is deferred. Then, there is no follow-up, and subsequent meeting ends with the same outcome.

This may happen if the stakeholders have seemingly weak reasons to disagree but haven’t taken the time to make their disagreement a cohesive story. It is also possible that they are not the decision-makers and are waiting for someone influential to make the call. Perhaps they don’t see the decision as critical and are deprioritizing it.

What you should do

1. First, agree on the timing of this decision. If this is not the right time, consider postponing the decision-making to a better time.

2. Ask your tech lead or manager if the right decision-makers are in the audience.

3. Give people time to think through things, but set deadlines for follow-ups.

💡 Parting Note

The goal isn't to eliminate all disagreements but to surface them as early as possible. While vocal disagreements may seem uncomfortable, silent ones can be more damaging in the long run.

Confrontation is challenging for many, so it's crucial to create a safe space that encourages open disagreement and facilitates resolution. By fostering an environment where people feel comfortable expressing their concerns, teams can address issues proactively and prevent silent disagreements from derailing projects.

If you enjoyed this article, then hit the ❤️ button. It helps!

If you think someone else will benefit from this, then make sure to 🔁 share this post.

Share

Shoutout

1. 5 Lessons I learned the hard way from 10+ years as a software engineer by and

2. Why Engineers Should Be at the Product Strategy Table ? by and

3. Don’t Become an Engineering Manager by and Suresh Choudhary

You don’t.

Today, I will share a story from early in my career in which I managed to do this, but at a high cost!

Enterprise Ready Conference for B2B Leaders (Sponsor)

The Enterprise Ready Conference is a free, one-day event in SF for product and engineering leaders building enterprise SaaS.

The event features speakers from OpenAI, Vanta, Checkr, Dropbox, and Canva on key topics like advanced identity management, compliance, encryption, logging, and fine-grained authorization—critical features that many enterprises require.

Request an invite

📖 Story

This is a story of a time when I was a junior engineer. I had been on my team for a while and had delivered many features. I also had a reputation for solving “diverse” problems “quickly.”

So, I was tasked to build a complex feature for a different project pod in my broader team.

🤔 Underestimating

While this wasn’t the usual code base I worked on, I was familiar with it, so I knew how to evaluate the feature and build a design. I spent a couple of days and arrived at an estimate of “2 weeks.”

In reality, I kind of forced a “2-week " estimate because that was the sprint cycle. Also, after those two weeks, I had another feature to work on for my main project. I wasn’t honest with myself.

I think you see where this is going!

Subscribe now

📈 Scope increase

Once I started working on the feature, I uncovered a lot of hidden work in the first few days. While I had anticipated some of it, the actual scope was much larger. Things started piling up quickly.

In retrospect, the feature wasn't a quick add-on. It was a massive addition to the product that needed a solid foundation and planning.

🤐 Didn’t communicate

Scope creep is expected, and the right thing to do is communicate that with the team. However, I didn’t tell anyone what I had discovered. I painted a rosy picture in the daily stand-ups by sugar-coating the additional work.

I felt shame in saying, “This needs significantly more time.” Also, I wanted to spend only two weeks on this feature and then get back to my main project.

😴 Personal life impact

I sacrificed sleep and spent two weekends working on the feature. It was exhausting.

Sadly, this wasn't an isolated incident—I often pushed myself like this, though this case was extreme. Such behavior sets unsustainable expectations. If you keep doing it, you'll be expected to maintain this pace long-term, which isn't viable.

🛠️ Quality Impact

Needless to say, I took shortcuts. The test coverage was sub-optimal, didn’t account for anticipated future changes, and ignored all necessary refactors.

This resulted in more code than expected for the reviewers. I essentially ambushed the code reviewer with this large changeset. The senior engineer reviewing it was kind enough to invest the time to meet the deadline. In hindsight, they should have pushed back.

Of course, I left behind a lengthy list of todos. Some of those, perhaps, have still not been done even after a decade. 😛

📉 The Aftermath

We shipped the feature at the end of the sprint. However, 2 months later when other people started building on top it, they found it to be too rigid to make changes. Similarly, testing was hard and there were a few hard to understand code blocks. Also, I had moved on to my main project so wasn't actively working on the aforementioned feature.

When I got a bunch of questions about design quirkiness from the new owners I sensed frustration, and I got defensive. However, at the back of my mind I realized I was wrong and needed to fix my approach going forward.

💡 What should I have done instead?

1. Not be rigid in my “estimate” even before understanding the details of the design.

2. Not feel shame in saying, this can’t be done in 2 weeks but needs more than double the time.

3. Raise awareness of the scope creep the moment I learned it

4. Pause development and do a design review to ensure feedback is taken upfront.

5. Showcase the expanded scope and break it down into sub-projects.

6. Not sacrifice personal time (at least not without raising red flags and discussing it with the team).

7. Be willing to push back my next project to finish the current one with high-quality.

8. Ask for help (and I would have easily gotten it)

9. Take the time to build it right instead of fast i.e making it extensible to accommodate future additions.

I was a junior engineer and didn’t have the maturity to see what I needed to do to level up. I had the technical ability to tackle the problem but my behaviors were wrong. In retrospect, I could have easily set a new timeline based on what I discovered. There was no external pressure to finish the work in “2 weeks”.

Parting Note

The next time you're tempted to cram six weeks' worth of work into two, pause and reflect. Rushing through projects often comes at a steep cost—one you'll regret paying. Remember:

• Be honest with yourself and your team about realistic timelines

• Communicate scope changes promptly

• Don't sacrifice personal time or quality for speed

🎤 Shoutout

1. 3 Career Principles that got me to Director at Google by and

2. Mastering Time Management by a Staff SWE at Meta by and

3. How to use engineering metrics for the success of engineers and teams by

Blabber defensive words? Or make a decision prematurely?

Did you feel like running away from the situation? This is more common than you think. When I feel scared in such situations, I use the BAA framework, which has helped me not succumb to the pressure over the years.

Let’s look at three situations to understand the framework. By the way, they are all situations where I messed up the first time I encountered them. I didn’t follow BAA, i.e., Breath, Assess, and Act. Instead, I followed Act, Assess, and Regret :)

Enterprise Ready Conference for B2B Leaders (Sponsor)

The Enterprise Ready Conference is a free, one-day event in SF for product and engineering leaders building enterprise SaaS.

The event features speakers from OpenAI, Vanta, Checkr, Dropbox, and Canva on key topics like advanced identity management, compliance, encryption, logging, and fine-grained authorization—critical features that many enterprises require.

Request an invite

😳 1. A Grilling Leadership Review

Picture this: You're presenting to leadership, feeling confident. Suddenly, a VP interrogates you with an unexpected question:

“Why aren’t you building Feature X? Why are you focused on Feature Y?”.

A long time back, everyone had agreed that Feature X wasn’t necessary. So, this question stumps you. Gulp. 😳

It's natural to feel your heart racing and palms sweating. You weren’t ready for this from someone with authority.

You feel fear because

1. You don’t want to give a ‘less than ideal’ answer to your VP

2. You wonder if you missed a memo about Feature X

3. You fear saying “NO” to your VP.

What you shouldn’t do

1. Start blabbering and giving non-answers.

2. Make promises (without thinking over) that you will work on Feature X.

What you should do

Breath

Take a deep breath and let the feeling pass. For a moment, forget it’s a person with a big title!

Assess

Ask yourself -

• Do you understand the question and the intent?

• Is there a baked-in assumption in the question that does not align with yours?

  • For example, you assume Feature X is not prioritized, but your VP may have a different assumption.

• Do you hesitate to give a direct response? If so, ask why.

  • Do you assume the answer may make them unhappy?

Act

Don’t let their tone scare you or let your hesitation overpower your response.

In this case, you want to start with a clear answer and share your justification. The justification may be as simple as, “Feature X was deemed unnecessary in the previous review, and Feature Y adds the most value based on the user study”.

You should add, “Do you believe we should consider Feature X again?” This way, you can let them chime in if they have new data points.

The more you practice, the more comfortable you get. VPs appreciate that!

Subscribe now

😱 2. Crazy Outage

Your phone's buzzing like crazy. There's a major outage, and your team can't find the root cause. 😱

A bunch of super senior engineers and managers are waiting for you to fix it! These high expectations in an unknown situation can scare you into - trying random fixes and potentially making things worse.

You feel the fear because you think:

1. You are the team lead, so you are “supposed” to have the answers!

2. If you don’t fix the problem, those super-senior engineers may think you know nothing. So, everyone will know you are an imposter!

Acting rashly will surely hamper your reputation. So, take a moment.

What you should do

Breath

Take a deep breath and spend a minute understanding the symptoms. Let people know you need a minute to gather context. If someone is being pushy, let them know you will respond soon.

Assess

Make a mental note of things you understand vs not. Specifically,

• Do you understand the symptoms and the impact?

• Do you understand the trigger?

• Do you understand potential issues that have been ruled out or the potential theories?

Act

This may be a complex outage with an unclear root cause. Clearly communicate what you know vs. what you don't. Share the potential theories you and your team will validate. If you need help from a specific team, then ask for it. Engineers from other teams want to help, but you must ask for it.

Share regular updates so that they are not left guessing.

🧐 3. Unexpected Critical Feedback

You’ve just wrapped up a project, and expect praise for your leadership. Instead, you hear, "You didn’t communicate well during the project." Suddenly, your confidence takes a hit. 😳

You feel fear because

1. You thought you did well, and now doubt creeps in.

2. You’re worried this might impact your promotion.

What you should not do

1. Reject the feedback right away

2. Accept it without understanding the specifics

What you should do

Breath

Listening to critical feedback is never easy, especially when it comes as a surprise. So, take a moment.

Assess

Ask yourself -

• Do you know if the feedback is true?

• Do you understand the specific instance that this feedback refers to?

• Do you feel uncomfortable talking about this now? If so, why?

  • Is the worry about your promotion scaring you?

Act

Respond with something like, “Oh! This is a surprise, but I want to understand the specifics.” This signals to the feedback giver that you are listening and relaxes them.

Discussing the feedback is the only way to get more details, but do it respectfully. If you need time to reflect on the details, do so before disagreeing.

When we are scared, we forget to think before acting. That results in rash decisions. Practicing BAA will help you deal with high-pressure situations. That will make you a better leader.

If you enjoyed this article, then hit the ❤️ button. It helps!

If you think someone else will benefit from this, then make sure to 🔁 share this post.

Share

Shoutout

1. SWE v/s MLE by and

2. 5 Keys to the Hiring Manager Interview from a Meta Senior Manager by

3. Framework to land $500k+ Software Engineer Job without Leetcoding by

Do any of these sound familiar?

WorkOS: start selling to enterprises with a few lines of code (Sponsor)

WorkOS is a modern identity platform for B2B SaaS. It provides flexible and easy-to-use APIs to ship user management, SSO, SCIM provisioning, and fine-grained authorization in minutes instead of months.

WorkOS powers some of the world's hottest startups, including Perplexity, Vercel, and Webflow.

Get started today

👿 1. Being A Brilliant Jerk

You might be the best coder in the room, but no one will want to work with you if you're condescending. Technical skills may get you far, but soft skills determine how far you’ll go with others.

Watch out for these behaviors:

• Getting annoyed at people asking seemingly naive questions

• Being dismissive when asked to explain your decisions

• Becoming overly pedantic about trivial issues and not giving others independence

I still recall being afraid of someone like this as a junior engineer. So, I care a lot about how I interact with engineers today, irrespective of their knowledge levels.

Subscribe now

🤐 2. Faking Knowledge

We've all been there — pretending to understand something we’re unsure of. We often think admitting "I don't know" is a sign of weakness. But it's quite the opposite.

Remember:

• Use “I don’t know” to stimulate the discussion and not end it.

• If you don’t ask, you will spend hours figuring it out on your own. So ask!

• Make a note of things you say “I don’t know” to repeatedly and learn those in your spare time.

It took me years to feel comfortable saying those words out loud, which was a relief. Read the power of “I don’t know.”

✋ 3. Interrupting Constantly

Cutting people off mid-sentence doesn’t just come across as rude — it shuts down collaboration. It conveys that your ideas are more important than everyone else’s.

Here’s what to do:

• Wait for a natural pause before speaking.

• If you must interject, say, “Sorry to interrupt, but...”

• Jot down your thoughts to avoid blurting them out in the moment.

I had no clue I had this annoying habit until a good manager made me realize it. Read more about it here

🔍 4. Not Investigating on Your Own

Asking questions is great. However, bombarding others with all your questions before attempting to solve them yourself can frustrate your team.

A better approach:

• Spend time trying to figure it out on your own.

• Document your efforts and findings.

• When you ask for help, show what you’ve already tried and provide context.

Take a look at my framework to debug anything.

🤐 5. Disagreeing Silently

Staying silent when you disagree in meetings and then complaining later will frustrate your teammates. Sometimes, the cost of changing things later can be high!

To address this:

• Share your concerns respectfully in the meeting.

• If you’re not comfortable speaking up, follow up offline.

• Asking clarifying questions can also be a great way to highlight where you disagree.

🚫 6. Rejecting Every Feedback

It is easy to reject feedback when it feels “wrong” or “vague”. When you do that for everything, you would come across as defensive or hard to work with. Over time, people will not like working with you.

Do these instead:

• Acknowledge that the feedback could be true to change your mindset

• Reflect on your behaviors to understand how the feedback could be true

• Ask for specific examples and suggestions.

🙅‍♂️ 7. Dismissing Others

Strong opinions are good, but refusing to listen to others is a problem. Note that the goal is to find the best solution, not prove you are right.

How to be mindful:

• Listen to the ideas fully instead of assuming what they are trying to share.

• Ask questions to validate that you understood their suggestion.

• Be open to changing your mind when their ideas are justified.

🏃‍♂️ 8. Rushing Decisions

Making quick decisions without considering all the factors can lead to costly mistakes. When you do it too often, people will lose trust.

To slow down:

• Make a list of factors that might impact the decision.

• Seek input from teammates with different perspectives.

• Consider both short- and long-term implications.

🤝 9. People Pleasing

Trying to please everyone often leads to vague suggestions and mediocre outcomes. They stem from the fact that some engineers don’t want a conflict, so they play it safe. However, in the process, they get labeled as indecisive.

What to do instead:

• Present clear pros and cons for each option.

• Make a recommendation based on what you know. Say if you are unsure.

• When you get the information you need, take a stand.

I could lead effectively only after I grew out of this behavior.

😓 10. Struggling Silently

Struggling in silence doesn’t make you a hero — it makes you inefficient. When you share your struggles, others may realize how complex your project is.

How to improve:

• Set a time limit for struggling alone.

• Be specific when you ask for help and provide context.

• Share what you have already considered and where you are stuck.

🌞 11. Being Too Optimistic

Optimism is great, but being overly optimistic can lead to unrealistic estimates and missed deadlines.

To be more grounded:

• Use data from past projects to inform your estimates.

• Build in buffer time for unexpected issues.

• Be upfront about potential risks or roadblocks.

💔 12. Lacking Customer Empathy

As engineers, sometimes we focus too much on technical challenges and forget what matters most to our customers. Note that our goal is not to build the best technical solution but to build the right solution.

Do this instead:

• Assume good intent when they share their problems

• Empathize with their constraints while solving your problems.

• Understand the business goals.

I hadn't built customer empathy early in my career. Transitioning from that to making frustrated customers happy was a significant level-up for me. Check out how I made this frustrated customer happy.

🌀 13. Setting Up Bad Meetings

Meetings without a clear agenda often lead to confusion, wasted time, and frustration. Without knowing the purpose, attendees can struggle to contribute effectively or prepare relevant input.

Be better with meetings:

• Set a clear purpose. Even open-ended brainstorming meetings should have an expected outcome defined.

• Share pre-read for complex topics that your audience will understand.

• During the meeting, help people stay on topic.

Read more about tips on how to run meetings like a pro.

Remember, most engineers work in a team. Undesirable behaviors can bring the team morale down. So, we need to identify and manage them.

What other “undesirable” traits have you noticed in yourself or others? Share them in the comments!

If you enjoyed this article, then hit the ❤️ button. It helps!

If you think someone else will benefit from this, then make sure to 🔁 share this post.

Share

Sometimes, in the moment, we fail to think critically and just agree to things that seem right superficially. I feel bad when that happens to me and worse when others find faults that I missed 😛. Jokes aside, critical thinking is a disciplined approach to reasoning that anyone can learn. It simply requires diligence and practice.

Today, I am sharing steps that help me think critically most of the time.

WorkOS: start selling to enterprises with a few lines of code (Sponsor)

WorkOS is a modern identity platform for B2B SaaS. It provides flexible and easy-to-use APIs to ship user management, SSO, SCIM provisioning, and fine-grained authorization in minutes instead of months.

WorkOS powers some of the world's hottest startups, including Perplexity, Vercel, and Webflow.

Get started today

To keep the article focused, I am sharing tips on thinking critically when a coworker shares a proposal (to add rate limiting to your service). However, the tips can also be used in other contexts.

🧐 1. Understand What is Being Proposed

First things first: get crystal clear on what the problem and the suggestion are.

Here's how:

• Grasp the elevator pitch: What's the TL;DR version?

• Uplevel, but get specific: Prefer using an example to validate your understanding.

Example:

❌ "We're adding rate limiting to protect the service."

This is too vague and doesn’t help you think critically. Let’s look at a better version:

✅ "The service gets overloaded (CPU/memory/other metrics) by a few clients, affecting others. We propose adding rate limiting to address this."

In this refined version, you know

1. who is causing the issue (specific clients),

2. what is being affected (service performance), and

3. how the proposal aims to solve the problem (rate limiting).

This clarity helps you focus your critical thinking on the right aspects.

Subscribe now

🕵️‍♀️ 2. What’s the REAL problem?

Don’t take the problem at face value, even if it comes from someone you trust. Validate the issue by digging deeper into the data and the backing evidence.

For example, if the proposal suggests that the service is overloaded, you should understand:

• Is the overload system-wide or isolated?

• What do the metrics say? Is there a direct relationship between the rise in traffic and the overload?

• Is the overload proportional to the increase in load, or do we see a very high overload with a marginal increase in traffic?

Example:

The overload issue only appears with a subset of customers using a particular feature. This may suggest that the problem isn’t a general overload but a bottleneck specific to that feature. So, optimizing the feature might be a better solution than rate limiting.

Asking these questions helps you distinguish between the symptoms (overload) and the underlying causes.

🤔 3. SO WHAT?

Once you validate the problem, it’s time to quantify the impact by asking, "So what?" This helps you prioritize the issue and understand its business implications.

Example:

If the proposal says, “When client A overloads the service, it affects other customers,” keep digging deeper by asking, “So what?”

• Many customers saw their requests fail. So what

• Some key customers suffered huge revenue losses. So what

• They will take their business elsewhere if this keeps happening. (Of course, this one was obvious 🙂)

By asking, "So what," you might discover subtle nuances: Some customers are affected more than others.

This helps you decide if: The problem is big enough to need the suggested solution.

🔍 4. Does the Proposal Actually Solve it?

Now that you understand the depth of the problem statement, it’s time to evaluate whether the proposal solves all of those problems.

Ask yourself:

• Does this address the root cause or just the symptoms?

  • For example, rate limiting isn't enough if you find inefficiencies in the service. The proposal also needs to make the service efficient.

• Are there any unintended consequences?

  • For example, if the proposal builds a simple global throttling, it could result in starving high-priority requests from customers that send less traffic.

• Is this a long-term solution or a quick fix?

  • For example, maybe the proposal intends to add rate limiting as a short-term fix, and in the long term, it also makes sense to partition the service for better isolation.

This step is about vetting the proposal’s effectiveness. You ensure it’s not just a band-aid but a comprehensive solution that addresses the immediate problem and potential long-term implications.

😈 5. Play Devil’s Advocate

Even if the proposal looks solid, it’s crucial to challenge your thinking and assumptions. Playing devil’s advocate pushes you to identify risks, weaknesses, and potential failures, ensuring that no blind spots remain.

Challenge your thinking even when the proposal looks sane. Think about:

• What could go wrong? Consider scenarios where this proposal might fail. Are there edge cases that could break the solution?

• What if this solution backfires? Think about worst-case scenarios. Could the fix introduce new problems, like performance bottlenecks or customer dissatisfaction?

• Are there hidden costs? Could this proposal introduce technical debt, maintenance overhead, or unforeseen negative impacts on users?

• Am I being swayed by biases? Are you too trusting of this proposal because of the presenter’s credibility, or does it align too easily with your existing beliefs?

For example, if you’ve advocated rate limiting for a while, you might overlook other solutions, such as optimizing the service or partitioning traffic.

The goal is to test your reasoning and uncover any blind spots or biases. By challenging the proposal from multiple angles, you can ensure you’ve considered all potential risks and haven’t overlooked any critical details.

💪 Parting Note

Think of critical thinking as strength training. Just as you don’t build muscle overnight, sharpening your critical thinking takes time and consistent effort. The more you use this framework, the stronger your decision-making skills become. So keep practicing.

You will miss things along the way, and that’s okay. The key is to identify what you missed using the steps above and improve next time.

If you enjoyed this article, then hit the ❤️ button. It helps!

If you think someone else will benefit from this, then make sure to 🔁 share this post.

Share

Many engineers think presentations are only for managers. So, they don't work on getting better at creating presentations. This makes it hard for them to explain their work clearly to others. As a result, they lose out on leadership opportunities.

I used to have the same problem until someone taught me these tricks that transformed how I approached building & delivering presentations. Over the years, I have also helped other engineers adopt these strategies, so it works!

WorkOS makes selling easy (Sponsor)

With WorkOS you can start selling to enterprises with just a few lines of code. It provides flexible and easy-to-use APIs to ship user management, SSO, SCIM, and other enterprise features in minutes instead of months.

Some of the hottest startups in the world are powered by WorkOS, including Perplexity, Vercel, and Webflow.

Get started today

Let’s dive in.

🏗️ 1. Build The Content First, Slides Last

A common trap: you fire up PowerPoint and start creating slides right away. Suddenly, you're stuck, unsure what to put on the next slide. It is hard to have clarity of thought when distracted trying to make those slides look good.

Instead, it would help if you focused on getting the story right first. When creating content, I scribble down the details as if I were verbally explaining the topic to my audience. Then, I restructure those raw notes into an outline.

Think of it like building a house. You must have a blueprint before you lay down the bricks.

🎯 2. Build a Specific Message

Many years ago, I was tasked with giving an all-hands presentation about a new project. However, once I started creating slides, I struggled to create content. My framing was pretty generic — talk about project X. I was stuck because I didn’t address key questions like — Talk about what? Why should people care? What aspects should I focus on more?

My director helped me reframe the presentation to a specific problem we had encountered in the project. So I went from “talk about project X” to “talk about how this new component could not run in environment X and how we solved it.”

Ask the following questions to frame your talk better:

• What specific problem is this presentation solving?

• Why is this worth talking about now?

• What is the takeaway for the audience?

• Why should the audience care?

Subscribe now

👥 3. Know Your Audience

The same topic can be presented in N ways depending on who you are presenting to. One size does not fit all!

When I present to my team vs. leadership vs. in an all-hands, the audience will have different backgrounds and levels of interest.

For example, a presentation to leadership should focus on high-level strategy and ROI. For a team of engineers, it can deep dive into the technical specifics.

A common mistake is when we present to a diverse group of people, we make one slide for person A and others for person B, C, etc. This can be jarring for everyone. Instead, pick a person representing the critical mass as the target audience. For example, if I present a technical topic to 100s of people in an org, I would think of one person we don’t regularly work with who would be interested in listening.

✂️ 4. Keep it Simple!

It can be tempting to create fancy presentations and out-of-the-world animations. However, congested slides can add to your audience’s cognitive load, and they may lose interest. This is true for documents and articles too. So, I strive to keep this cognitive load low for all my articles even when I don’t have great content.

Tips that always work for me:

• Avoid crowding the slides and leave a lot of white space.

• Keep a uniform appearance/font for all your slides.

• Use less busy themes that keep the focus on the content.

📝 5. One Slide, One Message

This was one of the best advice I got!

Previously, when I was unstructured in creating my presentations, I would cram in a lot of details on a single slide.

For example, a single slide that shared the API design, SLAs, and bottlenecks. The audience had to work harder to remember all of it. Instead, breaking them into individual slides lets the audience absorb the API design details before a deep dive into the bottlenecks or the SLAs.

Note that you don’t always need new slides to follow this rule. You could animate your architectural diagram or your bullet points to give a perception of one slide, one message.

Think of each slide as a billboard on a highway. The message should be that one thing you want the audience to remember.

🎤 6. Delivery Matters

Even the best content can fall flat with poor delivery. Think about the last time you dozed off in a presentation:

• Was the presenter reading off the slides?

• Did they have a monotonous tone throughout?

• Were they using complex sentences that made it hard to follow?

Perhaps, it seemed like they just didn’t care. When that happens, it is hard for the audience to stay engaged.

Here are some tricks I use to keep my audience engaged:

• Vary my tone to emphasize the important stuff.

• Short and simpler sentences.

• A positive body language that shows I am interested in the topic.

• A joke if I can pull it off.

• Slow down the pace when explaining complex ideas.

🕒 7. Practice!

Don't wing it! Even the most seasoned speakers rehearse. It helps understand how long the presentation takes, weak areas that don’t flow well, and gain confidence.

For the important ones, record yourself practicing. It might feel awkward, but you'll catch things you never noticed before. Are you using too many filler words? Is your posture showing confidence? Is your tone monotonous?

If you find out you are going over time, cut down the content instead of speeding up.

If you are nervous about forgetting things, note some index words in your speaker notes to help you remember the flow. If you still forget during the talk, don’t panic. Pause for a bit and refer to those notes.

🎬 Parting Note

Figure out the message you want to deliver to your target audience and build the right story before building your slides. Slides are just a visual aid to tell that story. Don’t fall into the trap of creating shiny slides that don’t tell the right story. That will put the audience to sleep. 🙂

Shoutouts

1. Big Tech vs. Mid Tech: Which One’s Right for You? by &

2. Latest Innovations in Recommendation systems with LLMs by

3. The 3 Big Mistakes That Almost Cost Me My Promotion by &

Some of you have me asked how I create the images on my newsletter. I had taken this course that taught me how to explain ideas visually. (Discount code - RA10)

If you enjoyed this article, then hit the ❤️ button. It helps!

If you think someone else will benefit from this, then make sure to 🔁 share this post.

Share

Staff Engineers are overpaid & expensive, so replacing them with four fresh grads seems smart.

Don’t hire new grads! They need a lot of coaching.

Relax! I don’t believe either of those. Today’s article is a fun post to explore what different leveled engineers bring to the table.

To dive into this, let’s say we have two hypothetical teams:

1. Team A, with 2 Staff Engineers

2. Team B, with 8 college grads

Then, examine how they would perform across the following dimensions.

Also, let’s assume they are average Staff Engineers & average college grads to eliminate any rockstar biases.

Subscribe now

💰 Business decisions

While both Team A & B would figure out what the core business requirements are, Team A will take it a few steps deeper to

1. Validate the requirements and understand why they are needed.

2. Figure hidden requirements instead of discovering them later

3. Prioritize the requirements based on their value.

Sometimes, Staff Engineers are notorious for analyzing a little too much, which results in a slower start. That won’t happen with Team B.

👥 Team Structure

For a team to function smoothly, engineers must take on various auxiliary roles(in addition to coding), such as lightweight program management, sharing updates with management, and running discussions with customers.

Staff Engineers on Team A will know how to handle tricky situations and play the required roles as the situation demands. For examples,

• When reliability is bad, Team A may introduce a lockdown to improve it.

• When the customer is upset, Team A will know how to mitigate their concerns.

• When the leadership is unhappy with progress, Team A will provide a good justification.

Also, Staff Engineers on Team A can complement each other without stepping on the other’s toes.

Team B won’t introduce unnecessary processes, which can be great for faster iterations (sometimes).

⚡Speed

Team B has more manpower, and sometimes, that is necessary.

• When building something new, Team B may be able to add features faster. (assuming they are already ramped up on the tech)

• When I was a new grad, I was hungry to learn new things. That attitude can bring a lot of positive energy to the team.

• The Staff Engineers on Team A may also have other responsibilities in their org, which means less time for their core projects.

Team A will be able to use their experience to avoid common pitfalls, which will make them faster in the long run.

🌟 Quality of work

Senior+ Engineers have seen the downsides of taking shortcuts, so they uphold best practices within the team. So, Team B will discover many rough edges in their work over time. Some examples,

• Parts of the codebase may need to be rewritten as new features get added.

• Performance issues will surface in production instead of development.

• They may struggle to choose the right frameworks/APIs/tech-stack, which will result in churn later.

While Team A may have better code quality, it will accumulate tech debt due to shortage of engineers.

🔦 Mentorship

Team B should be able to help each other with tactical questions, but they will struggle to find support with strategic questions.

• Team B engineers may get competitive with each other for similar opportunities.

• They will have little opportunity to learn from others’ mistakes, so they will make many new ones.

Over time, as Team A won’t have new grads, they will grow impatient with ramping up and mentoring junior engineers.

Parting Note

Teams need to be balanced. We need a healthy mix of Staff, Senior, and junior engineers for high-quality work and solid team health. Each of them has specific strengths and weaknesses. Depending on the kind of problem being solved and the project stage, the exact number of junior & senior engineers will change.

In a future article, I will share how I structured teams for different projects throughout the project life cycles.

Announcement

I am traveling outside the US with my 18 month old, so my schedule has been off and will likely remain that way for the month. Thanks for reading today! You can read my older articles here,

Also, check out other awesome newsletters

1. by

2. by

3. by

4. by

5. by

If you enjoyed this article, then hit the ❤️ button. It helps!

If you think someone else will benefit from this, then make sure to 🔁 share this post.

Share

One common reason for this is that people are afraid to pick something vague where success isn’t guaranteed. They give up too soon.

99% of people let this fear take control and miss out on opportunities. I am no exception, either. While I have learned to manage it, I still succumb to it sometimes. Today, I will share how you can manage and use this fear to your advantage.

Subscribe now

🤔 Why?

Fear of the unknown stems from the fear of failure. We tend to focus on how difficult that thing is, worry about potential negative outcomes, and let our imagination run wild with worst-case scenarios.

Fear of failure was ingrained in me early on as I focused on always getting the best grades. That carried on into adult life as well. I would worry about:

• What will people think of me if I fail?

• Will I lose my job?

• What if I'm not as smart or capable as everyone thinks?

These thoughts can paralyze us from taking risks and exploring the “unknown.” But here's the truth: the unknowns are hard for everyone. Only when we tackle those can we grow.

🛠️ How to overcome it

Most often, this fear is an involuntary response. It is the classic flight or fight response on seeing a challenging problem.

What helps me is:

1. Labeling the feeling and acknowledging that this is transient.

2. Reminding myself of past successes where I overcame similar fears.

3. Breaking down the problem into achievable milestones that boosts confidence

This approach helps overcome the initial hesitation and instills a sense of accomplishment as I progress, one step at a time.

Real-world scenarios and how I managed my fears:

1. This new project needs a complex ramp-up, and I don’t have time.” So, you give up.

• Labeling: I incorrectly assume that ramp-up will take a long time!

• Reminding: I recollect the past occurrences where I expected something to take days, but it took just a few hours.

• Breaking down: Let me spend a few hours building the sample program and then create a prototype. That will boost self-confidence.

2. Fear sharing your design document broadly

• Labeling: I worry that people will spot obvious gaps in my document. So, “I need to find all of them before others do!”

• Reminding: “I have felt this way before, but it was unwarranted. So, am I overthinking again?”

• Breaking down: Instead of broadcasting it, let me get early feedback from someone and see how that goes.

3. Don’t want to sign up to be the primary point-of-contact(poc) for the project

• Labeling: What if there is a setback in the project? I don’t feel comfortable explaining our failures to leadership

• Reminding: Being accountable for previous projects helped me grow and learn from my mistakes. So this is a great opportunity.

• Breaking down: I can be the poc and don’t need to know everything. When I need help, I can seek it from others.

💪 How to use this fear

When you spot a bear while hiking, you should be afraid. It would be foolish to fight the bear! Fear will keep you sharp and make you tread carefully.

I love how the right amount of fear keeps me grounded. Once I get over the mental hurdle of tacking on a complex problem, I use fear to:

1. Identify the potential roadblocks and build a plan to tackle them.

2. Stay vigilant and thorough in my approach.

3. Be realistic about what I can accomplish in a limited time.

4. Learn what I don’t know.

5. Seek help from others who have done this before.

Parting Note

The next time you get afraid, remember two things:

• You have tackled fear before, and you can do it again.

• If not, remember how someone else built the idea you gave up on. 🙂

Shoutout

1. The #1 new engineering managers mistake by

2. How to influence with data as a software engineer by

3. The biggest-ever global outage: lessons for software engineers by

If you enjoyed this article, then hit the ❤️ button. It helps!

If you think someone else will benefit from this, then make sure to 🔁 share this post.

Share

For that reason, I collaborated with Gourav this week. He has graciously agreed to share his struggles and journey, which is truly inspirational. 

For more from Gourav, follow him on LinkedIn & subscribe to his newsletter, The Curious Soul's Corner.

Over to Gourav.

I never thought I would drive a Mercedes ever in my life.

I couldn’t even dream of owning a home 🏠 in the USA.

And today having achieved all that, I am considering retiring early after meeting my FIRE number.

This transformation wasn’t easy. In childhood, my family faced severe financial hardships. I lost my father in my teenage years, and debts surrounded my family. Uncertainties about life's basic necessities left me anxious. I would wake up with a pounding heart and sweat. 

Upon entering the corporate world, I found myself underpaid, struggling to meet my expenses. Balancing a full-time job, a side hustle, and continuous rounds of interviews meant sacrificing social gatherings, leisure, and sleep for years until I finally triumphed.🏆

My hard work got me a high-paying job in software engineering at Big Tech, which changed my life forever.

👋 Hello! This is Gourav, a Staff Software Engineer at Hubspot. In today's article, I will share what kept me going during tough times and helped me achieve growth. I hope that can inspire the budding engineers who are struggling right now.

Subscribe now

📉 Financial Struggles

Coming from a lower middle-class Indian household, we used to live paycheck to paycheck.

My father worked tirelessly to make ends meet. However, he kept taking on debt to pay for a business venture that didn't succeed as planned. This placed immense pressure on our family's finances, and I vividly remember the stress and uncertainty that filled our home.

Tragically, just 20 days before my 12th-grade finals, when I was 17, my father passed away. His sudden death left us not only grieving but also grappling with the harsh reality of mounting debts and financial instability.

I wanted to attend college and get an Engineering degree, but I couldn’t afford it. Obtaining a loan was difficult due to lack of assets as collateral. A friend of my father's came to the rescue and helped me secure a loan.

🫶 Support and Motivation

My older brother stepped up and took on family responsibilities. He left his passion for photography and took on a job in media to pay for my college supplemental expenses. He met with failures in his job, got laid off, and had to hop into multiple small jobs to meet the ends. His struggles and sacrifices taught me invaluable lessons about resilience and determination.

During college, I was fortunate to have my girlfriend (now my loving wife) by my side. She believed and motivated me to take bold steps. She trusted in me and firmly believed I would succeed and achieve great things one day. 

My mom’s blessings were incredibly powerful. Her prayers and encouragement always felt like a guiding light. During my toughest moments, when I felt overwhelmed and would break down in tears, she offered comfort and reassurance. Her unwavering support gave me the confidence to believe in my dreams and keep moving forward.

💼 Initial Job and Hustle

My first software engineering job in India was with a consulting firm that paid me very little — just enough to cover my rent and food. Whatever remained, I used to settle debts and provide groceries and household essentials for my mom. I soon realized that this job wouldn't alleviate my financial burdens and obligations, and it would take me years to pay off the debt. 

I started a side hustle preparing and delivering Food Boxes in the evenings 🥘. This involved shopping for groceries, cooking, packing meals into boxes, and delivering them across the city on my bike.

Using Facebook for marketing, I began receiving 20-50 orders daily. However, scaling up the business posed challenges requiring hiring a skilled cook and additional staff. Even if I had taken on more debt to expand, with a 50% net profit rate, achieving around 200 guaranteed daily orders would have been necessary to match the annual compensation at a Big Tech company. 

I wanted a more stable and predictable income stream and wanted to eliminate debt rather than take on more.

My passion for software engineering motivated me to succeed, but managing this hustle consumed much of my time. I juggled long hours at the office, followed by rushing home to fulfill orders. After whatever time I was left with, I used to prepare for Big Tech Interviews at night, sleeping very little.

Managing it was difficult, so I had to end my side hustle. I doubled down preparing for interviews and started interviewing with Amazon, Google, Adobe, SAP Labs, and many other companies. 

📈 Career Growth

All that hard work paid off when I made a leap to Amazon India as a Software Development Engineer early in my career. This move increased my salary 6x and marked a significant turning point.

Within the next two years, I managed to pay off all my debts. 🎉

The sense of freedom I felt was indescribable! 🌟

I saw pride in my mom’s eyes and her newfound lightness of spirit.

My brother, too, experienced a big relief as if a heavy weight had been lifted off his shoulders. 

My family was no longer burdened by the constant worry that had shadowed our lives.

As I progressed further in my career, thanks to Amazon, I relocated to Seattle, USA 🌍, where my compensation skyrocketed 🚀to 130 times what I earned in my first job in India. This financial leap was truly life-changing. With my debts settled, I didn’t know what to do with this much money. I began investing in equities and upskilling myself.

I doubled down on my engineering skills, solved complex business problems, and led multiple projects with an extreme ownership mindset. This dedication earned the trust of industry leaders and propelled my career growth. 

• Within the next 5 years, I received two promotions. ⚡

• In a total of 8 years of experience, I became a Staff Software Engineer.🌈

I connected with like-minded professionals and industry leaders, further elevating my career. I changed companies and now earn over half a million dollars annually. 

This is not a brag; I aim to inspire others facing similar challenges. 

🌟 Helping Others

During my professional struggles, I found limited support, which inspired me to help others break through barriers in the tech industry. I am committed to sharing my knowledge and mentoring those looking to overcome life's challenges and pursue lucrative careers in software engineering, aiming for both high salaries and financial stability.

I find joy in helping these individuals navigate both their career paths and life's challenges. 

• Throughout my journey, I have referred numerous friends and colleagues to opportunities across various companies and have mentored over 50 individuals. 

• Today, I run a newsletter called 'The Curious Soul's Corner,' where I share weekly stories and insights on becoming a leader in the software engineering field. 

• I also post meaningful and relatable content on LinkedIn. I aim to help others accelerate their growth, find fulfillment in their careers, and achieve work-life harmony.

The Curious Soul's Corner

Join hundreds of peeps discovering Actionable Insights in under 8 minutes: Become a Leader in Tech Career, and an Effective Human balancing Financial Growth, Relationships & Mindfulness.

By Gourav Khanijoe

Key Learnings

🏋️‍♀️ Resilience and Hard Work

• Losing my father and taking on responsibilities at a young age taught me resilience.

• Balancing interview preparation and side hustles with work made me value hard work and persistence. These qualities are invaluable in the software engineering field, where challenges are constant.

💻 Continuous Learning

• The learning never stops. Embracing this mindset has helped me stay ahead in my career.

• The field is always evolving, and staying updated with the latest technologies and methodologies is crucial.

💸 Financial Literacy

• Understanding finances was a game-changer. Learning about paying off debts, switching to high-paying jobs, and then saving and investing has provided me with a sense of security and future planning.

🫰Closing Note

To all the aspiring software engineers and professionals facing their struggles, remember that your persistence and hard work will pave the way for a brighter future. Let my story be a testament to what is possible when you refuse to give up.

As a parting note, I would like to leave you with these words of wisdom from Winston Churchill:

"Success is not final, failure is not fatal: It is the courage to continue that counts."

It’s Raviraj again! If you enjoyed this article, then hit the ❤️ button and follow .

If you think someone else will benefit from this, then make sure to 🔁 share this post.

Share

Shoutout

1. How to have a top performing, healthy and active day as an engineer or a manager by

2. 5 Writing Tips to Overcome the Blank Page 5 Writing Tips to Overcome the Blank Page by

3. Know Who to Take Advice From by

It almost feels like they have memorized the entire codebase. While it seems like magic, it is not. You can do it, too.

Note: Memorizing the codebase does not mean you remember everything line by line. It is about doing these five things:

🌐 1. Know the APIs

Memorize your team’s API surface/workflows. In fact, you should be very familiar with those and not need to refer to the documentation.

Here is what I do:

1. Make a list of the prioritized scenarios.

2. Use the API / product like my customer.

3. Run those scenarios under a debugger and add log lines to understand which code path is being executed.

4. Tests can shed light on nuanced behaviors, so understand & run them.

5. Fix bugs in different areas(very helpful!).

I have seen some engineers who have been on a team for a while but still do not know key areas. So, when a major issue strikes, they rely on others to resolve it.

Subscribe now

📑 2. Document & understand the core “flow”

Next, I understand how the code is organized. While there is no alternative to actually reading the code in depth, there are some tricks:

1. know which source files are important vs. which are not.

2. know the lines to focus on vs. skim through

I start by deep-diving into one workflow in code search and under the debugger. Next, I document the classes/files, starting from the API surface layer and working my way through all the dependencies.

• Key classes to know are API handlers, caching layers, database interactions, etc.

• Classes to skim through are the simple utilities, logging helpers, etc.

Note that memorizing the code is not a one-day job. I learn something new every time I look at it, so I keep live notes.

Here is a sample version of my high-level notes:

🕵️ 3. Read older “issues”

Memorizing code is not just about what is visible in it but also about knowing system constraints, bottlenecks, and the sources of repeated problems. Reading about past issues is a great way to learn about these issues.

Here are key things I look for in the past issues

1. How did the system behave with bad inputs?

2. Overload incidents highlight bottlenecks and how the system deals with it.

3. How did the team handle the past issues, and which issues/areas still need attention?

4. Issues that repeat and why

5. How annoyed do critical customers get when our team has issues

🧵 4. Threading model

I have dealt with many production issues, and quite a few were caused by race conditions.

The key to solving those was memorizing the threading model in my head.

Examples of things I try to learn:

1. Can the request threads be blocked in any circumstances?

2. Do the key states get accessed/updated from different threads? Does it have the right locking mechanism?

3. Do the long-running stuff run on their thread pool? Can they be resource-intensive?

4. Were there past issues due to deadlocks or blocked threads?

5. How does the request thread use the cache, and does another thread invalidate the cache?

I document the different kinds of thread pools and their responsibilities, i.e., states they update, code they run, i/o operations, etc.

🔥 5. The crazy stuff

Every codebase has few code blocks that are extremely complex, even with a giant comment section.

Knowing these can make you:

• Effective when esoteric issues strike. It will reduce debugging time as you can connect the dots faster than others.

• good at identifying gotchas with new design proposals

• A great mentor who can help others navigate the complex codebase

I keep a log of such stuff and add to it whenever I encounter such code blocks.

Parting Note

Memorizing the codebase is an important skill for every engineer, especially tech leads. It does not mean you remember things line by line, but you must know the core scenarios, system constraints, and other code nuances.

Don’t expect to learn everything in a day and retain it forever. It is a continuous process. So, keep live notes and spend quality time learning this regularly.

🎤 Shoutout

1. Managing up: 3 things I wish I realized sooner by Jordan Cutler

2. Product Thinking by

3. Prioritize your Tasks Effectively by

If you enjoyed this article, then hit the ❤️ button. It helps!

If you think someone else will benefit from this, then make sure to 🔁 share this post.

Share

I used to face this a lot and still do sometimes. I would get impulsive in conversations and respond with something completely unrelated.

Today, I will share three reasons why I fall into this trap and what I do to avoid them.

Subscribe now

🚫 1. Cutting people off

I had this terrible habit of completing people's thoughts for them. I would even rush to respond before they finished asking their question. It happened because

• I was immature and more focused on sharing my thoughts than being interested in what others had to share.

• I hadn’t yet gotten the feedback that I didn’t listen.

Of course, I ended up answering the wrong question.

How I manage it

• Active listening: I focus on what the other person has to share. I block my train of thought as much as I can. That allows me to understand what they are saying.

• Mindful pausing: I pause one breath after the other person has finished asking their question. This intentional break ensures that I do not cut them off.

💭 2. Biased by my thoughts

During conversations, I would zone out into my thoughts. For example, when discussing a design proposal, I might think about why solution Y is difficult. If I got asked why we chose solution X, I would talk about the difficulty of solution Y even when the other didn’t bring it up. This was the hardest one to manage, and I still struggle with it.

How I manage it

• Repeating the question: In addition to active listening, I would repeat the question out loud. That helps me decouple any biasing thoughts and focus on the real question.

• Understanding their intent: Clarifying the question and knowing why they ask helps me provide a more accurate and relevant response.

🛡️ 3. Defending prematurely

Certain trigger statements may catch me off guard and evoke a strong emotional response. This can make me defensive even when they don’t mean bad. I would go on a tangent in such situations, upsetting the other person.

How I manage it

• Deep breath: When I feel defensive, I take a deep breath and find my inner peace.

• Assume good intent: Not all engineers are great at expressing disagreement. So, when someone makes a triggering statement, I try to find out their underlying point and ask clarifying questions.

Parting Note

Failing to get to the point isn't just about misunderstanding the question; it's often about how we process and respond to what we're asked. By listening fully, avoiding assumptions, and managing defensiveness, you can improve your communication and ensure your responses are on point.

Like any other skill, this takes practice. Let me know how these tips work for you.

🎤 Shoutout

1. My process for writing this newsletter by

2. When is the Right Time to Quit? by

3. How I plan my week as a Senior Engineer in Big Tech by

If you enjoyed this article, then hit the ❤️ button. It helps!

If you think someone else will benefit from this, then make sure to 🔁 share this post.

Share

1. Says yes to all upper-management requests.

2. Agree with every pushback from the team.

3. Can’t make decisions independently or always make the wrong ones.

Such leaders always try to please everyone but end up upsetting everyone in the long run. Luckily, I have worked with someone like that. While it wasn’t pleasant, it taught me things I should not do.

Today, I share tips that can help you not be that leader!

Subscribe now

⏳ 1. Don’t Rush to Decide

Imagine you decide to do X in a rush when the right answer is Y. People will get upset and lose trust if this becomes a pattern. That isn’t good for a leader. Watch out for the following:

Feeling the pressure to decide?

Some leaders feel they must know everything and make decisions because they are the “leader.” Amateur leaders often succumb to this pressure.

Your job is to support the team, but sometimes you need to seek help from others. Do that!

Don’t have all the information right now?

Take a moment to think through the request. If you are unsure about the trade-offs or the depth of the request, say, “Let me get back to you in X hours/days.” There is no shame in acknowledging that you don’t have the necessary information right now.

Are you not the decision maker?

Don’t decide for someone else. If you do, you will upset the decision-maker and the stakeholder. When you realize a situation needs someone else, delegate it to the right person or involve them in this discussion.

🗣️ 2. Give Clear Feedback

Unless you communicate what you expect from your upper management, team members, and partners, they will do what they think is right. As a leader, it is your job to align all of them for the smooth functioning of your team. Do the following:

With the team

• It is your job to shield your team from external noise. If there are unjustified requests or churns, absorb/transform them for your team.

• Don’t go overboard shielding, though. For example, if your partner team is upset with your team’s reliability, you need to tell your team or let them hear it directly. That way, they will understand why you are pushing for reliability projects.

With upper management

• If a deadline is aggressive, speak up and manage expectations.

• If management has an incomplete picture, then help bridge that gap. For example, if management needs visibility into how busy the team is, provide that. That can help you get more headcount.

With partner teams

• Hold them accountable if they slip their promises. Highlight how that has a cascading effect on your projects.

• If their decisions will cause your team any harm, surface it to them.

⚔️ 3. Don’t Fear Conflicts

Trust me, nobody likes a YES man. It may seem great initially and feel like you connect with folks, but no one will trust your advice in the long run.

When you take up leadership, stop living in the constant fear of upsetting others. Disagreements become a norm and think of them as tools to enable and encourage critical thinking.

Start with questions

Ask clarifying questions to understand their reasons if you hesitate to challenge them.

Articulate your disagreement

Be very clear that you don’t agree with their proposal. Don’t just slide it into conversations.

Also, share what worries you and what your suggestion is. A common mistake is not sharing the full picture when you disagree. That keeps people guessing and results in arguments.

Be approachable

Resolving conflicts can take time, depending on the root cause of the disagreement. Be patient and debate the problem and not the people involved. This mindset will enable you to find an optimal solution, and others will appreciate your leadership.

📄 Parting Note

Lead with decisiveness, clarity, and courage. Embrace challenges, communicate openly, and never fear conflict. This is the path to true leadership. Doing so will earn trust, inspire your team, and drive lasting success.

Have you encountered a weak leader before? I would love to know how you handled the situation. Please share your thoughts in the comments.

🎤 Shoutout

1. From Liberal Arts Major To Amazon Principal Engineer: Steve Huynh by &

2. How to get promoted: Lessons from an ex-Amazon VP by &

3. How to Succeed as a Machine Learning Engineer by

If you enjoyed this article, then hit the ❤️ button. It helps!

If you think someone else will benefit from this, then make sure to 🔁 share this post.

Share

• someone questions a complex decision that shouldn't be questioned again?

• a new manager forces you to change direction

If so, you're not alone. I know how frustrating it can be to reconsider past decisions, especially when you've put a lot of time and effort into making the original decision.

Today, I will share how you can manage such situations and defend your decisions, assuming they were reviewed & accepted at that time.

Subscribe now

⚡️ 1. Watch your initial reaction

When someone new challenges past decisions, it is natural to feel uncomfortable and dismiss their concerns. I am not proud of it, but I have done it too. I used to think:

• you are trivializing the problem

• you don’t realize the nuances you are missing, so don’t jump to changing the decisions here.

Some people are not good at asking clarifying questions, so they sound like they are proposing a decision change. In such cases, I change the framing of their statement and ask - are you asking:

• Why are we doing X instead of Y?

• What factors did we consider, and did we evaluate the trade-offs?

The timing of the question may be wrong, but don’t be rude. Let them know that you will follow up later. For example, you are dealing with an incident, and someone asks an unrelated question at the moment. (Caveat: sometimes, those seemingly unrelated questions could matter)

🔄 2. Should you resolve this?

If you two cannot resolve the disagreement quickly, then you have two ways to proceed:

1. Resolving the disagreement is important. Do this.

• If this is a new team member or a stakeholder who believes the decision needs to change.

• If the original decision was made with partial information and is pending re-evaluation.

2. Resolving the disagreement is not worth the time/effort.

• If they are not stakeholders, they are missing too much context and are unlikely to influence the direction.

• If the cost of the wrong decision is low or easy to pivot in the future.

🕵️‍♂️ 3. Root cause

Complex disagreements stem from situations that have no easy answers. So, to find the root cause of the disagreement, you need to look at non-obvious places. Some dimensions to consider:

Weighing options differently?

Let’s say the problem has two subproblems—A and B. Someone who feels problem A is bigger may choose a different solution than the one who thinks B is bigger. You and that person may not realize this is the reason you disagree. You might defend your own solutions but not realize the reasons for disagreement.

Different past experience

Our past projects influence how we perceive new projects. So, someone who has done large-scale migrations before will err on the side of avoiding them. Conversely, someone tired of the current system’s problems may want to migrate away.

Risk-taking appetite

Let’s say your team is balancing a thin line between adding new customer features and improving reliability. The rush to add them can make things unstable, which in turn can affect customer relations. There may be no easy answer here.

What is an acceptable level of unreliability? Will you lose a customer because you can’t deliver the requested feature? Do you need more customers when you can’t handle the existing ones?

You and your team need to have an honest discussion about the balance. Set acceptable reliability thresholds upfront and use those to pivot over time.

⚖️ 4. (Re)Decide

Now that the two of you understand where you disagree, you must decide. Common dimensions to consider so that the (re-) decision is not wrong:

Ideal vs Practical

Ideally, your software should have no bugs and not fail under any overload. You should fix those gaps. But what if you have 100s of gaps? You don’t have the time to fix all of them!

That means you must prioritize what you will build real fixes for vs. where you will build “hacks.”

Sunken-fallacy syndrome

We have already spent months doing this, we can’t stop now. But are you ok doing this for another year(s)?

If your decision isn’t producing a good outcome, stop and pivot! There is no shame in stopping a project when it isn’t the right solution.

Not accounting for all factors.

What seems like the “right” technical solution on paper may not account for operational load, cost of change, and customer requirements. So, when you re-decide, don’t make the decision in isolation.

Also, if the change in decision has a marginal change in the outcome but has a huge cost, stick to the prevailing decision.

📄 5. Document to avoid future churn

While this debate is fresh, document it. That way, when the question comes up again, you just point people to it. Note, don’t just document the decision but capture the journey of the decision. Include:

1. How did you evaluate the trade-offs and the thesis behind the decision?

2. Capture the summary of any analysis/data used to decide.

3. Capture notes likes - which problem was weighed more, FAQs challenging the decision, etc.

4. How much instability is acceptable during rollout?

5. If the decision should be re-evaluated in the future, then when & after which milestone?

Parting Note

It is natural to get annoyed when complex decisions are challenged after a long time. Watch out for your reaction, and don’t be dismissive. Some disagreements are worth solving and require an intentional effort to resolve. Lastly, keeping an open mind will help you find better solutions.

🎤 Shoutout

1. Communicate like a Senior: Phrases used by the best leaders by

2. How to keep up with all the digital content by

3. The Sweet Spot Between Too Much and Too Little by

If you enjoyed this article, then hit the ❤️ button. It helps!

If you think someone else will benefit from this, then make sure to 🔁 share this post.

Share

❓Figure out WHY you want to write

The journey to writing online can be long and hard if you want to increase your readership. So, you need a solid motivation. If it is a whim, then it won’t last long.

My reasons when I started writing

• I have played a TL role for 7 years and mentored many engineers to grow into a TL role. So, I had a lot to share and wanted to explore writing during my paternity break last year.

• Get better & faster at writing.

• Get 1K active subscribers to feel good.

My reason now

• I see Techlead Mentor becoming a brand. While I don’t have any near-term plans for it, I see it as an enabler for bigger things in the long term.

So, find your reasons and remind yourself of those when things seem hard.

Subscribe now

Back to actionable tips that will help you grow sooner.

🎯 1. Pick one audience

Cater your first 20 articles to one audience. It can be tempting to write about LLMs first, then interview tips, and then leadership. When you flip-flop between topics, your audience will flip-flop, too. I found that writing about similar topics helps build a loyal audience.

Know what differentiates you and stick to those topics. For example,

• if you grew quickly in tech, then share your journey

• if you are a fast/persistent learner, then share when you learn new things

• if you switched job profiles (lawyer to software engineer), share what that was like.

My audience is people who want to hear a Staff engineer at FANG share his leadership experience and actionable tips for their growth.

🎨 2. Initial topic corpus

When I started writing, I outlined my 12+ year career and annotated the ups & downs. I also relived the key situations where I mentored others through their difficulties. Soon, I found a list of repeated problems that formed my topic corpus. Examples

• How I got vague feedback OR how one of my mentees got vague feedback

• Struggles I saw every upcoming TL encounter

• How convincing some stakeholders was hard and why

• My difficulties with writing good documents

• Interesting stories that taught me valuable lessons

Keeping it close to my experience saved me time researching the topics.

💡 3. Add value

Nobody likes reading a 1000+ word article that doesn’t

• Tell an interesting/inspiring/captivating story OR

• Teach something difficult OR

• Give actionable tips for relatable problems.

So, when you plan an article be very clear about - what problem you are solving with your article and the benefit to the reader. For example, for my articles

• 5 mistakes that made my document terrible: the value was a framework that helps engineers write good documents.

• My career story from Intern to Staff: the value was sharing an inspiring story that most aspiring Staff Engineers can learn from

📋 4. Topic backlog management

Having a healthy topic backlog gives me confidence that I can keep writing. I have a master list of topic ideas. Whenever I get an idea I jot it down in this list.

Topic ideas are vague and notoriously deceptive. It isn’t clear whether the topic is a good article unless I expand on it. So, periodically, I do the following for each unexplored topic idea.

1. Write the article's core message and a five-bullet point version. (raw bullet points only)

2. If I realize a topic has more hidden topics, I will add those to the master list.

   1. For example, when I considered writing “poor communication blocking promotion,” I realized I should write articles on improving written, verbal, and nonverbal communication.

3. Put current favorites on the calendar for upcoming weeks.

🕰️ 5. Cadence

Don’t exhaust all your articles in a short span of time. I used to write 2 articles a week in my first month. It wasn’t sustainable in the long run. You should balance the following:

1. Your work-life balance overall

2. Quality of writing

3. Do you still have enough to keep writing for the next 6 months?

Like many, I found writing one article a week to be sustainable for a long time. However, due to recent life events, I have been contemplating a more relaxed cadence.

So, find what works for you and stick to it.

🌐 6. Newsletter website

Where to host?

When I started, I chose Substack without much thought. However, I love the decision because:

1. It is a platform with a network and the recommendation system helped boost my growth.

2. Provides options to customize my layout.

3. Reasonable metrics for my usage.

If you don’t have a preference, just go with Substack. However, don’t try to host your website when you start. Driving traffic to it will be harder.

Aesthetics

• Pick a newsletter name that describes what you write about.

  • Eg: , , , etc.

• Add an “about” page that introduces what you write about.

• Add a logo so that people recognize your brand.

• I picked a custom domain to give it more credibility.

• Include your top articles in your intro email when a new subscriber joins.

🖊️ 7. Writing process

Writing can feel hard when you first start. The biggest mistake I made was not setting a deadline for an article. I would spend hours just sitting with a topic and then feel agitated when I made no progress. Over time, I realized I needed to block a contiguous chunk of time (2 hours is great) to have a productive writing session.

What I do when I start to write an article:

1. Identify the person I am writing the article for.

   1. For example, this article is for one of the many budding creators who have asked me for tips.

2. Play out a conversation in my mind where I share tips with this person.

3. I take raw notes of that conversation.

4. Create an article outline.

5. Using the notes and the outline, I write a fresh article.

If the draft doesn’t look good, I will archive the current version and repeat steps 4 & 5. A fresh reattempt can do wonders instead of trying to fix the earlier draft.

🎣 8. Good hook

A hook is an opening to your article that should grab and hold the reader’s attention. This includes the title and the first paragraph. The reader will decide in the first few seconds if they should continue or not.

Title

A good title should tell the reader what they will get and if this article is for them. Some good examples,

• How I read books with limited time: This is targeting folks who are struggling to read many books, and the title promises that it will share valuable hacks.

• 5 Mistakes That Made My Documents Terrible: Most engineers find it hard to produce good documents, so the title promises to share 5 of those mistakes and implies that it will share actionable tips to avoid them.

The Intro

The first paragraph should get straight to the point. Look at the first paragraph of this article. It tells you who this article is for and what will be covered. Additionally, it tells you why you should listen to me.

A common mistake here is to beat around the bush or provide too much context. A bad intro would have been to talk about the newsletters, go into the background of Substack, share top newsletters, or engage in other distractions.

✍️ 9. Quality writing

Write direct and simple.

A common misconception is that using flowery language and fancy quotes will make you sound smart. However, readers just want to get value, and they want to get it with the least cognitive load.

Use the Hemingway app to gauge how simple your articles are to read. You should try to target grade-6 readability.

Optimal layout for readability

• Highlight important words/sentences in bold.

• Use shorter paragraphs

• Use bullet points wherever applicable

Images

Each article of mine includes at least one image. I create my own pictures instead of using stock images. I think personalized pictures give more authenticity to your articles, and the audience appreciates the effort.

🤝 10. Networking

Like it or not, networking is important to building an audience. Your audience won’t magically show up. The typical way in which it works is:

people you know like & share → people they know like & share

If one of them is a big creator, it can have a multiplicative effect. So, building up your network is important, as it increases the likelihood of your articles being shared broadly.

How?

• Build a real connection with other creators in your domain.

• Add valuable comments to their LinkedIn posts and Substack. This can kick off meaningful conversations and put you on their radar.

  • Pro tip: don’t do this for the sake of it, as it will put you in a bad light.

• Send a private message introducing who you are and what you write about. If you loved any of their articles, then let them know. You can even seek feedback for your writing if they have time.

As an introvert, I avoided doing this for a long time. Luckily, reached out to me, and asked me about my struggles and interests. That was pivotal to my growth. After that, I messaged many creators and built real connections with some of them.

👥 11. Collaborations

The key to networking was selfless collaboration. I genuinely supported fellow creators in their endeavors, helping review articles or courses or bringing more eyes to their efforts. I still do whenever I can without expecting anything in return.

Over time, I got opportunities to partner with other creators on various things that boosted my growth. Especially, I cherish the following collaborations:

• With on a joint article and our long discussions solving world problems 🙂

• With on publishing my career story

• With on What is a Staff Engineer

I love that I can do the same for budding writers now. Re: Collaborating on ’s career story

Recommendations

• It may be easier to collaborate with creators who are in a similar place as you in the journey. If you contact for a collab, that may not work out.

• Do a guest post if there is a mutual benefit. You can approach a creator with topic ideas.

• If you are not camera shy, start a podcast with fellow creators. That will boost your visibility.

📤 12. Share your articles

Growth happens when you get new subscribers. So, you need to post your articles at places where new people can read them. Things that I do:

1. Share my articles on LinkedIn with a sneak peek.

   1. Pro tip: Use short URLs to track the click-through rate. I use short.io for this, as it is free.

2. Share on Reddit. Note: Reddit can be mean sometimes, but if something goes viral, it can attract many new subscribers.

   1. A couple of my articles went viral there and got me 100+

3. I tried Hacker News and Twitter for a bit but gave up because they didn’t give me good results.

🚀 13. Invest in your growth

Just like any skill, you need to hone it to get better. Here are the things I did:

• Read books that improved my writing. I would recommend:

  • The Art and Business of Online Writing

  • Smart brevity: The Power of Saying More with Less

• Experimented with my writing style to see what resonated with my audience.

  • Over time, I realized my “How to” articles with personal examples got a great reception.

• Took a course on image creation that helped me create quality images

• I pay for Grammarly premium to make inline corrections, which saves a lot of time.

• I analyzed better creators around me and saw what they were doing well to take inspiration on quality writing.

Parting Note

Starting as a social media recluse and getting to where I am took a lot of smart and hard work. The process needed patience, resilience, and never-ending hustle. Most importantly, it wouldn’t have been possible without the support and mentoring I got from fellow creators. So, this article is my way of giving back to the community.

Let me know if you have any questions or want to write a guest post on my newsletter.

If you enjoyed this article, then hit the ❤️ button. It helps!

If you think someone else will benefit from this, then make sure to 🔁 share this post.

Share

For more from Akash, follow him on LinkedIn and subscribe to his newsletter, .

Over to Akash now!

Hey! This is Akash, a Staff Engineer at Apple. I work in Apple AIML, keeping our promises to protect your privacy and trust. I completed my Master’s at USC and worked at companies of different sizes before joining Apple. My most recent role was at Google, where I was the TL for the Chrome Infra team.

I have also worked as a founding engineer at an early start-up. Both worlds had a lot to teach, but Google was where I experienced the most growth. Going into Google, I was determined to leave an impact. In my 3.5-year tenure, I got the highest rating twice.

Today, I will share my growth journey and strategies that helped me grow as an engineer fast. I hope my experience can help you navigate the changing demands and accelerate your career growth.

The story is divided into four parts as follows:

• 💻 Onboard at Google: Finding my way at Big Tech

• 🌟 Struggles to “Superb”: Taking ownership and being visible

• 🌱  IC to Lead: Growing as a leader

• 🚂 Journey to “Transformative Impact”: Balancing support and feedback

Subscribe now

💻 Onboard at Google (Feb 2020)

Before Google, I worked at 3 companies: 

1. Perfit, an early-stage startup that we started in the USC incubator 

2. Credit Karma, a unicorn startup where fast delivery was crucial

3. Proofpoint, a mid-size enterprise with agile development practices 

Google was my first Big Tech job. 

Onboarding was very different and filled with feelings of being undeserving. The vastness of everything was intimidating. Despite having a well-documented starter project, I felt clueless. Everyone around me had it all figured out, and my imposter syndrome peaked.

Making the transition from a start-up into Big Tech, I found:

• The vastness of systems, codebases, and existing processes felt like drinking from a firehose

  • For example, the code base our team worked on was over a million lines of code

• Less work from the ground up, solutions existed for most problems, and we were pushing it from 99.9% to 99.99%

  • This is where problems become much harder to solve, and understanding the existing systems becomes crucial.

• Predefined guidelines and opinionated standards that everyone must follow

  • Requirements for code coverage and internal language-specific style guides were the reasons why my first code change took ten rounds of back-and-forth

In the next few weeks, I dove deep to build a mental map of the systems we owned. My mentor also helped me understand these complex systems better. We’d spend almost 5 hours every week on:

• Code walkthroughs: This helped me understand the codebase and patterns. I learned:

  • Where to look for particular codebase

  • How different modules interacted with each other

  • Where to go when I couldn’t figure out what’s going on

• System breakdowns: Whiteboard sessions with component deep dives helped me understand past decisions.

• Random Q/As: Whenever I got stuck, I asked ad-hoc questions.

Takeaways

• Onboarding is hard. The transition from a start-up to a large company can seem overwhelming. There are no shortcuts. The key is to invest in building a solid foundation and be willing to learn.

• Build your support system, and find an onboarding mentor. My first mentor at Google joined six months before I did. So, his recent onboarding experience was relatable.

🌟 Struggles to My First “Highest” Rating (Apr 2020 - Apr 2021)

My team was brand new - just me and my manager! I spent a month or two on onboarding and making slow progress on the project. I had to write a detailed design document and somehow managed to write one. Expectedly, I was told:

“Your design is hard to read, important details are hidden”

Luckily, my manager empathized with me and provided great resources to learn the skill. I spent the next week scouring through “perfect” designs to learn the structure. After a few rounds, I finally got a thumbs-up, and the new version was well received.

By this time, I had delivered a major milestone. Also, we grew to 5 people, and I was already becoming the “senior”. I was influencing the direction and starting to help others onboard. 

After multiple discussions with senior leaders, it was clear that we had only covered ~3-5% of the underlying problem. I stepped up and worked with my manager to draft a roadmap for our team. Our goal was to address the company-wide highest priorities and solve them within Chrome. This drove close partnerships with core engineering groups from other parts of the company.

The project I laid out was planned to be delivered over the next 3-5 years. By the end, the goal was to make Chrome’s build process repeatable, reliable, and secure. This project involved working across multiple organizations, touching 2000+ developers internally and externally.

Leadership bought into the plan that outlined the goals for 3 years. It involved two big priorities (read more at the Chrome blog).

I successfully onboarded other team members on the project. We achieved our first-year milestone in just six months, which helped me build credibility across the organization. Org leaders started trusting me as someone who’d not drop the ball. That’s how I got my first highest rating at Google, Superb (top 1% of ratings).

I also received feedback for writing one of the best design documents. Another peer reviewer mentioned, “Akash has too many things on his plate; I don’t know if it’s sustainable.” My manager interpreted this feedback as a testament to my hard work.

Takeaways

• Impact: Focus on impact, and growth will follow. Solve what’s important for your team, organization, and company.

• Visibility: Leading strategy discussions and getting buy-ins from senior leadership is a great way to be recognized.

🌱  Transition from IC to Lead (May 2021 - Sep 2021)

I wanted to rush to the Staff (L6) level, but soon learned it’s a different job altogether.

Everything was great until I took a “productivity hit”. Transitioning from high-volume coding to primarily building strategy was hard. Without the lines of change or number of code changes, it became difficult to measure what I did.

I wish someone had told me this sooner. Many first-time TLs experience this issue. The advice was to be patient. I was busy all day but still picked up two community projects, promising my “20%” time outside my team.

Those projects helped me feel productive and compensated for the lack of "code" in my team.

Takeaways

• Transitioning to a leadership role is hard for everyone. You might not feel productive in the beginning. In time, you will learn your work is different. Your impact is delivered through others.

• Be patient. I wish I listened to my mentors when they said this. I found my way into leadership by contributing elsewhere. You don’t have to. You’ll recognize increased impact if you increase the time horizon in your thinking.

🚂 Journey to My Second “Highest” Rating (Oct 2021 - Mar 2023)

While I learned to measure my leadership contribution to feel productive, I had a lot of work to do to build the right leadership traits. For example, I was always obsessed with delivery and speed. I expected the same from others. I said yes to everything, and that drove the team towards burnout. Additionally, I was struggling to find the balance between micromanaging and being too nice.

While I asked for many status updates, I didn’t question folks when they missed deadlines multiple times. I hated confrontation. But avoiding it resulted in missed targets. It was clear that the team's output depended on my leadership ability. So, I started digging deeper and asking direct questions. For example,

• “Are you blocked on anything?”

• “Do you feel stuck, can I help or take a look?”

• “Shall I escalate this with the partner team to get you unblocked?”

I remember if it weren't for feedback, my design docs would’ve sucked for a long time. So, I needed to do the same with my team. At first, I struggled to deliver direct feedback. To improve, I took a course in Leadership Principles from Harvard Business School. It helped me build a toolkit for how I led.

• Self-awareness: It changed how I communicated feedback and made it actionable (read this article for my detailed learnings)

• Being authentic: I started sharing my concerns when we didn’t make expected progress. It establishes trust and delivers feedback much easily.

By the end of 2021, I found my new leadership style. In early 2023, our team delivered a comprehensive system to secure build pipelines. Outside Borg, this was the first large-scale secure build system at Google. It was a company-wide priority, and our team was able to deliver it first. 

That’s what got me my second “highest” rating at Google. This time, it was “Transformative Impact (T),” which replaced “Superb” in the new scale. Then, I quit my job at Google in the second half of 2023, but that’s for another time. 🙂

Takeaways

• Don’t hide constructive feedback. You’re doing more harm than good. Balancing feedback with support is vital for every leader.

• Remember, what you say as a leader has impacted others’ lives beyond imagination. Open communication and transparency are important, but be aware of how you are perceived.

What Matters?

This story by no means paints the whole picture. I tried to highlight the most significant points but made many other mistakes. My ratings make it easy to mistake me for a perfect engineer. If you learn from your mistakes, it doesn’t reflect in your performance. 

As a parting note, I’d like to share three pieces of wisdom,

• Never get comfortable: In my journey, I moved through levels fast. I never felt I had all the skills, which pushed me to always get better.

• Be trustworthy: I always went the extra mile to ensure I didn’t drop things. It helped me build credibility with leadership. I was able to become the face of the team or work stream. It was instrumental in growing my visibility.

• It’s never too early to invest in Soft Skills: Earlier in my career, I thought, “If I can be technically strong, I’d get recognition”. I couldn’t be more wrong. My growth journey took off after I invested in communication.

It’s Raviraj again! I hope you enjoyed reading Akash’s journey and found it relatable. I did.

If you have any questions for him, then leave them in the comments below. If you think others will benefit from it, then share!

To read more from Akash, subscribe to his newsletter.

Leadership Letters

Actionable tips to grow as the most effective leader everyone wants to work with in <10 mins per week.

By Akash Mukherjee

Share

As software engineers, we take pride in our ability to write great code but ignore the importance of good communication. But, what exactly is bad communication and why does it matter?

Today, I will share common situations where miscommunication easily occurs and provide tips to prevent it.

Subscribe now

1. Slipping a deadline?

Did you uncover a major surprise with your project that will delay the project? Will the delay upset a customer or other stakeholders?

• Let’s say you tell your team lead once. But, you don’t explain the severity of the surprise. Maybe they don’t realize this setback impacts other high-priority deliverables. Nobody is alarmed yet.

• Weeks later, things escalate, and people realize this surprise is a major blocker. You get dinged for not sounding an alarm when you first learned of the problem.

Recommendation

• Don’t hide the key message with convoluted words. Say, “We uncovered a major performance bottleneck with the design, blocking XYZ milestone”.

• Have a discussion instead of just declaring the status. That way, others can identify what else gets impacted.

• Don’t wait long. If you are unsure about the impact, say so. Your team lead can help you clarify things.

2. Disagree with a design?

Did someone present a proposal with hidden gotchas that can make the product unstable? If you stay quiet, the flawed design may get implemented. That would mean you and your team must deal with the repercussions.

Recommendation

• Stop hesitating to give feedback. Read more about how to avoid hesitation here.

• Phrasing your concerns as questions is a great way to keep it constructive.

• Discuss it 1:1 if you worry about hurting them.

3. Your project estimates are off?

Your product manager requests that you deliver project X in 3 weeks.

• You say, “That is too aggressive, and it will take two months.” When they push back, you push back harder, leaving them unheard.

• Maybe they want parts of project X done in 3 weeks but don’t know how to describe what they want. By being blunt, you shut any room for discussion.

When this pattern repeats, you get feedback that you are “slow” or that your estimates are off.

Recommendation

• Understand the business requirements so that you make a well-rounded decision.

• Explaining why things take time is a part of your job. Break down your project into milestones and explain how some of those milestones are expensive.

• If you can deliver partial goals sooner, propose that as an alternative.

4. Misalignment on project scope?

Have you ever found yourself deep into a project, only to realize that your understanding of the scope differed from your stakeholders'? This disconnect leads to frustration, wasted effort, and subpar outcomes.

Recommendation

• Write down the project plan and explicitly capture what is in scope & out of scope.

• Get it reviewed by the opinionated folks early on.

• If the scope changes, then broadcast that to the stakeholders.

5. Your manager thinks your work is easy.

You delivered an amazing feature that required a lot of effort. However, nobody understands the project's difficulty, so you get feedback saying, “You should take on more work.”

Recommendation

• Don’t think that talking about your work is bragging. If you don’t, no one else will.

• Share continuous project updates that include the ups and downs.

• Give a tech talk and explain the challenges encountered so people can see the depth of your work transparently.

Parting Note

I regret investing too late to improve my communication skills. I don’t want you to repeat my mistakes. So, I encourage you to read more about improving your:

1. Written communication

2. Verbal communication

3. Non-verbal communication

If you enjoyed this article, then hit the ❤️ button. It helps!

If you think someone else will benefit from this, then make sure to 🔁 share this post.

Share

For example, I neither write about productivity nor have I coached people to be more productive. So, when I decided to write an article on how I find “focus” and be “productive”, I perceived the problem to be extremely difficult. I considered giving up.

Fortunately, I beat those thoughts and avoided procrastinating on this one, and have an article for you.

I followed these three steps:

Subscribe now

🚫 1. Block distractions for 30 minutes

Try the following to get in the “zone” to solve your problems:

1. Introspect things that can cause distraction. Knowing those helps block those.

2. Pick a time when you are energetic and not when you are already tired.

3. Choose to scribble or type things instead of just ‘thinking’.

4. Have a timer and focus on the problem until the timer runs out.

5. Keep those distractions away for at least 30 minutes until creativity kicks in.

Examples that distract me these days,

• Worrying if my contractor will finish the renovation on time can spiral in my head. OR

• Acting on other “important” problems is a classic guilt-free way to procrastinate. OR

• Notifications on my phone.

Here is what I did for writing this article

• I chose to start only when I didn’t feel tired.

• I picked a quiet corner of my house and kept my phone away.

• Had my text editor on full screen to minimize distractions.

• Every time I got distracted I yelled the article's name out loud.

The first 10 minutes were hard but distractions died down over time.

🔍 2. Break it down into simpler problems

Don’t tackle the giant monolith

New problems seem harder when we see them as a giant monolith. We tend to focus on the scary parts and find N reasons to avoid solving them.

In this case, when I started with the high-level goal, ‘write 5 actionable steps to avoid procrastination’, it made things worse. I over-indexed on writing the article instead of going deep into the topic.

Identify what scares you

This was the first time I was writing about productivity. So, I was afraid of coming across as fake.

Find similar experiences

I have written other articles out of my comfort zone before. So, I looked at those to recall the journey and the outcome. That helped me with two things:

1. Tricking my brain to think it was achievable

2. How to define a simpler goal.

For the newsletter, I created these simpler goals

1. Make a list of past situations when I procrastinated and how I managed them.

   1. That helped me focus on what I already knew instead of obsessing over the article.

2. Draw parallels between those experiences and what I was facing while writing this article

3. Later, check to see if I have an article to share.

   1. That helped me postpone the difficult part of the problem until I had more information and a writing mindset.

An engineering example, is when I need to refactor a huge codebase: I fear the number of files, tests, frameworks, etc. that would have to be updated. Then I worry about the time I need to spend. That can scare me from taking the first step. My hack is to curb those thoughts and focus on fewer changes at a time.

🏃‍♂️ 3. Don’t stop when you just get started

It is hard to get my brain primed to solve hard problems. But, once I am past the initial hurdle the worst thing I can do is stop. That means I have to get over the hurdle again.

Think through the harder parts now

Building focus can be hard, so don't break it. This is the best time to tackle the hardest parts of the problem. Convert that 30-minute focus time into an hour or two session as the minor setbacks won’t demotivate you while you have momentum.

Pause after an “accomplishment”

Some problems are too large to be solved in a single session. Also for various reasons, you need to pause your session and return later. If possible, take that break after you hit some “milestone”. That leaves a good feeling for when you come back.

Serialize your thoughts

Capture detailed notes. In addition to the technical details, also capture

• How you felt about the problem at first and how you feel now

• Challenges that remain and how you perceive them

• Notes for the future you who may procrastinate

These help me with continuity and reduce the chances of procrastination.

Parting Note

Building focus for a hard problem can be a challenge for me. Involuntarily, I had been following these aforementioned steps to get in the “zone”. So, I hope it helps those of you who, like me, get scared by the perceived difficulty of the problem.

Focus is a very personal thing so this article may not resonate with all. So, please share what works for you in the comments.

While my family continues to deal with the loss of a loved one, my writing schedule will remain erratic. Thanks for your continued readership.

Hit the ❤️ button if the article resonates with you.

Share

“I didn’t code enough”, “Leadership doesn’t get it!”, “Why can’t we get all requirements upfront?”, etc.

I fell into the same trap and have seen many aspiring tech leads, that I mentored, do the same. Today, I am sharing those common pitfalls that new leaders encounter so that you can avoid them.

Subscribe now

🚧 1. Frustrated with Distractions

Depending on where you are in your project life cycle, expect different kinds of distractions. Examples,

• When new requirements come up, you need to evaluate & prioritize them. This may need ad-hoc discussions with stakeholders.

• When critical issues surface closer to deadlines, you must help the team find a way forward.

You have to make time for these. That is your job! If you stay busy with mundane things and don’t handle these urgent & important things then you have failed as a tech lead.

I have noticed newer tech leads feel guilty of not “coding” as much as they used to. So, they try to take on these distractions AND still code for 40 hours a week. That tires them out.

What works for me is, that during critical times, I will take the less important P0s myself. That way, I can punt them in favor of the distractions. After years of “tech leading”, I know which distractions to expect and which ones bother me. I watch out for early signs of those.

📅 2. Not Valuing Project Management

If your team does not have dedicated program managers then you are it. For large projects, you need to break them down into milestones and figure out the dependencies. Read more about how to manage long-term projects.

Your job is beyond the basics like:

• Ensuring tasks for upcoming milestones are getting done

• Identifying delays and helping people get unblocked

• Building progress reports

You also need to

• Understand the reasons when things are blocked

• Maybe give suggestions/feedback to a teammate if they are slow

• Manage expectations with stakeholders

Some new tech leads will expect everyone in the team to be equally “motivated and self-manage their work. They get frustrated when others don’t seem equally diligent with “project management”.

🤷‍♂️ 3. Expecting to Know Everything

Nobody knows “everything” and Tech leads are no exception. Problems occur when Tech leads don’t accept this. They begin hiding their lack of knowledge and either try to “learn” everything on the side OR make decisions with half-knowledge.

Read more about how embracing “I don’t know” can be a game changer.

As a tech lead, you should have a reasonable working knowledge of different parts of your system. However, you have to rely on “experts” for specialized areas. Redirect the specialized questions to those experts.

Also don’t feel pressured to decide in the moment if you don’t have the background.

• Saying “I don’t know the details. Let me get back to you” is a great way to not make hasty wrong decisions.

A delayed decision is better than a rushed bad one.

💬 4. Under-valuing Communication Skills

Your job is no longer just writing code. The sooner you accept it, the better it is for your growth as a tech lead. Your role also requires you to:

• Share ideas with others and build alignment

  • I hadn’t invested in communicating effectively.

  • That meant, I wrote & rewrote my documents and got frustrated with the process. Read my tricks to write well.

• Foster a healthy team culture

  • Watch out what you are saying with your body language.

  • Do you ‘roll your eyes’ when you hear bad ideas or do you ‘not appreciate the team’ on accomplishment?

  • Your body language can make people feel “small”. Read more about how to improve your non-verbal communication.

• Give honest feedback.

  • I used to hesitate to give feedback and sugarcoat the message. That left others with vague feedback.

  • Read how to not hesitate to give feedback.

🔝 5. Not Managing up

Leadership may want your team to deliver faster or have another “unreasonable” ask. Your job is to highlight the steam’s challenges and explain the constraints to leadership. Failing to do so can result in two outcomes:

• You force your team to overwork and then they hate you and leave.

• The team fails to deliver and leadership loses trust in you.

The harder part is identifying when the leadership has “concerns” but hasn’t asked you yet. You manage these by

• Sharing frequent status updates for the project

• Broadcasting your accomplishments & failures(and what you learned).

• Proactively, asking leadership about their concerns

Parting Note

Few people are naturally born leaders; most of us learn leadership skills over time.

So it is natural for engineers who step into a leadership role, to make these mistakes during their transition. However, recognizing these behaviors and taking corrective action is the first step toward effective leadership.

🎤 Shoutouts

1. Read by if you are interested in LLMs

2. Most micromanagers are blind to being seen as one by

3. Dealing with Impostor Syndrome in the Engineering World by

Hit the ❤️ button. You may think, what difference would that make?

It tells me you found it insightful else I have no way of knowing. Also, make sure to 🔁 share this post if others will benefit from it.

Share