Why do projects managers have higher pay than developers?

[Amandeep Singh]

Even though developers have higher in depth knowledge and have to stay constantly update. or very common in world BOSS always have higher pay.

[Tim Cooke]

More responsibility, and accountability = More money.

[Junilu Lacar]

That's another reason I like Agile. Managers in organizations that use agile methods become problem solvers, obstacle removers, mentors, coaches, and enablers. There are no "project managers" in the traditional sense because the whole team is responsible for delivering the product. Accountability may still be with the Product Owner but that's a whole 'nother story.

I think the good Agile teams tend to move away from the "Boss is paid more" mentality and more towards a "get paid at your level of performance" where you are assessed mostly on what you have accomplished with respect to the expectations at your current pay grade. I think this levels the "paying field" more, so to speak. For example, while their role is slightly different from the traditional Project Manager role, the Scrum Masters in my group can be at any level. I have had Scrum Masters on my teams who were at least a couple of pay grades lower than myself and other developers. That's not to say that they are not compensated fairly. I have been very vocal in the past about giving promotions to the Scrum Masters who did their jobs well.

As for the managers who become problem solvers and servant leaders, I have no problem with them getting paid more. They do a lot of the work that I'd rather not do as a technical person anyway and as long as they leave me to do my work the best way I see fit and as long as I get paid what I think is fair for doing my job, I really don't concern myself too much about whether other people are getting paid more than me. I trust my managers to be the judge on what's fair in that respect.

[Jayesh A Lalwani]

This is a side effect of how upper management sees programmers. Programmers are considered as "resources". in the mind of the upper management, the manager is doing the work using the "resources" given to him. The programmer barely counts as a person. you are a machine. If the manager is able to manage more people and do it efficiently, s/he is going to get more work done. The more work done at lower cost, the higher the managers pay.

[Amandeep Singh]

The manager is working in Outlook and Word, Excel all day. Is that a difficult skill to achieve, communication yes needed not a big deal ? Why this is a expensive skill than technical skill?
i have seen programmers more smart and intelligent.

Ofcourse programmers do work longer hours than managers. There is a reason for this because programming expertise level is much higher than managing level.

i dont know if evryone will agree here because i dont see it fair.

[Paul Anilprem]

Amandeep Singh wrote:The manager is working in Outlook and Word, Excel all day. Is that a difficult skill to achieve, communication yes needed not a big deal ? Why this is a expensive skill than technical skill?
i have seen programmers more smart and intelligent.

Ofcourse programmers do work longer hours than managers. There is a reason for this because programming expertise level is much higher than managing level.

i dont know if evryone will agree here because i dont see it fair.

[Tim Cooke]

Amandeep, I think your assessment of a manager role is not entirely fair. You say:

Amandeep Singh wrote:The manager is working in Outlook and Word, Excel all day. Is that a difficult skill to achieve

Which is a bit like saying "The mathematician is working with paper and pencil all day, is using a pencil such a difficult skill to achieve?". You see how you are missing the point by a mile right?

Communication is a non trivial skill too. I've heard it said a number of times that the thing that differentiates 'normal' people and very successful people is the ability to deal with other people. Those 'people skills' are very valuable and doesn't come naturally to a lot of people.

Programmers don't necessarily work longer hours than managers, it works both ways a lot of the time so let's not dwell on that.

I suspect the reason you 'don't see it fair' is due to your own experience which is making you feel somewhat bitter about the topic. Hence this little rant. In my workplace, I have no interest in learning what my colleagues around me earn. No good can come of it. Either I'd feel resentment (as you do) that a person earns more than me, and I'm of the opinion that they shouldn't. Or if I earned more than someone then I'd feel guilty / awkward if I liked the person, and smugness / self-importance if I didn't like the person.

I recommend you forget about what others around you earn, and worry about whether you think you are suitably compensated for your own work.

[Amandeep Singh]

Very brilliant reply.

In two lines i will say then project management is much easier than progamming. Programming is brain storming task compared to project management.

[Tim Cooke]

Project management, and programming require a different set of skills. One who might be skilled at one, may not be skilled at the other.

One reason that managers may be paid more in some organisations is that it's quite common for programmers to be 'promoted' into management, therefore receiving a wage increase.

[Bear Bibeault]

Amandeep Singh wrote:Ofcourse programmers do work longer hours than managers.

If this is the case, one of you is doing it wrong.

[Jeanne Boyarsky]

Amandeep Singh wrote:In two lines i will say then project management is much easier than progamming. Programming is brain storming task compared to project management.

I dont' think that it true. They are different; I don't think one is harder than the other.

Project management (done well) involves problem solving. How do you deal with dependencies, impediments, etc.

