What are the advantages and disadvantages of splitting teams by architecture tier rather than by product?

Question

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.

Answer 1

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.

Answer 2

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.