This time, even Software Engineers.

Yes, the prestigious ones who once felt secure in the past while other roles were eliminated due to macroeconomic conditions.

But what about those who’ve grown comfortable vibe coding with Copilot, Claude, or Cursor?

It’s good that they’ve adapted—but that’s no longer going to be enough.

Well, you still need someone to write long-term Software Vision. Roadmaps. Strategy docs. Right..?

Well, AGI has that covered too. The AI context windows are becoming practically infinite.

Hmmmm….Leaner teams? The new normal.

Layoffs…?

Well, unless you've been living under a rock, it's already happening. Here's what leaders at top companies are saying and doing:

Harsh... right?

Here’s the thing: It’s not new. Every technological revolution reshapes the job landscape.

Software engineering roles won’t vanish entirely.

But only a few archetypes will rise to the top.

That raises the next question:

When it's time to chop off the puff—

What decides if you're "for here or to go"?

Or put another way—

What are the archetypes that will survive?

👋 Hey there, I am Gourav. I write about Engineering, Thought Leadership, Human Psychology and the Mysteries of the mind!

Today, I am sharing an article in ‘Tech, AI & Leadership’ section of this newsletter.

It’s my prediction there are three archetypes of Software Engineers who will survive.

Archetype 1: Intraprenuers

Let’s understand these engineers via a true story about Mike (named changed to maintain anonymity):

A long time ago, I worked with Mike, a Product Manager at my former company.

Brilliant at his job. He wasn’t just obsessed with customers and products—he was obsessed with how engineers coded.

He had a software engineering background but had moved into product management.

Empathetic. Visionary. Business-minded. But...

He was limited by engineers because he hadn't coded in years.

He'd ping engineers daily:

"Can we build this?"
"How much effort?"
"When can we ship?"

Engineers would scramble, estimate weeks, and deliver slowly.

He grew impatient.

With his engineering background, he understood concepts enough to dive into the codebase himself. He would question estimates, perform QA testing, and fix smaller bugs.

Crazy, right?

We joked:

“Mike could replace half of us—if only he knew coding better.”

Over time, he actually sharpened his technical skills and turned out to became a “Technical Product Owner”—a role specifically created for him.

Fast forward to today.

I truly believe people like Mike have a higher chance of thriving in the AI era.

As a leader, if given a choice between:

• Someone who only codes,

• Or someone who deeply understands customers, identifies problems, pitches solutions, rapidly prototypes, and leverages AI to build—

I’d always pick the latter.

Companies often assign prestigious labels to such people.

Some call them “those who think like owners.”

Others refer to them as the “CTO of their small teams.”

And some call them Intrapreneurs — “entrepreneurs within the company”. covered this topic well in her latest article in The Pragmatic Engineer. (Must read!)

These folks talk to customers, challenge the status quo, and understand that there’s a human on the other end of the product.

They possess strong interpersonal skills and deep empathy for their teammates and customers.

They bring in the deals. They create business.

They are the real leaders.

Archetype 2: AI Checkers

This type is relatively easier to understand.

They validate whether AI is doing its job well—similar to how senior engineers review the work of junior engineers. I simply call this archetype the AI Checkers.

These are exceptional Software Engineers who specialize in niche domains.

Think Infrastructure Architects.

Cybersecurity Networking Engineers.

Data Engineering and Security Experts.

Don’t get me wrong—AI will eventually make inroads here too.

But these areas are often deeply tied to company-specific systems and practices.

That’s exactly where human specialists will step in—to oversee how AI agents operate and identify when they fall short or go off track, and course correct.

Archetype 3: AI Builders

This one is even easier to grasp, especially if you’ve been following what’s happening in the industry right now.

I call this final archetype the AI Builders.

These are the engineers building the foundation of the AI era.

They train large models, fine-tune them post-deployment, and stitch together multi-agent workflows that resemble mini-AI companies.

They don’t just adapt to AI tools—they build them.

They don’t just automate tasks—they create the automation.

These engineers will not only become essential—they’ll become elite.

The top 0.1%.

Highest paid. Most in-demand. Courted by everyone.

Meta, for example, is already poaching OpenAI engineers with multi-million packages.

Companies are forming entire divisions just to attract and retain these folks.

Closing Thoughts

You’ll need to fall into one of these three archetypes to stay relevant in this new era.

Now is the time to reflect.

Figure out what aligns with your strengths, passion, lifestyle, and personal goals.

Do you enjoy building things from scratch? You might be a future AI Builder.

Do you love working with customers and solving business problems? You might be an Intrapreneur.

Do you have deep expertise in systems or infra? You could thrive as an AI Checker.

There’s no one-size-fits-all answer here. But there is a path for those willing to adapt.

What exactly should you start doing today?

That’s a whole article in itself—and maybe, just maybe, I’ll write that next.

🤝 Let’s Connect

Sponsorship | Collaboration | LinkedIn | 1:1 Mentoring | Twitter

Gourav Khanijoe

Today’s article features a special guest, , Engineering Director at Taranis and the author of the Leading Developers newsletter, a must-read for engineering managers and team leaders. His content offers sharp, actionable strategies for leading dev teams.

Without further ado, I’ll pass the mic 🎤 to Anton 👏

"Honey, what have you done? My father wants to kill you!”

😨

I never knew my tendency to refactor stuff would get me in so much trouble…

Let’s back up a little.

Yes, I promise this relates to the software world.

Back in February, my wife's parents invited us to their home for 2 weeks. We had a 3-month-old baby (our first), and we appreciated the invitation.

The help was amazing - we finally had some free time, slept well, and ate great food!

Near the end, I decided I wanted to pay back the kindness. On a Saturday morning, they all went out, and I had a great idea.

The house has a huge yard, which was a complete mess:

• Piles of garbage

• Fallen leaves everywhere

• Abandoned tools in random places

• Old and rusty buckets getting in the way

Her mom always complained about how messy it was, so I thought my idea was GENIUS!

I cleaned up everything - I organized the tools on the shelves, collected all the fallen leaves, and threw away the garbage and the old buckets. The result was something like 5 huge bags full of trash!

I took a shower and went for what I thought was a very well-deserved nap.

Imagine my surprise, when I woke up to my wife saying: “Honey, what did do? My father wants to kill you!”

You get where this is going, right?

• Turns out that although I cleaned up some real garbage, I also threw away

  the compost corner my father-in-law started a few weeks ago.

• In addition, the leaky buckets were placed under strategic places where the gutters overflowed during heavy rains, and they distributed the water in a better way.

• And worst of all, my mother-in-law was very happy, and kept saying: “Look what a great job Anton did! You should learn from him!”

🤦‍♂️🤦‍♂️🤦‍♂️🤦‍♂️🤦‍♂️

And one more:

🤦‍♂️

But enough about my in-laws, let’s go back to tech.

Why do developers always want to refactor?

How often did you hear from someone in your team: “This repo is in terrible shape, we must refactor it!”.

I’m working at a 10-year-old startup, so there is no shortage of old repositories and obsolete code lying around.

I agreed with most complaints, and that’s what I usually did: if we needed to do substantial work in a certain place, I factored in ‘tidying it up’ in the estimation.

Until one day, the ‘this-repo-is-in-terrible-shape-and-I-can’t-understand-anything’ complaint was directed at a codebase that I wrote myself 2 years ago! It was covered with UnitTests, well documented, and still highly used!

I was confused. Was I a worse programmer than I thought? After consulting with some people from other teams, and asking them to go over that code, I concluded that it’s not my fault (this time).

Since the dawn of time, developers always wanted to re-write things.

Joel Spolsky wrote in his great 25-year-old article:

Programmers always want to throw away the code and start over - as they think the old code is a mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code is a mess is because of a fundamental law of programming:

It’s harder to read code than to write it.

This is why code reuse is so hard. This is why everybody on your team has a different function they like to use for splitting strings into arrays of strings. They write their own function because it’s easier and more fun than figuring out how the old function works.

You can ask almost any programmer today about the code they are working on. “It’s a big hairy mess,” they will tell you. “I’d like nothing better than to throw it out and start over.”

This was written in 2000(!), and I find it fascinating it’s still true. It can cause an endless cycle - if a code I wrote mere 2 years ago is already considered ‘legacy’, who will guarantee that the new code will be better?

From the same article:

It’s important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time. You’re just going to make most of the old mistakes again, and introduce some new problems that weren’t in the original version.

The concept is best explained by the famous illustration by Manu Cornet (there are many more great comics on his website!):

Old code is the best code

Jumping back to my father-in-law’s backyard story (I swear, it’s real. Since then we made up, but this stain will last a while…) - when you try to rewrite a codebase you don’t fully understand, you will fail.

During lunch a few weeks ago, someone asked one of the developers in my team how long it would take to write one of our internal-facing systems from scratch.

He looked at me and said: "Something like 3 months, right Anton?"
And I replied: "Closer to 6. And then 3 more years to add all the edge cases".

The longer the code exists - the more stable it is. When I started leading my team 2.5 years ago, I was given a legacy system to support, that nobody really knew. So far, it had maybe 2 small problems due to external API changes, and is just working flawlessly…

Code is like wine - it ages well.

Vadim Kravchenko wrote a great article about it:

Why should you consider aging your code? Because the longer your code has been around, survived different cataclysms (read: business pivots), and evolved, the more robust it is. The team that has built it before you had time to debug, to optimize, to improve — the code has accumulated years worth of bugfixes that are in places you cant even imagine.

The kinks have been worked out, and what you're left with is a mature, stable system that can handle whatever comes its way.

Finding the balance

I'm not saying that code should be kept forever. Requirements change, and new technologies emerge.

My point is that developers should be much more careful with how they define ‘legacy’, and how trigger-happy they are with refactoring.

Your role as a manager is to help the team find the balance - represent the developers, fight for the time to refactor when you believe you need it, but also represent the business side, and push back if you believe a refactor is not critical right now.

2 things I advice you to do before starting a refactor:

1. Think about the future. Are there big features planned in that codebase in the near future? If not - wait for them before you do anything, they might never come.

2. Make a TRUE effort to understand the old code. Let a developer spend a few days trying to understand the existing code. I’m surprised how often 6-8 weeks long refactor projects are started without even spending a day to understand what you are trying to replace!
   
   If the developer feels more confident after a few days, maybe a huge refactor is not that urgent.

The next time you consider refactoring a working codebase - remember my father-in-law...

🙏 Thank you Anton

Gourav here again 👋

Thank you to Anton for sharing this backyard-cleaning escapade which not only made us laugh but also served as an unforgettable metaphor for one of the software world's biggest dilemmas: refactoring versus understanding legacy code. This article should act as a humorous yet great reminder on finding balance, appreciating the value of "aged" code, and thoughtful decision-making before diving into a rewrite are invaluable for engineers and leaders alike.

To get more such valuable insights from Anton, check out his newsletter, Leading Developers.

Shoutouts for this week 🔊

1. How Changing Teams Can Boost Your Career Growth by

2. The one framework every engineer should know by &

3. CPTO: A role every company should consider? by &

4. How to Identify Silent Disagreements? by

🤝 Let’s Connect

👋 Hey there, I am Gourav. I write about Engineering, Productivity, Thought Leadership, and the Mysteries of the mind!

Sponsorship | Collaboration | LinkedIn | 1:1 Mentoring | Twitter

A recruiter won’t schedule your interviews just because you’ve got 10+ years of ‘impactful’ experience on a fancy resume written with a best-practice template.

They have got hundreds of applicants with similar skills as yours.

Ouch! Painful to even get a chance to showcase your skills... right?

Tech job seekers need to digest these harsh facts when sending cold emails or LinkedIn messages to get a job referral.

No, the world out there isn’t evil.

There are legitimate reasons behind this, and I’ll cover a few.

But there’s a way out.

I call it “Interview-Call Insurance.” 🛡️

A few weeks ago, I shared a framework to land a $500k+ software engineer job without Leetcoding. But it’s important to get an interview before you can reach that stage.

That’s why today, I’m sharing a multi-faceted approach to getting that interview call. I’ll cover:

1. Why doesn’t cold emailing work? 📧

2. What’s an interview-call insurance? 🛠️

3. Four ways to buy that insurance. 💡

👋 Hey there, I am Gourav. I write about Engineering, Productivity, Thought Leadership, and the Mysteries of the mind! 🧠

❌ Why doesn’t cold emailing work?

Short answer? Because they don’t know you.

People are generally more willing to do favors for those they know—both personally and professionally.

For instance, if folks like , , , , , , , , , hypothetically posted on LinkedIn today that they’re looking for their next opportunity, they wouldn’t need to cold-email anyone. 👋

Their LinkedIn post would be flooded with comments from people eager to help them out or make them their peer. 🫂

This is what happens when you cold-email or DM a stranger on LinkedIn asking for referral:

1. It get lost in their inbox. Tech job market isn’t what it used to be. Current employees are too busy saving their own asses and couldn’t get time to refer you. Referral bonuses—“free money”—aren’t on their priority list anymore.💼

2. Their image is on stake: It's tough for employees to justify referring someone they don't know, especially at senior levels where their reputation is at risk. That’s why you don’t hear back from senior leaders often.

3. Recruiting is screwed up right now: Companies downsized their recruiting teams in last two years. Limited recruiters are juggling multiple jobs with hundreds of candidates. This causes inefficiencies and burnout in filtering candidates.

🔥 Interview Call Insurance

The classic mistake candidates make is reaching out for help when they’re desperate.

Like “I need a referral now.” Immediately.

Well, you know there are no free lunches.

You pay the premium for car insurance before an accident happens. 🚗💥