[Paul Clapham]

Amandeep Singh wrote:In two lines i will say then project management is much easier than progamming.

I found the opposite to be true. Programming is easy for me, management is not. Fortunately I had good managers throughout my career and none of them ever made the mistake of trying to make me into a manager.

[Junilu Lacar]

Paul Clapham wrote:I found the opposite to be true. Programming is easy for me, management is not. Fortunately I had good managers throughout my career and none of them ever made the mistake of trying to make me into a manager.

Hear, hear!

My experience exactly. Well, one tried to get me on the management track but I politely but firmly turned him down. "I will stay on the technical track, thank you very much." And that has made all the difference for me.

[Maneesh Godbole]

I am yet to encounter any PM who could actually 'manage' the project.

[Joe Bishara]

Managing people is much more valuable to a business owner than managing software. I read somewhere that managing people is like herding cats.

[Henry Wong]

Maybe it is because I am jaded. Or perhaps, I still have a strong belief in the laws of supply and demand... but unless your boss is related to the owners of the company, or there are some weird union rules or laws in place, he/she is getting paid more because that is what the market demands.

It doesn't matter what skill set someone has for a position, if there is a healthy supply of people who can do that role, and is willing to get paid less, the salary for that position is going to get downward pressure.

Henry

[Satyaprakash Joshii]

Bear Bibeault wrote:

Amandeep Singh wrote:

Ofcourse programmers do work longer hours than managers.

If this is the case, one of you is doing it wrong.

That is a common scene in IT industry. As per you one of the two is doing the wrong. Being a developer I would like to know what is the wrong which the developer is doing here?

[Bear Bibeault]

In short, allowing themselves to be exploited.

[arulk pillai]

It is very hard to generalize. There are Java developers especially in contract roles earning more than PMs. Also, programmers who know exactly what they are doing need not work very long hours. It is generally longer than 8 hours, but there are PMs who work long hours as well.

Also, often it is much easier to work with technology than with people.

[Satyaprakash Joshii]

In short, allowing themselves to be exploited.

Ok but how does one come to know in a situation whether one is being exploited.

[Bear Bibeault]

Are you routinely being expected to work long hours with no extra compensation? If yes, you are being exploited.

[Satyaprakash Joshii]

Are you routinely being expected to work long hours with no extra compensation? If yes, you are being exploited.

Yes but expectation from resource to work long hours routinely can happen for not 1 but 2 reasons.Either the resource may be exploited or the resource is given task which he does not complete on time because is lack of skills. How can one judge which of the 2 reasons it is?

[chris webster]

Satyaprakash Joshii wrote:Either the resource may be exploited or the resource is given task which he does not complete on time because is lack of skills. How can one judge which of the 2 reasons it is?

Either option is still bad management. If you have the skills to complete task X in 100 hours, but your manager only gives you 40 hours, then I see two explanations.

1. The job can be done in 40 hours, but not by somebody with your skills. In this case, your manager should either give the job to somebody else or give you the support to finish it quicker, or change the job to fit the available resources (time, skills). Of course, it's possible that they don't realise you don't have the skills, in which case they need to look at how they select people for their team.

2. The job cannot be done in 40 hours, in which case they are just being stupid in expecting you to achieve the impossible. Again, they need to match the work to the resources they have available.

3000 years ago the pharoahs built the Egyptian pyramids using tens of thousands of slaves, but these days you'd use a skilled construction crew. It's stupid to try and build 21st century computer systems using Bronze Age management methods. And you are not a slave, so don't behave like one.

[Satyaprakash Joshii]

chris webster wrote

The job cannot be done in 40 hours, in which case they are just being stupid in expecting you to achieve the impossible.

How can one really conclude that the job cannot be done in 40 hours. There will be some resource for whom the job cannot be done in 40 hours but for another super intelligent resource it might be a 15 hour work.

it's possible that they don't realise you don't have the skills, in which case they need to look at how they select people for their team.

I did not say for "don't have the skills', some resources have the skills to do the task but may take few hours more to complete it.

It's stupid to try and build 21st century computer systems using Bronze Age management methods.

Completely agree.

[chris webster]

If you can't do the job you've been given in the time you've been given, then you and your manager need to take responsibility for solving the problem. You need to have the professionalism to explain why it can't be done, and your manager needs to be professional enough to make better use of the time, budget and people they have available. It doesn't matter if some hypothetical genius could do the job faster, unless that genius is on your team, in which case they can explain to you how to do it faster or your manager can give them the job instead.

