Mixing
Working in pairs when it is not actively encouraged?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
4
down vote
favorite
I'm a firm believer that I can do any unfamiliar work, as long as an expert first shows me how to do it and perhaps supervises me when I do it for the first few units of time (depends on the task). But how can you pursue that when it's not encouraged - although also not *dis*couraged? Should it be discussed with the team and manager?
Of course it would be a non-issue if there wouldn't be a timesheet to fill. But what about when your daily activites are monitored with a 30 minute granularity and non-billable work is actively discouraged? Working in pairs would directly fall into non-billable work (self-learning, for example) for one of the two people, as only one can bill it. Otherwise the hour estimates would go vastly over. The timesheet system is not negotiable.
One more challenge is that the work is not easily searchable online, as the system, technologies and the programming language are quite obscure.
What would be the best way to sell the idea of pair work to the powers that be?
software-industry team work-experience work-time learning
edited Jan 22 '13 at 14:09
gnat
3,23273066
asked Jan 22 '13 at 11:49
Juha Untinen
1,5261018
add a comment |Â
up vote
4
down vote
favorite
I'm a firm believer that I can do any unfamiliar work, as long as an expert first shows me how to do it and perhaps supervises me when I do it for the first few units of time (depends on the task). But how can you pursue that when it's not encouraged - although also not *dis*couraged? Should it be discussed with the team and manager?
Of course it would be a non-issue if there wouldn't be a timesheet to fill. But what about when your daily activites are monitored with a 30 minute granularity and non-billable work is actively discouraged? Working in pairs would directly fall into non-billable work (self-learning, for example) for one of the two people, as only one can bill it. Otherwise the hour estimates would go vastly over. The timesheet system is not negotiable.
One more challenge is that the work is not easily searchable online, as the system, technologies and the programming language are quite obscure.
What would be the best way to sell the idea of pair work to the powers that be?
software-industry team work-experience work-time learning
edited Jan 22 '13 at 14:09
gnat
3,23273066
asked Jan 22 '13 at 11:49
Juha Untinen
1,5261018
1
Read up on Pair Programming en.wikipedia.org/wiki/Pair_programming and Agile working.
– Simon O'Doherty
Jan 22 '13 at 13:32
2
"Working in pairs would directly fall into non-billable work ...." This makes no sense to me. Is it corporate policy, or just your assumption? If the latter, I suggest getting clarification from your managment. Part of my thinking: If you have to ask someone a question is the time of only one of you (the asker or answerer) billable? What if you have a meeting (with or without the client), is the time of only one person billable? In my experience, these are billable activities, so I don't see why working in pairs would not be.
– GreenMatt
Jan 22 '13 at 13:55
@GreenMatt: Mostly due to hour estimates per work task. Exceeding them is frowned upon. If two people work on the same task, twice the amount of hours is consumed from the estimate. Unfortunately the estimates are not made with pair work in mind.
– Juha Untinen
Jan 22 '13 at 14:04
@SimonO'Doherty: I'm aware of pair programming, but this question is mostly meant to be about non-programming work, such as software configuration.
– Juha Untinen
Jan 22 '13 at 14:06
add a comment |Â
up vote
4
down vote
favorite
up vote
4
down vote
favorite
I'm a firm believer that I can do any unfamiliar work, as long as an expert first shows me how to do it and perhaps supervises me when I do it for the first few units of time (depends on the task). But how can you pursue that when it's not encouraged - although also not *dis*couraged? Should it be discussed with the team and manager?
Of course it would be a non-issue if there wouldn't be a timesheet to fill. But what about when your daily activites are monitored with a 30 minute granularity and non-billable work is actively discouraged? Working in pairs would directly fall into non-billable work (self-learning, for example) for one of the two people, as only one can bill it. Otherwise the hour estimates would go vastly over. The timesheet system is not negotiable.
One more challenge is that the work is not easily searchable online, as the system, technologies and the programming language are quite obscure.
What would be the best way to sell the idea of pair work to the powers that be?
software-industry team work-experience work-time learning
edited Jan 22 '13 at 14:09
gnat
3,23273066
asked Jan 22 '13 at 11:49
Juha Untinen
1,5261018
I'm a firm believer that I can do any unfamiliar work, as long as an expert first shows me how to do it and perhaps supervises me when I do it for the first few units of time (depends on the task). But how can you pursue that when it's not encouraged - although also not *dis*couraged? Should it be discussed with the team and manager?
Of course it would be a non-issue if there wouldn't be a timesheet to fill. But what about when your daily activites are monitored with a 30 minute granularity and non-billable work is actively discouraged? Working in pairs would directly fall into non-billable work (self-learning, for example) for one of the two people, as only one can bill it. Otherwise the hour estimates would go vastly over. The timesheet system is not negotiable.
One more challenge is that the work is not easily searchable online, as the system, technologies and the programming language are quite obscure.
What would be the best way to sell the idea of pair work to the powers that be?
software-industry team work-experience work-time learning
edited Jan 22 '13 at 14:09
gnat
3,23273066
asked Jan 22 '13 at 11:49
Juha Untinen
1,5261018
edited Jan 22 '13 at 14:09
gnat
3,23273066
edited Jan 22 '13 at 14:09
gnat
3,23273066
edited Jan 22 '13 at 14:09
gnat
3,23273066
3,23273066
asked Jan 22 '13 at 11:49
Juha Untinen
1,5261018
asked Jan 22 '13 at 11:49
Juha Untinen
1,5261018
asked Jan 22 '13 at 11:49
Juha Untinen
1,5261018
1,5261018
1
Read up on Pair Programming en.wikipedia.org/wiki/Pair_programming and Agile working.
– Simon O'Doherty
Jan 22 '13 at 13:32
2
"Working in pairs would directly fall into non-billable work ...." This makes no sense to me. Is it corporate policy, or just your assumption? If the latter, I suggest getting clarification from your managment. Part of my thinking: If you have to ask someone a question is the time of only one of you (the asker or answerer) billable? What if you have a meeting (with or without the client), is the time of only one person billable? In my experience, these are billable activities, so I don't see why working in pairs would not be.
– GreenMatt
Jan 22 '13 at 13:55
@GreenMatt: Mostly due to hour estimates per work task. Exceeding them is frowned upon. If two people work on the same task, twice the amount of hours is consumed from the estimate. Unfortunately the estimates are not made with pair work in mind.
– Juha Untinen
Jan 22 '13 at 14:04
@SimonO'Doherty: I'm aware of pair programming, but this question is mostly meant to be about non-programming work, such as software configuration.
– Juha Untinen
Jan 22 '13 at 14:06
add a comment |Â
1
Read up on Pair Programming en.wikipedia.org/wiki/Pair_programming and Agile working.
– Simon O'Doherty
Jan 22 '13 at 13:32
2
"Working in pairs would directly fall into non-billable work ...." This makes no sense to me. Is it corporate policy, or just your assumption? If the latter, I suggest getting clarification from your managment. Part of my thinking: If you have to ask someone a question is the time of only one of you (the asker or answerer) billable? What if you have a meeting (with or without the client), is the time of only one person billable? In my experience, these are billable activities, so I don't see why working in pairs would not be.
– GreenMatt
Jan 22 '13 at 13:55
@GreenMatt: Mostly due to hour estimates per work task. Exceeding them is frowned upon. If two people work on the same task, twice the amount of hours is consumed from the estimate. Unfortunately the estimates are not made with pair work in mind.
– Juha Untinen
Jan 22 '13 at 14:04
@SimonO'Doherty: I'm aware of pair programming, but this question is mostly meant to be about non-programming work, such as software configuration.
– Juha Untinen
Jan 22 '13 at 14:06
1
1
Read up on Pair Programming en.wikipedia.org/wiki/Pair_programming and Agile working.
– Simon O'Doherty
Jan 22 '13 at 13:32
Read up on Pair Programming en.wikipedia.org/wiki/Pair_programming and Agile working.
– Simon O'Doherty
Jan 22 '13 at 13:32
2
2
"Working in pairs would directly fall into non-billable work ...." This makes no sense to me. Is it corporate policy, or just your assumption? If the latter, I suggest getting clarification from your managment. Part of my thinking: If you have to ask someone a question is the time of only one of you (the asker or answerer) billable? What if you have a meeting (with or without the client), is the time of only one person billable? In my experience, these are billable activities, so I don't see why working in pairs would not be.
– GreenMatt
Jan 22 '13 at 13:55
"Working in pairs would directly fall into non-billable work ...." This makes no sense to me. Is it corporate policy, or just your assumption? If the latter, I suggest getting clarification from your managment. Part of my thinking: If you have to ask someone a question is the time of only one of you (the asker or answerer) billable? What if you have a meeting (with or without the client), is the time of only one person billable? In my experience, these are billable activities, so I don't see why working in pairs would not be.
– GreenMatt
Jan 22 '13 at 13:55
@GreenMatt: Mostly due to hour estimates per work task. Exceeding them is frowned upon. If two people work on the same task, twice the amount of hours is consumed from the estimate. Unfortunately the estimates are not made with pair work in mind.
– Juha Untinen
Jan 22 '13 at 14:04
@GreenMatt: Mostly due to hour estimates per work task. Exceeding them is frowned upon. If two people work on the same task, twice the amount of hours is consumed from the estimate. Unfortunately the estimates are not made with pair work in mind.
– Juha Untinen
Jan 22 '13 at 14:04
@SimonO'Doherty: I'm aware of pair programming, but this question is mostly meant to be about non-programming work, such as software configuration.
– Juha Untinen
Jan 22 '13 at 14:06
@SimonO'Doherty: I'm aware of pair programming, but this question is mostly meant to be about non-programming work, such as software configuration.
– Juha Untinen
Jan 22 '13 at 14:06
add a comment |Â
3 Answers
3
active
oldest
votes
up vote
7
down vote
Working in pairs would directly fall into non-billable work (self-learning, for example) for one of the two people, as only one can bill it. Otherwise the hour estimates would go vastly over.
If working as an individual would take 4 hours or working with a pair would take 2 then why can't you bill it as 2 hours each, totaling 4 hours? Estimates would not "go vastly over".
If working as an individual would take 4 hours or working with a pair would take 3, then there is a good argument that you shouldn't do it. There is also an argument that the quality of the product would be better if you'd both worked on it, saving time and money later, but that's another conversation entirely and one that the business is entitled to make its own decisions on, even if you think it's wrong. (Of course, you're entitled to point it out to them, if you don't think they've considered it.)
But I suspect the real problem behind your question is that you're not accounting for training in your estimates. You must do this, otherwise the business cannot account for it.
answered Jan 22 '13 at 13:41
pdr
19.2k46081
add a comment |Â
up vote
2
down vote
@pdr's hit the nail on the head in the classic tradeoff - particularly for paired work where it's not a function of training, but rather an overall assumption that two people working together works out better almost always than one working alone. After all, a paired programming environment is not just the new guy.
But training via working together is a pretty classic way getting a new guy ramped up in a badly-documented, somewhat business-case-unique technology or environment, so I'm surprised to hear there is no approval from management on it. Usually senior/experienced engineers end up with a part of their job requirements that ends up boiling down to - "spend part of your time here helping other people be better at work" just to cover the fact that this is a needed part of knowledge work.
It's probably time to start asking questions:
How does the management think you are going to learn?
It is totally OK to ask "any pointers for how best to figure this stuff out?", particularly where you are working in a language that sounds somewhat unique to your situation. And also "Is there a person I can ask for help from?" and "how many hours a week can I ask for help from him without being out of line?"
That segways nicely into a discussion about how much time you think you'll need and how much time management can afford to give you. In many billable projects, there's a bit of a buffer in the estimate for the knowledge that sometimes you have a new guy and he needs to learn something on the job, so he (and the team) are a bit less efficient while that happens. In many cases, I've been in situations where the group has billed the customer, because the work was happening for the customer's work. Anything in a true class was a different story - but the "hey, can you help me with this for an hour or two?" generally fit into tasks unique to the customer's needs, and therefore could be justified by both people as billable.
But the call is management's - they are the ones justifying what you spent the customer's money on.
Taking it from the management's side, my first question would be "how much time do you need?". I'd be hoping to hear something like "I'll need a lot of handholding this first week or so - say 15 hours a week this week, 10 next week. Then I'm probably good to go for a while, but may beg 2-5 hours a week for the next few weeks after that just to make sure I have it down right... maybe less if there's a formal proofing/peer review process" What I don't want to hear is that the employee won't be able to figure anything out on their own, even in a new language. And, if I'm a somewhat paranoid manager, I will be wandering by here and there, and hoping to see the two people in earnest work conversation (probably staring at a screen) and only rarely talking about something fun and social.
How is the other guy getting rated?
The other resistance I've seen is that senior engineers don't always realize that helping others is part of the job. If you end up with the experts running back to their desks after only a few minutes of helping, it's probably time for a second talk with management on what's the deadline and why is there no willingness to help? You shouldn't be the one explaining their job to them, it's the management's call. But this is one of the hardest things to figure out as management, because unhelpfulness looks a lot like doing your own work... so it's hard to tell that the employee who is getting tons done is getting tons done because he's not helping anyone else on the team.
answered Jan 22 '13 at 14:58
bethlakshmi
70.4k4136277
add a comment |Â
up vote
0
down vote
Define what is Billable This is what your company is not doing. Do they only consider the time a developer is actually typing code as billable?
When working for a client, these things should be billalbe (it's what a lawyer would do)
- meetings discussing a specific project
- desigining
- creating documenation or presentations
- communication with the client: phone calls, email, etc.
- testing
- debugging
- research (this shouldn't be something like reading 'Programming for Dummies').
Of course you should be upfront with the client and there is room for negotiation. Also, you should have some references from other clients indicating you stick to your estimates. This way they can compare your quotes to the competition.
Why hire someone who charges more per hour and ends up billing you for even more hours because they don't know how to estimate.
add a comment |Â
StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function()
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
;
var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');
$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function(popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');
pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);
)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();
);
);
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
7
down vote
Working in pairs would directly fall into non-billable work (self-learning, for example) for one of the two people, as only one can bill it. Otherwise the hour estimates would go vastly over.
If working as an individual would take 4 hours or working with a pair would take 2 then why can't you bill it as 2 hours each, totaling 4 hours? Estimates would not "go vastly over".
If working as an individual would take 4 hours or working with a pair would take 3, then there is a good argument that you shouldn't do it. There is also an argument that the quality of the product would be better if you'd both worked on it, saving time and money later, but that's another conversation entirely and one that the business is entitled to make its own decisions on, even if you think it's wrong. (Of course, you're entitled to point it out to them, if you don't think they've considered it.)
But I suspect the real problem behind your question is that you're not accounting for training in your estimates. You must do this, otherwise the business cannot account for it.
answered Jan 22 '13 at 13:41
pdr
19.2k46081
add a comment |Â
up vote
7
down vote
Working in pairs would directly fall into non-billable work (self-learning, for example) for one of the two people, as only one can bill it. Otherwise the hour estimates would go vastly over.
If working as an individual would take 4 hours or working with a pair would take 2 then why can't you bill it as 2 hours each, totaling 4 hours? Estimates would not "go vastly over".
If working as an individual would take 4 hours or working with a pair would take 3, then there is a good argument that you shouldn't do it. There is also an argument that the quality of the product would be better if you'd both worked on it, saving time and money later, but that's another conversation entirely and one that the business is entitled to make its own decisions on, even if you think it's wrong. (Of course, you're entitled to point it out to them, if you don't think they've considered it.)
But I suspect the real problem behind your question is that you're not accounting for training in your estimates. You must do this, otherwise the business cannot account for it.
answered Jan 22 '13 at 13:41
pdr
19.2k46081
add a comment |Â
up vote
7
down vote
up vote
7
down vote
Working in pairs would directly fall into non-billable work (self-learning, for example) for one of the two people, as only one can bill it. Otherwise the hour estimates would go vastly over.
If working as an individual would take 4 hours or working with a pair would take 2 then why can't you bill it as 2 hours each, totaling 4 hours? Estimates would not "go vastly over".
If working as an individual would take 4 hours or working with a pair would take 3, then there is a good argument that you shouldn't do it. There is also an argument that the quality of the product would be better if you'd both worked on it, saving time and money later, but that's another conversation entirely and one that the business is entitled to make its own decisions on, even if you think it's wrong. (Of course, you're entitled to point it out to them, if you don't think they've considered it.)
But I suspect the real problem behind your question is that you're not accounting for training in your estimates. You must do this, otherwise the business cannot account for it.
answered Jan 22 '13 at 13:41
pdr
19.2k46081
Working in pairs would directly fall into non-billable work (self-learning, for example) for one of the two people, as only one can bill it. Otherwise the hour estimates would go vastly over.
If working as an individual would take 4 hours or working with a pair would take 2 then why can't you bill it as 2 hours each, totaling 4 hours? Estimates would not "go vastly over".
If working as an individual would take 4 hours or working with a pair would take 3, then there is a good argument that you shouldn't do it. There is also an argument that the quality of the product would be better if you'd both worked on it, saving time and money later, but that's another conversation entirely and one that the business is entitled to make its own decisions on, even if you think it's wrong. (Of course, you're entitled to point it out to them, if you don't think they've considered it.)
But I suspect the real problem behind your question is that you're not accounting for training in your estimates. You must do this, otherwise the business cannot account for it.
answered Jan 22 '13 at 13:41
pdr
19.2k46081
edited Jan 22 '13 at 13:46
answered Jan 22 '13 at 13:41
pdr
19.2k46081
answered Jan 22 '13 at 13:41
pdr
19.2k46081
answered Jan 22 '13 at 13:41
pdr
19.2k46081
19.2k46081
add a comment |Â
add a comment |Â
up vote
2
down vote
@pdr's hit the nail on the head in the classic tradeoff - particularly for paired work where it's not a function of training, but rather an overall assumption that two people working together works out better almost always than one working alone. After all, a paired programming environment is not just the new guy.
But training via working together is a pretty classic way getting a new guy ramped up in a badly-documented, somewhat business-case-unique technology or environment, so I'm surprised to hear there is no approval from management on it. Usually senior/experienced engineers end up with a part of their job requirements that ends up boiling down to - "spend part of your time here helping other people be better at work" just to cover the fact that this is a needed part of knowledge work.
It's probably time to start asking questions:
How does the management think you are going to learn?
It is totally OK to ask "any pointers for how best to figure this stuff out?", particularly where you are working in a language that sounds somewhat unique to your situation. And also "Is there a person I can ask for help from?" and "how many hours a week can I ask for help from him without being out of line?"
That segways nicely into a discussion about how much time you think you'll need and how much time management can afford to give you. In many billable projects, there's a bit of a buffer in the estimate for the knowledge that sometimes you have a new guy and he needs to learn something on the job, so he (and the team) are a bit less efficient while that happens. In many cases, I've been in situations where the group has billed the customer, because the work was happening for the customer's work. Anything in a true class was a different story - but the "hey, can you help me with this for an hour or two?" generally fit into tasks unique to the customer's needs, and therefore could be justified by both people as billable.
But the call is management's - they are the ones justifying what you spent the customer's money on.
Taking it from the management's side, my first question would be "how much time do you need?". I'd be hoping to hear something like "I'll need a lot of handholding this first week or so - say 15 hours a week this week, 10 next week. Then I'm probably good to go for a while, but may beg 2-5 hours a week for the next few weeks after that just to make sure I have it down right... maybe less if there's a formal proofing/peer review process" What I don't want to hear is that the employee won't be able to figure anything out on their own, even in a new language. And, if I'm a somewhat paranoid manager, I will be wandering by here and there, and hoping to see the two people in earnest work conversation (probably staring at a screen) and only rarely talking about something fun and social.
How is the other guy getting rated?
The other resistance I've seen is that senior engineers don't always realize that helping others is part of the job. If you end up with the experts running back to their desks after only a few minutes of helping, it's probably time for a second talk with management on what's the deadline and why is there no willingness to help? You shouldn't be the one explaining their job to them, it's the management's call. But this is one of the hardest things to figure out as management, because unhelpfulness looks a lot like doing your own work... so it's hard to tell that the employee who is getting tons done is getting tons done because he's not helping anyone else on the team.
answered Jan 22 '13 at 14:58
bethlakshmi
70.4k4136277
add a comment |Â
up vote
2
down vote
@pdr's hit the nail on the head in the classic tradeoff - particularly for paired work where it's not a function of training, but rather an overall assumption that two people working together works out better almost always than one working alone. After all, a paired programming environment is not just the new guy.
But training via working together is a pretty classic way getting a new guy ramped up in a badly-documented, somewhat business-case-unique technology or environment, so I'm surprised to hear there is no approval from management on it. Usually senior/experienced engineers end up with a part of their job requirements that ends up boiling down to - "spend part of your time here helping other people be better at work" just to cover the fact that this is a needed part of knowledge work.
It's probably time to start asking questions:
How does the management think you are going to learn?
It is totally OK to ask "any pointers for how best to figure this stuff out?", particularly where you are working in a language that sounds somewhat unique to your situation. And also "Is there a person I can ask for help from?" and "how many hours a week can I ask for help from him without being out of line?"
That segways nicely into a discussion about how much time you think you'll need and how much time management can afford to give you. In many billable projects, there's a bit of a buffer in the estimate for the knowledge that sometimes you have a new guy and he needs to learn something on the job, so he (and the team) are a bit less efficient while that happens. In many cases, I've been in situations where the group has billed the customer, because the work was happening for the customer's work. Anything in a true class was a different story - but the "hey, can you help me with this for an hour or two?" generally fit into tasks unique to the customer's needs, and therefore could be justified by both people as billable.
But the call is management's - they are the ones justifying what you spent the customer's money on.
Taking it from the management's side, my first question would be "how much time do you need?". I'd be hoping to hear something like "I'll need a lot of handholding this first week or so - say 15 hours a week this week, 10 next week. Then I'm probably good to go for a while, but may beg 2-5 hours a week for the next few weeks after that just to make sure I have it down right... maybe less if there's a formal proofing/peer review process" What I don't want to hear is that the employee won't be able to figure anything out on their own, even in a new language. And, if I'm a somewhat paranoid manager, I will be wandering by here and there, and hoping to see the two people in earnest work conversation (probably staring at a screen) and only rarely talking about something fun and social.
How is the other guy getting rated?
The other resistance I've seen is that senior engineers don't always realize that helping others is part of the job. If you end up with the experts running back to their desks after only a few minutes of helping, it's probably time for a second talk with management on what's the deadline and why is there no willingness to help? You shouldn't be the one explaining their job to them, it's the management's call. But this is one of the hardest things to figure out as management, because unhelpfulness looks a lot like doing your own work... so it's hard to tell that the employee who is getting tons done is getting tons done because he's not helping anyone else on the team.
answered Jan 22 '13 at 14:58
bethlakshmi
70.4k4136277
add a comment |Â
up vote
2
down vote
up vote
2
down vote
@pdr's hit the nail on the head in the classic tradeoff - particularly for paired work where it's not a function of training, but rather an overall assumption that two people working together works out better almost always than one working alone. After all, a paired programming environment is not just the new guy.
But training via working together is a pretty classic way getting a new guy ramped up in a badly-documented, somewhat business-case-unique technology or environment, so I'm surprised to hear there is no approval from management on it. Usually senior/experienced engineers end up with a part of their job requirements that ends up boiling down to - "spend part of your time here helping other people be better at work" just to cover the fact that this is a needed part of knowledge work.
It's probably time to start asking questions:
How does the management think you are going to learn?
It is totally OK to ask "any pointers for how best to figure this stuff out?", particularly where you are working in a language that sounds somewhat unique to your situation. And also "Is there a person I can ask for help from?" and "how many hours a week can I ask for help from him without being out of line?"
That segways nicely into a discussion about how much time you think you'll need and how much time management can afford to give you. In many billable projects, there's a bit of a buffer in the estimate for the knowledge that sometimes you have a new guy and he needs to learn something on the job, so he (and the team) are a bit less efficient while that happens. In many cases, I've been in situations where the group has billed the customer, because the work was happening for the customer's work. Anything in a true class was a different story - but the "hey, can you help me with this for an hour or two?" generally fit into tasks unique to the customer's needs, and therefore could be justified by both people as billable.
But the call is management's - they are the ones justifying what you spent the customer's money on.
Taking it from the management's side, my first question would be "how much time do you need?". I'd be hoping to hear something like "I'll need a lot of handholding this first week or so - say 15 hours a week this week, 10 next week. Then I'm probably good to go for a while, but may beg 2-5 hours a week for the next few weeks after that just to make sure I have it down right... maybe less if there's a formal proofing/peer review process" What I don't want to hear is that the employee won't be able to figure anything out on their own, even in a new language. And, if I'm a somewhat paranoid manager, I will be wandering by here and there, and hoping to see the two people in earnest work conversation (probably staring at a screen) and only rarely talking about something fun and social.
How is the other guy getting rated?
The other resistance I've seen is that senior engineers don't always realize that helping others is part of the job. If you end up with the experts running back to their desks after only a few minutes of helping, it's probably time for a second talk with management on what's the deadline and why is there no willingness to help? You shouldn't be the one explaining their job to them, it's the management's call. But this is one of the hardest things to figure out as management, because unhelpfulness looks a lot like doing your own work... so it's hard to tell that the employee who is getting tons done is getting tons done because he's not helping anyone else on the team.
answered Jan 22 '13 at 14:58
bethlakshmi
70.4k4136277
@pdr's hit the nail on the head in the classic tradeoff - particularly for paired work where it's not a function of training, but rather an overall assumption that two people working together works out better almost always than one working alone. After all, a paired programming environment is not just the new guy.
But training via working together is a pretty classic way getting a new guy ramped up in a badly-documented, somewhat business-case-unique technology or environment, so I'm surprised to hear there is no approval from management on it. Usually senior/experienced engineers end up with a part of their job requirements that ends up boiling down to - "spend part of your time here helping other people be better at work" just to cover the fact that this is a needed part of knowledge work.
It's probably time to start asking questions:
How does the management think you are going to learn?
It is totally OK to ask "any pointers for how best to figure this stuff out?", particularly where you are working in a language that sounds somewhat unique to your situation. And also "Is there a person I can ask for help from?" and "how many hours a week can I ask for help from him without being out of line?"
That segways nicely into a discussion about how much time you think you'll need and how much time management can afford to give you. In many billable projects, there's a bit of a buffer in the estimate for the knowledge that sometimes you have a new guy and he needs to learn something on the job, so he (and the team) are a bit less efficient while that happens. In many cases, I've been in situations where the group has billed the customer, because the work was happening for the customer's work. Anything in a true class was a different story - but the "hey, can you help me with this for an hour or two?" generally fit into tasks unique to the customer's needs, and therefore could be justified by both people as billable.
But the call is management's - they are the ones justifying what you spent the customer's money on.
Taking it from the management's side, my first question would be "how much time do you need?". I'd be hoping to hear something like "I'll need a lot of handholding this first week or so - say 15 hours a week this week, 10 next week. Then I'm probably good to go for a while, but may beg 2-5 hours a week for the next few weeks after that just to make sure I have it down right... maybe less if there's a formal proofing/peer review process" What I don't want to hear is that the employee won't be able to figure anything out on their own, even in a new language. And, if I'm a somewhat paranoid manager, I will be wandering by here and there, and hoping to see the two people in earnest work conversation (probably staring at a screen) and only rarely talking about something fun and social.
How is the other guy getting rated?
The other resistance I've seen is that senior engineers don't always realize that helping others is part of the job. If you end up with the experts running back to their desks after only a few minutes of helping, it's probably time for a second talk with management on what's the deadline and why is there no willingness to help? You shouldn't be the one explaining their job to them, it's the management's call. But this is one of the hardest things to figure out as management, because unhelpfulness looks a lot like doing your own work... so it's hard to tell that the employee who is getting tons done is getting tons done because he's not helping anyone else on the team.
answered Jan 22 '13 at 14:58
bethlakshmi
70.4k4136277
answered Jan 22 '13 at 14:58
bethlakshmi
70.4k4136277
answered Jan 22 '13 at 14:58
bethlakshmi
70.4k4136277
answered Jan 22 '13 at 14:58
bethlakshmi
70.4k4136277
70.4k4136277
add a comment |Â
add a comment |Â
up vote
0
down vote
Define what is Billable This is what your company is not doing. Do they only consider the time a developer is actually typing code as billable?
When working for a client, these things should be billalbe (it's what a lawyer would do)
- meetings discussing a specific project
- desigining
- creating documenation or presentations
- communication with the client: phone calls, email, etc.
- testing
- debugging
- research (this shouldn't be something like reading 'Programming for Dummies').
Of course you should be upfront with the client and there is room for negotiation. Also, you should have some references from other clients indicating you stick to your estimates. This way they can compare your quotes to the competition.
Why hire someone who charges more per hour and ends up billing you for even more hours because they don't know how to estimate.
add a comment |Â
up vote
0
down vote
Define what is Billable This is what your company is not doing. Do they only consider the time a developer is actually typing code as billable?
When working for a client, these things should be billalbe (it's what a lawyer would do)
- meetings discussing a specific project
- desigining
- creating documenation or presentations
- communication with the client: phone calls, email, etc.
- testing
- debugging
- research (this shouldn't be something like reading 'Programming for Dummies').
Of course you should be upfront with the client and there is room for negotiation. Also, you should have some references from other clients indicating you stick to your estimates. This way they can compare your quotes to the competition.
Why hire someone who charges more per hour and ends up billing you for even more hours because they don't know how to estimate.
add a comment |Â
up vote
0
down vote
up vote
0
down vote
Define what is Billable This is what your company is not doing. Do they only consider the time a developer is actually typing code as billable?
When working for a client, these things should be billalbe (it's what a lawyer would do)
- meetings discussing a specific project
- desigining
- creating documenation or presentations
- communication with the client: phone calls, email, etc.
- testing
- debugging
- research (this shouldn't be something like reading 'Programming for Dummies').
Of course you should be upfront with the client and there is room for negotiation. Also, you should have some references from other clients indicating you stick to your estimates. This way they can compare your quotes to the competition.
Why hire someone who charges more per hour and ends up billing you for even more hours because they don't know how to estimate.
Define what is Billable This is what your company is not doing. Do they only consider the time a developer is actually typing code as billable?
When working for a client, these things should be billalbe (it's what a lawyer would do)
- meetings discussing a specific project
- desigining
- creating documenation or presentations
- communication with the client: phone calls, email, etc.
- testing
- debugging
- research (this shouldn't be something like reading 'Programming for Dummies').
Of course you should be upfront with the client and there is room for negotiation. Also, you should have some references from other clients indicating you stick to your estimates. This way they can compare your quotes to the competition.
Why hire someone who charges more per hour and ends up billing you for even more hours because they don't know how to estimate.
answered Jan 22 '13 at 14:55
user8365
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f9078%2fworking-in-pairs-when-it-is-not-actively-encouraged%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
1
Read up on Pair Programming en.wikipedia.org/wiki/Pair_programming and Agile working.
– Simon O'Doherty
Jan 22 '13 at 13:32
2
"Working in pairs would directly fall into non-billable work ...." This makes no sense to me. Is it corporate policy, or just your assumption? If the latter, I suggest getting clarification from your managment. Part of my thinking: If you have to ask someone a question is the time of only one of you (the asker or answerer) billable? What if you have a meeting (with or without the client), is the time of only one person billable? In my experience, these are billable activities, so I don't see why working in pairs would not be.
– GreenMatt
Jan 22 '13 at 13:55
@GreenMatt: Mostly due to hour estimates per work task. Exceeding them is frowned upon. If two people work on the same task, twice the amount of hours is consumed from the estimate. Unfortunately the estimates are not made with pair work in mind.
– Juha Untinen
Jan 22 '13 at 14:04
@SimonO'Doherty: I'm aware of pair programming, but this question is mostly meant to be about non-programming work, such as software configuration.
– Juha Untinen
Jan 22 '13 at 14:06