How to deal with an "I'm not paid enough to do this task" argument?

Question

I'm the current tech lead and team lead of our development team. We usually function like clockwork (with the intern somewhat behind), but today I encountered a problem that I wasn't able to solve.

We have a relatively big project on our hands. This project is a bit different from the others that we usually do, centering itself not on money, human resources or financial transactions—our usual thing—but instead focuses on a lot of predictive analytics. This is usually the type of project I absolutely love to do, so I got extremely hyped about it.

With the idea of a big, tasty and juicy project coming our way, I was ordered by my boss to pick two developers of the team to work on it while the rest of the team would stay on the usual maintenance/upgrade cycle of our other systems.

Since this project needs a math background that our developers currently don't have, we would pay for them to take relevant courses in the area. It's a bit outside their normal task scope as developers because it's a fairly specific skill.

So, I called the two oldest and most experienced developers I have on my team and presented the project to them. While one of them seemed really interested in it, the other one was... less than amused, to say the least.

"I'm not paid enough to do something like this."

"I'm sorry, what?"

"This is work that needs a lot of really difficult research on math stuff. I'm paid to develop software, not to do this sort of research. If you want me to work on this, you'll have to give me a raise for the extra responsibilities as a researcher I'll have."

And then ... I got stuck.

While it is true that he is a software developer and his job doesn't include academic-level research projects, I'm not sure if he has the right to argue about a raise for those reasons. Since this is basically software R&D, I think it falls inside our current responsibilities as developers. Yes, he will need to learn a few new skills, but this learning would be done on company time, using company resources.

Can someone ask for a raise when they are presented with a problem that is "too hard" for their current position or that demands "extra responsibilities"? How should I address this?

---

Please note that the training will be done on company time and will be paid using company money. If the employee needs 4 hours on a day for a given class, those hours will count toward the worked hours on that day. This is our usual policy for training, so it's nothing new for the employees.

Answer 1

Well, the solution here is simple. Thank grumpy for his honesty, put him back on regular tasks, and bring in the next guy from the bench.

If someone is not interested in a project like this and there are other people available then it is in everyone's interest to put the people on the project that are most interested in it. Giving grumpy a raise is not going to make him more excited about the project, so it is not in your or the project's interest to have him there anyway.

Further down the road you are going to need to make some tough choices, too. I would keep an eye on this developer's attitude and how it affects the team. It could be that you have a cancer starting. If he is actually enjoying his job, this is one of those statements that he will come to regret. But to me, the best result this developer can hope for is that he has hit his ceiling with the team—and that may be ok if he knows your systems, does his job well and does not cause problems. If that is not this person, though, you are going to have to deal with it eventually.

Answer 2

This is something that should have been prevented, not dealt with after the fact. I'm sorry but if you (as it seems, without any kind of previous warning) suddenly change the direction of the employees personal development, and get surprised when this is not the same direction the developer wants to progress towards, the problem is not with the employee.

Is it fair to be grumpy in this scenario? Of course. Is it fair to request a raise? Maybe, maybe not - perhaps the employee is even paid too much. Since the employer and the employee obviously has different expectations on the employee's scope, it's not possible for a 3rd party to say.

Culture matters as well of course - I'm in Sweden FWIW (typically relatively flat hierarchies and empowered employees/weak managers).

Answer 3

So, I called the two oldest and most experienced developers I have on my team and presented the project to them. While one of them seemed really interested in it, the other one was a bit... grumpy, to say the least.

You made a choice to ask the two most experienced developers to take on the challenge. If the one who declined the task had done so without being grumpy, or had presented a well thought out argument, would you just have turned to candidate #3? If so, then do so.

If there is still a place for the developer who declined the opportunity, then assign them that task.

Remember, you aren't asking them to slightly go outside their comfort zone. You are asking them to learn some math that they may see no need for beyond this project. The best candidate may not have been the two most senior developers. It may have been the most junior developer, or even the intern (though I would not plan on asking an intern to be responsible for a long term critical skill).

Answer 4

Let me play the devil's advocate here:

• Your company have taken up a work they have absolutely no competences in.
• This work is in a field that is very much different than most of other fields in software development. This ain't your regular "learn new programming language", this is heavyweight math that even most full time mathematicians fear.
• Your company refuses to hire a new person to lead, instead it believes that theoretical trainings and courses can make up for no experience.
• They have put a hopeless optimist and enthusiast at the helm (you)
• The leader (you) can't even acknowledge that other people might have different goals than he does.

Now, I'm not saying that this is a recipe for disaster. But many disasters have followed this recipe.

Joining your spearheading team is not all roses as you describe it. You say it's about learning, but there is no one with experience to teach you. That means you'll be learning on your own mistakes and in many cases you'll learn wrong. In best case, you'll have to unlearn big chunks of your new knowledge. In worst case, you'll never know what you've got wrong.