As for working long hours without pay, you are responsible for deciding if you want to do this. If you think this is benefiting you in some way, then don't complain. If it's not benefiting you, don't do it. But every time you passively accept being bullied into working for free, you are helping to perpetuate an unhealthy working culture not just for yourself but also for your colleagues. If you don't want to be exploited, don't let yourself be exploited. You and your colleagues are people, not "resources", so try treating each other like people.

[Satyaprakash Joshii]

As for working long hours without pay, you are responsible for deciding if you want to do this. If you think this is benefiting you in some way, then don't complain. If it's not benefiting you, don't do it.

But how will the resource come to know whether he is taking more time in completing the work and it should have taken or whether he is being exploited.Is there a way to determine this?

[chris webster]

If your own professional experience doesn't give you a good idea of how long a task should take and you are regularly taking longer than expected, try asking more experienced colleagues what they think. And if you are regularly taking e.g. 80 hours to complete tasks your manager says should only take 40 hours, then you and your manager are definitely in the wrong job.

[Jeanne Boyarsky]

Satyaprakash Joshii wrote:

As for working long hours without pay, you are responsible for deciding if you want to do this. If you think this is benefiting you in some way, then don't complain. If it's not benefiting you, don't do it.

But how will the resource come to know whether he is taking more time in completing the work and it should have taken or whether he is being exploited.Is there a way to determine this?

Do you normally take more time for tasks that the average developer? That's how you know if you are being slow. However, some people are faster than others. The solution isn't to work more hours to get the same work done. If I work twice as fast as you, does that mean you work an 80 hour week to keep up forever even when no problems arise?

[Satyaprakash Joshii]

80 hours to complete tasks your manager says should only take 40 hours, then you and your manager are definitely in the wrong job.

It is easier to judge between 80 hours and 40 hours but judging between 40 and 45 hours is the one that is difficult.

[Claude Moore]

chris webster wrote:If you can't do the job you've been given in the time you've been given, then you and your manager need to take responsibility for solving the problem. You need to have the professionalism to explain why it can't be done, and your manager needs to be professional enough to make better use of the time, budget and people they have available. It doesn't matter if some hypothetical genius could do the job faster, unless that genius is on your team, in which case they can explain to you how to do it faster or your manager can give them the job instead.

That's interesting. I wonder if speed in programming is always a crucial skill. Of course, if one takes always twice to get his or her job done with respect to the average of his or her colleagues, that's a real problem. But a manager should evaluate quality of the job as important as speed. Times ago I worked with the hypothetical genius (nice definition !) you talked about, who always worked fast and furious. As result, management gave him with a lot of works, until they discovered that code was, in turn, filled with bugs.

[chris webster]

Claude Moore wrote:I wonder if speed in programming is always a crucial skill...

No, of course it isn't. "Doing the job", in my view, includes doing it to the required quality i.e. finishing in half the time but with twice as many bugs is not satisfactory. The problem is that too many people focus on what is easy to measure - time taken - rather than what is important i.e. quality, not least because that's how budgets tend to be calculated i.e. you can afford to pay for so many developer-weeks of effort, regardless of what quality is delivered at the end. In many workplaces it's common for developers to be chastised for taking too long to finish a task, but less common for them to be criticised for finishing on time but with too many bugs, because hey, we can always fix the bugs in the next sprint (until the money runs out). Not saying this is the right approach, but it seems pretty widespread.

[Jeanne Boyarsky]

Agreed. I wouldn't consider a bug laden feature to be "finishing the job"!

[chris webster]

Satyaprakash Joshii wrote:

80 hours to complete tasks your manager says should only take 40 hours, then you and your manager are definitely in the wrong job.

It is easier to judge between 80 hours and 40 hours but judging between 40 and 45 hours is the one that is difficult.

It sounds like you are very concerned by this question of how to estimate how long a task should take. Remember some of the advice people gave in your previous posts on this topic, and see if you can improve your accuracy and confidence in your own estimates. This will help you to feel more confident in negotiating realistic deadlines with your manager.

[Satyaprakash Joshii]

It sounds like you are very concerned by this question of how to estimate how long a task should take. Remember some of the advice people gave in your previous posts on this topic, and see if you can improve your accuracy and confidence in your own estimates. This will help you to feel more confident in negotiating realistic deadlines with your manager.

The advice in that old thread had helped me become a better resource. Now I estimate better but I found that it cannot be accurate but can be near. Example suppose it is a 40 hour work. Predicting it incorrectly as 20 hours or 80 hours would be wrong but mostly I would be able to predict it as 40 + 5 or 40 -5 which is quite near to actual but I feel predicting very accurate might not be possible. Is it true that we can predict very near but not accurate or it is otherwise?

[chris webster]

