Mixing
How can an organization keep the benefits of generalists on large-scale projects?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
8
down vote
favorite
I work for a company experiencing rapid growth, with more growth projected in the future. We currently use generalists who can work on multiple projects for better communication, teamwork, and maneuverability.
Even with generalists, some members do end up with concentrated domain knowledge in certain projects, so some executives are considering switching to smaller dedicated project teams who will become specialists in a specific area as a natural extension of that domain knowledge and the growth of the company.
My problem is that this would be a large shift for the style of work we do, and I don't want to sacrifice the communication, teamwork, and maneuverability if possible.
When working on large-scale projects (think of developing Excel or the equivalent), how can you maintain the same level of communication, teamwork, and maneuverability between project teams?
software-industry team
edited Nov 6 '13 at 6:14
jmac
19.4k763137
asked Nov 5 '13 at 20:23
Eric
1,0122915
add a comment |Â
up vote
8
down vote
favorite
I work for a company experiencing rapid growth, with more growth projected in the future. We currently use generalists who can work on multiple projects for better communication, teamwork, and maneuverability.
Even with generalists, some members do end up with concentrated domain knowledge in certain projects, so some executives are considering switching to smaller dedicated project teams who will become specialists in a specific area as a natural extension of that domain knowledge and the growth of the company.
My problem is that this would be a large shift for the style of work we do, and I don't want to sacrifice the communication, teamwork, and maneuverability if possible.
When working on large-scale projects (think of developing Excel or the equivalent), how can you maintain the same level of communication, teamwork, and maneuverability between project teams?
software-industry team
edited Nov 6 '13 at 6:14
jmac
19.4k763137
asked Nov 5 '13 at 20:23
Eric
1,0122915
1
I reopened this post because, in its current form, it describes a problem faced in many organizations that experience rapid growth. In its current form, this can be answered with facts, references, and be backed with shared personal experiences to support claims. Hope this helps.
– jmort253♦
Nov 6 '13 at 7:28
add a comment |Â
up vote
8
down vote
favorite
up vote
8
down vote
favorite
I work for a company experiencing rapid growth, with more growth projected in the future. We currently use generalists who can work on multiple projects for better communication, teamwork, and maneuverability.
Even with generalists, some members do end up with concentrated domain knowledge in certain projects, so some executives are considering switching to smaller dedicated project teams who will become specialists in a specific area as a natural extension of that domain knowledge and the growth of the company.
My problem is that this would be a large shift for the style of work we do, and I don't want to sacrifice the communication, teamwork, and maneuverability if possible.
When working on large-scale projects (think of developing Excel or the equivalent), how can you maintain the same level of communication, teamwork, and maneuverability between project teams?
software-industry team
edited Nov 6 '13 at 6:14
jmac
19.4k763137
asked Nov 5 '13 at 20:23
Eric
1,0122915
I work for a company experiencing rapid growth, with more growth projected in the future. We currently use generalists who can work on multiple projects for better communication, teamwork, and maneuverability.
Even with generalists, some members do end up with concentrated domain knowledge in certain projects, so some executives are considering switching to smaller dedicated project teams who will become specialists in a specific area as a natural extension of that domain knowledge and the growth of the company.
My problem is that this would be a large shift for the style of work we do, and I don't want to sacrifice the communication, teamwork, and maneuverability if possible.
When working on large-scale projects (think of developing Excel or the equivalent), how can you maintain the same level of communication, teamwork, and maneuverability between project teams?
software-industry team
edited Nov 6 '13 at 6:14
jmac
19.4k763137
asked Nov 5 '13 at 20:23
Eric
1,0122915
edited Nov 6 '13 at 6:14
jmac
19.4k763137
edited Nov 6 '13 at 6:14
jmac
19.4k763137
edited Nov 6 '13 at 6:14
jmac
19.4k763137
19.4k763137
asked Nov 5 '13 at 20:23
Eric
1,0122915
asked Nov 5 '13 at 20:23
Eric
1,0122915
asked Nov 5 '13 at 20:23
Eric
1,0122915
1,0122915
1
I reopened this post because, in its current form, it describes a problem faced in many organizations that experience rapid growth. In its current form, this can be answered with facts, references, and be backed with shared personal experiences to support claims. Hope this helps.
– jmort253♦
Nov 6 '13 at 7:28
add a comment |Â
1
I reopened this post because, in its current form, it describes a problem faced in many organizations that experience rapid growth. In its current form, this can be answered with facts, references, and be backed with shared personal experiences to support claims. Hope this helps.
– jmort253♦
Nov 6 '13 at 7:28
1
1
I reopened this post because, in its current form, it describes a problem faced in many organizations that experience rapid growth. In its current form, this can be answered with facts, references, and be backed with shared personal experiences to support claims. Hope this helps.
– jmort253♦
Nov 6 '13 at 7:28
I reopened this post because, in its current form, it describes a problem faced in many organizations that experience rapid growth. In its current form, this can be answered with facts, references, and be backed with shared personal experiences to support claims. Hope this helps.
– jmort253♦
Nov 6 '13 at 7:28
add a comment |Â
3 Answers
3
active
oldest
votes
up vote
8
down vote
accepted
The short answer is "you don't keep the same level of communication."
To use your example, it's a pretty fair bet that the folks developing Excel will never be called to contribute to the device drivers.
For a generalist to be useful on multiple projects, it is important to stay somewhat current on those projects - know the technologies, know the people, know the issues, know the solutions to previous issues, etc.
At some point there's just too much information to keep up. Your generalist will have too much breadth / not enough depth to remain useful.
Switching to dedicated teams will permit those teams to remain fully focused on their area of concern. They're sacrificing breadth to gain (or at least keep) depth.
answered Nov 6 '13 at 16:39
Dan Pichelman
24.7k116882
add a comment |Â
up vote
2
down vote
My main concerns would be:
From an organizational standpoint, changing to this structure could be incredibly disruptive of current projects. (I've seen this happen at least twice and clients were very unhappy.) Is there any gain which could offset this disruption? This type of change would affect deadlines, would affect ability to deliver the product (some people are bound to end up on projects they are not very familair with) because of having to learn the new project. It is also incredibly risky as some things might get lost in the shuffle as people currently assigned to do them move to other projects. What would be the plan? Is there a way to do a phased change?
If there is less cross-pollination, will you be in trouble if someone key on a project takes another job? Developers tend to move around. Having fewer people know the details of projects could be costly. If we are talking project teams of 5-10 that might not be an issue, but if the teams end up as 1-2 on a particular project it could be.
If you silo people into specific product lines, are you limiting their ability to gain new knowledge (a must have for most good programmers) and thus pretty much forcing the best ones to leave to keep up their professional qualifications? The more projects you have using older technology, the worse this could be.
How easy will it be to transfer to other projects? Once you get to be expert in one project, the chances of moving around become much reduced. So if devs feel you are hurting their career paths, they will leave in droves and you will lose alot of the current knowledge. At the very least you will need a plan to allow transfers to other projects and a way to get past the "I can't give him up because he is the only one who knows..." issues. Career progression is important, the more project specialized people are the harder it is to move up as well. You need a plan to handle it. You might consider moving 5-10% of the developers each year and making it a requirement that everyone has to be allowed to change product lines at least once every 5 years. This could help force the cross pollination, give people a chance to get new types of experience and keep the bulk of the team relatively stable. The ramp up time should be figured into the project plans because you know you will get some new developers every year. It would also help keep managers from relying too much on one person as they know he will evenetually be transferred. You might also make sure people can apply for new openings without having to have approval of their current boss (to prevent people hoarding).
I would ask your boss what he expects to gain that would offset the possible problems (I'm sure that being in the current situation you can think of more than I could. You can also probably see what the benefits might be.)
You also need to consider that you might have specialists who need to remain cross-functional no matter what. Or were you going to hire 7 business intelligence specialists (1 per projet) instead of the 2 you have (as an example). The best bet might be to do a hybrid organization where some are siloed and some are not.
You could even do a cost-benefit analysis that quantifies the risks and rewards of both possibilities so that he can see what the impact would be.
answered Nov 6 '13 at 16:37
HLGEM
133k25227489
add a comment |Â
up vote
-1
down vote
If a developer writes 10,000 lines of code a year, and a team of 5 work on a project for 18 months, then one could expect the project to have 75,000 lines of code when it rolls into production. If it remains in production for ten years, it will probably expand to 250,000 lines over that time. This is a highly hypothetical case focused on either a website or subscription software - it wouldn't apply to embedded control necessarily.
100,000 lines of code divided by 50 is roughly 2000 pages, so any developer involved in a mature project has to keep the equivalent of 2000 pages of instructions in their head. If you're spreading people out among multiple projects, multiply this by the number of projects they're assigned to keep track of.
This might work if you have people who operate in very myopic roles - nothing but data services or certain kinds of summary reports or UI consistency across multiple products. However, if you want a few people to thoroughly understand a given application, they should be doing that full time. 'Cross functional' is a serious dilution of effort.
answered Nov 5 '13 at 21:36
Meredith Poor
8,8661730
Hopefully someone will explain their downvote.
– Meredith Poor
Nov 5 '13 at 21:46
Regarding your answer, thanks. I've really enjoyed the flexibility of being able to move lots of developers from one product to another, but there's probably a ton of inefficiencies happening as well.
– Eric
Nov 6 '13 at 0:02
3
Hey Meredith, as I made a significant edit to the question, you may want to consider revising your answer if it gets reopened. Just a heads up.
– jmac
Nov 6 '13 at 6:15
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
8
down vote
accepted
The short answer is "you don't keep the same level of communication."
To use your example, it's a pretty fair bet that the folks developing Excel will never be called to contribute to the device drivers.
For a generalist to be useful on multiple projects, it is important to stay somewhat current on those projects - know the technologies, know the people, know the issues, know the solutions to previous issues, etc.
At some point there's just too much information to keep up. Your generalist will have too much breadth / not enough depth to remain useful.
Switching to dedicated teams will permit those teams to remain fully focused on their area of concern. They're sacrificing breadth to gain (or at least keep) depth.
answered Nov 6 '13 at 16:39
Dan Pichelman
24.7k116882
add a comment |Â
up vote
8
down vote
accepted
The short answer is "you don't keep the same level of communication."
To use your example, it's a pretty fair bet that the folks developing Excel will never be called to contribute to the device drivers.
For a generalist to be useful on multiple projects, it is important to stay somewhat current on those projects - know the technologies, know the people, know the issues, know the solutions to previous issues, etc.
At some point there's just too much information to keep up. Your generalist will have too much breadth / not enough depth to remain useful.
Switching to dedicated teams will permit those teams to remain fully focused on their area of concern. They're sacrificing breadth to gain (or at least keep) depth.
answered Nov 6 '13 at 16:39
Dan Pichelman
24.7k116882
add a comment |Â
up vote
8
down vote
accepted
up vote
8
down vote
accepted
The short answer is "you don't keep the same level of communication."
To use your example, it's a pretty fair bet that the folks developing Excel will never be called to contribute to the device drivers.
For a generalist to be useful on multiple projects, it is important to stay somewhat current on those projects - know the technologies, know the people, know the issues, know the solutions to previous issues, etc.
At some point there's just too much information to keep up. Your generalist will have too much breadth / not enough depth to remain useful.
Switching to dedicated teams will permit those teams to remain fully focused on their area of concern. They're sacrificing breadth to gain (or at least keep) depth.
answered Nov 6 '13 at 16:39
Dan Pichelman
24.7k116882
The short answer is "you don't keep the same level of communication."
To use your example, it's a pretty fair bet that the folks developing Excel will never be called to contribute to the device drivers.
For a generalist to be useful on multiple projects, it is important to stay somewhat current on those projects - know the technologies, know the people, know the issues, know the solutions to previous issues, etc.
At some point there's just too much information to keep up. Your generalist will have too much breadth / not enough depth to remain useful.
Switching to dedicated teams will permit those teams to remain fully focused on their area of concern. They're sacrificing breadth to gain (or at least keep) depth.
answered Nov 6 '13 at 16:39
Dan Pichelman
24.7k116882
answered Nov 6 '13 at 16:39
Dan Pichelman
24.7k116882
answered Nov 6 '13 at 16:39
Dan Pichelman
24.7k116882
answered Nov 6 '13 at 16:39
Dan Pichelman
24.7k116882
24.7k116882
add a comment |Â
add a comment |Â
up vote
2
down vote
My main concerns would be:
From an organizational standpoint, changing to this structure could be incredibly disruptive of current projects. (I've seen this happen at least twice and clients were very unhappy.) Is there any gain which could offset this disruption? This type of change would affect deadlines, would affect ability to deliver the product (some people are bound to end up on projects they are not very familair with) because of having to learn the new project. It is also incredibly risky as some things might get lost in the shuffle as people currently assigned to do them move to other projects. What would be the plan? Is there a way to do a phased change?
If there is less cross-pollination, will you be in trouble if someone key on a project takes another job? Developers tend to move around. Having fewer people know the details of projects could be costly. If we are talking project teams of 5-10 that might not be an issue, but if the teams end up as 1-2 on a particular project it could be.
If you silo people into specific product lines, are you limiting their ability to gain new knowledge (a must have for most good programmers) and thus pretty much forcing the best ones to leave to keep up their professional qualifications? The more projects you have using older technology, the worse this could be.
How easy will it be to transfer to other projects? Once you get to be expert in one project, the chances of moving around become much reduced. So if devs feel you are hurting their career paths, they will leave in droves and you will lose alot of the current knowledge. At the very least you will need a plan to allow transfers to other projects and a way to get past the "I can't give him up because he is the only one who knows..." issues. Career progression is important, the more project specialized people are the harder it is to move up as well. You need a plan to handle it. You might consider moving 5-10% of the developers each year and making it a requirement that everyone has to be allowed to change product lines at least once every 5 years. This could help force the cross pollination, give people a chance to get new types of experience and keep the bulk of the team relatively stable. The ramp up time should be figured into the project plans because you know you will get some new developers every year. It would also help keep managers from relying too much on one person as they know he will evenetually be transferred. You might also make sure people can apply for new openings without having to have approval of their current boss (to prevent people hoarding).
I would ask your boss what he expects to gain that would offset the possible problems (I'm sure that being in the current situation you can think of more than I could. You can also probably see what the benefits might be.)
You also need to consider that you might have specialists who need to remain cross-functional no matter what. Or were you going to hire 7 business intelligence specialists (1 per projet) instead of the 2 you have (as an example). The best bet might be to do a hybrid organization where some are siloed and some are not.
You could even do a cost-benefit analysis that quantifies the risks and rewards of both possibilities so that he can see what the impact would be.
answered Nov 6 '13 at 16:37
HLGEM
133k25227489
add a comment |Â
up vote
2
down vote
My main concerns would be:
From an organizational standpoint, changing to this structure could be incredibly disruptive of current projects. (I've seen this happen at least twice and clients were very unhappy.) Is there any gain which could offset this disruption? This type of change would affect deadlines, would affect ability to deliver the product (some people are bound to end up on projects they are not very familair with) because of having to learn the new project. It is also incredibly risky as some things might get lost in the shuffle as people currently assigned to do them move to other projects. What would be the plan? Is there a way to do a phased change?
If there is less cross-pollination, will you be in trouble if someone key on a project takes another job? Developers tend to move around. Having fewer people know the details of projects could be costly. If we are talking project teams of 5-10 that might not be an issue, but if the teams end up as 1-2 on a particular project it could be.
If you silo people into specific product lines, are you limiting their ability to gain new knowledge (a must have for most good programmers) and thus pretty much forcing the best ones to leave to keep up their professional qualifications? The more projects you have using older technology, the worse this could be.
How easy will it be to transfer to other projects? Once you get to be expert in one project, the chances of moving around become much reduced. So if devs feel you are hurting their career paths, they will leave in droves and you will lose alot of the current knowledge. At the very least you will need a plan to allow transfers to other projects and a way to get past the "I can't give him up because he is the only one who knows..." issues. Career progression is important, the more project specialized people are the harder it is to move up as well. You need a plan to handle it. You might consider moving 5-10% of the developers each year and making it a requirement that everyone has to be allowed to change product lines at least once every 5 years. This could help force the cross pollination, give people a chance to get new types of experience and keep the bulk of the team relatively stable. The ramp up time should be figured into the project plans because you know you will get some new developers every year. It would also help keep managers from relying too much on one person as they know he will evenetually be transferred. You might also make sure people can apply for new openings without having to have approval of their current boss (to prevent people hoarding).
I would ask your boss what he expects to gain that would offset the possible problems (I'm sure that being in the current situation you can think of more than I could. You can also probably see what the benefits might be.)
You also need to consider that you might have specialists who need to remain cross-functional no matter what. Or were you going to hire 7 business intelligence specialists (1 per projet) instead of the 2 you have (as an example). The best bet might be to do a hybrid organization where some are siloed and some are not.
You could even do a cost-benefit analysis that quantifies the risks and rewards of both possibilities so that he can see what the impact would be.
answered Nov 6 '13 at 16:37
HLGEM
133k25227489
add a comment |Â
up vote
2
down vote
up vote
2
down vote
My main concerns would be:
From an organizational standpoint, changing to this structure could be incredibly disruptive of current projects. (I've seen this happen at least twice and clients were very unhappy.) Is there any gain which could offset this disruption? This type of change would affect deadlines, would affect ability to deliver the product (some people are bound to end up on projects they are not very familair with) because of having to learn the new project. It is also incredibly risky as some things might get lost in the shuffle as people currently assigned to do them move to other projects. What would be the plan? Is there a way to do a phased change?
If there is less cross-pollination, will you be in trouble if someone key on a project takes another job? Developers tend to move around. Having fewer people know the details of projects could be costly. If we are talking project teams of 5-10 that might not be an issue, but if the teams end up as 1-2 on a particular project it could be.
If you silo people into specific product lines, are you limiting their ability to gain new knowledge (a must have for most good programmers) and thus pretty much forcing the best ones to leave to keep up their professional qualifications? The more projects you have using older technology, the worse this could be.
How easy will it be to transfer to other projects? Once you get to be expert in one project, the chances of moving around become much reduced. So if devs feel you are hurting their career paths, they will leave in droves and you will lose alot of the current knowledge. At the very least you will need a plan to allow transfers to other projects and a way to get past the "I can't give him up because he is the only one who knows..." issues. Career progression is important, the more project specialized people are the harder it is to move up as well. You need a plan to handle it. You might consider moving 5-10% of the developers each year and making it a requirement that everyone has to be allowed to change product lines at least once every 5 years. This could help force the cross pollination, give people a chance to get new types of experience and keep the bulk of the team relatively stable. The ramp up time should be figured into the project plans because you know you will get some new developers every year. It would also help keep managers from relying too much on one person as they know he will evenetually be transferred. You might also make sure people can apply for new openings without having to have approval of their current boss (to prevent people hoarding).
I would ask your boss what he expects to gain that would offset the possible problems (I'm sure that being in the current situation you can think of more than I could. You can also probably see what the benefits might be.)
You also need to consider that you might have specialists who need to remain cross-functional no matter what. Or were you going to hire 7 business intelligence specialists (1 per projet) instead of the 2 you have (as an example). The best bet might be to do a hybrid organization where some are siloed and some are not.
You could even do a cost-benefit analysis that quantifies the risks and rewards of both possibilities so that he can see what the impact would be.
answered Nov 6 '13 at 16:37
HLGEM
133k25227489
My main concerns would be:
From an organizational standpoint, changing to this structure could be incredibly disruptive of current projects. (I've seen this happen at least twice and clients were very unhappy.) Is there any gain which could offset this disruption? This type of change would affect deadlines, would affect ability to deliver the product (some people are bound to end up on projects they are not very familair with) because of having to learn the new project. It is also incredibly risky as some things might get lost in the shuffle as people currently assigned to do them move to other projects. What would be the plan? Is there a way to do a phased change?
If there is less cross-pollination, will you be in trouble if someone key on a project takes another job? Developers tend to move around. Having fewer people know the details of projects could be costly. If we are talking project teams of 5-10 that might not be an issue, but if the teams end up as 1-2 on a particular project it could be.
If you silo people into specific product lines, are you limiting their ability to gain new knowledge (a must have for most good programmers) and thus pretty much forcing the best ones to leave to keep up their professional qualifications? The more projects you have using older technology, the worse this could be.
How easy will it be to transfer to other projects? Once you get to be expert in one project, the chances of moving around become much reduced. So if devs feel you are hurting their career paths, they will leave in droves and you will lose alot of the current knowledge. At the very least you will need a plan to allow transfers to other projects and a way to get past the "I can't give him up because he is the only one who knows..." issues. Career progression is important, the more project specialized people are the harder it is to move up as well. You need a plan to handle it. You might consider moving 5-10% of the developers each year and making it a requirement that everyone has to be allowed to change product lines at least once every 5 years. This could help force the cross pollination, give people a chance to get new types of experience and keep the bulk of the team relatively stable. The ramp up time should be figured into the project plans because you know you will get some new developers every year. It would also help keep managers from relying too much on one person as they know he will evenetually be transferred. You might also make sure people can apply for new openings without having to have approval of their current boss (to prevent people hoarding).
I would ask your boss what he expects to gain that would offset the possible problems (I'm sure that being in the current situation you can think of more than I could. You can also probably see what the benefits might be.)
You also need to consider that you might have specialists who need to remain cross-functional no matter what. Or were you going to hire 7 business intelligence specialists (1 per projet) instead of the 2 you have (as an example). The best bet might be to do a hybrid organization where some are siloed and some are not.
You could even do a cost-benefit analysis that quantifies the risks and rewards of both possibilities so that he can see what the impact would be.
answered Nov 6 '13 at 16:37
HLGEM
133k25227489
answered Nov 6 '13 at 16:37
HLGEM
133k25227489
answered Nov 6 '13 at 16:37
HLGEM
133k25227489
answered Nov 6 '13 at 16:37
HLGEM
133k25227489
133k25227489
add a comment |Â
add a comment |Â
up vote
-1
down vote
If a developer writes 10,000 lines of code a year, and a team of 5 work on a project for 18 months, then one could expect the project to have 75,000 lines of code when it rolls into production. If it remains in production for ten years, it will probably expand to 250,000 lines over that time. This is a highly hypothetical case focused on either a website or subscription software - it wouldn't apply to embedded control necessarily.
100,000 lines of code divided by 50 is roughly 2000 pages, so any developer involved in a mature project has to keep the equivalent of 2000 pages of instructions in their head. If you're spreading people out among multiple projects, multiply this by the number of projects they're assigned to keep track of.
This might work if you have people who operate in very myopic roles - nothing but data services or certain kinds of summary reports or UI consistency across multiple products. However, if you want a few people to thoroughly understand a given application, they should be doing that full time. 'Cross functional' is a serious dilution of effort.
answered Nov 5 '13 at 21:36
Meredith Poor
8,8661730
Hopefully someone will explain their downvote.
– Meredith Poor
Nov 5 '13 at 21:46
Regarding your answer, thanks. I've really enjoyed the flexibility of being able to move lots of developers from one product to another, but there's probably a ton of inefficiencies happening as well.
– Eric
Nov 6 '13 at 0:02
3
Hey Meredith, as I made a significant edit to the question, you may want to consider revising your answer if it gets reopened. Just a heads up.
– jmac
Nov 6 '13 at 6:15
add a comment |Â
up vote
-1
down vote
If a developer writes 10,000 lines of code a year, and a team of 5 work on a project for 18 months, then one could expect the project to have 75,000 lines of code when it rolls into production. If it remains in production for ten years, it will probably expand to 250,000 lines over that time. This is a highly hypothetical case focused on either a website or subscription software - it wouldn't apply to embedded control necessarily.
100,000 lines of code divided by 50 is roughly 2000 pages, so any developer involved in a mature project has to keep the equivalent of 2000 pages of instructions in their head. If you're spreading people out among multiple projects, multiply this by the number of projects they're assigned to keep track of.
This might work if you have people who operate in very myopic roles - nothing but data services or certain kinds of summary reports or UI consistency across multiple products. However, if you want a few people to thoroughly understand a given application, they should be doing that full time. 'Cross functional' is a serious dilution of effort.
answered Nov 5 '13 at 21:36
Meredith Poor
8,8661730
Hopefully someone will explain their downvote.
– Meredith Poor
Nov 5 '13 at 21:46
Regarding your answer, thanks. I've really enjoyed the flexibility of being able to move lots of developers from one product to another, but there's probably a ton of inefficiencies happening as well.
– Eric
Nov 6 '13 at 0:02
3
Hey Meredith, as I made a significant edit to the question, you may want to consider revising your answer if it gets reopened. Just a heads up.
– jmac
Nov 6 '13 at 6:15
add a comment |Â
up vote
-1
down vote
up vote
-1
down vote
If a developer writes 10,000 lines of code a year, and a team of 5 work on a project for 18 months, then one could expect the project to have 75,000 lines of code when it rolls into production. If it remains in production for ten years, it will probably expand to 250,000 lines over that time. This is a highly hypothetical case focused on either a website or subscription software - it wouldn't apply to embedded control necessarily.
100,000 lines of code divided by 50 is roughly 2000 pages, so any developer involved in a mature project has to keep the equivalent of 2000 pages of instructions in their head. If you're spreading people out among multiple projects, multiply this by the number of projects they're assigned to keep track of.
This might work if you have people who operate in very myopic roles - nothing but data services or certain kinds of summary reports or UI consistency across multiple products. However, if you want a few people to thoroughly understand a given application, they should be doing that full time. 'Cross functional' is a serious dilution of effort.
answered Nov 5 '13 at 21:36
Meredith Poor
8,8661730
If a developer writes 10,000 lines of code a year, and a team of 5 work on a project for 18 months, then one could expect the project to have 75,000 lines of code when it rolls into production. If it remains in production for ten years, it will probably expand to 250,000 lines over that time. This is a highly hypothetical case focused on either a website or subscription software - it wouldn't apply to embedded control necessarily.
100,000 lines of code divided by 50 is roughly 2000 pages, so any developer involved in a mature project has to keep the equivalent of 2000 pages of instructions in their head. If you're spreading people out among multiple projects, multiply this by the number of projects they're assigned to keep track of.
This might work if you have people who operate in very myopic roles - nothing but data services or certain kinds of summary reports or UI consistency across multiple products. However, if you want a few people to thoroughly understand a given application, they should be doing that full time. 'Cross functional' is a serious dilution of effort.
answered Nov 5 '13 at 21:36
Meredith Poor
8,8661730
answered Nov 5 '13 at 21:36
Meredith Poor
8,8661730
answered Nov 5 '13 at 21:36
Meredith Poor
8,8661730
answered Nov 5 '13 at 21:36
Meredith Poor
8,8661730
8,8661730
Hopefully someone will explain their downvote.
– Meredith Poor
Nov 5 '13 at 21:46
Regarding your answer, thanks. I've really enjoyed the flexibility of being able to move lots of developers from one product to another, but there's probably a ton of inefficiencies happening as well.
– Eric
Nov 6 '13 at 0:02
3
Hey Meredith, as I made a significant edit to the question, you may want to consider revising your answer if it gets reopened. Just a heads up.
– jmac
Nov 6 '13 at 6:15
add a comment |Â
Hopefully someone will explain their downvote.
– Meredith Poor
Nov 5 '13 at 21:46
Regarding your answer, thanks. I've really enjoyed the flexibility of being able to move lots of developers from one product to another, but there's probably a ton of inefficiencies happening as well.
– Eric
Nov 6 '13 at 0:02
3
Hey Meredith, as I made a significant edit to the question, you may want to consider revising your answer if it gets reopened. Just a heads up.
– jmac
Nov 6 '13 at 6:15
Hopefully someone will explain their downvote.
– Meredith Poor
Nov 5 '13 at 21:46
Hopefully someone will explain their downvote.
– Meredith Poor
Nov 5 '13 at 21:46
Regarding your answer, thanks. I've really enjoyed the flexibility of being able to move lots of developers from one product to another, but there's probably a ton of inefficiencies happening as well.
– Eric
Nov 6 '13 at 0:02
Regarding your answer, thanks. I've really enjoyed the flexibility of being able to move lots of developers from one product to another, but there's probably a ton of inefficiencies happening as well.
– Eric
Nov 6 '13 at 0:02
3
3
Hey Meredith, as I made a significant edit to the question, you may want to consider revising your answer if it gets reopened. Just a heads up.
– jmac
Nov 6 '13 at 6:15
Hey Meredith, as I made a significant edit to the question, you may want to consider revising your answer if it gets reopened. Just a heads up.
– jmac
Nov 6 '13 at 6:15
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%2f15488%2fhow-can-an-organization-keep-the-benefits-of-generalists-on-large-scale-projects%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
I reopened this post because, in its current form, it describes a problem faced in many organizations that experience rapid growth. In its current form, this can be answered with facts, references, and be backed with shared personal experiences to support claims. Hope this helps.
– jmort253♦
Nov 6 '13 at 7:28