The accident may or may not happen—hopefully, it doesn’t—but you still prepare for the worst.

It’s the same with getting an interview call. You need to “do the things” that buys you that “interview-call insurance” for yourself.

💼 Four ways to buy Interview Call Insurance

1. Build a personal brand and provide value.

The big problem is the internet doesn’t know what skills you have.

No, polishing resumes doesn’t work anymore. 🚫

To change that, you need to become more visible. You need to inform people.

Building a personal brand helps with that.

Today, you’ve got tons of options, thanks to professional social media. Here are a few, in increasing order of complexity:

• Share your perspective on others’ LinkedIn posts via comments.

• Post regularly on LinkedIn about something “valuable to others.”

• Reach out to people, offering help without expecting anything in return.

• Start a newsletter, like the one you’re reading right now.

• Start a YouTube channel.

• Build and teach others a course on a skill you’re an expert in.

Now, you might rebel and say, “I don’t want to be an influencer” or “I’m not a content creator.” 🙅

Yes, you are. You have to influence people every day at work to take action in some way. And you’re a content creator if you’ve sent an email, DM, or text message in the last 365 days.

Share your expertise in fields like distributed systems, databases, or system design. Your current projects. Your leadership style. The list of topics is endless.

But you also don’t need to be an expert to post something online. You can also write about how you feel working, the kind of work culture you like or dislike.

Trust me, I get way more job opportunities now than ever before—thanks to my writing.

2. Build friendships with leaders at work

No, not the kind of friendship where you gossip about others. Though funny enough, that works sometimes, too.

And definitely not the type where you break HR rules—if you catch my drift ;)

I’m talking about building relationships through supporting your leadership.

This is simple. Just do small extra things on top of your regular work at your current job:

Deliver results.✅
Make an impact.✅
Solve your leaders’ bigger problems.✅
Then ask them, “What else can I solve for you?”✅✅✅
Have regular 1:1s to catch up on life—both inside and outside of work!✅✅✅✅✅

When you solve your leaders’ problems, they’re willing to help you out. Sometimes even when you’re about to leave the company or get laid off.

I have a friend who got laid off due to bad luck—his entire project/org was shut down. Fortunately, a senior manager from a peer org reached out, gave him multiple leads, and connected him directly with recruiters from other companies.

Gone are the days when your managers would envy you for leaving.

3. Don’t lose touch with people who leave your company.

This one builds on the previous point. What if your leader friends leave and you’ve built a strong relationship with them?

Simple. Keep that relationship warm. 🔥

I’m still in touch with almost all the leaders from my past organizations. Actively with a few. Passively with others.

• Just text them once a month to see how they’re doing. Offer help if they need it.

• This can actually have a win-win outcome. When a leader moves somewhere else, they might need people they can trust—and they might vouch for you internally. This happened to me when I moved to Coinbase.

Building trust goes a long way.

4. Build relationships with recruiters

Wait, how? They don’t know you—and that’s exactly the problem we’re trying to solve.🤔

When your current job is stable, and the market is good, randomly apply and interview with companies once a quarter.

This has a few benefits:

• You get to know some recruiters and grab their direct contact information.

• You know your worth.

For this article, the first point is key. 🎯

Another way? Build rapport with recruiters at your current company. So, when they leave, you’ll know how to reach out—kind of like not losing touch with leaders.

Final thing: Never ignore a cold email from a recruiter during your good times. Reply with kindness, save their contact for future, maintain a friendly relationship.

Shoutouts 🔊

1. How to have 27 hours in your day by

2. Why techies leave Big Tech by

3. Lessons from Projects That Didn’t See the Light of Day by

4. You May Need a Gap Year - Five Reflections by

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

🤝 Let’s Connect

Sponsorship | Collaboration | LinkedIn | 1:1 Mentoring | Twitter

Gourav Khanijoe

Well, yes and no.

Sure, AI and Machine Learning (ML) are big parts of it, but they rely on data—lots of data (Big Data, anyone?)—to train model and be analyzed.

Humans like Data Analysts and Scientists spot trends in the market, then tweak strategies to make sure the recommendation systems are on point.

But it’s Data engineering and engineers that makes the magic happen. Huge Respect!

But hey, I’m a software engineer, so why should I care about data engineering? 🧐

Think twice, you might be wrong!

Today, I'll give software engineers a quick intro to data engineering, covering:

• Why It Matters: Why learning data engineering basics is helpful, even if you’re not aiming to become a data engineer.

• Role Breakdown: A simple example to explain the roles of software engineers, data engineers, analysts, and scientists, and how they work together.

• Tech Overview: A snapshot of data engineering platforms, tech stacks, and processing workflows.

👋 Hey there, I am Gourav. I write about Engineering, Productivity, Thought Leadership, and the Mysteries of the mind!

Why should software engineers care about data engineering?

As a junior engineer, terms like "Big Data," "Spark," and "Data Warehouse" would fly right over my head.

I used to think, "That’s for the data engineers. I’m busy building distributed systems, so why should I bother?"

Being a senior engineer, I realized knowing data pipelines, batch-processing, and data analysis influences my system’s design.

So, I rolled up my sleeves and dove into a project and got hands-on experience with MapReduce, and Spark—just enough to get by.

Then, I got pulled into other business-critical projects and that little spark (pun intended) of interest in data engineering fizzled out.

As a staff engineer now, there’s no more room for excuses. I need to understand enough to help the company make tradeoff decisions.

In general, software engineers benefit by just knowing the basics:

• Better System Design & Architecture: Knowing data pipelines will help you understand their trade-offs. You'll build more scalable, efficient systems.

• Enhanced Debugging: Ever had a bug that’s tied to data? Understanding data will make you a better problem-solver when those tricky issues pop up.

• Data-Informed Decision Making: As you grow into leadership roles, understanding data engineering will help you. It will give you more insight into product, system, and business decisions.

The Difference Between Software Engineers, Data Engineers, Data Analysts, and Data Scientists

Here’s the breakdown:

• Data Engineers build data pipelines—systems that transform raw data into something useful for analysis.

• Data Analysts take that clean, processed data and use it to find patterns and trends, helping companies figure out what’s happening now.

• Data Scientists go a step further by building models that predict future trends and offer recommendations.

• Software Engineers build the systems that solve the problems those data insights reveal.

In short, the data engineer sets up the infrastructure. The data analyst finds current trends. The data scientist makes future predictions. The software engineer builds the product that uses them. 🚀

Data Engineering Tech Stack: A Primer for Software Engineers

Oh man! The field’s come a long way, and it’s still changing fast!

Concepts like Data Lakes and Lakehouses and tools like Trino, Flink, data formats like Apache Iceberg, Avro, and Parquet.

More confusing than ever!

I’ll try to explain simply and cover only the Tech Stack of Data Engineering.

Tech Stack of Data Engineering

The image below is a courtesy of . Thanks to him for creating this.

As a software engineer, you're likely familiar with the request lifecycle in an app. It starts with an API call (ingestion), runs some business logic (processing), then saves it to a database (storage). This is what we call Online Transaction Processing (OLTP), where the system handles day-to-day operations.

Data engineering works similarly but picks up after your application’s database. Just as APIs bring in data for apps, data engineers create pipelines. They process and store data on a much larger scale for analytics. This is called Online Analytical Processing (OLAP).

The Basics: ETL vs. ELT

Data engineering revolves around one key idea: building systems that ingest, process, and store data in ways that make it useful for analysis. This process is called building a data pipeline, and the most common architecture for this is ETL:

• Extract: You grab raw data from various sources like APIs, databases, or files.

• Transform: You clean and shape the data into a usable format.

• Load: You store it somewhere (like a data warehouse) where analysts and business tools can easily access it.

There’s also ELT, which is like ETL’s cooler cousin. Instead of transforming the data right away, you load it into a storage system first and then transform it as needed. This is especially useful when you don’t know upfront what the data might be used for. It keeps your options open and flexible.

Data Warehouses, Lakes, and Lakehouses

Where does all this data go? Great question!

• Data Warehouse: This is structured storage for quick analysis. It’s fast and optimized for answering specific questions.

• Data Lake: This is a giant storage pool for raw data. It’s great for when you have tons of different data but aren’t sure yet what you want to do with it.

• Lakehouse: A happy blend of the two. It offers the flexibility of a data lake with the structured query power of a data warehouse.

The evolution from warehouses to lakes to lakehouses happened because businesses needed faster, more scalable ways to handle growing amounts of data.

Big Data: The Heavyweights

Big Data is all about handling massive amounts of information, the kind that Amazon, Netflix, and Instagram deal with every day. Traditional systems can’t handle this scale, so we use distributed systems like Hadoop.

Hadoop is an ecosystem that chops up huge datasets and processes them across multiple servers at once, kind of like an army of worker bees.

Here’s the core of Hadoop:

• HDFS (Hadoop Distributed File System): Stores huge amounts of data.

• MapReduce: Breaks down data tasks and processes them in parallel.

• YARN: Keeps everything running smoothly.

Other cool tools you should know about:

• Apache Spark: A super fast engine for processing big data in near real-time.

• Apache Kafka: A messaging system for streaming data.

• Apache Flink: A tool that handles both real-time and batch processing.

These tools are like the superheroes of Big Data, ensuring massive amounts of data can be processed and analyzed efficiently.

File Formats: Keeping Data Organized

When managing massive amounts of data, the format you choose can make or break performance and flexibility. Let’s break down some popular data formats you’ll see in data warehouses and lakehouses:

Iceberg & Delta (Lakehouse Formats)

• Apache Iceberg is the table format for huge, distributed datasets. It supports file formats like Parquet and ORC, and cool features like time travel (yes, you can query old data!) and dynamic partitions. Works great with Spark, Trino, and Flink.

• Delta Lake (by Databricks) is a fast, real-time data pro, optimized for Spark. It supports Parquet, gives you schema control, and speeds up read-heavy tasks like machine learning.

JSON & Parquet (Warehouse Formats)

• JSON is the human-friendly, semi-structured format perfect for web apps, but not the fastest for big data crunching.

• Parquet is the warehouse star! A columnar format is perfect for large datasets. It's efficient for analytics and supported by all the big data platforms.

There’s a lot about this data format that we can detail out but that’s beyond the scope of a basic primer. I may cover this in a future edition of Tech Comprehension.

Wanna build a strong Data Engineering understanding and make a career in it?

If you want to build a solid understanding of Data Engineering, try out ’s bootcamp here. Use coupon code “GOURAV” and you will get 25% off. :)

Shoutouts 🔊

A big shout-out to all the Data Engineering folks I know , , , . You all are rockstars!

Also, special shoutout to other Tech newsletter writers - , , - writing tech deep dive newsletter is hard.

Interesting reads last week:

1. SWE v/s MLE by and

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

3. Being an engineering manager at Amazon by and

4. I Worked More and Achieved Less by

🤝 Let’s Connect

Sponsorship | Collaboration | LinkedIn | 1:1 Mentoring | Twitter

Gourav Khanijoe

Code a bit. Then eat.

Cut time with your family. Grind Leetcode while dreaming about doubling your compensation.

Give interviews. Fail.

Feel like sh*t. Sleep.

Repeat.

Sounds familiar?

This is how most software engineers practice switching jobs.

It sucks when you have to spend a lot of time being an algo-coding monkey to crack interviews.

Reality at job is totally different. You are hired and paid to come up with ideas and solve business problems quickly, not to memorize algorithms like parrots.

But what if I told you something amazing? Something achievable.

As a Staff+ Engineer, you can land a $500k+ salary without Leetcode.

As a Senior+ Engineer, you can land a $300k+ salary without Leetcode.

As a Junior-Mid-Senior level engineer, you can land a $200k+ salary without Leetcode.

Yes, without Leetcode—it’s possible. I’ve been there, done that myself.

Today, I’ll cover:

• How Leetcode evolved and why it isn’t for everyone?

• Is it really possible to get high compensation as a SWE without Leetcode?

• A framework I use to land high-paying SWE jobs with almost no Leetcode.

👋 Hey there, I am Gourav. I write about Engineering, Productivity, Thought Leadership, and the Mysteries of the mind!

How have Coding Interviews and Leetcode evolved?

Coding interviews existed long before Leetcode became a thing.

In 2016, I cracked my Amazon interview after practicing 100 known questions on GeeksforGeeks. Those were closer to real-world problems.

Over time, big tech companies found it convenient to use Leetcode as a proxy for assessing problem-solving skills.

Leetcode monetized this problem. To thrive on its subscription model, it began scaling and overcomplicating its problems.

Now, there are over 3,300 problems, mostly unrelated to what engineers actually face in their daily work.

Companies end up hiring algorithm experts, not necessarily great software engineers.

Why It Isn’t for Everyone?

For new grads with time on their hands, grinding through thousands of Leetcode problems is doable.

But for experienced engineers with families? That’s a whole different ball game.

We’re busy delivering results on real, high-impact projects at work. Plus, we’ve got lives outside of work that we can’t just put on pause.

Most of us are out of touch with those tricky algorithms and shouldn’t have to cram them like we’re back in college.

Think about it: the algorithms we’re expected to memorize took experts months to create!

Is it really possible to get high compensation as a SWE without Leetcode?

What’s the catch?

You can get into FAANG without Leetcode— it’s not an easy road.

Here's the thing: You don’t need to chain yourself to Big Tech to get the salary, learning, and growth you’re after.

You can find all that in mid-tier companies too.

The trouble starts when you get wrapped up in the whole “Big Tech Prestige” mindset.

Joe: “Hey, I heard you can land a fat salary without grinding through Leetcode.”

