Hello, I'm Rick! Welcome to the premier issue of my newsletter, where I share career experience, insight, and strategy for getting promoted and rising as a software developer. If you're already a subscriber, thank you so much for your support. If you're not - subscribe.


What a 20 Year Career in Tech Has Taught Me About Getting Promoted

I started my career in the late 90s as a software developer. At the time, my goals included being good at what I was doing, adding value to the people I worked with, and being rewarded for my efforts through promotion to more challenging roles. A few things have changed since I started my career. Like the various titles between a beginning developer and a more senior role now being better defined—somewhat. But the challenge of finding the path from one level to the next is still varying between companies.

I’ve learned a ton about rising as a developer. Many of these learnings have seemed counterintuitive at times. Yet, they all yielded observations, and fundamental principles that I think will help you execute on your rise as a developer.

The Challenges

The topic of promotions, especially in tech, can be very confusing. Employee count, stage of company growth, company culture, and a company's leadership experience may all have a role in how or when you might be eligible for a promotion. And the methodologies and philosophies around promotions can differ from company to company—your strategy for rising in one company might not translate to the next.

Consider this, based on an article by Indeed.com - with data from US Business Dynamics Statistics, larger firms (1000+ employees) employed nearly half of all US workers. In contrast, small to mid-sized firms (less than 1000 employees) employed most of the rest. However, the narrative regarding promotion paths comes mainly from the larger companies where the different job levels are better defined. As a result, roughly half of us in the US alone, especially those newer to their careers, may be lacking a well-defined path to career growth and promotion.

There is another variable that will impact your rise. You might be “re-leveled” due to a merger, an acquisition, or after a company reorganization. You can even promote yourself by leaving one company to join another. And you can get leveled back to where you were previously by joining yet another company. I’m a Director level employee at the time of this writing. If I wanted to join Facebook as a Director, I would need to be a VP level candidate when applying, and I would be re-leveled from VP to Director if hired.

None of this is necessarily good or bad. However, it emphasizes the need for awareness when devising your strategy for rising as a developer.

Where to Focus

When I started my career in software development, the situation around titles was quite a mess. As a contract developer, folks described me as a webmaster, web developer, and UI/UX Designer. Eventually, those titles evolved to become more technology-focused; I was a Multimedia Developer for a while when Flash was popular, then a Sr PHP Developer when PHP was the language du jour.

As I worked on larger and more complex systems for scale, titles like Software Engineer came into play, then Sr Software Engineer. These changes were not necessarily always promotions. A lot of them derived from the fact that companies didn’t have these paths figured out. Many still don’t.

At the time of this writing, I’m a Director of Engineering leading managers that lead teams—I’m still learning. And despite the challenges that came with finding and executing on a path to a more challenging role, a 20+ year career in software development has taught me that there are ways to manifest what you desire and deserve.

Here are a few strategies that I think make you promotion worthy.

Aim for Impact Over Output

Early in my career, I paid far too much attention to work output. I even volunteered to take on more work than I needed and relished working late nights and weekends to get projects across the finish line. I’ve seen this same pattern in others; we all wanted to be that so-called 10x developer.

This kind of effort might be helpful in a small startup for some time, but it’s not how you make an impact, and it’s not how you rise as a developer. The hard truth is companies can purchase output by employing freelancers, contractors, or staff augmentation agencies. Therefore, the output is not necessarily a promotion metric.

The impact is what matters, and I’ve learned this can mean different things in different companies. Here are a few areas to consider when seeking to focus on impact over output:

  • Understand as much detail as possible about the problem or challenge you are trying to solve, finding the “why” in what you are doing can often help you propose a smarter or faster alternative.
  • Share your work early and often, especially for projects that take longer than usual to complete. Regardless of how confident you may feel in your approach and solution, getting extra eyes on something can reveal a possible improvement or expose a risk early.
  • Look for ways to automate tasks you are repeatedly doing. Imagine others coming along in the future to expand and improve on your work. Look for efficiencies you can put in place, so their job is quicker and less complex.
  • Remove yourself as a single point of failure by transferring knowledge. Share and document what you know, think of the edge-cases and nuances surrounding your work and capture the context needed for others to pick up where you left off.

