Why Am I Not Getting Promoted?

Promotion is always a “top of mind” topic when you talk about career growth. Why some folks find it hard to get promoted at work?

Nikhyl Singhal boils it down to four reasons.

1. You need someone to believe in you

↳ “You need someone to see the magic in you to be promoted”

↳ It’s super important to have a manager or a team who sees how awesome you are.

↳ If they don’t, you might need to change things. Find a different project, team or even a new manager.

2. Sometimes, the job you want doesn’t exist

↳ There are times when the job you’re aiming for just isn’t there.

↳ This isn’t your fault; it’s just how things are at your company.

↳ You are still being held back but it is very different than “you are not there yet”

3. Be Patient

↳ If you’re doing really well, you might want to move up fast.

↳ But sometimes, you have to wait a bit longer, especially for big roles.

4. Work on Yourself

↳ Unfortunately, this is the most common one.

↳ There is a development area but the individual doesn’t see it.

↳ Maybe manager is not doing a great job of identifying it.

—-

I recently listened to Nikhyl Singhal’s interview on Lenny’s Podcast and this piece on promotions resonated with me a lot. 

Leveling Up as a Junior Engineer

Many times software engineers ignore these three easy ways of leveling up in your team.

🧐 Start observing staff+ role models
Look around for teammates who excel and are considered role models. Check out how they work, how they talk, and the way they solve problems.  That’s the easiest way to learn what kind of behavior is rewarded in your company culture.

🗣️ Ask if you can shadow them
Don’t hesitate to ask if you can shadow these high performers during meetings or cross-functional conversations. You’ll grasp firsthand how successful conversations are steered.

🎭 Emulate Rewarding Behaviors
Jot down your observations and start mirroring those behaviors in your own way. Add your own flavor to make it unique.

Don’t just work hard, work smart! Leveling up is not only about hard work but also about adapting and learning from the ecosystem around you.

Staff Engineer: Growing beyond code

When you are invited to a cross functional meeting as a staff+ engineer, you are expected to add value beyond just a technical input.

Once you get to staff level, the skill of connecting your technical knowledge with the business context becomes very important.

Your thinking needs to evolve beyond just coding and solving technical problems.

You are expected to know or start forming answers to questions like:

🤔 Why are we building this?

💊 What customer pain point are we trying to solve?

🫰 Which parts are expensive to build?

🔄 How can we build it iteratively and deliver customer value fast?

🔝 What is the right way to prioritize and sequence?

🧩 Who is best suited to own each piece and why? (connecting dots between skills and career aspirations)

⚖️ What technical debt can we payoff and what is ok to accrue?

Your ability to leverage your technical knowledge to collaborate with cross functional partners and making decisions to move initiatives forward is what makes you valuable.

As a staff engineer, you’re now a bridge between tech and business, an ally to the customers, and a role model to junior engineers.

Sam Altman’s Insight: Productivity is More About ‘Why’ Than ‘How

“It doesn’t matter how fast you move if it’s in a worthless direction. Picking the right thing to work on is the most important element of productivity and usually almost ignored.” – Sam Altman

There is so much written about productivity tools, techniques, hacks, but very few articles focus on asking the questions-

are you working on the right thing? are you enjoying what you are working on?

Other piece of advice that resonated with me from Sam Altman’s essay on productivity was:

“The right goal is to allocate your year optimally, not your day.”

If our long-term goals excite us and we enjoy the journey, we naturally boost our productivity. 🎯 But if we’re stuck in tasks we dont like or we’re clueless about the destination, it is really hard to make your day productive.

So sometimes it’s worth asking ourselves — Are you sprinting in the direction you truly want to be heading? Is your daily grind aligned with your yearly goals?

Integrating Refactoring into Your Coding Routine

“I’m opposed to setting aside time for refactoring. In my view refactoring is not an activity you set aside time to do. Refactoring is something you do all the time in little bursts.” – Martin Fowler

This quote really resonated with me given I spend most of my day writing code.

I’ve seen how easy it is to push refactoring to the backburner. 🔄 Every time I add a ‘refactor later’ ticket, two things happen–

Either I forget about it or, when I do remember, it’s a massive task, because I have to recollect and load up all the context.

If we embed refactoring in our feature-building process it can significantly reduce tech debt.

Keeping Your Manager in the Loop: Balancing Autonomy and Transparency

As a manager or technical leader, while you want to demonstrate that you can operate independently and run your show, it is important to keep your manager in the loop about the progress you are making and the hurdles you are overcoming.

