Can you Avoid the Software Salary Ceiling by Specializing?


This is a follow up to a post I wrote a couple of years ago: How to Avoid the Software Salary Ceiling.

For better or worse, I didn’t follow my own advice. I unexpectedly got promoted into management, and that’s what I’ve been doing since.

My pay increased by around 30% which was better than any single raise I ever got as an individual contributor. I wrote about management here.

So do I still believe you can avoid the software salary ceiling by specializing?

Specializing might be a good strategy in certain companies, but not anywhere I’ve worked.

Companies where I’ve been employed always seem to hire people as generic software engineers. Sometimes they want people with specific skill sets, like 3D Graphics or front-end web development, but those skills don’t give those people special salary treatment. They’re on the normal engineering career ladder like everyone else.

At these companies, it makes more sense to follow the time tested strategy for making more money: accepting more responsibility.

That being said, I can understand specializing if you’re working as a consultant.

If you’re just a generic web developer consultant, you won’t be able to charge as much as if you specialize in say, WebGL. In the latter situation, the hiring company is trying to accomplish a very specific job, and they usually want to do it quickly because they’re looking at consultants instead of hiring someone.

With those constraints, the company will be willing to pay a premium for your skill set.

I’m sure this is also true to a certain extent outside of consulting, I just haven’t seen it. Or maybe I’m just too low level. I can imagine hiring at the executive level being a lot more specific than at the lower engineering levels.

Another aspect to consider, even if it’s not reflected directly in your pay – I could imagine a company being less willing to get rid of you if you have skills that nobody else on the team has.

That being said, I’ve seen companies make the bone headed decision to get rid of their specialized people anyway, usually resulting in the death of products.

You can’t always expect your company to value your contribution even when it’s warranted.

Job Satisfaction

My post about avoiding the software salary ceiling resonated with a lot of people, I think because it gave engineers hope that they didn’t need to move into management to keep their pay growing.

Many engineers dread management, and I think that even most managers have days where they wish they could come in, put on headphones, and spend the day programming.

That’s definitely been true with me at times, although recently I’ve gotten used to management, and I’m starting to enjoy it consistently.

If you’re the type who wants more money, but you feel stuck because you don’t want to be a manager, let me offer some advice.

1) Give Management a chance.

The managers I’ve seen who hated it didn’t give the job enough time. They bailed and went back to engineering within 6 months.

When you take any new job, you have to give yourself time to acclimatize. The amount of time varies from person to person, but the number in my head is 18 months. If you’ve been an engineer for the last 10 years, how can you expect to adapt to a completely different job in 6 months or less?

18 months should be long enough to develop competence in your new position, and usually confidence in your ability leads to job satisfaction.

My first 6 months were fraught with constant feelings of insecurity that I was doing something wrong. I didn’t have any intuition about the job, and so I had a lot of worry and anxiety about everything I did. Those feelings started dissipating at 10 to 12 months, and it will be interesting to see if that trend continues.

2) Carve out time for stuff you like to do

Management comes with a lot of sometimes unpleasant responsibilities, like performance reviews. You also have to ensure that everyone on the team has work and that nobody is blocked.

But the beauty of management is that you also have a lot of freedom. Your actual responsibilities usually only take 30-50% of your time, depending on your team size. What you do with the rest of your time is up to you, assuming you’re adding value. You can use that time to code, design new features, or to look at data for your product.

Personally, I really enjoy prototyping. I like looking at new technologies, learning new things, and getting stuff working.

So as a manager, I’ve been able to use my prototypes to set the technical direction for our product. In late 2016, I started messing with AWS Redshift, Golang, and Cloudfront logs. This eventually grew into our new analytics pipeline.

Right now, I’m looking at Graph databases like Neo4J, and I hope we’ll eventually be able to use that work to make a better, contextual based search on 3dWarehouse.

Another awesome part of the job is that you now have a team to help you. Are you dreading some task that has to get done? Maybe there’s someone on your team who would be excited by that type of work, and you can delegate.

I actually think one of my favorite things about management is the freedom it gives me in my day to day tasks. I can choose what I work on, and sometimes delegate what I don’t want to work on. Sure there are parts of the job I don’t enjoy, but that was true as a regular software developer as well.

I also think it’s unwise to hand off tasks just because you don’t want to do it. A huge part of your job is keeping your people happy, so you need to ensure that your team member is legitimately interested in the work before handing it off.

Every now and then you’ll still have to “fall on a sword” for the good of the team.


If you’re in the first 5 or 10 years of your career, I wouldn’t worry about any of this. You just need to focus on excelling at your job.

Once you hit the magical ‘senior’ level then it might be time to take stock of your surroundings and set a new roadmap for the future.

I know plenty of people who keep growing beyond senior to staff level engineers and beyond, but that roadmap is even more uncertain than either specializing or going into management.

I couldn’t explain how to get there because everyone I know who did took a different path. To be fair, at certain companies with well established engineering ladders like Google, the journey to staff would be easier than at others.

But in general, I’d say going into management is more straight forward. You get to a senior level, exhibit some leadership ability, and show any measure of social skills, and you’ll be slated as a manager.

Management isn’t for everyone, but I would still give it a chance if you’ve been offered the job.

Let me know how you feel about management, specializing, or progressing beyond the senior level below.

Photo Credit: Joe Lewis