Nick: “Nah, man, that’s a pipe dream. No way Big Tech hires without Leetcode.”

Joe: “But what’s your priority? Is it the pay, learning, growth—or just having a fancy company name on your resume?”

I get it.

Working at Amazon, Google, or Netflix is the dream. Even your grandma knows those names.

But let’s take a step back for a second. What are you really aiming for?

If your next gig offers similar pay, growth, and learning as Big Tech, why not explore that?

Play a different game.

The best part?

Once you’ve got some solid experience under your belt, the dynamics shift.

If you are valuable, even Big Tech is occasionally open to bending their interview process to fit your terms. More on that in next section.

Use my EOF framework to cruise through coding rounds.

When I was on the job hunt after Coinbase, the last thing I wanted to do was grind through Leetcode.

So, I tapped into my network and found a bunch of non-FAANG companies working on some seriously cool stuff—places that value real-world coding chops over solving obscure algorithms.

And guess what? I scored four offers in just twenty days.

Two from mid-tier companies, one from a startup, and even one from Apple.

All of them over $500k for a Staff role—except the startup.

Here’s how I did it with the Eliminate-Offset-Frame (EOF) framework to sidestep the whole Leetcode circus.

Eliminate

I ‘eliminate’ Leetcode prep using these two methods:

1. I use a list of companies that don’t ask Leetcode.

   1. I then use levels.fyi and Glassdoor to filter companies based on my target compensation.

   2. Then, I find its employees on LinkedIn and try to understand the culture and work ethics.

   3. If everything aligns, I schedule interviews, and unless I had a bad day, 90% of the time, I get an offer.

2. I negotiate with big tech companies to skip Leetcode rounds.

   1. Many experienced folks know this secret, and it works a few times.

   2. Before interviewing with Apple, I negotiated to replace the Leetcode rounds with real coding challenges. I got the offer.

Offset

This is a fallback I use when I can’t completely cut Leetcode rounds.

I have a good grasp of system design interviews. I try to use this leverage to 'offset' one or more Leetcode rounds with these interviews.

At a mid-sized company, I replaced one of the two Leetcode rounds with an in-depth design discussion. For the other one, I prepared Blind 75 questions and was able to get through it without any issues.

Frame

This is my final fallback.

If I'm here, it's because a mid-tier company didn't meet my expectations for culture, pay, or ethics. Or, I'm desperately seeking a specific company that wouldn't accept my leetcode negotiation offer.

Two options. Either:

1. Smartly crack a few important Leetcode patterns with timeboxed preparation. Still no guarantee.

2. Take a step back and ‘Frame’ the problem differently.

I can join at some other role in company and later transfer internally at the role I aimed for.

Here’s how one of my friends did it:

He was a skilled Salesforce engineer who wanted to transition to a software engineering role at Amazon. The leap to prepare for Leetcode was too steep. Instead, he interviewed for a Salesforce engineer position at Amazon. Since it was a different interview loop, he avoided Leetcode-style questions and got the job.

Later on, he transitioned to SDE-2 role internally.

I acknowledge that this is a slow option, but it works for those who don’t have a strict timeline constraint.

Shoutouts 🔊

1. Being an engineering manager at Amazon by and

2. If you cannot track, you cannot improve by

3. Growing from engineer to Staff engineer and thriving by and

4. How to Cultivate Clarity and Kindness in Your Engineering Team by

🤝 Let’s Connect

Sponsorship | Collaboration | LinkedIn | 1:1 Mentoring | Twitter

Gourav Khanijoe

His words resonated, and as I shared my own thoughts.

The next day, I expected things to feel awkward, but we picked up right where we left off.

Over time, we became casual and friendly. We discussed projects. I shared my advice on solving bigger problems.

Then he started involving me in key meetings. Soon after, I was leading a high-priority project. 🙌

Of course, it wasn’t just the newly built relationship—but also the trust he had in my past successes.

That moment taught me a powerful lesson—relationships matter more than anything else.

Today, I’m going to share how to build people connections beyond just technical skills that can open doors to your next promotion.

👋 Hey there, I am Gourav. I write about Engineering, Productivity, Thought Leadership, and the Mysteries of the mind!

It’s About People, Not Politics

As a senior engineer, you’ve likely heard, “What got you here won’t take you to the next level.” — You feel its real impact hits when you start to grow in your role.

Career growth beyond the senior level seems to mean scaling your influence and solving bigger problems. But many engineers hit a wall. They've spent years honing their tech skills. But people skills are a whole different ballgame.

They struggle to build relationships with people, and it becomes their toughest hurdle.

They shy away, mistaking relationship-building for politics ❌. But there’s a difference between playing games and building real trust.

Here’s how to build real connections at work.🤝

🌟 Become a vent.

Most people miss the fact that the folks you work with aren’t just colleagues—they’re human, like you.

They have work stress, life stress, and family issues. They too feel overwhelmed, have insecurities, and sometimes need someone to open up to.

If you provide them with that space to vent and talk without judgment, and you listen attentively, people will feel heard and will then open up. They will start trusting you, respecting you, and may even follow you. 🙌

Here’s what I do:

1. ✅ I talk to people about ‘life’ outside of work.

   1. I try to dig into what they care about, what makes them tick, and what hurdles they are facing in both their personal and professional lives.

2. ✅ I give them my undivided attention.

   1. When they open up, I listen to their issues without thinking about my own next sentence.

3. ✅ I care for folks with sincerity.

   1. I often ask them: “Is everything okay at home?” or “How’s your kid doing now?”.

🌟 The Psychological Power of Face Time

While remote and hybrid work is an amazing perk, nothing beats those in-person moments.

It's because, psychologically, you gain a deeper understanding of someone by watching their body language, speech, movements, and reactions to jokes.

I often found that my assumptions about others changed after meeting them. Just talking made us both more comfortable.

For example, I once thought about an engineer being rude ❌. But after talking to them, I understood them better.🚀

Here’s what I do:

1. ✅ When working remotely, I find opportunities to meet people.

   1. I try to find common ground and make plans to meet in person outside work. Maybe they love catching up over a coffee, or they’re a huge fan of sci-fi movies. There are plenty of opportunities to meet.

   2. I never miss team summits or joint meetups organized by the company.

2. ✅ When in the office or meeting in person, I share a laugh 😆:

   1. If I am at the coffee machine or at a party-boozing together in happy hours — I tell a funny story or share my vulnerabilities. That way, they get to know me and I get to know them by how they react.

   2. I once told my peer that “I don’t feel like working today because the coffee machine isn’t working” and we clicked instantly.

   3. Recently, I also learned how my peer makes money doing options trading. :)

🌟 Solve leaders’ problems and make it their win.

When was the last time you solved a problem that wasn’t just technical, but helped to ease the burden on your leaders? Probably never. ❌

Once my manager told me about a micro-service we inherited that had become a liability.

It wasn’t a deep technical issue; it was draining resources and keeping him up at night. I saw it as an opportunity to solve his problem.

I worked on it, identified the cause of the alerts, and fixed it within a week. The team's operational workload shrank significantly.

When my manager’s manager got to know that, he appreciated him.

In the email chain, I thanked him for hunting the right problems. I didn't reveal that I solved the problem behind the scenes. 💪

Helping others solve their problems creates connections. These connections strengthen your leadership presence.

This is how you build loyalty, and more importantly, show that you care about solving the right problems and have an inner desire to help.

Here’s what I do:

1. ✅ I have regular 1:1s with my manager, project leads, and key stakeholders.

   1. I go beyond surface-level talk and ask about their real challenges: What’s keeping you up at night? What’s making your job harder?

2. ✅ I follow through promises.

   1. When someone shares a problem, I take action and circle back with progress updates.

3. ✅ I offer help.

   1. I tell them that I can take their on-call duties while they take some time off.

   2. If it’s my leadership chain, about what I can take off their plate. For example, I once relieved my manager of a few follow-up duties on 2 projects and it made him find some slack.

4. ✅ I celebrate their wins.

   1. I acknowledge the hard work and successes of those around me. Even if I have contributed to their win, I make it sound like their win. 🙌

Shoutouts 🔊

1. Scope Management 101 by

2. Wait What!? Delegation is Bad? by

3. Spirituality for Techies by

4. Build Influence Without Authority by

5. A 3-step framework for behavioral interviews by and

🤝 Let’s Connect

Sponsorship | Collaboration | LinkedIn | 1:1 Mentoring | Twitter

Gourav Khanijoe

I had an insightful chat with Sitesh on his podcast. I shared my journey across companies of all scales and how it shaped me. Tune in to satisfy your curiosity about career changes, adapting to cultures, or find inspiration!

Justin Bieber is one of the world’s most popular music artists. He has it all—Grammy awards, over 150 million albums sold, and a massive social media following. 🎤✨

Yet, Justin opened up about his struggles in an interview with NME.com:

“I am struggling just to get through the days... You get lonely... People see the glam and the amazing stuff, but they don’t know the other side. This life can rip you apart.”

This experience isn’t unique.

We, as software pros, seem to have it all. We have high-paying jobs, loving families, and good friends. We also have some savings. Yet, we still feel unhappy. 😔

Negativity and burnout are common on platforms like Blind. In the race to become a 10x techie, we lose it all and become 1/10 at life.

Since returning to Seattle from a life-changing spiritual retreat in Dallas, I've been reflecting on the powerful insights shared. The retreat was led by my guru and attended by top tech leaders and engineers. The discussions on happiness deeply resonated with me

Today, I’m sharing what it means for the tech world to practice spirituality and the key strategies it offers for understanding and finding happiness in the moment.🌱💻

👋 Hey there, I am Gourav. I write about Engineering, Productivity, Thought Leadership, and the Mysteries of the mind!

Today’s article is bit different but I feel its important to take a step back and think about inner-engineering.

Spirituality 101. What is it?

The best thing about spirituality is that you can define it for yourself!

There is no fixed religious school of thought tied to it. That’s why:

However, you are free to choose a religious tool, refer to a scripture, or knowledge if you want to.

It's a personal, broad concept. It seeks meaning, purpose, and peace in life. It also seeks a connection with something greater than oneself. 🌍✨

Here are some key aspects of spirituality:

• Self-awareness and inner growth: Reflect on your thoughts and feelings. It will help you understand yourself and the world.

• Connection to a higher power: This could be a connection to God, the universe, or a sense of greater purpose or meaning beyond the material world.

• Mindfulness and presence: Often using tools like meditation or mindfulness, which help us stay present and find peace. 🧘‍♂️

How can it help Software Engineers and Managers?

Spirituality can help bridge the gap between high performance and personal well-being. It helps resolve conflicts at work and within.

As a personal example, I used to be aggressive and defensive when people questioned my methods. I’d often complain and find faults in others, not realizing I was doing no good to myself.

I started practicing spirituality a while back. Now, when I face tough times at work, I can take a step back. I analyze the situation from a new perspective. I handle it peacefully and, most of the time, I am happy within. 😊

How do I find happiness within? Read on.

Destination Disease of Happiness

At the retreat, a Senior Tech Leader at Capgemini asked a question

“With growing challenges, expectations, and layoffs, how can we find happiness in our everyday lives?”

We often fall trap of thinking:

I’ll be happy if I could land that dream job at a top tech company, or
I’ll be happy once I am done with this project, or
I’ll be happy once I get promoted to senior engineer or manager.

These are just illusions. Chasing future goals for happiness is like trying to debug an endless loop—it never stops. 🔄

Answers from the Retreat

What is True Happiness?

Whatever we do throughout our lives, we do it for the ultimate goal of happiness.

From school to top colleges, then to high-paying jobs. Then, marriage, kids, and wealth. All the hustle is to meet a single goal: to be happy! 🎯

It’s natural for us to seek happiness continuously because we are part of a perfect, blissful universal energy where everything functions in balance.

Take gravity as an example—it’s finely tuned to hold everything on Earth together. If gravity were to fluctuate even slightly, the consequences would be catastrophic.

True happiness comes from recognizing this balance and then striving to give it back.

In simpler terms—it's a state of mind to practice:

• Serving others and providing value 🤝

• Satisfaction and gratitude 🙏

What Happiness Is NOT

We conflate happiness with temporary pleasures.

• Happiness is NOT materialistic. Pleasures are. Happiness lasts, while pleasures fade sooner.

• We often look for happiness in the wrong places—material things or milestones. These excitements fade, and soon we find ourselves chasing the next desire.

When material desires aren’t fulfilled, we get distressed. When they are fulfilled, greed often takes over, creating more desires. 🛍️

How to do I practice Happiness daily?

1. I practice a tool called Karma Yoga

"You have the right to perform your duty, but don't let attachment to the results consume you.” - it says.

Simply put: Rather than thinking of personal gains every time, think of your work as a contribution to the society of which you are a part. 🌍💡

Personal Experience

When things are going well, I feel gratitude and enjoy the moment. When things get tough, I treat them as lessons and find ways to serve others in the best possible way.

When I push a major code update and it works, I take a moment to appreciate it. I resist the urge to worry about the next task.

When things go wrong, I see it as a chance to learn. This includes software incidents, project snags, and failed leadership tactics. Instead of complaining, I accept it and find ways to solve for customers.

2. I try to do Daily Meditation

Just as you need the right tools to work well—like a powerful IDE, automation scripts, or AI—your mind needs tools to stay sharp and focused. Meditation has become one of those tools for those of us in high-pressure careers.

There are different ways to meditate. Sit in a comfortable position, close your eyes, and try to focus your mind in various ways:

• Take deep breaths and observe them, or

