Should Younger Developers be Paid More?

Tuesday Jan 18th 2011 by Eric Spiegel
Share:

If younger developers know hot new technologies, does that justify a higher salary?

“I heard Facebook is paying new computer science graduates over $200,000.”

I was shocked. Were new graduates really getting these offers? The person I was talking to told me a friend of a friend (first warning sign) said he was offered $220k at Facebook just out of Stanford’s comp sci program.

Even if true, this is an anecdotal reference. Perhaps the new grad was top of his class and had unique social networking development experience. Perhaps as an intern he or she created some awesome Facebook application.

Some quick Web research shows multiple survey sources with the average Facebook software engineer making around $120k. Still not too shabby!

Could this mean that there are older, more experienced engineers making less money than new college hires? If so, it wouldn’t be the first time.

This sort of salary game has been played for decades based on new technology cycles. As the next new thing puts pressure on CIOs and CTOs to identify and integrate new technologies into their applications and products, a battle begins for the fresh talent who actually are on the cutting edge.

Lost in all of this are the dedicated engineers who have put blood, sweat and tears into an organization, only to be left behind when technology changes. But is it their own fault? The company’s fault? Or just a natural cycle?

Not too long ago it was client server technology replacing mainframe applications. The cycle continued with web applications, mobile technologies, web 2.0 and social networking.

I was working on a project not too long ago when I found myself with a hiring decision being pushed by a new technology cycle.

My customer wanted to add new features that allowed inventory to be managed not only via the web, but also via their mobile phone. This was just as mobile computing was starting to catch on. All the developers on staff had deep experience with the client server platform. Many of them were even trained to “web enable” the applications.

The web development training was practically off the shelf, with a longer timeline for the “webification” project. But this mobile engineering project was needed ASAP and was bleeding edge stuff at the time. Training classes would not have been sufficient for the level of skill required in such a short period of time.

I worked with a recruiter to search for candidates with the required skills. It turned out there were a couple comp sci programs that were teaching the exact technology we were after. These engineers in their 20’s had software development skills specific to our needs.

The problem was that we were competing with other firms also targeting this new skill set. Our recruiter pushed us to increase our base salary in order to have a shot at this limited number of desirable graduates.

The VP responsible for the customer’s team felt it was justified to pay a premium for these college recruits and insisted we move forward, agreeing to support the budget required for these new mobile capabilities.

Personally, I argued against it because I didn’t see it as a mission critical application and it would throw our salary ranges out of whack. Was it really that important to manage inventory via mobile phones? Wasn’t web access enough?

The VP brushed off my concerns. “You worry too much. The other team members won’t ever find out how much these new recruits are making.”

Oh, sure.

I lost the battle and the hiring process moved forward.

The good news is we landed enough team members to get the ball rolling. I remember feeling pretty good about this. Then the bad news arrived in the form of a knock on my office door.

I cheerily greeted our lead developer. “Hey George, come on in.”

George wasn’t his usual smiling self. He sat across from me, feet crossed, arms crossed.

“I know you told the team we had to find our initial talent outside of the organization because there wasn’t time to train us and this was a more cost effective approach, correct?” he asked.

“That’s right George.” And I added, “Don’t forget I also promised training to qualified team members.”

“You certainly did. But the whole cost effective thing bothers me a bit because I found this.”

George handed me one sheet of paper. I quickly scanned it and saw it was a job posting from an online job web site. I knew immediately by the content that the job description was ours, even though the company name was withheld.

What really jumped off the page was the starting salary in bold black ink. I hadn’t told the recruiter not to include a salary range, so I shouldn’t have been too shocked.

I had initially created the description and the recruiter refined it. I was certain salary wasn’t included in my draft, but apparently it was added afterwards. Whoops.

How the salary ended up there wasn’t important at the moment George was glaring at me. I had to make a quick decision. Should I be honest and admit this was the job description used to hire our recent new college graduates, thus by default allowing their salaries to be approximately known? Or should I lie and say I have no idea if this job posting was from our company?

“So what is this George?” I asked, buying time for my brain to process.

“Is it a coincidence that this job posting is for a locally based company recruiting for the specific mobile expertise we recently hired for? “ George asked, his eyes not leaving mine.

“Well, you know, George, I’m not familiar with all the job postings, but this certainly could be” I hedged.

George frowned. “Look, I don’t usually make a stink about anything, but this starting salary is 30% higher than mine, and I’m the team lead!”

I figured it best to deflect from the job posting question and instead focus on the obvious issue at hand.

“Now George, you know I can’t discuss salary details. But I will say that these new employees were hired with a new job description and title. They are Mobile Application Engineers and this puts them in a different category, so this is like comparing apples to oranges.”

George’s frown deepened. “Oh really? So here I sit with over ten years of experience and a functional expert in our customer’s business and you are telling me it’s okay for some kid with almost no experience to make that much more than me? Come on, that’s not fair!”

“I understand your frustration George. I used to be a mainframe programmer and found myself being usurped by web developers who made more money. What I came to realize is that these new positions weren’t a direct reflection on me. Salaries are driven by the market, so anyone with skills in demand can ask for a premium on what other engineers are making.”

I continued before he could interrupt, “And we are committed to training our team in these new mobile engineering skills. Eventually you will have these skills as well.”

George rubbed his chin, contemplating my response. “Yeah, but by the time we are trained and have practical experience, the market demand may lessen, and we will have missed the boat. Or are you willing to guarantee me a 30% raise once we are trained?”

Wow, that was a good point and a tough question.

“When the time comes and any engineer from the team proves themselves in the new technology required for this newly created position, we will evaluate that accomplishment along with the person’s body of work, as we do in any performance review” I responded.

“The bottom line is that we believe the company is paying you fairly for the excellent work you do.”

George looked down and sighed. “So you are telling me there are no guarantees, and oh by the way, you want me to mentor these new guys on the business requirements?”

“Yep, that sums it up,” I responded, not half as convinced as I sounded.

“Well, that sucks.”

George stood up and left without another word. I felt like I was letting down one of our most promising engineers. He was someone who had the most knowledge about the business we supported and was an expert in the core client-server application. If he resigned, we would have a huge gaping hole. And obviously he wasn’t happy.

I took up the case with my manager and human resources. We ended up restructuring the salary ranges of the “old world” client-server developers, but it still didn’t bring them close to the “new world” mobile application engineers. You simply couldn’t argue with market forces. However, I was able to get a special team lead/analyst category created that put George in the same neighborhood as the mobile engineers. He had a combination of business and technical experience that made him just as critical to keep on board and satisfied.

I wonder if today some of those same mobile engineers are having a similar conversation with their managers at companies like Facebook as social networking experts are hired from the leading edge college programs. The market and technology cycles just keep churning.

What do you think? Is it fair to create new job categories for hot technologies to support the salary bidding wars? Should companies proactively train developers -- or is up to the developers to stay up to date with newer technologies? How else could these situations be avoided?

ALSO SEE: Are these Developer and IT Salaries Believable?

Share:
Home
Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved