Recently, our biggest product failed majorly because we'd only used outsourced labor to do it, and they never tested anything, etc.

Finally, our CEO decided that the US team should learn the code and fix it up. (Not a total rewrite, but lots of formatting/style changes, refactoring, etc). However, he knows next to nothing about programming (thankfully, he admits it).

He had been grooming me to take on the project manager position, but I had to go back to college. Now he gave it to another programmer who is naive and inexperienced. I don't feel the naive programmer will do nearly as well. The CEO's reasoning is that the naive programmer can work full time and I can only do part time, so the less senior programmer could put more work into it.

How can I convince him that 15 hours of my time is worth more than the other guy's 40?

  • 11
    Your question should be: How can I prove that 15 hours of my time is worth more than the other guy's 40?
    – Bernard
    Sep 26, 2012 at 14:35
  • 3
    Have you offered to assist the junior during your 15 hours? It would seem that 15 of you + 40 of junior > than 15 of just you. Sep 26, 2012 at 16:34
  • @Chad Junior thinks he's better than me (because of promotion) and won't listen. sigh Sep 26, 2012 at 16:57
  • 6
    OK, but for how long would your 15 be worth his 40? Perhaps this person is ready for the challenge and like anyone else will make mistakes along the way but keep going until the project is done. Anyone who has done good work has always had projects that were too big or for which they were under-qualified. Maybe this is his "break"?
    – Angelo
    Sep 26, 2012 at 16:59
  • 1
    @Chad Actually, if they're not working together and coordinating properly, 15 + 40 actually accomplishes less then either the 15 or 40 would alone. Parsing out the work is often not as easy as it sounds. There is so much interoperability that coordinating the work of two developers can take more time than either of them works. Sep 27, 2012 at 13:37

8 Answers 8


Remember that there is more to his decisions than the quality of work per hour as you framed it. There is another facet to the job of project manager -> manager. If you aren't there, you can't be managing. So, the junior can provide something that you can not: availability. Other members of the team need support/direction/assistance from the project manager on their time schedule not yours, so it will be hard for you to manage the project when you can't be there for the team working on the project.

  • 8
    And I would add being the best programmer does not make you the best person for the project management role. Many great programmers are lousy managers and frankly if the OP can't see that project management cannot be done on 15 hours a week, he is likely to be one of them.
    – HLGEM
    Sep 27, 2012 at 13:52
  • Managers and developers are often two different kinds of people, see this SE post: programmers.stackexchange.com/questions/43460/…
    – cdkMoose
    Sep 27, 2012 at 16:04

First of all, don't become too emotionally attached to a project. Doing so will keep YOU from being able to make the best objective decisions. Although it might be hard to see happen, letting the project fail again might be what is needed in this case. Of course, if the project fails again and, due to wasted funds, you could potentially lose pay or your job, you will naturally be more invested in its success. I am NOT saying to have a cavalier attitude toward your work or your team, but if you provide the facts well and then recommend the correct approach (both done respectfully), all that is left for you to do is support the project to the best of your ability even if it fails again. (Even if you KNOW it is going to fail again.)

From another point of view, if it is true that the original failure (with the outsource team) was caused by a lack of skill or experience, then handing it off to a less skilled or experienced internal developer will not produce better results.

Lastly, even though you might only have 15 hours per week to invest in this project, that 15 hours might be best spent mentoring the more junior developer as he is the one doing most of the coding. You may not get the recognition for salvaging the huge financial loss, but you get the personal satisfaction of seeing your team mature and grow.

  • 3
    This situation brings to mind The Serenity Prayer: Grant me the serenity to accept the things I cannot change, the courage to change the things I can, and the wisdom to know the difference. If your boss and/or colleague have already emotionally bought into this arrangement, you may need to just stand back and watch the train go off the cliff. And when it does (good chance) try to refrain from any sort of "I told you so." Sep 26, 2012 at 19:10

It is not enough to make a staffing decision based strictly on current productivity/capability differences (assuming one can even measure that accurately).

There are other things to consider, in particular:

  • Diligent workers improve over time. Perhaps this less-experienced person has demonstrated that he is up to the task given some ramp-up time?

  • Often it is useful to allocate less experienced folks full time to certain projects and have more experienced people "float" to handle complex problems and hot, cross-functional projects as they arise.

In other words, it is not enough to simply prove using "data" that the more experienced person can do the work "better". There are other considerations.


I hate to be harsh, but this is to be expected. You leaving to go back to college and only being available 15 hours/week means you will be passed over for opportunities and advancement until you're back to 100% commitment to the company: this is unavoidable. And the statement that your 15 hours are worth more than his 40 hours as a developer has no bearing on your relative strengths as project managers.

And just the fact that you're convinced that you'd do a better job than the other guy while only spending 15h/week actually on site, with your project(s) and team makes me frankly conclude that you're indeed pretty junior in terms of project management and team leadership. Being available and present 100% of the time is worth a lot.

I'm guessing that your boss sees that you are the star today, but unfortunately you are leaving (at least part time) so e's going with the next best thing. Apparently he sees potential in this other guy (he may be wrong) and he's hoping that guy will grow to your level and be able to shoulder the additional responsibilities. And you should rejoice in this and do your best to make it so. It means that when you get back from college, the company will be strong and successfull and have greater opportunities for you.