• Imagine sitting in a beautiful place and appreciate nature, or

• Think of a godly image and serve it virtually.

Personal Experience

For a long time, I thought spirituality and meditation were things you started later in life—something for when you’re older and have more time.

What surprised me most was how this simple practice started influencing every part of my life.

My problem-solving skills improved. I became more patient and thoughtful in my interactions, whether in a code review or a meeting. 💡

My way of meditation relates to the third method: “praising the creation of this vast world.” I do it like this:

• I wake up early and, after sitting comfortably and closing my eyes, I begin to "zoom out" from the place I’m sitting.

• From my room to my house, to the sky, and to outer space—I visualize and appreciate the vastness of creation.

This simple, yet effective, approach helps me ignore small issues and take a broader view of life. 🌌

Shoutouts 🔊

1. The importance of having a career growth plan in the engineering industry by and

2. How to Scale an app to 100 Million Users on GCP by

3. 7 Tips for Killer Presentations by

4. How to be Influential as a New Hire by

5. Tips to become 10x better in Tech Interviews by and

🤝 Let’s Connect

Sponsorship | Collaboration | LinkedIn | 1:1 Mentoring | Twitter

Gourav Khanijoe

Throughout my career, I’ve been through countless performance reviews. While I’ve received both positive and constructive feedback, there are a few pieces of advice that truly stand out. Addressing them transformed my career and leadership skills in profound ways. 💡

In today’s edition, I’m sharing the top five critical pieces of feedback I received and how I tackled each one. Please shower some love and share with your friends if you like it! 💖

👋 Hey there, I am Gourav. I write about Engineering, Productivity, Thought Leadership, and the Mysteries of the mind!

Thank you for your kind support and love on my previous article.

1. Influence Without Authority

What Was I Doing Wrong?❗

When I first got promoted to a Mid-Senior Engineer in my career, I felt I was in power. Instead of acknowledging others' opinions, I imposed my own. ❌

I remember when a junior engineer, Sam, once questioned a code comment I had made. I was baffled and my ego flared—how could someone question their senior's comment? - I thought 🤔

The Feedback 📮

"You’re leading by asserting power," my manager said, "not by guiding others with respect and collaboration."

That hit me hard. 💥 I was causing friction in the team, and junior engineers were second-guessing their contributions because they feared my reaction. ❌

That night, I couldn’t sleep, replaying conversations in my head—realizing how often I shut down differing opinions and pushed my agenda. 😔

How I Addressed It 🚀

• I confided in my mentor, who encouraged me to talk to Sam. When I did, I realized he was right. I apologized and admitted my ego had blinded me to his valid points. ✅

• Over time, I embraced the idea that I didn’t always have the best answers. I encouraged others to lead discussions and share perspectives. I started asking others to lead sprint ceremonies and share their viewpoints. This created space for diverse perspectives to emerge. 🗣️💬 ✅

Key Takeaway 🌟

True leadership isn’t about control. It’s about influence— understanding, and guiding others by example, and not due to formal authority.

2. Active Listening

What Was I Doing Wrong?❗

During strategy discussions or critical reviews, I had a habit of interrupting others the moment they opposed my ideas. ❌

I wasn’t listening to understand—I was waiting for my turn to speak, cutting people off mid-sentence to push my justifications.

The Feedback 📮

In a 1:1, the senior engineer told me, “You’re smart, but it seems like you’ve already decided what the other person is going to say, and you’re just waiting to jump in.”🎯

It was then raised during my review. I felt a mix of frustration and embarrassment. 😳 I thought I was being efficient, but the reality was that I wasn’t listening actively. ❌

How I Addressed It 🚀

• I read the book 📖 You're Not Listening and realized that real listening isn’t just about hearing words—it’s about making people feel understood. I had to train myself to shift my mindset from trying to win a conversation to trying to understand it.🤝

• One of the most challenging changes I made was to satisfy my urge to speak by taking notes during meetings. When I felt the impulse to interrupt, I’d write down my thoughts instead. This gave me the space to listen fully. 📝 ✅

• I also made it a rule to be the last person to speak. The change was tough. But, it improved things. The discussions became richer, and people opened up more. 💡 ✅

Key Takeaway 🌟

Active listening is an underrated leadership skill. It’s about understanding, not just responding. When you listen with intent, you create space for better ideas and deeper connections.

3. Content Over Consensus

What Was I Doing Wrong?❗

I wanted everyone to agree before moving forward with any major project. I thought this would produce better results, but instead, it led to endless meetings and stalled progress. ✖️

One complex project suffered because of this. I kept revisiting the same conversations, trying to get everyone's approval. As a result, we lost weeks of valuable time.⏳ ❌

The Feedback 📮

I got this in performance review - "You’re spending too much time trying to get consensus. It’s stalling execution. You would benefit from getting consent, not consensus." 🛑

At first, I struggled because I had always believed that getting everyone to agree was key to effective collaboration.

But my manager explained that leadership isn’t about making sure everyone is happy with every decision. It’s about moving forward with the right intent, even if not everyone is fully on board.

How I Addressed It 🚀

• I began breaking projects into smaller phases, seeking consent to prototype early ideas instead of pushing for full alignment upfront. 💡 ✅

• One example was a critical backend payment processor project. Rather than waiting for everyone to agree, I secured permission to build a small proof of concept. ✅

• I got buy-in in my project when the prototype results spoke for itself and over time, even skeptics came on board. ♨️

Key Takeaway 🌟

Leadership often requires making progress without universal agreement. Aim for forward momentum and allow the results to speak for themselves, rather than waiting for everyone to be on the same page.

4. Scaling Myself

What Was I Doing Wrong?❗

I fell into the "do it yourself" trap. I was a fast coder and thought taking on tasks directly was the quickest way to get things done. ❌

But this led to burnout, and my team wasn’t growing because I wasn’t giving them the space to contribute. 🤯

The Feedback 📮

In my performance review, my manager didn't mince words. He told me, “Gourav, you need to scale yourself.” ❌ This wasn’t a surprise to me, I immediately agreed.

How I Addressed It 🚀

• I deliberately slowed down myself and instead started mentor others more. I would delegate tasks that I could have easily done on my own. ✅

• At first, it was frustrating—watching others take longer than I would have—but I resisted the urge to jump in. ☑️

• Slowly, I saw progress. Engineers began growing in confidence, delivering better results, and stepping into leadership roles. 🏆 ✅

• Finally, I led a project with a 12-engineer team on a major payments project, which we delivered on schedule and it resulted in several members earning promotions. 🎉 ✅

Key Takeaway 🌟

Scaling yourself requires slowing down to speed up. By mentoring, delegating, and trusting your team, you create a culture of growth and collaboration that extends beyond your own individual contributions.

5. Clear, Crisp, Actionable Communication

What Was I Doing Wrong?❗

I’ve always been a talker, often over-explaining. In meetings, I would give excessive context and over-justify my points, which confused people instead of clarifying. ❌

During a wider team meeting, I was asked for a brief update but I ended up providing a long-winded explanation, and noticed I was losing everyone’s attention halfway through. 🤦‍♂️

The Feedback 📮

In my performance review, my manager pointed out that my communication needs to get to the point and be direct and actionable. ❌

He recommended I read the book Simply Said, which focused on delivering clear, concise, and impactful communication. That recommendation was a turning point for me.

How I Addressed It 🚀

• I started reading the book, and it was a revelation. It taught me that effective communication about conveying what matters to others succinctly.

• One interesting fact is that I am still addressing that feedback. One practice that I have incorporated is that I am writing short reflection pieces on it every Sunday. As I am learning this, I am writing those down and sharing the knowledge with others on how to do it. ✍️ ✅

• My manager and I have observed that my Slack comms have became shorter and more focused, my presentations more engaging, and my conversations more efficient. There is still room for improvement but I am on the right path. 🎯 ✅

Key Takeaway 🌟

Clear, concise communication is a critical skill for any leader. When you cut out the noise and focus on the essentials, your message becomes stronger, and your influence grows. Say less, but mean more.

Shoutouts 🔊

1. Grinding My Way to Work-Life Balance by on ‘A Life engineered’ by

2. Best Mentors in the World Just For You by

3. Senior Engineer or Senior Citizen? How Can Vintage Tech Workers Age Like Fine Wine? by

4. Empathy is a superpower in the engineering industry by

🤝 Let’s Connect

Sponsorship | Collaboration | LinkedIn | 1:1 Mentoring | Twitter

Gourav Khanijoe

One day, Nik’s pull request was met with a flood of comments. Already behind schedule, he DM’ed me on Slack:

"Can you please approve my PR? Everyone expects me to deliver fast, and I'm losing time."🕒

It was clear he hadn’t fully thought through the problem, which was why he was struggling. Concerned, I asked him:

“Why are you so stressed and didn’t do it right the first time?”

He quickly admitted:

"I’m dealing with sleep issues, demotivation, and depression due to work. I’m terrified of layoffs, worried about not meeting expectations, and constantly anxious about what others think. It’s affecting my work” 😓

He added, “Even when I’m not on my screen, my mind is still at work. It feels like I’m always working, never resting, yet I’m unsure about my performance. It’s becoming counter-productive."

I knew Nik outside of work—he had a loving family, good enough savings, and a support system in place. Yet, his mind was consumed by anxiety, fear of losing his job, and the constant worry about others’ opinions.

This is a struggle many of us face, fueled by misguided beliefs, wrong principles, and a lack of critical thinking. It’s no wonder that we're seeing a disturbing rise in heart attacks and strokes among young professionals in their 20s and 30s due to ever-increasing tensions. 💔

In today’s newsletter, I’ll share what I’ve learned about these deep-rooted issues in my career by sharing few examples and offer strategies to help you:

• Break free from toxic thoughts and beliefs.

• Overcome fear of performance expectations and layoffs.

• Face and handle complex problems at work.

👋 Hey there, I am Gourav. I write about Engineering, Productivity, Thought Leadership, and the Mysteries of the mind!

1. Break Free from Toxic Thoughts and Beliefs

Each time Nik’s manager offered direct feedback, he saw it as a shadow of impending failure—a threat of getting placed on a Performance Improvement Plan (PIP). ⚠️

Though his manager was doing his part, he was unaware of how Nik was interpreting the feedback. Over time, Nik’s insecurities quietly grew stronger.

So, whenever he faced challenging problems that required timely deep dive, his fears and worries would dictate his uncoordinated actions, often resulting in unwanted outcomes. 🌀

I’ve been there too. I remember designing a flawed system under changing requirements and beating myself up for it. Instead of learning from feedback, I let negative beliefs take over. 😞

Root Cause ♨️

1. As Ray Dalio explains in his book Principles, our actions are driven by our beliefs and values. If we dwell on negative thoughts—like missing deadlines—we begin to believe we’re not good enough. 🚧

2. The more we dwell on negativity, the stronger those neural pathways become. Over time, these beliefs deepen and control our actions, habits and destiny. 🧠

How to overcome this? ⚡

Monitor your thoughts and remember—they don’t define you — you can distance yourself from them as separate entities. It helped me focus on taking action — fixing my design, when I messed up. 🔄

In practice:

1. Meditation helps manage your thoughts and brings clarity.. You can focus on your breadth, a godly Image or just empty space while sitting in quite place.

2. Focussing on gratitude and acknowledging existing skills, knowledge, and financial stability you’ve achieved goes a long way towards building positive neural pathways.

2. Overcome Fear of Layoffs

Layoffs have become a constant threat in tech. Over 124,000 employees have lost jobs in 2024 across 384 companies (at the time of writing this). Nik’s fear of layoffs was shared by many, and I’ve felt it too—especially during my time at Coinbase in 2022.

With ever-increasing expectations of high performance, it’s hard to focus on work.

Root Cause ♨️

1. After attending a few mindfulness sessions, I understood that this fear often comes from our brain’s tendency to jump to conclusions that we’re next in line.

2. We tend to over-index on hardships if the worst case has to happen. Many talk about saving for early retirement, they forget that these savings can also serve as a crucial safety net during tough times. 🛟 💼

How to overcome this? ⚡

Do your best work and prepare for worst rather than constantly worrying about it. The true job safety is knowing that you will get another job and can use your hard-earned money during tough times.

In practice:

1. Learn to pick highest-impacting projects wisely while focussing on elevating your skills, staying current with the latest technologies. 🎯

2. If you’ve saved enough to cover 6-12 months of expenses and kept your skills sharp, a layoff won’t keep you down for long. Don’t worry — AI is far from replacing us.💡

3. Facing and Handling Complex Problems at Work

Early in my career, I often avoided complex problems, thinking others were better suited to solve them—especially when it came to messy operational issues.

I remember finding a kernel memory issue as a junior engineer and threw it under the rug because I didn’t have anything to talk. I can empathize with Nik’s situation.

Root Cause ♨️

1. I was afraid of being judged for not knowing the solution. This fear paralyzed my growth. 🛑

2. When I discussed it with my mentor, she pointed out that this fear stemmed from a lack of confidence and a need to protect my image.

How to Overcome This ⚡

Over time, I learned to embrace challenging situations, seeing them as "interesting problems to solve." This mindset shift built my expertise and confidence.🔍💪

In practice:

1. Face problems head-on. Initially, it was uncomfortable and often required extra hours, but it paid off. I became more efficient at spotting patterns and finding solutions. While every problem is unique, I found that breaking them into smaller parts and tackling each step-by-step is key. 🌀

2. Admit when you don't know something. I was surprised that exposing my vulnerabilities opened doors for help and new perspectives without folks judging me. This shows that most of the times our mind make up stuff. People are more forgiving than we think, and saying, "I don’t know," invites valuable insights.☀️