Don’t wait for them to ask for an update. Most managers will appreciate an update even if they haven’t asked for it.

Frequent concise updates are a lot more useful than infrequent lengthy updates.

It’s not only about updating but also about asking for help when necessary. It’s a sign of maturity, not weakness.

Autonomy and transparency go hand in hand in any leadership role.

How Well Do You Know Your Company’s Career Levels?

Have you ever sat down to truly understand your company’s career leveling guide?🤨

As a junior engineer, this was an exercise I often overlooked, only to realize its significance later on. 🕰️

Understanding your company’s different levels and expectations sets the bar for your own growth beyond mere promotion. 🚀

Often, we focus on the final reward but lose sight of the journey. 😵

If you haven’t discussed this with your manager yet, it’s time to take the initiative. 🗣️

An exercise I recommend is creating a personalized career-level rubric. 📝

Against each bullet point, write relevant examples where you’ve demonstrated a particular skill. 💪

You’ll then begin to see a clear picture of your strengths, weaknesses, and the gaps that you need to fill. 🧩

Next, discuss this document with your manager. 🤝

You may be surprised to find misalignments in your assessments. 💫

But, these conversations will give you clarity about your role, your growth potential, and the journey ahead. 🏞️

I guarantee this exercise will reshape your understanding of growth and promotion. 🌱

If you have never done this, prioritize it, understand your career leveling guide, and start mapping your journey.

Remember, not all growth is vertical. Sometimes it’s about becoming more rounded, versatile, and confident in your abilities. 💪🚀

On-call Shifts: Great Learning Opportunity

I have seen junior engineers often dread their on-call shifts or they are frustrated when their turn comes around.

They feel like it’s a burden and a major distraction from their main projects.

But guess what? On-call shifts offer many learning opportunities and can make you a better engineer.

Here’s why:

1️⃣ It’s like a crash course in understanding the production systems and customer issues.

2️⃣ It’s a great opportunity to learn which graphs and metrics to look up while debugging production issues.

3️⃣ It allows you to discover and learn the parts of the system you’re not usually involved with.

4️⃣ It’s an excellent chance to get better at system design, especially at big companies where opportunities to design large-scale systems from scratch are rare for junior engineers.

No doubt, it’s scary at first. 😱 But with patience, shadowing, and a little bit of curiosity, you’ll be amazed at how much you can learn.

So, the next time an on-call shift comes around, go in with curiosity and a learning mindset, it can truly make you a better engineer

“Shipping fast” vs “Shipping fast with engineering craftsmanship”

Building fast or building right? Most likely, the eternal debate of every engineering founder in an early-stage startup… 💭

As a technical founder, I’ve experienced two types of satisfaction:

🚀 The thrill of creating a quick, scrappy prototype that users love.
🏗️ The contentment that follows shipping an improved, refined version of the prototype.

You would be surprised by the kind of joy that comes from rebuilding and refining.

Yes, it’s a struggle to balance speed with craftsmanship. But at the end of the day, accumulating tech debt is a choice.

Getting it right matters. Whether you’re hustling in a startup or working on the next big innovation, don’t forget that quality precedes quantity.

“Shipping fast” gets the job done, but “Shipping fast with engineering craftsmanship” is what keeps us engineers truly engaged.

Climbing the IC Ladder – Why Infrastructure Might Not Be Your Golden Ticket

Here’s a myth – Many engineers working at FAANG companies think that moving to the infrastructure team is the easiest way to climb an IC career ladder to staff+ role 🧗‍♂️

At the outset, it seems logical because infra projects impact multiple teams or orgs by the nature of work. And impact of your work is one of the major criteria for promotion.

⚠️ However, I have seen many examples of engineers transferring to infra teams because they think they’ll grow fast but they struggle because of the unexpected challenges.

Infra projects look shiny from the outside but they have very high technical complexity. 😳

Infrastructure lives at the intersection of multiple systems and developer workflows – hence, infra engineers need to have knowledge of multiple systems and developer workflows.

Most of the infra teams don’t have product managers, and engineers need to play that role. 🎭

💡 Both infra and product roles require engineers to put themselves in the customer’s shoes. But, understanding customer requirements falls squarely on engineers, unlike product teams where PMs and designers provide support.

🕵️‍♀️ Consider these points before committing to what seems like an easy solution. “Tour of Duty” in infrastructure is an effective method to test the waters. “Tour of duty” also gives you an opportunity to be on the other side and build some empathy for infra engineers.