Frankly, I don't see the point in convincing your boss that you are so much more valuable than your co-worker at this point since the fact that you're leaving part time makes it practically impossible to assign you certain roles due to your lack of presence.


I think comparing your time to the less experienced person's (LEP) isn't as imporant as the time you can save on the project.

There will be some aspects of the project the LEP will never be able to do that you will no matter how much time he spends on it. It is possible there will be others on the team who can provide answers, but now the project has used up the time of 2 people.

If it takes more time/iterations to fix the code, you have testors that are waiting around and/or duplicating efforts.

Will you be available to other's that have questions? You may provide answers twice as fast, but it takes you 10x longer to get to it.

My suggestion, would be to put you in charge of a particular piece of the application and show what you can do unless you can show your performance on previous projects.

"A man without data just has an opinion." Henry Ford.

Edit: Other members of the team should be concerned about who will lead the project. Is there a reason they are not giving any input?


If you're basing that on the fact that he's inexperienced, then facts are against you:

[In the analysis of Coding War Games results, 1977 - 1986, we found that] people who had ten years of experience did not outperform those with two years of experience. There was no correlation between experience and performance except that those with less than six months' experience with the languages used in the exercise did not do as well as the rest of the sample (Peopleware, p. 47)

On the other hand, it does not mean that all programmers are equal:

In programming specifically, many studies have shown order of magnitude differences in the quality of the programs written, the sizes of the programs written, and the productivity of the programmers. The original study that showed huge variations in individual programming productivity was conducted in the late 1960s by Sackman, Erikson, and Grant (1968). They studied professional programmers with an average of 7 years' experience and found that the ratio of intitial coding time between the best and worst programmers was about 20:1; the ratio of debugging times over 25:1; of program sizes 5:1; and of program execution speed about 10:1. They found no relationship between a programmer's amount of experience and code quality or productivity. (Code Complete, page 548)

However proving that you're 4 times as effective requires hard evidence beyond "he's young and naïve" rant.


Let your boss learn about 10X productivity difference that is a known fact measured for programmers (McConnell 1, 2).

Being unaware of this looks like most likely reason for boss giving laughable ideas like

...naive programmer can work full time and I can only do part time, so the less senior programmer could put more work into it...

...without even trying to get a rough estimation of their productivity difference.

Results of full 40h week of low performer can be the same as those of half-day (4h) of top performer.

It is quite dangerous when someone managing programmers doesn't know this. For example, if your case turns out to fall into that "10X-difference" category, boss would better be prepared to find that full time guy produces almost 4 times less that they would get from 15 h/week work of a fluent programmer.

  • 1
    The question is asking how he can show this... this is the op's arguement for him over the new guy that the OP dislikes. Sep 27, 2012 at 14:17
  • @Chad It doesn't really matter given that whole communication starts with flawed logic. It is plain wrong to compare 15h vs 40h work without at least rough estimate of productivity difference. Without such an estimate all the conclusions, ideas and wishes that may be there are senseless. These are like results of some math calculation based on assumption that 2 + 2 = 5: no matter what math is there besides, it just has to be re-calculated from scratch using corrected base assumption
    – gnat
    Sep 27, 2012 at 17:02
  • I get that. The op is basically asking how he can get that information though in a rather clumsy way. Sep 27, 2012 at 19:06

Short Answer: I hope your boss makes decision on facts. If it is not the case, i would skip wasting my time to convince him :)

I would basically get the facts from source control by comparing on what that naive guy did in 40hrs and what was my contribution 15 hrs. That should make the difference for him.

However, you would better present it from company's benefit perspective and without finger-pointing to other guys in the team.

Edit: There is a misconception on what facts can be get from source control. PM - does not need to look at the source code. Each code check-in into repository should be bound to the Task. Thus PM may get good understanding on what type of tasks (difficulty level) were done by naive guy, and which tasks were resolved by experienced developer.

  • 3
    I completly agree with your answer, facts ARE the only way to prove this in such a context. The only thing I'd like to add is "why bother?". Under such conditions, even if you do prove your point, and you are put in as Tech Lead or whatever, why would you want to keep going (and have even more responsibility) in such an environment? You'll still have to go through the whole charade next time you'll get in a situation like this...
    – Shivan Dragon
    Sep 26, 2012 at 14:55
  • 1
    How can one get "the facts" from source control? There's a lot of interpretation involved to say the least. Moreover, a unilateral code-review like that involves cherry-picking the mistakes and highlighting them to somebody that may or may not understand what is going on at a technical level. It is a move that can easily backfire.
    – Angelo
    Sep 26, 2012 at 16:55
  • 1
    @Angelo, they will just look at what was done as a task, and measure productivity and contribution to the project progress.
    – Yusubov
    Sep 26, 2012 at 17:13
  • @ElYusubov - Good idea, but it would need a technical person capable of interpreting the check-ins, and that sounds like it might be tough for them.
    – psr
    Sep 26, 2012 at 17:27
  • 2
    The question was about a Project Manager position, so it doesn't seem likely that you could gather facts from source control to determine how good a job the less experienced guy is doing. Sep 27, 2012 at 3:04

Not the answer you're looking for? Browse other questions tagged .