Shoutouts 🔊

1. Should you Start a Startup? by

2. Nobody Is Watching — The Spotlight Effect by

3. How to say "No" and win back your time as a software engineer by

4. Why It Takes Forever to “Get to Staff” by

5. How I went from Tech Lead → Engineering Management by

🤝 Let’s Connect

Sponsorship | Collaboration | LinkedIn | 1:1 Mentoring | Twitter

Gourav Khanijoe

Today in this short and crisp edition, I've compiled several of my life and career learnings as one-liners that I use as guiding principles. These are organized into different sections, each representing various aspects of life.

👋 Hey there, I am Gourav. I write about Engineering, Productivity, Thought Leadership, and the Mysteries of the mind!

I am humbled by the love and support you all are showing for my Reflection Shorts.

Software Engineering

1. Code is the most fragile thing in the software industry. Tribal knowledge, when documented well, is gold.

2. You're not judged on your skills if your outcomes are solid. The reverse isn’t true.

3. Never feel bad for not knowing things at work. Every company has complicated systems; no one knows everything.

4. Feel bad only when you don’t put in the effort to understand.

5. Staff/Principal Engineers don’t know everything, but they know how to know what they don’t know.

6. Hundreds of things vie for your attention, but finding time for deep work is key to making meaningful progress.

7. Be proud of getting rid of unnecessary code, services, and clutter in your architecture. Eliminate liabilities wherever possible.

8. Appreciate the OGs for the work they did. Complaining won’t help—fixing stuff would.

Professional

9. It takes a lot of effort to build trust, but breaking it takes only a second.

10. Clear communication is underrated and misunderstood. Deeply understand how to effectively communicate to make a huge difference in your life.

11. Stay away from people who drain your energy.

12. You can’t please everyone with your design. Aim for consent, not consensus.

Tech Interviewing

13. Leetcode isn't bad. However, engineers suffer due to the complex interview environment created as a result of it.

14. The issue isn’t Leetcode vs. no Leetcode; it’s the same Leetcode questions at every candidate level.

15. For system design interviews, you don’t need to know everything. Basics can do wonders.

16. Being humble and saying “I don’t know” can get you hired more than pretending to be all-knowing and smart.

17. You can’t fake behavioral questions; an experienced interviewer will catch you out.

Joining a new company

18. People aren’t impressed by your past learnings alone. Adapting to a new company’s culture is what makes you likable.

19. Congratulating a new hire is like congratulating a chef for buying vegetables.

Life

20. Not every attempted hit results in scores, but it builds your muscle memory.

21. You might think successful people have it all sorted. Reality? They’re as confused as you are.

22. Don’t measure your value by someone’s judgment in one place; you might just be in the wrong place.

23. There’s no long-term success without first achieving short-term wins.

24. More information doesn’t necessarily make you wise; it can make you stressed.

25. Develop long-term habits with small, consistent efforts.

26. Execution is more important than awareness.

27. Your to-do list will never be empty. Focus on completing the 1-2 most important and urgent tasks each day.

28. You realize the real multitasking power after having kids.

29. Your current situation is a net result of luck, hard and smart work.

Content Creation

30. Identify yourself as a brand, and others will too.

31. Share deep, witty, and brutally honest thoughts and stories.

32. Readers love hearing about your failures more than your successes.

33. Leveraging social media for marketing is crucial, but creating valuable content is primary.

34. Your unique, brand-new idea is a myth; someone is probably already working on it. What makes it different is execution.

Money

35. Comparison is the thief of joy.

36. Never hesitate to invest in yourself.

37. Don’t overthink purchases. It’s okay to buy things that bring you pleasure but spend wisely. Money buys pleasure, not happiness.

38. Money can only solve money problems.

39. Get rid of high-penalty, high-interest debts.

40. Learn about investments, but be honest about whether you have time for active management.

41. Using a third party to manage your money isn’t a bad idea if you lack the time. Opportunity cost is real if you’re too busy or lazy.

Shoutouts

1. How to find nearby entities? by

2. Entropy - Mental Model by

3. From Staff Engineer at Meta to Y-Combinator Founder by

4. "20% for tech debt" doesn't work by

5. How Netflix Uses Chaos Engineering to Create Resilience Systems by

🤝 Let’s Connect

Sponsorship | Collaboration | LinkedIn | 1:1 Mentoring | Twitter

Gourav Khanijoe

"Originality" is a key trait of great writing, especially in the age of Gen AI, where anyone can create fake content. Thankfully, our brains can now (as of July 2024) distinguish original content from AI-generated. And that’s why only a few great tech writers stand out for their humane narratives.

Creating original content takes time and effort. Writers sacrifice family or leisure time to deliver valuable, authentic content. There is no replacement for that if you want to be a great writer.

However, once the original draft blessed with personal experiences is ready, writers still have to spend hell lot of time making an article “publish-ready” which includes:

• researching data,

• fixing grammar, adding images and emojis,

• using SEO-optimized words,

• ensuring simplicity and clarity, and much more.

Experienced writers use different AI tools to incorporate these in their original drafts, which is justified given the effort involved. But using those tools is costly and the process is cumbersome. For new writers, overcoming these challenges comes with experience and following best practices.

To ease out this process, I am openly sharing a custom GPT Workflow that I’ve created — “Tech & Leadership Newsletter GPT”. I'll demo it in today's newsletter. This tool helps content creators worldwide become more efficient and reduces friction for new writers in sharing their stories.

To access this GPT tool, all you need to do is subscribe to this newsletter for free. In the newsletter’s welcome email, you will have a personal link accessible to use this efficiency tool. Existing subscribers would get the link in a separate email as a freebie.

👋 Hey there, I am Gourav. I write about Engineering, Productivity, Thought Leadership, and the Mysteries of the mind!

This article is little different from my typical writings. However, it holds the power to enable Techies across the globe to share their stories in an efficient way.

Demo of using this tool

The tool is designed to be used as a workflow. The steps of the workflow are ordered to help:

• draft an outline,

• take-in original draft and iterate on ideas,

• image creation and insertion

• adding research data and stats

• adding emojis

• simplicity checks to make sure its grade 7 read

• proof reading and final grammar checks

With that, let’s get started.

Kickstart using the tool

• Once you have subscribed to the newsletter, you will have the link to the tool. On the onset, it will give you an intro message asking you details about your topic, theme, title and target audience.

• You can ask it about the overall workflow before starting with the draft.

Start by sharing your idea!

• Here you will provide some input points to the tool.

• It will then ask you if you have an outline to share.

  • It can generate an outline for you as well if you don’t provide your own and ask it to create it for you.

• It will then create an professional outline based on your rough ideas and inputs. Further, it will ask you for your initial draft.

Start Preparing the Draft

• You can play around with surprises that GPT can give to you, aka, ask it to create draft for you. but I highly recommend creating your own draft with your own tone, structure, stories.

  • Below is just an example where GPT created the draft for you.

• Here, I asked it to ignore its draft and rather take my draft.

Refine your draft

• Then, it will tell you the next steps in the workflow.

• It can create an AI image for you, if you want.

• Then, it will can help you add some stats in your draft.

See example below:

• Then, it will make sure the article is simple to grade 7 level and simple to read.

• You can also ask it to add emojis at appropriate points in the next step.

• Post a final review, it will make it publish ready with proof reading, consistency checks, etc.

Disclaimer

First, you would need GPT-4o subscription to use this tool for longer periods of time as free Open AI usage may have some limits.

Second, this GPT tool is solely my creation, refined over a few days to streamline workflow and integrate best practices for newsletter writing. I've incorporated insights from great reference articles and the personal style guides of various authors. However, it's important to note that this is still a GPT tool and may sometimes produce inaccurate or unexpected information. Please use it at your own discretion. It's designed to enhance your efficiency, not replace your creativity or judgment.

Shoutouts

1. How to Impress in High-Stakes Presentations by

2. From Staff Engineer at Meta to Y-Combinator Founder by

3. How the Fear of "Unknown" is Blocking your Growth by

4. Why perfectionism destroys your productivity, and what to do instead by in collaboration with

5. 5 reasons why your best developers will quit - and how can you postpone it by

🤝 Let’s Connect

Sponsorship | Collaboration | LinkedIn | 1:1 Mentoring | Twitter

Gourav Khanijoe

When life feels like a mess of to-do list items, I think about how someone else might be dreaming of the life I live.

A question often comes to my mind: “Am I just a lucky, privileged guy?”

Last week, in collaboration with , I shared my journey through struggles and how I overcame obstacles with dedicated efforts to change my life.

But isn’t it just that things worked out in my favor? Or, Did I work hard or Smart?

It's not just me. Many in the workplace experience Impostor Syndrome. It's the persistent doubt about whether their accomplishment is deserved or legitimate.

To understand what contributed to my journey, I researched and deeply reflected on the role of luck, privilege, hard work, and smart work. I discovered some guiding principles that consistently apply.

Today, I’m sharing these principles to help you separate noise from the signal when Impostor Syndrome strikes. They will give you a clearer view of your achievements and success.

👋 Hey there, I am Gourav. I write about Engineering, Productivity, Thought Leadership, and the Mysteries of the mind!

Thank you for all the support, love, and motivation on my previous article.

Guiding Principles

1. Luck And Privilege play a huge role in one’s life and career.

2. Smart work is the key but it isn’t possible without hard work first.

3. Find the balance between Imposter Syndrome & “Successful Man Fallacy”.

1. 🍀 Luck And Privilege play a huge role in one’s life

Luck — the random entropy of the universe showering unique positive situations and events on you from birth and beyond.

Privilege — an unearned, significant advantage like generational wealth that you are born with.

Yes, I was lucky. But NOT privileged. You must have heard this saying:

Luck is what happens when preparation meets opportunity.

This is true most of the time, but sometimes favorable, non-privileged things happen naturally beyond your control.

There are things I took for granted but were sheer luck:

Personally:

• I was born and married into a loving family. 👪

• I was naturally good at academics and deep dive. 📚

• I am spiritually sound which helps me alleviate stress. 🧘‍♂️

• I have supporting friends who are always there for me. 🤝

• I achieved everything I worked towards without unsolvable setbacks. ✔️

Professionally:

• I had a knack for writing clean code and solving business problems. 💻

• My coding interviews went well and I didn’t get any unfair interviewers. ✅

• I was fortunate to have good managers who helped me improve further. 📈

• I did not face discrimination based on religion, color, or ethnicity at work. 🌍

I cannot imagine the struggles I would have faced without these fortunate traits and events. I call it God's grace or simply blessings.🙏

🌟 Key-Takeaways

• Luck factors can significantly impact one's opportunities and outcomes.

• I highly recommend you do self-introspection. Recognize their role to be more fair and empathetic to progress.

2. 🧠 Smart work is the key but isn’t possible without hard work first

I define hard work as applying brute-force solutions to problems.

Smart Work is about finding efficient and effective ways to achieve a goal. This is done by using existing knowledge, people, tools, and technology.

We, as humans and software engineers, often have the instinct to apply brute force when we first encounter a problem.

I still remember when I started my career and used to face a complex bug in the code. My first reaction and action was to throw hours of debugging at it by just reading tons of code and testing every possible scenario. However, as I gained experience, I started to recognize patterns and develop smarter approaches. I began using efficient debugging tools, taking thread and heat dumps, and writing automated tests. 🛠️

As I became a leader, I learned to delegate tasks and to teach. I also learned to force-multiply. In software engineering, this is a great example of smart work. So, I worked hard first and then became a smart worker organically.

🌟 Key Takeaways

• Hard Work:

  • It's necessary for building skills and achieving initial breakthroughs. 💪

  • It laid down the foundation for where I am right now.

• Smart Work:

  • Involves strategic thinking and leveraging tools and techniques to work efficiently. 🔧

  • As my experience grew, my ability to work smartly led to greater wins with less effort.

3. Find the balance between Imposter Syndrome & “Successful Man Fallacy”.

Imposter Syndrome is when people doubt their skills. They feel unworthy of their achievements, despite being capable.

The "Successful Man Fallacy" is a wrong belief. It holds that success comes only from personal qualities and actions, like hard work or intelligence.

Geoff Charles, a writer on Medium, described how different identities try to make sense of their circumstances in one of his articles:

When someone feels like an imposter, they might be acting as a Lucky or Privileged one.

But also, successful software engineers often credit hard work and smart thinking. Admitting that luck is a factor is difficult because it challenges their notion that they fully deserve victory.

When I read about Equalitarian, I found the answer to my question. My success wasn’t just luck; it was a perfect blend of hard work, smart work, and good fortune.

While I can credit my long hours of coding, continuous learning, and strategic moves, I must also recognize the role of access to education, great mentors, early opportunities, and supportive leaders.

This made me embrace the identity of an Equalitarian. I understood that my growth came from both my efforts and the opportunities I received.

❌ I worked hard throughout my next jobs, always taking on more work to get more responsibility, and rose through the ranks

✅ I got referred to another company. I practiced the interviews to get the job and built upon my brand on paper. I got mentorship from senior leaders because they liked me.

🌟 Key Takeaways

• Embracing an Equalitarian view helped keep a balanced perspective. It recognized the roles of hard work, smart strategies, luck, and privilege.

• I learned that not everyone has the same opportunities. This taught me to empathize with those who may be struggling. It made me a more kind colleague and leader.

Parting Note

To all Software Engineers facing layoffs and economic challenges, I say:

Shoutouts

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

2. 3 steps to write messages that people will enjoy reading by

