Team Setups in Larger Projects: Delivering Across Team Boundaries
PersonalModern features no longer fit into a single team. That has become normal.
An IoT device sends events. An MQTT service forwards them. A mobile app displays them. Add deployment on AWS, a database schema, push notifications, UX for edge cases, IT security for authentication and privacy, and operations for three environments.
That is five to six disciplines. Many companies have separate teams for each. That is exactly where the problem starts.
The Paradox: “You Build It, You Run It” — But the Teams Are Separate
“You build it, you run it” is a clean principle. Werner Vogels popularized it in a 2006 ACM Queue interview: the team that builds the software also operates it.1 No throwing it over the fence to a separate operations team.
It only works if one team can own the system end to end. When development, UX, operations, and architecture sit in separate departments with their own priorities, end-to-end responsibility disappears under coordination overhead.
I see exactly this happening in my current project: UX, operations, and architecture are being pulled out of the development teams. Coordination is missing, or only possible with effort. Different priorities cause delays. Missing information costs time.
My practical estimate: if we had implemented our IoT feature (device → MQTT → push notifications → mobile app) across four separate teams, each with its own roadmap, we would have lost at least 30 % more time through coordination and conflicting prioritization alone.
The reason is structural. Conway described in 1968 that a system’s architecture mirrors the communication structure of the organization.2 Distribute the work on a feature across separate teams and you get a feature that breaks at exactly those boundaries.
The Solution: One Team with Real Throughput
We did it differently. One team took the lead — somewhat by accident, because it could hold it all together: the necessary skills, the context, and the capacity.
One point matters here: this role does not have to be assigned formally. It is a capability, not a hierarchy. The team could engage with problems early and react quickly because it could create an overview for all other disciplines.
In Team Topologies terms, that is a stream-aligned team: organized along a value stream, cross-functional, responsible from concept through operations.3
On-Site Coworking: The Concentrated Block
Teams were brought to one table. On-site, one or two days of intense work on the end-to-end slice.
It was shoulder-to-shoulder work instead of a meeting marathon. Together with UX, we clarified what the app should show when the connection drops. We first built the prototype as a PoC; later these insights flowed into Terraform scripts. We decided architecture questions about interfaces at the whiteboard.
A concentrated block replaces weeks of message ping-pong. Afterwards, we had our first end-to-end slice.
Concepts as Proposals, Not Directives
The lead team drafted a technical concept: MQTT topic structure, push notification flow, database schema, deployment strategy. All documented and reasoned.
This concept went to the other teams as a proposal. They contributed their expertise: “For our use case we still need X here.” — “The schema does not fit our infrastructure; would Y also work?”
That changes the dynamic. Everyone is invested in the same concept instead of having to implement an externally imposed requirement. Team Topologies calls such close, time-bound collaboration “collaboration” — high throughput, deliberately temporary.[^3]
IT Security Belongs in the Team From the Concept Phase
One discipline is still missing from most lists of this kind: IT security. It matters more and more — and just like UX or operations, it only works if it is thought through across team boundaries.
The usual mistake: security is defined externally after the fact. An architecture review after implementation, a pentest shortly before launch, a checklist to be ticked off at the end. The problem is not the care of the review, but the timing. Raise security requirements only after the architecture is already in place and you get rework instead of secure design.
If software is supposed to be secure from the ground up, that has to happen in the concept phase — with all parties at the table. For our IoT feature, that meant: how does the device authenticate? What data is even allowed in the MQTT payload? How is the push notification pipeline secured against abuse? You cannot answer such questions cleanly if security is only brought in after the first end-to-end slice.
The same pattern applies here as with the other disciplines: the harder the coordination, the greater the risk that gaps arise. Not out of negligence. Because nobody with full context is at the table at the right time.
Terraform for Fast Changes
A big problem with cross-team features is the many environments: test, integration, production — each with its own configuration and secrets.
We put everything in Terraform. When something changed — a new queue, a different Lambda timeout, an additional SNS topic — the lead team updated the script and deployed in minutes. No manual clicking in the AWS console, no Jira ticket, no waiting for another team. Everyone could trace changes transparently.
Learnings from the test phase flowed directly into integration and then production. Changes to the setup and deployments of the individual environments took minutes, not days.
Continuous Learning: From Test Phase to Operations
After launch, it got interesting. We observed where the load lay, which notifications were actually needed, and where latency caused problems.
We could implement every insight quickly because the same team kept working with the same mental model. We still use the learnings from the first test phase to optimize production operations today — that saves real money: lower AWS costs, less database load, better user experience.
If another team had taken over operations after launch, these optimizations would have come much slower, if at all.
Knowledge and Responsibility Cannot Be Outsourced — Not Even to AI
An obvious objection: can’t contextual knowledge be documented and handed over — perhaps even processed by AI?
In my experience, not completely. AI can summarize documentation, recognize patterns, and help with onboarding. But the knowledge individual people build during development is never fully captured in any document. Why a decision went one way and not another. Which edge cases were consciously accepted. Which dead ends have already been tested. That knowledge emerges in the doing and lives in the heads of the people involved.
Real responsibility can therefore only be taken by the team that was involved in the development itself. Responsibility requires understanding, and understanding arises through participation.
A practical recommendation follows: if operations is ultimately supposed to be taken over by a separate team, its members should actively participate during the creation — as part of the coworking sessions and concept work, not as spectators in a handover meeting. That way, knowledge travels with the people, not just with documents. This aligns with DORA research: high delivery performance comes from shared responsibility across the entire lifecycle, not from isolated ownership by individual departments.4
Knowledge also develops over the lifecycle of software — not statically, but almost event-based. Every decision, every incident, every operational learning shifts the context a little further. A handover document can only ever capture a snapshot. That is the state at a specific point in time. A snapshot is better than nothing. But part of the overall context is inevitably lost, because events after that no longer enter the document. They only remain in the heads of those who experienced them.
One distinction matters for evaluating such setups: do you look at the lifecycle of a single software component, or the lifecycle of the whole feature — across teams, platforms, and components? The lifecycle of a single piece of software is far less valuable by itself. It only answers what one part of the system does. It does not answer why the feature as a whole works the way it does. Only the continuous view across all involved teams and components completes the context. And exactly this continuous view is lost when knowledge is handed over at team or system boundaries as a snapshot instead of growing continuously.
Why This Works
The bottleneck in cross-team features is rarely technical. It is the lack of a shared mental model.
When five teams work independently, they have five different ideas of the system: five different assumptions about interfaces, tolerances, and responsibilities. The coordination itself becomes a source of error.
A lead team with access to all disciplines creates a single source of truth: a consistent vision, iteratively improved by the feedback of other experts. On-site coworking compresses coordination. Terraform enables fast iterations without approval loops. Continuous monitoring keeps the team learning.
This Is Known, but Often Overlooked
Team Topologies, squad models, cross-functional teams — all of this is well documented.[^3] Still, many organizations insist on keeping operations in the ops department, UX in design, and development in engineering.
For stable, well-understood features, that works. For new features whose direction changes with every learning, it measurably slows things down. The structure is the cause, not the people.
Conclusion
If your next larger feature needs multiple disciplines, this approach has worked well for us:
- One lead team: the group that holds the core together — practical, without hierarchy, with access to the necessary experts.
- A concentrated block: one to two days on-site to build the shared mental model.
- Concept as proposal: integrate the expertise of the other teams instead of overriding them — including IT security from the concept phase, not as a later review.
- Automation: Terraform and CI/CD so changes are validated in minutes.
- Continuous learning: keep optimizing after launch with the same team — and involve the operations team from the start. Knowledge emerges event-based over the entire lifecycle of the feature, not as a one-time snapshot.
One honest caveat: a lead team does not scale forever. With very many involved teams, you also need clear interfaces and platform teams that take over recurring tasks. And on-site coworking costs travel time and money — it pays off for the first end-to-end slice, not for every small change.
Most of this is primarily an attitude — and that is what decides whether a cross-team feature takes weeks or months.
What does your team structure look like? Do you face similar problems with cross-team features — or have you found another way to solve them?
Sources
- Werner Vogels: A Conversation with Werner Vogels — ACM Queue, 2006. queue.acm.org/detail.cfm?id=1142065 ↩
- Melvin E. Conway: How Do Committees Invent? — Datamation, 1968. melconway.com/Home/Conways_Law.html — Context by Martin Fowler: martinfowler.com/bliki/ConwaysLaw.html ↩
- Matthew Skelton, Manuel Pais: Team Topologies (2019). Key concepts: teamtopologies.com/key-concepts ↩
- DORA: State of DevOps Report 2024 and DORA Metrics Guide. dora.dev/research/2024/dora-report · dora.dev/guides/dora-metrics ↩
Leave a Reply