Work on the Right Things, the Right Way

I once worked for a video game startup where I tackled many challenging problems, and I led others in doing the same. Eventually, I had a playbook of approaches for the various challenges that came up. I felt like a hero—I knew I was good at this.

Later in my career, I worked for a much larger and established video game company, where I unleashed my playbook on folks to save them from their inevitable path to failure, so I thought. My so-called playbook was all wrong. It was like trying to execute football plays on a baseball field of tennis players. My playbook eventually became something more flexible, more rubric than a playbook.

I learned that the right thing to work on and the right way to do it are moving targets. However, you can set some constraints to ensure you are thinking in a way that allows for flexibility while remaining as close to “right” as possible.

Here are some questions to ask yourself to help filter for the “right things”:

  • Is what I’m working on prioritized against other things I could be doing? Were these projects part of a planning meeting with group input on prioritization?
  • Is this work captured and tracked somewhere for transparency, with a thorough understanding of the requirements and success criteria?
  • Does my team know this is what I’m doing? If I pivoted while responding to a production issue, did I broadcast this pivot?

Here are some questions to help filter for the “right way”:

  • Will other teams use what I’m building, and should I consider their specific needs?
  • What are the requirements for scale? Is what I’m building going to be used long term, or is it part of a first phase iteration? Will it be used by hundreds, thousands, or millions of people?
  • Do we have the internal expertise, bandwidth, and interest in building, operating, and maintaining this, or should we consider buying a solution instead of making our own?

The answers to the questions above won’t always be obvious, even after working through them with your team. Often you will only have answers to a few and the need to make progress right away.

The most important part here is the conversation. Asking these questions to yourself and your team increases the odds of working on the right things the right way and is another driver towards impact over output.

Ruthlessly Prioritize Personal Growth

It should be no surprise that continuous learning will always be a significant component of your success. I knew this early in my career and embraced it, but I missed something that slowed my growth for a bit; I wasn’t asking for enough feedback.

I now realize that feedback is a multiplier to personal growth. If you are looking for a way to accelerate learning and development, this is it. I didn’t learn this until I received enough critical feedback that stung, forcing me to throw my arms up and set my ego aside, and focus on gathering and integrating as much input from others as I possibly could.

Share everything and share it early, not just the work you are doing. Share your point of view, your gut feelings, your decisions, and your decision-making process. Share how you approached a conversation or how you are thinking of conducting a conversation—share it all with folks who are more experienced and listen to what they say.

In addition to being intentional about always learning, I made it a point to seek feedback around what I should be doing less and what I should be doing more. I didn’t judge that feedback; instead, I analyzed it, threw away some, and fully integrated the rest. Then I asked for more feedback.

Every company and team you join is a school. Look for schools that will help you explore your capabilities and help you fill any gaps. If you’re not feeling challenged, or getting enough feedback, find a better school.

Focus on Team Over Self

There’s this urge to compare ourselves to others, and look at the more technically experienced developer next to us and wonder about the things we should be doing to be like them. As I worked within different companies and different teams, I found myself doing this very thing. It was a waste of time and emotional energy.

I once worked with a very talented database engineer. I would partner with him on building out specific features, and everything we did together came out great. I envied his abilities, and I worked hard to learn as much as I could about everything he did on the database side so that I could be like him.

He did not do the same. He learned enough from me to get by, to pick up where I left off if needed but not much more. When I asked him why he simply stated, “That’s not my role; it’s yours.”

He saw us as a team. We augmented each other’s abilities, and together we were greater than the sum of our parts—I should have focused more on bettering my role like he was.