3. From Lead Engineer to Software Engineer II by

🤝 Let’s Connect

Sponsorship | Collaboration | LinkedIn | 1:1 Mentoring | Twitter

Gourav Khanijoe

Many customers who placed orders having some special kind of discount missed the 'prime 1-day delivery promise' and received their orders up to a day late.

My code was the culprit..

This was my promotion project, and I messed it up. Interestingly, I still got promoted after a quarter.

Today, I am sharing a personal experience that will help you understand that sometimes while striving for growth and promotion in your career, you might face setbacks. However, if you handle difficult situations well and have strong leadership that trusts you, you can emerge stronger.

👋 Hey there, I am Gourav. I write about Engineering, Productivity, Thought Leadership, and the Mysteries of the mind!

🧨 What happened?

Amazon India was an emerging market.🚀

When I joined Amazon India in 2016, the market was just emerging. I became a member of a new Payments team responsible for launching features to make purchases more affordable for customers. One of our major projects was "Instant Discount" which provided discounts for using partner credit cards. This feature was expected to drive significant revenue.

Our team was in startup mode, moving fast, breaking, and fixing things. The architecture was complex and evolving.

Prime Day Rush.🤹‍♂️

I designed and implemented a new payment processor service. I implemented it to handle discounts on orders. I wrote unit and integration tests for the service and also manually tested it.

Confident in our stable state, we declared "Go time" for the 2017 Amazon Prime sale.

The entire company prepared for the heavy surge in traffic, expecting around 100,000 transactions per minute. We scaled up our services, increased autoscaling capacity, and added more memory and CPU to the servers.

Then came the D-Day.

Finally, the sale started, and we had an "Ouch" moment. 💥

Many orders with instant discounts started failing in the service. This caused payment workflows to get stuck and delayed order shipping.

The issue? I wrote flawed code in the payment processor service, using Double instead of BigDecimal type in Java. This caused precision errors with non-whole prices. It led to incorrect discounts and mismatched totals.

😓 Chaos, Mitigation, and Guilt

We started receiving sev-2 tickets, customer complaints, and business inquiries about the issue. I checked the logs and explained the problem.

Order delays affected customers and the delivery pipeline. Our leadership got involved. My manager, Arun, was a great leader, and my senior engineer, Puneet, was the most respected engineer on the team.

Puneet and I took the lead in resolving the situation. We quickly deployed a hot patch in production during the sale event. But, this wasn't enough to fix workflows stuck in a loop, so we needed manual intervention.

We involved all the engineers, divided the huge list of workflows, and prepared a runbook to resolve the issues. It took us seven hours to fix all the workflows, leaving everyone drained.

I overheard some engineers criticizing me for the mistake, and I felt guilty. 💔

🏋️‍♀️ How I Still Got Promoted: Learnings and Key Takeaways

I was up for a promotion that quarter, which got delayed for obvious reasons. Yet, my promotion came in the following quarter. Here’s why I still got promoted quickly:

⚡ Trust

• Throughout the project, I progressed in line with the team's expectations. My manager appreciated my speed of execution and proactive communication. We knew there could be sharp edges. But, we moved forward pragmatically. We skipped too much exhaustive testing to meet the timelines.

• My senior engineers acknowledged that the service handled normal cases correctly, and only 10% of orders were affected. Due to previous trust, my leadership supported me instead of blaming me. They understood that such reversible mistakes (two-way door decisions) can happen when moving fast.

⭐️ Key takeaway: Build trust by being a go-getter and meeting leadership expectations, and they'll support you in tough times.

🔥 Adaptation and Ownership.

• After the incident, I adapted and helped mitigate the issue. I also took a step back to understand the architecture better and added guardrails to make the service more resilient.

• Demonstrating ownership in learning from mistakes and improving the service contributed to my promotion.

⭐️ Key takeaway: Always learn from your mistakes, take the lead, set examples, and come out stronger.

🧳 Business Backing

• In the next quarter, I not only improved the service but also collaborated with product managers to incorporate more features.

• This restored my reputation and earned positive feedback from business leaders.

⭐️ Key takeaway: Build trust with business leaders, keep them informed, and help them achieve their goals.

🏆 Strong Leadership

• Understanding and supportive leadership is a blessing. Arun and Puneet helped me focus on improvements rather than dwelling on the mistake. Their guidance was invaluable, and they've remained close friends for life.

⭐️ Key takeaway: Strong leadership is a blessing. If you have supportive leaders, maintain lifelong relationships and strive to become a similar leader.

Shoutouts 🔊

1. Look at ’s amazing journey writing newsletter: Reflecting on my 6 months of writing this newsletter

2. Support by reading Mastering Feature Development in Software Engineering

3. Understand if you want to stay or quit your current job by reading ’s latest: When is the Right Time to Quit?

4. I really loved the heading and content of this article written by on The real job security these days is knowing you can get another job

5. Being a leader means having a backbone, read what explained related to it: Don’t be a Spineless Leader: 3 Tips to Lead Better.

Let’s Connect 🤝

Sponsorship | Collaboration | LinkedIn | 1:1 Mentoring | Twitter

Gourav Khanijoe

It was a Sunday when the main microservice owned by my team crashed, affecting multiple customers. I was a junior engineer on-call at the time. I paged Jon, our most experienced engineer and team tech lead, along with a few others for assistance.

Jon received my page while he was at the barber shop, getting his hair and beard done. He could have said - “Please check with Josh, I am out and will check back once I reach home”.

Instead, he joined the incident call via phone, and started providing debugging instructions: "Can you run iptables to check for dropped packets? I suspect the kernel upgrade on the node", while his neck was under a blade.

Others on the call chuckled, commenting, "If he isn’t responding from a barber shop, he isn’t Jon."

That’s Extreme Ownership.

But what does that mean? What are its benefits and challenges, and how can you apply it in your career without burning out? Today, as an engineer with significant experience and having done my fair share, I'll share my perspective to answer these questions.

👋 Hey there, I am Gourav. I write about Engineering, Productivity, Thought Leadership, and the Mysteries of the mind!

What Jon Was Doing?

Jon was applying his infrastructure expertise to assist the team, regardless of his location or circumstances. He prioritized resolving customer impact and minimizing downtime.

He didn’t dwell on the lack of knowledge or runbooks within the team; instead, he took accountability and felt responsible for resolving the issue.

When I joined the call, I identified the root cause and began working on mitigating the problem. Despite knowing the situation was under control, Jon continued to provide guidance, effectively leading the resolution effort from a low-network environment at the barber shop.

It took 3 hours to resolve the issue. In the postmortem, Jon said that he could have done better to mitigate issue and took blame for it.

This exemplifies extreme ownership.

What’s Extreme Ownership? 

It’s when a leader deeply accepts responsibility for their team, product, and customers, using their influence and knowledge to restore order amidst chaos.

This approach means leaders don’t blame others when things go wrong; instead, they take ownership and work towards solutions, regardless of the conditions.

It’s a leadership concept popularized by retired Navy SEALs Jocko Willink and Leif Babin in their book Extreme Ownership.

Benefits

1. Career Advancement: Promotes rapid career progression by fostering a proactive, accountable mindset.

2. Accountability: Encourages leaders to take full responsibility for outcomes, nurturing a culture of accountability within teams.

3. Trust: Builds trust as team members see leaders taking ownership of mistakes and actively working to correct them.

What are its sharp edges? 

• Burnout: It can lead to leaders feeling overwhelmed, as they might take on too much responsibility, leading to burnout.

• Overdo: You might start over-optimizing solutions to the problems at work.

• Blame Shifting: There’s a potential for Blame Avoidance by your team members as they might become overly reliant on the leader to solve problems, hindering their own growth and initiative.

My opinion on how to pursue Extreme Ownership

We should strive to become extreme owners. But, as a leader, if you try to control all variables, which isn't always possible in complex environments, you will get burnt out. It can also lead to the case where you confuse taking responsibility and doing things on others’ behalf.

This is where Dichotomy of Control comes in. It goes with extreme ownership. But, it suggests that you take responsibility for things "only in your control". For things outside your control, you can still use it well. Use it to process the outcome well and not get burnt out overoptimizing.

Other important aspect leaders may lose on exert is force multiplication. They try to do things themselves. Part of extreme ownership is to spread it out such that every member of the team feels that, and you get more done with the help of others.

Key Takeaways

• Focus on what you can control, avoid burnout and over-optimization.

• Exert Force multiplication and empower team members to lead.

• Foster a culture of accountability and sustainable growth.

Shoutouts 🔊

1. Glass swords, moving fast and breaking things, and advocating for quality💡 by

2. The Value of Taking Breaks by

Let’s Connect 🤝

Sponsorship | Collaboration | LinkedIn | 1:1 Mentoring | Twitter

Gourav Khanijoe

Not a great experience, huh?

You must jump out of bed, check the logs, and review the order details to update the ticket. Picture waking up to two angry customers from another continent—stressful, right?

I am no AI expert. But, I recently used GenAI to solve operational pain at my company. In this edition, I will share it with you so you can do it too.

But to keep my work confidential, I am using a hypothetical e-commerce company as an example. It shows how you can ease customer frustrations, like those late-night pages, and still sleep well, thanks to AI.

I want to focus on the applications of Gen AI. So, I won’t go into much detail about Gen AI concepts. But, I will give references to articles where you can learn about them.

👋 Hey there, I am Gourav. I write about Engineering, Productivity, Thought Leadership, and the Mysteries of the mind!

This topic is a detour from soft skills into technical gigs territory using Gen AI.

Architecture at a high level

Let’s an example of an e-commerce system. Customers could get unhappy if their order remains stuck. They could reach out to a customer agent. The agent may reach out to or page the orders-tech-team on-call to fix the issue.

The on-call follows a Standard Operating Procedure (SOP). They check logs and service availability. They check Slack for older tickets and how they were resolved for a similar error.

Let’s see how to build a Gen AI application. It would make some magical system API calls and do things you would do. It would also generate responses for your customers on your behalf.

Below is a fancy little system diagram that shows different parts of such a system.

Support Ticket Tool

This is your operational communication hub—like a ticketing system or Slack workflow. Here you would tweak your ticketing system that triggers-in when specific tickets come in, to direct it to your new GenAI resolver instead of paging you.

GenAI Support Ticket Resolver

Your main Gen AI service parses ticket details. These include the order number, customer ID, and timestamps. It then calls the Order Workflow Service API to fetch order details, logs, and potential errors.

Issues might arise:

• from technical glitches, such as overloaded services

• for valid reasons, like pending payments.

It will consume and interpret OrderService call output. It will also use the Retrieval-Augmented Generation (RAG) API (details below). The RAG API draws understanding from past incidents stored in the Vector DB to craft a response. This service then uses text prompting techniques (see below) to call your company’s GenAI.

Company’s Gen AI Platform and Models

It is highly likely that your company may have its own Gen AI platform, abstracting direct access to models like GPT-3.5 or Mistral. This ensures security and cost-efficiency.

Gen AI Models

It depends on your company’s setup, like restrictions or specific models (e.g., GPT-4, Mistral 7b). You feed the prepared prompt into the model. The prompt contains input details and the desired output format.

Prompt Template and Prompt engineering

Use various techniques (YAML, JSON, Jinja) to create templates with placeholders for data. These templates guide the model on how to structure its response. Read more about it here. Below is a crude example prompt for our use case that shows how we can use different prompt engineering techniques to generate output. This particular template uses zero-shot. Read about various other prompt engineering techniques here.

RAG API Service and Vector Database

This service enhances the AI's ability to generate responses by combining traditional generation techniques with the retrieval of relevant information. It accesses the Vector Database, which stores past incidents and their resolutions. The RAG API queries the database to find similar older cases. This ensures that the responses it provides are accurate and based on real scenarios your team encountered in the past.

The RAG API Service and Vector Database empower your Gen AI application. They help it deliver informed responses. The responses reflect the collective knowledge and experience of your organization. Read more on RAG and vector Database here.

Caveats and Limitations

1. Risk of Hallucinations: Gen AI operates based on patterns in data it has been trained on. It may generate responses that appear coherent but are factually incorrect or misleading ("hallucinations").

2. Dependency on Data Quality: The RAG API and Vector Database's effectiveness depends heavily on the quality and relevance of the data they access. Inaccurate or incomplete data can lead to incorrect conclusions or responses.

3. Complexity and Nuance: Gen AI excels at handling predefined scenarios based on historical data and patterns. Complex or nuanced issues that require human judgment or empathy may still pose challenges and might benefit from human intervention.

Key Takeaways

1. You don’t need to be an AI expert before creating a valuable application that solves your Organizational problems.

2. Just by plugging in basic APIs and their responses into prompts, you can create wonderful applications.

3. While Gen AI is great, it does come with known limitations that you should be aware of from the outset.

Shoutouts 🔊

1. Promoting Your Work by

2. Are You The Problem? by

3. Scaling for Billions: Uber's Data Ingestion Powerhouse by

4. Why you should attend a software engineering conference by

Let’s Connect 🤝

Sponsorship | Collaboration | LinkedIn | 1:1 Mentoring | Twitter

Gourav Khanijoe

In roles like Senior or Staff Engineer, Engineering Manager, or Technical Product Manager, it’s even more crucial to succeed early. The company has invested its trust in you during the interview.

Imagine joining a new company and feeling judged by every team member when you're asking questions or discussing topics. What could be going wrong?

Unfortunately, there isn’t a clear checklist for the behaviors or traits to exhibit when joining a new company or even a new team internally. But, I've seen a common theme among new leaders. They often carry unconscious habits from their old roles. These habits can hinder success in a new environment..

