On the question of how team structures align with service boundaries, something we've been experimenting with (quite successfully) is a less-strict division...
There are "squads" that have cross-functional representation for prioritization, risk-assessment and mitigation, and other "architectural" concerns, but the people on these squads take part in other structures as well.
When a unit of work has been sufficiently spec'd out, including the knowledge and skills needed for it, a "task force" gets formed. Any code written by that task force is submitted as pull-requests to the relevant repositories.
Those pull-requests are reviewed by "maintainer groups" - loosely one per repository. These maintainer groups take a longer-term perspective on a code-base than a task-force, and help balance the forces of delivery with maintainability.
Usually, the task force that is doing work across a number of repositories is made up of members from the maintainer groups of those repositories, as well as members of the squad.
There is also long-term rotation built-in to each of the longer-lived groups like squads and maintainer-groups, in addition to the natural osmosis from people working in different task-forces that form and dissolve. This is how knowledge is continuously spread across the org.
This non-strict / fluid association between an individual and a "service" has been working quite well for us for some time, with people distributed across the globe from Australia, Europe, and North America. It has taken a good 2-3 years to figure this out, though.
This does introduce some separation between a "business stakeholder" and the people that implement the code. Yet, we've found that that is usually a good thing, and helps avoid implementing workarounds rather than fulfilling more important business objectives.
It turns out that the "best" way to achieve most business objectives requires cross-functional collaboration, often touching areas of code not originally envisioned as being affected. Thus, having a 1-to-1 mapping from "business boundaries" to "code boundaries" isn't always ideal
One question is "how does this impact the speed of delivery?". The answer is somewhat philosophical: slow is smooth, and smooth is fast.
When developing a new skill, you start slow to build competence which, over time, enables you to smoothly go through everything correctly, and that smoothness, over time, develops into a fluid speed that keep quality high.
If you try to go fast prematurely, essentially "rushing", than quality tends to suffer. Under those conditions, people tend to institute various workarounds to try to compensate, usually increasing overall complexity.
Organizations need to realize that some things just take time (cue Mythical Man-Month references). Maturity can't be mandated, top-down. It needs to be nurtured. Mistakes will happen, that's natural. Invest in the long-term. Be patient.
This can be a challenge in organizations where upper management is measured quarter-to-quarter, whether that's public companies by the market/analysts or venture-funded companies by a board looking for constant growth.
This long-term thinking has been Jeff Bezos' approach at Amazon from the beginning, and one of the things that I think contributes to their continued success. Reference: 1997 letter to Amazon shareholders: media.corporate-ir.net/media_files/ir…
Anyway, just wanted to share some different thinking about organizational structure and processes, what's been working for us, and what we've learned along the way. Feel free to ask questions and share your experiences.