There is very high chance that you will fail. There are many ways it can fail, I'm betting on severe time (thus cost) overrun (few hundred %%) so your company will make a loss. Worst case is that client will invoke penalty clauses and your company will lose much more than just your time and salaries, so devs may get fired with reputation smeared. Don't you think that risk is worth compensation?

I've painted the most pessimistic image, but I believe it's necessary to counterweight your optimism.

Let's get back into the last point of my bullet list, which is the only thing that you've personally did wrong. You have taken the decision about what other devs want into your hands. You don't seem to realize that what you see as thrilling, other people may see as intimidating or merely boring. You see it as an upgrade while refusing to accept that others may see it as a downgrade. Or just not a good fit for their work-life balance. Another angle is that you see it as within the scope of "developer" position. The problem is that it is nothing but an opinion. An opposite opinion, that it constitutes a brand new job is just as valid as yours. You have to expect other people not sharing your opinions. It was OK to casually ask if someone wants the new job. But you should have expected "no" as much as "yes".

You also need to keep in mind that a job is always a contract. And as any contract, it takes two sides to change it. The job description is part of the contract. You can't change the job description unilaterally, just like the employee can't unilaterally change his salary. Yes, it is commonly expected for an employee to improve, but that doesn't mean taking up new responsibilities, it means staying competitive in carrying out the ones he was hired for.

The contract can be changed anytime whenever both sides agree to the change. It's as OK for him to ask for a raise as it was for you to ask for a job change. But everyone must be ready to live with the answer.

IMHO his question wasn't a real one, he just doesn't want the new job. And turned the tables on you, so it's you who has to actually say "no". There is nothing for you to handle here, except of changing your attitude about your team sharing your beliefs and life goals.

Answer 5

I do think it is fair to ask for a raise after being assigned to specialist work that requires a specific set of skills that are not common in the workplace. It sounds as if this may be a big data kind of project and those skills are highly in demand and pay much better than the average developer salary. This is also true only if the task will be an ongoing one.

Raises for specialist skills for a one-time 3-6 month project are not appropriate (a bonus might be). Raises for the new permanent Big Data team are. As the lead, you might research the salaries for people with the skill sets you are asking your team to get and see if it might be appropriate to discuss salary increases with management after your team has proven themselves.

However, normally that request would be for the whole team and would generally happen after they have acquired the proficiency, although it could be promised at a certain date later if the skills were acquired.

The way he went about it refusing to get qualified without a raise is generally frowned on. Personally, since you have other personnel to choose from, I would move on to the next person who might be interested. I probably would have polled the team before requesting anyone to see who was interested in gaining these skills and then made my choice from the volunteers after each had a chance to make his case for why he should be chosen. There are not that many people who really are interested in the higher math skills, a more junior person might already have done some study in this area though because it was part of his interests.

Answer 6

Grumpy handled this very poorly. However...

As someone who was a developer for decades, and is now a maths researcher doing a lot of predictive analytics, I kind of see Grumpy's point. While software developers have to be prepared to learn bits and pieces from a wide variety of disciplines in order to do their job, there is a significant difference between a developer and a researcher, just as there is between a manager and a developer. This isn't like he's refusing to learn a new programming language or figure out how to interface with some weird hardware; it's more like he's refusing to do graphic design or manage a team or fly a plane.

Grumpy may be maths-phobic. But it's also possible that he knows enough about statistics and data mining to suspect that it will be a difficult, murky slog. In this particular area of maths, it's very easy to learn some techniques, but it's also easy to apply them in the wrong situations! A high-school student could learn how to do ARIMA, but knowing when it's valid and how to choose the right parameters are more at the graduate student level. A lot of mathematicians don't like statistics, not because it's harder than other fields, but because it's more... fiddly.

Like you, I jump at the chance to learn new maths, and I love my job. But I can see how Grumpy might feel that he's being asked to do something that's just too far outside the role of a developer. As I said, he handled it very badly, and I don't excuse that. But he may have some justification for the way he feels.

Answer 7