I have worked in companies of all sizes and onboarded successfully a few times. I made a few mistakes, while others I observed among struggling new joiners. In today’s edition, I will share from my experience, a few mistakes to avoid when joining a new company as a leader.

👋 Hey there, I am Gourav. I write about Engineering, Productivity, Thought Leadership, and the Mysteries of the mind!

In the last few weeks, I couldn't release new editions because life hit me hard. My family and I had some big ups and downs. Things are finally settling, so I'm back with this new edition. I hope you like it.

1. Breadth vs Depth

In your last job, you were the senior person, and everyone relied on your input for various tasks. You may not need this in your new role immediately.

When I joined a company, in the past they told me that focusing on too many things at once was lowering my chances of success by losing focus.

It's crucial to check with your manager on their priorities. Generally, as a Senior/Staff engineer, it's better to have depth in a few areas and then expand breadth after settling in.

2. Not Building Trust

This is the most significant factor that can lead to failure in a new job, despite having technical strength.

Trust is crucial in every aspect of leadership. If your team doesn’t trust you today, you can’t lead them tomorrow.

Many tech-savvy people question the team’s every past decision. They cause conflicts to prove their point. Ego sometimes motivates individuals, especially those in senior roles. This behavior harms your career. It also leads to resentment and hurts performance and respect.

Another aspect is showing seniority and forgetting the key point: "Influence without authority".

When joining a new company, it's better to mentally step down and understand the ground realities that other engineers face. Imposing your knowledge without understanding the new tech stack and systems can hurt your success. You were an expert at your old company. But, these new systems and fields are complex. Comprehend their perspectives first, then exert your persuasive power.

3. Fighting with Your Manager

This is rarely effective. I once did this and regret it even today.

There are better ways to make your point while being humble and a good listener. While it's sometimes valid to disagree with your manager, remember they were here before you and probably know better than you. Being patient and putting effort into building a trusting relationship is essential.

Every manager has their own style and thought process. Adapting to their approach will take some adjusting. But, you must do this while keeping your aura and finding a balance. This will foster a good long-term relationship.

Remember, your manager is more important to you than the whole company. They play a huge role in your career growth, protecting you in difficult situations, and vouching for and promoting you.

4. Over-Showing Your Expertise

You may have done well in the interview. And you know a lot about distributed systems and complex software problems. But, if you talk too much about your past jobs, you may seem inflexible. You may seem like you don't want to learn new things or adapt to the new work culture.

Key Takeaways

1. Understand clear expectations of the role before you scatter yourself over.

2. Be humble, and polite and earn the trust of your juniors, peers, and leaders.

3. Never break a relationship with your manager. A manager is your best buddy.

4. Don’t stick to old practices, processes, and tech stacks. Unlearn to learn more.

Shoutouts 🔊

1. How to Start Writing a Newsletter and Succeed by Raviraj Achar

2. 5 Toxic Behaviors to Avoid if you are a Software Engineer by

3. Great software teams don't release in phases by Anton Zaides

4. 7 Tips to Crush Your Onboarding from An Apple Staff Engineer by in collaboration with

5. How to Influence Without Authority with Irina Stanescu by in partnership with

Let’s Connect 🤝

Sponsorship | Collaboration | LinkedIn | 1:1 Mentoring | Twitter

Gourav Khanijoe

👋 Hey there, I am Gourav. I write about Engineering, Productivity, Thought Leadership, and the Mysteries of the mind!

I am thrilled to share that we are a 1000+ members community now. Can’t express my gratitude enough to each one of you reading this newsletter. 🙏

I have worked in software companies of all sizes, from startups to Big Tech. I noticed some interesting aspects on how people think and build software.

Today I am sharing my key takeaways from working at companies of different sizes. These will be based on anecdotes of my experiences. I hope this will help you decide which company type is best for you.

1. Big Tech

Not all Big Tech companies are the same. I used to work in one such company and designed a technical solution involving distributed systems. It was roasted by other Senior and Principal Engineers in the review, to an unnecessary extent in the name of scale and safe rollout. It’s not uncommon at a few Big Tech companies.

They used to pick a lot of nitpicks and ask questions out of context. They looked forward to a 5-10-year vision, while the feature needs to be shipped “quickly” as per PMs’ timelines.

This loop of "improve the doc", misaligned expectations, and pushback from sister teams leads to churn and process-driven burnout. They add up to over-skepticism and slow down the company.

But there is a strong reason why they are forced to follow such a suit. They operate at a huge scale. A small hiccup can cause a loss of billions of dollars and of customer trust built over years. And that is the reason, Engineers are paid top-notch at Big Tech.

My key takeaways are:

1. You will learn many best practices and understand how to operate systems at scale.

2. When you land impact, it will touch millions of customers across the globe.

3. Your payscale is exceptional.

4. You often end up coding relatively less and get stuck in processes and approvals.

5. Safe practices come with burnout. You might end up waiting to see the impact of your work for months or years in some projects.

2. Mid-Tier Companies

To clear up this vague definition. I am referring ‘Mid-Tier’ to companies that are still on a growth trajectory. They also have a very high scale but not to the extent of Big Tech.

When I moved to mid-tier companies, I observed they move so fast and deliver results quickly by:

• making a small testable net-new logic module, possibly behind a feature gate.

• gathering early feedback by internal dogfooding and acceptance testing.

• iterating back, fixing stuff, adding more features, and repeating.

• avoiding unnecessary processes and consensus.

I had to unlearn many processes and coding practices. Most importantly, I had to unlearn 'asking for permission'. The autonomy and flexibility were great. They had the perfect blend of moving fast, showing impact quickly, and not overcomplicating. It positively blew my mind. On top of it, Engineers are paid really well.

But to enable teams to move fast, dedicated infrastructure teams build some abstractions. These hide the underlying concepts from product engineers. Systems could also go stale or become monolith pretty quickly.

My key takeaways are:

1. You will learn the art of a true 'Bias for Action' by coding the MVP quickly. This will deliver results faster and save the company's resources and money.

2. You seek consent over consensus.

3. Pay could be a little less than Big Tech, but mostly comparable.

4. You may slightly miss out a bit on best practices, processes, failure modes, and rollout experience at scale. System code becomes complex to manage relatively fast. But this is not always true.

5. Moving quickly without understanding the core dependencies could lead to shallow learning. This is especially true for some product-focused teams.

3. Startups

In between jobs, I also had an excellent opportunity to join a startup as Founding Engineer number #1. If done well, this role is sometimes matched to a CTO role.

I wrote the first set of APIs. I also implemented the build-and-deploy systems. I set a vision for the product and talked to potential customers. It was such a roller coaster ride. This journey was filled with a tremendous amount of learning in a short period. At the same time, the base pay was comparable to Big Tech but everything else was paper money.

But I was so burnt out after spending a major portion of my day and night contributing to the company. And I had some other personal commitments that I had to meet. I made a tough decision to part ways with the company.

My key takeaways are:

1. If you ever want to start your own company, working at an early-stage startup first is your best bet.

2. The surge of learning is incomparable. You learn deep tech in a short time. You also learn many different skills. This paves a path to C-suite leadership if you stick around.

3. The Gross Pay isn't great. But, it has a higher upside if you stay a long time and the company succeeds due to your deep contributions.

4. Your energy should match the commitments required at the startups. Also, the timing should suit your life. Otherwise, you won’t do the job or personal life justice.

5. Burnout at startups is real. Defining boundaries between personal and work life is hard. You should make a conscious, informed, and hard decision before joining a startup.

Shout-outs 🔊

1. Dumb Code Beats Smart Code - Don’t make the mistakes I made by

2. Feedback is a gift only if it is received well by

3. Design a Distributed Priority Queue by

4. The Role of a Technical Program Manager by

5. Feature flags are ruining your codebase by

6. Super Specific Feedback: How to give actionable feedback on work output by

7. 3+1 strategies to track your achievements by

Let’s Connect 🤝

Sponsorship | Collaboration | LinkedIn | 1:1 Mentoring | Twitter

Gourav Khanijoe

👋 Hey there, I am Gourav. I write about Engineering, Productivity, Thought Leadership, and the Mysteries of the mind!

We are going to be a 1000+ member community pretty soon, thank you for all the support!

Are you a Tech-savvy Engineer who is told to:

1/ Excel at work; 2/ Exercise at least 4 times a week; 3/ Pay taxes on time; 4/ Invest in high-performing assets; 5/ Be the best parent and spouse; 6/ Read books and newsletters; 7/ Become mindful and spiritual; 8/ Learn new skills; 9/ Travel the planet, and 10/ Crush the damn to-do list…

You are not alone!

We have been advised, thanks to the social media influx, to manage multiple life aspects simultaneously. But we are rarely informed how to effectively do a million things at once. In reality, our demanding jobs consume most of our time and we lose everything else.

Today, I am going to share a few interesting strategies I have adopted to get the most out of my life without getting overwhelmed.

My goal in sharing the tools and techniques is to help you solve the puzzle of managing this multifaceted life more efficiently.

My Techniques to Live a Balanced Life

I have divided it into 5 sections which are the key sections.

1. Work-Life Harmony via Prioritization and Delegation

Link to the LinkedIn Post.

Embrace Spikes & Prioritize

It’s okay if some days are work-heavy while others are more focused on personal matters. Planning my day through heavy prioritization in the calendar and clear communication about the same at the workplace helped me attain harmony between the two realms and reduced my stress level. It keeps me in check to not overdo my office work.

Acknowledge that you’d need to drop your kids off at daycare, talk to Tax Advisors or financial planners, visit for doctor appointments, and do many other things that could only be done on weekdays in between work. This is perfectly normal.

Delegation

I use the Todoist app to manage different to-do-list tasks and divide those into projects as per the Eisenhower matrix which helps decide the importance and urgency of tasks which then helps me decide ‘What can I delegate’.

I take it seriously. I delegate heavily.

• At work, I trust Engineers who can do the work which also helps them grow.

• In my personal life, I have a workforce, built over years, in place that I can rely upon. I have cleaners scheduled every 2 weeks for deep cleaning. Similarly, I have a tax advisor, property agent, Banking relationship partner, Auto-scheduled grocery deliveries, and much more. I strongly believe in putting the right people at the right job.

The key is to understand the value of your time and balance out between DIY and delegation expenses.

2. Financial Growth using Automations

A DIY investment strategy of investing in stocks and managing them is time-consuming and cumbersome. Use a financial planner/agent or Three Fund Portfolio to optimize for time and growth in equity.

After losing a lot of money and time, I learned two lessons:

• Investing should be as boring as watching the grass grow.

• Active equity investment is not ‘my thing’ with a full-time job.

Delving into a few chapters of "The Intelligent Investor," the wisdom struck me: an average investor in the USA can fare better with a simple “Three-Fund Portfolio” (managed passively or through robo-bots) than those constantly scrutinizing daily charts and staying overly active.

• For a good portion of this kind of investing, I use maxed-out Pre-tax 401k as well as Mega-backdoor Roth IRA contributions advantage.

• For foreign investments (India), I use an agent. Having someone manage my investments while I sleep peacefully is great because they understand the right times to shift money around. This helps me avoid the opportunity cost of potentially missing out on gains that could happen if I tried handling everything on my own. The fee paid to them is worth it.

The key takeaway is to Automate Investing - via technology and by involving experts.

3. Win on Physical and Mental Health by Overcoming Friction

Physical Health

The biggest life hack to keep yourself on track for physical health is to understand that your mind plays games.

All I need to do is take the first step and break the inertia.

• I don’t think about working an hour daily. I just think of 5-10 minutes. I end it whenever I think is okay to do so but push myself every time.

• Believe me, once I think that I will just do 20 pushups and squats each, I end up working out for more than 40 minutes because of the momentum that gets built up.

You may not love to start, but you will definitely cherish it once you’ve done it.

This reminds me of this recent post from Anthony Vicino:

Mental health :

• To build a knowledge base, I listen to motivational podcasts and YouTube videos while driving to run errands.

• I spare just 10 minutes to do meditation morning, and guess what? Time flies. (same idea from physical health). My meditations are spiritual in nature.

• I built a habit system of practicing and training my mind using the Productive app that reminds me that there is always someone else having bigger problems than me. Not taking conflicts seriously, treating failures as learning, and having gratitude, humbleness, and empathy for others are key factors that maintain my inner peace.

4. Driving Personal Growth via Writing

Writing helps you think deeply. No matter what you are learning for Personal growth, writing it down makes it simpler to understand and retain.

Personally, my avenue for growth is through writing this newsletter.

This skill allows me to absorb various learnings and share them through my newsletter, providing actionable content that adds value to others' lives.

To achieve this:

• My mornings are sacred. My routine involves dedicating at least an hour each morning to document my learnings before starting work.

• I fuel this growth by listening to podcasts, reading books, and documenting my own experiences in Notion and Google docs.

Tip: You can also leverage audiobooks and book summaries to save time. wrote a whole about it here.

5. Family and Relationships

The key is to make deposits into the deed bank.

An act of appreciation for your partner, sharing the burden of day-to-day activities, and taking care of their needs are deposits that you make. This needs mindfulness more than time.

Everything you do is tied back to your family.

Plan activities, dinner dates, travel, and relaxing vacations, or simply cook dinner together. To do that, I have reminders set to plan out family days in advance. That includes 15-30 minutes of planning, booking, calling, etc. three days a week during lunch time using custom GPTs. It’s fun and makes daily family time even more engaging.

Latest Interesting reads

1. 5 Mistakes That Made My Documents Terrible by

2. Taking Decisions in Engineering Teams by

3. If Your Network Is Your Net Worth, This Is How You Get Rich by

4. Joining an early-stage startup might not be financially worth it by

5. How I Almost Quit Because of $75 by

6. How to Multiply Your Experience As a Software Engineer by

Let’s Connect

Sponsorship: Unlock the potential for your business to shine! Simply reply to this email or DM on LinkedIn. Refer to the sponsorship packages here.

Collaboration: Whether it's cross-content sharing, podcasts, or interviews, let's create something amazing together. My DMs are open on LinkedIn.

Follow me for daily informational

🤝 Connect with me on LinkedIn

💪 Connect for 1:1 mentorship

𝕏 Connect with me on Twitter

Be the change you want to see,

Gourav Khanijoe

👋 Hey there, fellow tech enthusiasts, professionals, and wanderers of the digital realm! 🚀

I am Gourav. I write about Engineering, Productivity, Thought Leadership, and the Mysteries of the mind!

Performance reviews could be stressful. Back when I was a junior engineer, watching managers and senior engineers go into a performance review was enough to make me nervous.

“Would they delve into my pull requests? Could they possibly overlook my successes and zero in on that one incident where my code caused a hiccup? Am I being seen as just an average performer?” - endless questions pop up in my mind.

I've worked as a Staff+ Engineer for quite some time and have been part of many such conversations. With experience, I can tell that performance reviews are supposed to help you and not go against you. The process is designed NOT to scrutinize but to help you grow. Staff+ folks are invited in there to back you up when preconceived notions come into play.

Today, I'll share my firsthand experience to help you all understand the dynamics of perf reviews and calibrations and what role Staff+ engineers play in reviews. Towards the end, I will share what assessment I am getting in my reviews to help explain why the feedback should be ‘NO Surprise’

Staff+ and Managers Crush Bias During Review Prep

As a Staff Engineer, when performance season came around, I started getting lots of messages on Slack from managers asking for feedback on various junior and senior engineers.

This made me curious about what happens behind the scenes in preparing for performance reviews.

Luckily, I have many Engineering managers as close friends, and I got to understand what they do before the meeting. 😀

Here’s what Engineering Managers do “before” the review meeting:

• They think about the growth, successes, setbacks, strengths, and weaknesses of their team members.

• They gather data points, looking at code contributions, design documents, and peer feedback.

• Then, they talk to senior or staff engineers to get more feedback and confirm their own thoughts. This validation through feedback is crucial for them before the review meeting.

• Then they form opinions about each team member. For those doing well, they plan a path for promotion. For those consistently falling short, they create a performance improvement plan (PIP) and a plan to help them grow.

This cleared up two of my big doubts:

1. Managers do prep a lot and put in a lot of effort.

2. They don't want to push their own ideas as feedback. Instead, they seek diverse input, avoiding personal bias in decision-making.

But what if your manager is playing games?

When I joined my first-ever performance review meeting, I was surprised at how the process is designed to keep everyone in check.

Senior managers typically invite Engineering Managers (EMs) whose subordinates undergo calibration. They also invite senior and staff+ engineers to help in the goal is to turn anecdotes into facts.

Here’s what happens in the review meeting:

EMs are asked to discuss the strengths and growth points of key teammates.

Effective managers provide a growth-focused perspective and data-driven feedback. They also give estimated ratings on a five-level scale to the engineers they manage.

They brief on why a particular engineer deserves a higher rating, possibly being on a promotion path, and why others may need support, guiding them toward not meeting expectations.

Whenever a manager proposes someone for a promotion, they are often encouraged to make a promo plan and work on it immediately if there are no concerns.

Conversely though, if someone is put on a performance plan, managers face scrutiny. They are questioned about regular feedback and support to prevent reaching a point where a 'plan' is necessary.

Staff Engineers are asked to validate points. I recall a time when I took part in reviews and saved an Engineer from a Performance Improvement Plan (PIP) with strong data points.

But here are the interesting points I learned:

1. Performance reviews aim to help, not penalize. Your manager plays a crucial role in your success, if they rate you lower, it reflects poorly on them first and on you later.

2. Regular feedback is crucial; otherwise, both your manager and senior/staff engineer are at stake.

Calibrations ensure that you are set up for success

Post reviews, come calibrations. Calibrations ensure employees aren't judged solely on occasional hiccups or wins. They are judged on consistent, regular tracks.

In my view, this is the most crucial part of the process as it recognizes that impact and performance aren't a straightforward, linear scale.

Expectations may dip due to factors like team changes, project prioritization, extended leaves (such as maternity or paternity), and the employee's reputation.

So, your judgment isn't solely based on your code; it extends to your overall dynamics, like influence, historic contributions, and organizational factors.

Key learnings are:

1. As long as you keep on working hard, deliver value, and keep good relationships, these hold significant importance.

2. Occasional hiccups won’t make a difference if you are otherwise a good engineer.

What feedback am I going to get this time?

I know what feedback I am going to get this time in my performance review.

How do I know before I even received it?

Simple, because Performance Review feedbacks aren’t supposed to be surprises. They are meant to be a reminiscence of the regular feedback you get in your 1:1s.

My manager has lots of experience in managing people. He is also technically strong. He figures out when things may go wrong and gives immediate, positive feedback that sounds charming.

In my past 1:1s, we have been discussing how can I make my written communication like Slack announcements, cross-team feedback capturing, and other documentation crisp and concise. So, there you go…this is what I am going to get in my performance review.

You know the interesting part? I am already working to improve on this before getting it officially stoned out!

🥂 Shoutouts

1. Give Feedback that Helps, not Hurts by

2. How Canva Supports Real-Time Collaboration for 135 Million Monthly Users by

3. Mastering Leadership: Why We Hesitate Giving True Feedback by

4. Taking Decisions in Engineering Teams by

5. I wish I started doing this on day 0 of my career as an engineer by

Let’s Connect

If we haven't crossed paths previously, I'd be delighted to receive a message from you!

Sponsorship

Unlock the potential for your business to shine! Simply reply to this email or DM on LinkedIn, and let's embark on this exciting journey together. Here are the details of various sponsorship packages.

Collaboration on mind?

I am more than happy to collaborate! Whether it's cross-content sharing, podcasts, or interviews, let's create something amazing together. My DMs are open on LinkedIn.

Also, don't hesitate to reply to this email and introduce yourself. I make it a point to respond to every direct message, email, and comment.

Follow me for daily informational

Follow me on LinkedIn for daily interesting bytes, discussing all things software engineering, leadership, financial freedom, mindfulness, productivity —let's connect:

🤝 Connect with me on LinkedIn

💪 Connect for 1:1 mentorship

𝕏 Connect with me on Twitter

Be the change you want to see,

Gourav Khanijoe

👋 Hey there, fellow tech enthusiasts, professionals, and wanderers of the digital realm! 🚀

I am Gourav. I write about Engineering, Productivity, Thought Leadership, and the Mysteries of the mind!

How to get promoted from Staff to Principal Engineer despite having setbacks?

This is the third and final part of the multi-part series. We'll explore the journey from Staff to Principal Engineer. (Promotion from Principal to Distinguished Engineer is super rare, so I won’t go that far). Part 1 focused on progressing from a new grad to a Senior Engineer, while Part 2 covered transitioning from Senior to Staff Engineer.

Some companies have a Senior Staff level. By aiming directly for the Principal Engineer, we effectively cover aspects of both roles.

With that in place, let’s get started with actionable insights on a journey that is close to my heart (I am currently treading on this path)!

Staff → Principal Software Engineer

Experience years: 10-20 (lower experience promotions are rare; the more senior the better)

Current titles: Staff (Software) Engineer, Staff Tech-Lead, Architect, Staff Lead

Target Titles: Principal (Software) Engineer

Scope: Company-wide Impact Projects, Leadership, Technical and People skills, Business Mindset.

Much Needed Context Section:

Besides the context for Staff Promotions, I would like to give insights into the Principal level:

1. Promotion to Principal Engineer is rare. This level makes up the top 1% of the population at the company. You are definitely not expected to reach this level.

2. Getting hired as a Principal is intimidating. Even those with special expertise in fields such as AI, supply chain, crypto, and infrastructure, and having industry and business acumen may face challenges in getting hired as Principals.

3. Principal Engineer = (Top Management Chain work [Director / VP / CTO] - Core People Management + Strong Tech Expertise). Principal engineers need to have people management skills but here I am excluding typical resource allocation and empire-building stuff.

4. While I'm outlining various paths to the Principal Engineer in an action-item format, it's important to note that there's no singular guaranteed route. The journey is inherently ambiguous and challenging, and despite diligent efforts, success is not assured - For e.g. it’s fair for a company to not need this level at all.

With this, let’s get started:

Action Items

Beyond typical Staff Engineer responsibilities, you must also do the following:

1. Own Top 1% of Engineering Project and land Company-wide Business Impact:

   1. The top 1% Engineering Project spans many teams or the whole company’s way of doing day-to-day Engineering. These are the things that all other engineers take for granted and often affect the company’s bottom line.

   2. Examples include but are not limited to:

      1. Choosing a language for the whole company and setting up its infrastructure - build and deploy the system.

      2. Migrating the company’s database from SQL to NoSQL or vice-versa.

      3. Building Business Foundational Frameworks like Payment Gateway Systems.

      4. Introducing safe build-deploy practices by building abstractions and tools like REST APIs interceptor layer.

2. Execution & Strategic Leverage

   1. As one human being, you can only code so fast, there is a limit to what an individual can do. Folks on the path to PE understand this clearly and are a really efficient force multiplier.

   2. This would mean having an influence on many other engineers in the company. Strategically leveraging them and working through them to execute shared goals in a meaningful manner.

   3. That’s why even when you are targeting the PE level, which is an IC role, you still need to be a good people person. Here’s why naively, many go into management because they think, ‘If I can have a team of people who do what I say, I will have more leverage and more impact.’

3. Thought Leadership: It is absurdly vague but let me boil it down to two points:

   1. PE’s opinions matter a lot, not just to other Engineers but also to the C-Suite. CTOs, often look forward to hearing their thoughts and opinions on a strategic business move.

   2. In this position, you share innovative ideas, insights, and opinions with others. You do this to influence, inspire, and lead the industry or community. You also take the hit when things go wrong.

4. Ability to move broader and deeper seamlessly.

   1. You have Know-how at a high level of the whole company.

   2. You can move across business domains, technologies, teams, and leaders with fluidity.

   3. People wait to seek your advice before doing stuff.

5. Be one of the Key faces of the company:

   1. This doesn’t mean becoming a celebrity, (that’s for C-Suite - pun intended).

   2. You must deliver Tech Talks and key Notes at Inter-Company events. Also, you must conduct key events and make the processes lightweight and automated.

   3. You repeatedly experiment with new tools and technologies in the industry and propose the company adopt or sunset a few.

   4. You are a natural mentor at scale via your knowledge-sharing sessions.

There is much more to it. This is because such a role needs and covers a lot of different areas and skills. But, if you do these, there's a high chance it'll bring you closer to your Principal Promotion.

Acceptable setbacks and how to learn and overcome those

The bar for Principal Engineer is so high that any visible setback could cause drastic repercussions on your path to promotion.

However, it’s hard to be consistently in coding mode for some staff engineers when they are on the path to PE as don’t get enough time for it due to other high-priority responsibilities.

As long as the leadership is aligned, they won't see this as a setback, but if they are not cautious, they could perceive it as actionable feedback. The key is still to remain hands-on with coding and find some dedicated time for it.

Some Housekeeping

I have heard from some of the subscribers that the newsletter email sometimes goes to their spam or promotions folder.

Please move your newsletter emails to the primary folder, add gouravkhanijoe@substack.com to your email contacts, or simply reply to this email saying “Hi”!

In case you missed any previous editions due to this, please read all of them here.

Special Thanks

1. Author of the Leading Developers newsletter, for providing valuable feedback and support to this newsletter.

2. Author of the Techlead Mentor newsletter for cross-post collaborative efforts.

3. Author of Strategize Your Career newsletter for supporting my voice.

4. Author of the High Growth Engineer newsletter for conversational support and feedback.

5. Author of Developing Skills newsletter for recommending this newsletter.

In case you missed my previous articles…

How to level up as a Software Engineer despite having setbacks? - Part II (Sr. to Staff Eng)

How to level up as a Software Engineer despite having setbacks? - Part I (New Grad to Mid-level to Sr Eng)

Secret to become a Staff+ Engineer swiftly

Access the full archive here.

Your thoughts matter! Comment or reply with your post ideas—I'm all ears and ready to turn your concepts into content! 🙋‍♀️🙋‍♂️

Let’s Connect

If we haven't crossed paths previously, I'd be delighted to receive a message from you!

Sponsorship

Unlock the potential for your business to shine! Simply reply to this email or DM on LinkedIn, and let's embark on this exciting journey together. Here are the details of various sponsorship packages.

Collaboration on mind?

I am more than happy to collaborate! Whether it's cross-content sharing, podcasts, or interviews, let's create something amazing together. My DMs are open on LinkedIn.

Also, don't hesitate to reply to this email and introduce yourself. I make it a point to respond to every direct message, email, and comment.

Follow me for daily informational

Follow me on LinkedIn for daily interesting bytes, discussing all things software engineering, leadership, financial freedom, mindfulness, productivity —let's connect:

🤝 Connect with me on LinkedIn

💪 Connect for 1:1 mentorship

𝕏 Connect with me on Twitter

Be the change you want to see,

Gourav Khanijoe