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?

  • 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
    Commented Nov 6, 2013 at 7:28

3 Answers 3


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.


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.


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.

  • Hopefully someone will explain their downvote. Commented Nov 5, 2013 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
    Commented Nov 6, 2013 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
    Commented Nov 6, 2013 at 6:15

You must log in to answer this question.

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