# Prefer Vertical to Horizontal Teams There are two ways of splitting workforce into teams: by technology layer and by business capability. **The traditional way is to split teams by technology layer into a data team, UI team, backend team, etc.** This horizontal method (think stack) however has significant drawbacks. **==Simple changes require cross-team communication==, which leads to logic in every layer as, instead of paying the communication price, ==teams shove logic wherever possible==**, and experience has shown that logic in the UI is a recipe for disaster. Additionally, if a team is split horizontally it has to know the details of each service, making onboarding harder, and potentially making service separation more difficult to enforce. **==Instead, teams should be split vertically, making them in charge of a whole service== (or services).** This split suffers none of the drawbacks listed above and has extra benefits as well. **By letting them see the bigger picture, it helps developers think in terms of the whole problem and be closer to customers**, and by putting them in charge of operations and support as well as development and deployment it incentivizes them to focus on code quality as no one likes getting an emergency alert in the middle of the night. If your application crosses different [[Bounded Context]]-s, try to assign a single [[Bounded Context]] to one team only, to minimize [[Cognitive Load]].