The Enabling Team: Coaches, Not Gatekeepers
Even with a great platform, Stream-aligned teams will periodically hit walls. They need to adopt a new technology, improve their security posture, or optimize performance — but they lack the expertise to do it well on their own.
The Enabling team fills this gap. They are specialists who temporarily embed with Stream-aligned teams to transfer knowledge and capability.
The critical distinction: Enabling teams do not own the outcome. They teach the Stream-aligned team to fish; they don't fish for them. Once the Stream-aligned team has the skill, the Enabling team moves on.
Example: A security Enabling team embeds with the Payments team for six weeks. Together, they implement automated SAST scanning in the CI pipeline, conduct a threat modeling session, and document secure coding patterns for the team's specific tech stack. After six weeks, the Payments team owns and runs all of this themselves. The Enabling team moves to the next team that needs help.
Anti-pattern: An Enabling team that becomes a permanent dependency — where Stream-aligned teams always need to ask them before doing anything security-related — has become a gatekeeper, not an enabler. This increases cognitive load and slows flow.
The Complicated Subsystem Team: Specialists Behind an API
Some technical problems are genuinely hard in ways that go beyond normal software engineering. A fraud detection engine using custom ML models, a real-time video transcoding pipeline, or a high-frequency trading execution engine all require deep, specialized expertise.
Asking a Stream-aligned team to own one of these subsystems in addition to their business domain would be unreasonable. The cognitive load would be crushing.
The Complicated Subsystem team takes ownership of these components and exposes them via a clean, well-documented API. Stream-aligned teams call the API; they never need to understand what's happening inside.
Example: The Fraud Engine team maintains a REST API: POST /fraud-check with a transaction payload, returning a risk score and recommendation. The Payments team calls this API. They don't know — and don't need to know — that behind it is a gradient boosting model retrained nightly on 200 features.