Speaking as a mathematician-turned-software developer I sympathize with Grumpy: i.e. I now prefer software development (and I think I'm now better at software development than at mathematics).

On the other hand if I were in Grumpy's place and wanted to say that to you, I would -- and I would without confusing the issue by mentioning salary.

The fact that Grumpy mentioned salary might mean that Grumpy is grumpy about salary, and this project is merely a trigger or excuse for asking for a raise.

So my advice would be to try to separate the issues, even if Grumpy didn't separate them. Ask, "Is Grumpy happy with his current salary? Is he asking for raise regardless of this new project?" Given that he's the one of two oldest and most experienced developers should you offer him an unconditional raise first, and then ask whether he's willing to do this new thing?

And/or can you reassure him about the nature of the new responsibilities? If I were him I might worry about failing. The increased salary might be 'danger money' to compensate me for increased risk or stress or unpaid overtime. For example, will the company be providing enough help (e.g. a domain expert, i.e. a maths mentor) to guarantee his success?

You say this is "academic-level research" but also "basically software R&D" which might be mutually exclusive/contradictory. Apparently you are keener on academic research than he his?

Answer 8

Is it possible that the developer feels he is not get paid enough for the work he is doing now? Usually when people say "I'm not getting paid enough to do this," they mean they feel that they are undervalued in general, and could be a flight risk.

If you're in a position to adjust that, and he is undervalued (or not grossly over-valued), then he might be making a good point, and you can adjust his company goals to reflect that if he does do this research and develops this project successfully, he will get raise this year that will be better than increased cost of living. Propose a percentage beforehand and document it. Or your company might have designations such as 'exceed expectations' that automatically result in a large raise, so tell him that he will get 'exceed expectations' and be compensated accordingly. Money can be a great motivator, and turn grumps into happy campers.

Or he might be saying he really doesn't see himself as a math researcher. If that's the case, ask someone else to do it and present it to the team. If it's really just research, you might be able to ask your product manager or business analyst to study the information and relate it to the dev team in requirements.

Answer 9

While I am really, really not a fan of this guy's phrasing - in software development especially, we are paid a pretty decent amount to do what we do, and what we do often entails researching to figure out how you're going to do the thing that you said you were going to do - I think there is a kernel of truth to what he's talking about. No, you shouldn't give him a raise. There is a point though to where asking a person who doesn't work with mathy things to do mathy things is going to be a bad time for both you and them.

I actually have run into a semi-similar situation in my career as a developer. I mean, in some ways it's not exactly the same at all, but still... as noted, I am a developer. I develop stuff. If you want to implement some business logic and get widgets on a web page to jump around and do stuff, I am your guy. I've worked on the back end and the front end, built middle-tier web services, and have picked up new languages and frameworks on the fly when I've needed to. What I don't do - I should say, what I don't do well - is design. If you ask me to design a web page, I will do it, don't get me wrong, but I will do it telling you that I don't have training or expertise in this and you might not like the results. In the end I think you're going to be better off hiring an actual designer and then using me to take that person's design and implement it.

So what I would say to do here is to take this guy as if he's telling you this thing instead of "pay me more", because in a sense that kind of is what he's doing. The issue here really isn't so much that software devs get paid X and doing math should get you X + 10%, it's that some software development doesn't really require math and so asking people to do a lot of it means that you are going to wind up with less than stellar results. Depending on the situation, I might recommend:

• Looking through the skillsets of your other developers and seeing if someone else on your team has a more mathy background, or is willing to learn what you need to learn. You might even sell them on the notion that this represents a new tool that they can learn and take with them to future gigs (see below!). The biggest downside here is that in addition to the extra time spent on ramping things up (and in the process, possibly learning new architecture and frameworks), that particular dev is also going to be slowed down by having to learn and understand the math you want to implement.

• Bringing in an analyst to figure out the equations and then having your existing devs implement the equations into code, just the same as they'd do with any other piece of business logic. This has the downside that the person who knows the math isn't in the end writing the math into your system, but that can be pretty easily resolved by putting an emphasis on test-driven development (which you're already doing, right? Right?). This method also has the advantage that, if you're working in, for example, finance, you can grab one of the numbers people out their department: chances are, they're going to know this stuff better than practically any s-dev you can bring in off the street because that is their job.

• Bringing in a third-party consultant to handle nothing but the mathy portion of the code, and then just kind of locking that part up to never be touched again. This is also problematic for a lot of reasons - first and foremost, the day I find code that doesn't need to be refactored down the line is the day I introduce myself to the most psychic developer ever - but depending on what it is you're trying to do, this might be the way to go about it. That other guy might cost a bit more than what you're paying your current devs, too, but, well, it's a specialized sub-field.

Like I said, I'm not a really big fan of the phrasing here, and perhaps that in and of itself means you need to have a sit-down talk with the person who is saying this (I would, as an aside, be kind of wary of him not adhering to the Bus Factor and it may be time to walk through some of this guy's code, not as punishment but because IME people who think in terms of pay grades in this industry also think in terms of doing things to make themselves irreplaceable). I don't think he's necessarily wrong though.

Answer 10

You mention that grumpy is one of the oldest developers. I wonder how old? Years ago I had someone working for me who was in his mid 50s, he was a competent developer, he was happy in his work, but he refused to take on any extra responsibility. It turned out there was a history, he had had to take a career break in the past because of stress, he knew his limits, and he didn't want to over-reach them. Respect his judgement and use him for the things he does well.

Answer 11

I'd say the answer depends on how accurate the developer's assessment is.

If his job description actually does include doing this kind of work, and his pay rate is appropriate for that, then his claim is inaccurate.

On the other hand, his job description and/or pay rate don't match the new type of work, then they should be adjusted to accurately reflect that.

In general, even if a company trains an employee to a new job description, that doesn't mean the company should not then adjust that employee's job description and pay rate to match. Some companies may try to do that, but that's not appropriate and is prone to decrease morale and eventually lose employees.

From your comments, it sounds like you aren't sure. Rather than (as some other answers here have suggested) making his statement into a refusal or bad attitude, I'd suggest treating it as an adult respectable suggestion, and responding in an adult professional way, by acknowledging the suggestion and consulting people who would know what is appropriate for that type of work, and then getting back to him about what you found out about that.

Answer 12

Employee states he doesn't want to do work he wasn't hired to do, and provides a compromise: More money and he'll do the work anyway.

You need to reject the more money option. If he doesn't want to do the work, he'll likely be unhappy doing the work despite the additional money, and unhappiness can be contagious. Additionally, it sets a bad precedent for people who want to do the work but now know they can ask for a raise before learning something different.

Treat this like any other employee that doesn't want to do a job he wasn't hired for. And how you handle that depends on many other details, but in this specific case, you thank him for the time and ask for a different volunteer, because this is the kind of project where you want to work on with people who want to work on it.

Answer 13

I think a couple minor points related to the question haven't been asked/answered by other posters (as of this posting):

• What is the title of the old position?
• What does that position get paid? (Market rates)
• What is the title of the new position?
• What does that title get paid? (Market Rates)
• What is the difference in pay between "Senior Developer" and "That Title"
• Is it worth the time/effort for him to get the pay difference?

What is the title of the current position? Different titles get different pay rates... there is a difference between a Developer and an Engineer... a Senior Developer and Senior Engineer. What is the new title called? Mathmatics Developer? Researcher Developer? Senior Research Engineer?

What does someone of that title get paid, in market rates? There are some positions that are "harder" but get paid less... Think Researcher at Universities... lots of people trying to get the positions so demand lowers market rates.

What is the difference between current "Title" and "New Title" in the market? If it's $1000/year... that's a different conversation from it's $75000 a year...

Which means... is it worth it for "Grumpy Dev" to learn "Math Research"? Yes it's true that part of a Developers Life is learning new things... it's also learning new things that are valuable. Either in monetary terms (Pay Raise) or in other terms (Career progression, new opportunities, new technologies)...

Sir Grumpy, to me, has made it clear that his main priority is money. If he wants to be a Front End Developer and you are trying to make him an Applied Science developer... it may not be worth it to him to switch - given the same pay scale. The only way for him to consider it worth it would be $$$. Either that, or he's not interested and is passing the responsibility to you. Do Market Rates align with his expectations? Your expectations?

Answer 14

I feel that an answer to your problem has already been provided - that if you have a person on your team uninterested in a project going in a new direction, but you need someone with experience to help, then you go to the person with the next-greatest experience after him, or maybe even consider looking into their specific skills (does anyone on your team have a math background?) and let him continue doing the maintenance your team usually does.

But to answer your question - 'is this a fair request?' - it is fair of him to ask for it, but not at all required of you to take it up any further than that.

If you have done your due research and made sure that the pay rate for a person of his experience in his position is meeting market values, then there's little room to argue that a permanent raise is in order.

Also, consider the full implication of his title - a Software Developer is expected to perform some research and development when it is relevant to his position. Up until now, it hasn't been. But since your team is being tasked to implement this new type of program, now it is part of the job, and declining to perform those tasks means declining a part of his job.

As of right now, that's not a damning issue - you have other developers who you can set on this task instead. But if your team continues to need developers who have some understanding of this type of math, this employee may become a liability if he isn't willing to learn. So keep that in mind.

Note that whether or not it is within his job description also depends on his contract - many contracts have a clause for 'any other tasks required to perform your job', which includes additional training like this.

Answer 15

What your teammate is asking for is not fair -- at all.

Learning new skills is part of any job, especially today in the tech industry.

Your company is offering to pay for training, so it's not like your teammate is being thrown in the deep end.

Most people would appreciate the chance to expand and improve their skills at little or no cost, and be able to essentially learn on the job.

Your teammate's response is frankly insubordinate and toxic. You don't need anyone like this on your team.

This issue should be escalated to a manager or someone who is responsible for evaluating your teammate's performance.