As the title states; what are the advantages and disadvantages of splitting teams by architecture tier rather than by product?

For example:

Organization A has three teams:

  • Team Web and Front End
  • Team APIs, Web-Services and Data Stuffs
  • Team Embedded Stuffs

Organization A teams, over time, have become more specialized in their work rather than being truly full-stack developers.

Organization B has three teams:

  • Team Product Alpha
  • Team Product Beta
  • Team Product Charlie

Organization B has fostered an environment of full-stack developers that are all fairly interchangeable among one-another.

What will Organization A be able to do better (and not so better) than Organization B, and vice versa?

You don't necessarily need to take the examples to heart, as they were just to get the point of my question across.

  • Are we suppose to assume that people on the architecturally divided teams are not capable of working on another team? – JeffO Jun 17 '14 at 19:19
  • Let's make these assumptions (that I will also update the question with). Organization B has fostered an environment of full-stack developers. Organization A teams, over time, have become more specialized in their work rather than truly full-stack. – BrandonV Jun 17 '14 at 19:24
  • @BrandonV - That doesn't really happen. Because unless there is a barrier all of the teams talk to each other outside of their scrums, and work together to solve problems. If there is a barrier then you end up with dysfunctional teams full people who are too lazy to find a new job or too not good enough to get a better job, or so much of a jerk no one wants to hire them. You can end up that way with either organizational structure. – SoylentGray Jun 17 '14 at 19:33
  • 2
    This question is about a business process not programming – SoylentGray Jun 17 '14 at 19:35
  • 1
    What doesn't really happen? I'm not inferring that there are any walls here other than team focus. Traditionally, in agile methodologies, teams are split up by products and focus on a particular suite of products. I have also seen teams split by architecture tier, where the "web-service team" writes the web services, and the "web team" writes the client-side pieces, etc, etc. I do not think this question is about business process. It is about how these aforementioned team structures affect the SDLC. – BrandonV Jun 17 '14 at 19:38

The tier-bound organization runs the risk that decisions will be made based on who will implement them rather on where they should be implemented. For example, design a feature so that the major part of the work will be done in tier X, even though it naturally belongs to tier Y, since the tier Y team happens to have much more workload than the tier X team. These decisions might be correct business-wise, but they still incur technical debt and the project-bound organization can usually depend more purely on technical and architectural reason when making these decisions.

On the other hand, the tier-bound organization has an advantage since contrary to intuition - the borders between projects should be less strict than the borders between tiers. The interaction between tiers should be strict and depend on clearly defined protocol, and having separate teams implement the sides of these interactions force the teams to keep the protocols strict and well defined.

The borders between projects should be less strict since they share code, and sharing code is less dangerous than sharing data. If some code was useful in tier X of project A, it's more likely to be useful in tier X of project B than in tier Y of project A. I mean - how many JavaScript functions from your one-page framework are going to be useful in the database? A tier X developer working on project B might be familiar with that code since they've seen it in project A. A project A developer working on tier Y of the project might be familiar with that code since they've seen it in tier X - but they wouldn't be able to reuse it in tier Y anyways.

Data, on the other hand, must be shared between tiers of the same projects, and since sharing data is dangerous you need more strict borders. Here's where the separation of teams can be beneficial - if the desktop app could use access to some data from the server for a quick and dirty solution, a project-bound developer might be tempted to give it that access(since these programmers control both tiers), but a tier-bound developer will have to request that access from the server team, which are more likely to say no(since they have less need for that particular dirty hack so they are less inclined to corrupt the interface to support it) and force the desktop developer to seek a more proper solution.

Project separation is less important in this regard - there is far less need to share data between projects, and when there is such need it's often done through another tier(e.g. two smartphone apps talking through a server), and even when it's done directly, you need to give very little damn to screw this up with dirty tricks, since the border between projects is clearer than the one between tiers.


I would go with what works for the team members you have and/or are able to hire. Sort of let it happen organically. Larger organizations can probably hire enough specialists to handle all the tasks they need. This can also depend on how "agile" you really want to be. If everyone can do everything, you have the most flexibility.

One organization may have the luxury of allowing people to specialize because their projects are very similar. You have all the expertise you need and the workload can be balanced. On the other hand, if this organization has been forced to let people focus on one area because they lack the ability to be proficient in many areas, they will be limited in the types of projects they can do or are forced to hire external help to fill the void or help with the workload.

You really have to keep your documentation and domain knowledge up to date if you're going to let developers work on multiple projects.

We tend to think of programmers that can use many languages and work in all aspects of a project to be higher caliber, but it could also mean they know how to build crap 6 different ways.

Both can work and both can be bad. If I found myself having a team that likes to work in all phases of the stack, there would have to be significant increases in production before I would force them to specialize.

  • 3
    "We tend to think of programmers that can use many languages and work in all aspects of a project to be higher caliber, but it could also mean they know how to build crap 6 different ways." +1 – Matt Klinker Jun 17 '14 at 20:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.