Satyaprakash Joshii wrote:Now I estimate better but I found that it cannot be accurate but can be near. Example suppose it is a 40 hour work. Predicting it incorrectly as 20 hours or 80 hours would be wrong but mostly I would be able to predict it as 40 + 5 or 40 -5 which is quite near to actual but I feel predicting very accurate might not be possible. Is it true that we can predict very near but not accurate or it is otherwise?

In my experience as a developer, yes. It sounds like you are estimating tasks within about 10-12%, which is probably as good as most people manage. If you are consistently under-estimating by about 10%, then you probably need to recognise that and adjust your estimates accordingly. But a 10% margin is pretty good compared to the catastrophic time/cost over-runs that afflict many IT projects.

Estimation is notoriously inaccurate in software development, which is why some people have different ideas about how or indeed whether to estimate e.g. Scrum Estimation And Story Points, Agile Estimation Practice, MSDN Agile Estimation Techniques. Estimating a task by its relative size (story points) is fine, but in the end most managers/customers still want to know when you will finish a task, not how many story points it will be.

As a developer, I try to estimate within a margin of a couple of hours - anything less is too variable to be consistent about e.g. a ten minute task can easily blow up into an hour: if somebody gives you a task that looks tiny e.g. fixing a typo, you need to factor in all the ceremony that surrounds the task - checking code out/back in, running any relevant tests, any relevant conversations, etc - so a job that looks like it should take 10 minutes can easily take longer. So where possible I'll try to bundle small tasks to make a sensible block of work. There is also a lot of evidence that constantly switching between tasks is counter-productive, so that's another reason to bundle your work into sensible chunks of half a day or so.

Of course, everybody involved in the estimation process is making similar adjustments and second-guessing each other e.g. see this translation table for programmer's estimates, which just adds to the problem of inaccurate estimates. And on some projects it doesn't matter how long you think a task will take, because your manager will just tell the customer what they want to hear anyway. But you should at least try to make your own contribution as honest and accurate as possible, even if we all know that it's hard to estimate accurately.

[Jayesh A Lalwani]

You can have an accurate estimate, but it won;t be precise. You can have a precise estimate, but it won;t be accurate. There is no such thing as a precise, accurate estimate for a non-trivial job

For, example, you can estimate that you will be done next week. This could mean that you might finish by Wed, or you might finish by Fri. You are not being precise, but you are being accurate.
Or, you can estimate that you will be done by 2:32pm on Thursday. This is a precise estimate, but you will most certainly be done before that time or after that time. You are not being accurate

The goal behind providing estimates is to maximize for precision and accuracy as possible. 100%precision and 100%accuracy is impossible. Going for 100% accuracy and 0% precision is useless (you are really saying, I'll be done when I'm done). GOing for 100% precision with 0% accuracy is useless too (you are basically saying you will be done by certain time with no idea how to get there) Whether your estimate is more precise than accurate or more accurate than precise depends on the project needs. If there is someone waiting for you to finish, it;s better to be accurate than precise. If you are fixing a bug that is in production, it's better to be precise than accurate.

The important thing is to have a common understanding with your manager about precision vs accuracy. I never never say I'm going to be done by certain day. I always tell, I'm trying to finish by Wed, but if something comes up, I'll be able to finish by Fri. This gives the manager a good understanding of what precision I'm going for.

[Campbell Ritchie]

Also err on the side of caution. If you are not sure whether you can finish on Wednesday afternoon or Thursday lunchtime, say Thursday evening.

[Satyaprakash Joshii]

You can have an accurate estimate, but it won;t be precise. You can have a precise estimate, but it won;t be accurate. There is no such thing as a precise, accurate estimate for a non-trivial job

For, example, you can estimate that you will be done next week. This could mean that you might finish by Wed, or you might finish by Fri. You are not being precise, but you are being accurate.
Or, you can estimate that you will be done by 2:32pm on Thursday. This is a precise estimate, but you will most certainly be done before that time or after that time. You are not being accurate

The goal behind providing estimates is to maximize for precision and accuracy as possible. 100%precision and 100%accuracy is impossible. Going for 100% accuracy and 0% precision is useless (you are really saying, I'll be done when I'm done). GOing for 100% precision with 0% accuracy is useless too (you are basically saying you will be done by certain time with no idea how to get there) Whether your estimate is more precise than accurate or more accurate than precise depends on the project needs. If there is someone waiting for you to finish, it;s better to be accurate than precise. If you are fixing a bug that is in production, it's better to be precise than accurate.

The important thing is to have a common understanding with your manager about precision vs accuracy. I never never say I'm going to be done by certain day. I always tell, I'm trying to finish by Wed, but if something comes up, I'll be able to finish by Fri. This gives the manager a good understanding of what precision I'm going for.

Got to know the difference between precision and accuracy. Thank You.