We've got a new project going on, and at the moment developers have been split into two teams, team A and team B. This project has 2 parts to it which require development throughout the development stack. Very simplified sample of our stack shown below:

enter image description here

Each part of the project requires development across the entire stack, so I would typically expect a full stack developer approach which is how we have been breaking down our work within team B, designing and working out the interactions between different parts.

enter image description here

I've recently learnt however, that team A want to be in charge of certain parts of the stack, and they are proposing a divide between the two teams, where the Data Abstraction Layer (and putting content in the Data layer) is handled by themselves with no development from Team B. The divide would look something akin to this:

enter image description here

To me this feels very un-natural. Each team has different distinct objectives and timescales to achieve these on, but Team B will have a dependency on Team A to implement features. The proposed solution is that common interfaces are defined up-front (there is probably a 2 year timescale on the project so they could be numerous). Team A will then develop the required bits to these interfaces early on despite having their own set of goals, while Team B stub out all calls for the immediate short term so they can progress.

I have concerns about this approach regarding:

  • Interfaces may change and Team A may not have the bandwidth or time to accommodate changing requirements.
  • Bugs in Team A's code could prevent Team B progressing, and again they may not be the priority to fix these due to Team A having a different prioritization queue.
  • Lack of knowledge spread across the teams - Team B may not fully understand what goes on under the hood and may make poor design decisions because of this.

It has been suggested that many companies in the industry have sub-teams and must be able to handle this. From my understanding, generally teams are either split how I initially expected (Full Stack) or by breaking up the technology stack like below:

enter image description here

So I'm interested in knowing what the rest of industry is doing. Are most splits vertical/horizontal? Does a diagonal split make sense? If a diagonal split were to occur do my concerns seem valid and is there anything else Team B should be concerned about? To note I'm probably going to be held responsible for the success or failure of Team B.

  • 10
    The "rest of the industry" is probably doing every combination of splits you can think of. But honestly, you did not tell us why team A wants to be in charge. And it makes a difference how big your teams are, and if they are equally qualified.
    – Doc Brown
    Apr 11, 2015 at 12:56
  • In your third illustration, is Team A and Team B's work separated by a distinct API? Is there a clear, logical boundary imposed by that dividing line? Division of labor is not exactly a new thing; Stack Exchange has their own designer, for example. Apr 11, 2015 at 15:50
  • @DocBrown I believe Team A wants to be in charge because they feel like 'too many cooks spoil the broth' after a previous project failure with a larger team - but I don't really know for certain. Teams are about 5 Devs each, and reasonably equally skilled.
    – Ian
    Apr 11, 2015 at 18:31
  • 1
    If you don't succeed in convincing them of a vertical split, you might want to have Team A commit to handle Team B's requests with higher priority as their own requests. This could prevent blocking and bad blood, and seems a fair price to pay. Apr 14, 2015 at 10:47
  • 1
    @hstoerr: Interestingly this is exactly what the scrum alliance suggest A consuming component team (the component team that uses or "consumes" the deliverables of the other component teams) acts as the product owner of the producer team. taken from scrumalliance.org/community/articles/2012/september/…
    – Ian
    Apr 14, 2015 at 10:52

1 Answer 1


Your concerns are extremely valid. Especially the first two points about Team A not having the time to add features or fix bugs that impact Team B. I've seen this happen at my own job quite a few times.

This might be a good idea if:

  • It is known that Team A will be working on the projects that require new features in the database, while Team B's goal is essentially to do "only frontend" features. For instance, if Team B is writing your company's new iPhone app, it's likely that they will not be adding new database fields for a while, as they need to port/reimplement all the features of the desktop version.

  • The "full stack" has become sufficiently complex that no single dev (or dev team) can effectively "own" the entire thing. By "own" I mean not just add features and fix bugs, but understand and care about the whole system to the point that they can avoid adding more technical debt to it over time. In this case, the "diagonal" split is the sensible move if Team A owns a UI/Web API that's either extremely simple or unavoidably tightly-coupled to the DAL/database implementation (perhaps some internal diagnostic tools?), while Team B does all the complicated user-facing frontend stuff.

  • Management understands the risk of Team A becoming a bottleneck, and would be willing to de-diagonalize things if or when this risk turns into a real problem.

I can't speak to what is more or less common in the industry, but at least where I work, there is a clear need for all application developers to be "full stack". What we do have are "infrastructure" teams that develop/maintain our in-house database, our web service framework and our UI framework (did I mention my company is huge?), so that all of our hundreds of applications can have full stack devs while the company as a whole can still provide consistent performance and UI to all of our services.

Recently our company has been making a brand new UI framework, so there was a period when some of our new apps were quite badly blocked on bugs and missing features in the new framework. This is no longer the case, mostly because some of us were given permission to submit pull requests to the team that owns the framework (not quite "de-diagonalization", but you get the idea).

  • 2
    On your second point, this seems true of any reasonably-sized business application. Libraries with well-defined API's seem to be the logical boundaries, provided they aren't too large. Apr 11, 2015 at 15:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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