Once this clicked, I realized there were differences between myself and others in similar roles, we didn’t all know precisely the same things, but we augmented each other. We could support one another around the differentiators when needed.

Know your role and what the expectations are. Learn about what others do and focus on getting better in the areas where you are accountable. Having a team with varying capabilities and skill levels creates a Venn diagram of possibilities. You will all overlap in many places, but your differences are where insight, innovation, and creativity happen.

Finding your difference and strengthening that can elevate your team as a whole.

Build Organizational Awareness

As you progress in your career as a developer, you will start to detect a pattern. You will find that some people don’t care about what is happening beyond their immediate team, while others do.

Once I got into management, I saw this pattern from a different angle. I would receive complaints from folks about having been asked to sit in on a meeting or discussion with very little to do with their responsibilities. Others complained about being excluded from such discussions. They wanted to be a fly on the wall, listening in and learning a bit more about what’s happening elsewhere.

Finding that balance between avoiding distraction and building awareness can be challenging, but I would be lying if I said there wasn’t some kind of correlation between promotions and what side of the line you choose to sit on.

What I learned here is to avoid both extremes and find a middle ground. Lean on your leaders and team to help protect your time, to allow you to focus on doing great work without distraction.

Also, lean on them for additional insight and express interest in learning more about what goes on beyond just your team. By allowing a bit of both, you strengthen your filter and learn to focus on the right information, and information is power.

In Conclusion

There is a ton more to unpack here, and everyone’s situation is different. I didn’t learn or do everything I shared above in one single shot. I did a little as I knew a little—it all stacked into a strategy over time.

A little bit of what I shared above got me promoted. Larger chunks of it eventually got me into management. Better still, embracing and learning even more of it helped me get others promoted.

I learned that sometimes you need to claw to get to that next rung in the ladder, and other times you’re lifted. As you execute on your rise as a developer, remember to lift others on your way up!


This was a very informative thread by @curtiseinsmann, where he shares how he went from a software engineering intern to a tech lead at Amazon in about 5 years. He was also kind enough to answer a few questions related to his journey.

Here's some wisdom he shared:

  • "Get good at one compiled language and one scripting language. E.g., Java and Python. After you know the fundamentals, picking up different languages becomes easier."
  • "When I first started, I felt like an impostor. My peers were better coders. But my soft skills allowed me to overcome my technical incompetency. I now realize that companies look at potential. So I began to trust that hiring me was a good decision."
  • "I acknowledged that I don't know everything, and will never know everything. I acknowledged my incompetency and strived to improve. I developed the skills required to deliver on the job, and became OK with not having unneeded skills."

Check out his thread for more. Thank you @curtiseinsmann!


I've been re-reading one of my favorite books on the topic of scaling technology - Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations by @nicolefv, @jezhumble, and @realgenekim. You can find it here.

The topic of High Performers vs Low Performers (in the context of software delivery teams and delivery performance) stood out to me much more than before, particularly in its correlation to new work vs unplanned or rework. Check out the chart below:

Source - Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations

What this made me think about:

  • First, not a surprise that unplanned work, rework, or other work like meetings and routine maintenance are more prominent within low-performing teams.
  • Second, this book was published in 2018, so the image above is based on observations before or at that time. We are in 2021 now, I'm wondering if the ~11% difference in new work between high and low performing teams has widened or narrowed. Worth more digging here.
  • Third, I feel like there's a cyclical pattern here somewhere. If you measured teams at certain points in time, you might find them as high performers. Then low performers at another point in time, bouncing between the two due to varying complexities that come and go. In which case, the goal is to average out on the high performing end as much as possible. Wasn't sure if that's the actual observation being captured here.
  • Finally, this all reminds me of the notion (or rule) that you don't focus on adding things to speed teams up. Rather, you focus on removing or automating the things that slow them down.

Good stuff to ponder here if you're a developer looking for where to prioritize focus.