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

This article was part of The Rising Dev newsletter issue #1, published on Feb 1, 2021.

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!

If you enjoyed this article and want all the latest posts, tips, and resources for rising as a software developer delivered straight to your inbox - Subscribe Here.

Follow me on Twitter