Cross-functional IT teams replace sequential handoffs with shared responsibility: the people who build a service work with the people who deploy and operate it, and decisions sit closer to that work. The shift can make feedback and recovery more direct, but it does not eliminate specialist expertise or governance. Organizations still need to define who owns reliability, release decisions, risk controls, and the infrastructure product teams depend on.
What changes when IT work becomes cross-functional?
In a siloed arrangement, development builds an application package and passes it to infrastructure or operations for deployment and support. Each group can complete its part while the overall service waits on a handoff, clarification, or queue.
A cross-functional team brings relevant capabilities—such as product, development, infrastructure, testing, security, and operations—into a shared delivery unit organized around a product or service. Responsibility extends across planning, building, deployment, and runtime operation rather than ending when code is handed over. McKinsey describes teams combining application-development, infrastructure-management, and operations professionals to streamline ownership across the application-delivery pipeline.
The organizational change is about where responsibility and decisions sit, not simply adding more people to a meeting. Specialists may remain in distinct roles, but they coordinate around a shared service outcome and make their responsibilities explicit.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minute#1 Best Overall
How do the four common IT collaboration models differ?
The models are best understood by looking at who deploys software, sets up infrastructure, operates the service, and integrates development with infrastructure. Organizations may combine patterns rather than adopt one model everywhere.
| Model | Handoffs | Deployment and runtime ownership | Infrastructure and integration | Feedback and governance implications |
|---|---|---|---|---|
| Siloed departments | Work commonly passes between development and infrastructure or operations. | Development builds the package; operations or infrastructure handles operational work. | Groups are relatively separate, with limited collaboration. | Issues may take longer to cross team boundaries; controls can remain concentrated in specialist departments. |
| Classical DevOps | Development and operations collaborate more closely, reducing some separation. | Development and operations share operational work, but the division varies by organization. | Integration increases, though teams may still retain distinct structures. | Collaboration can bring operational feedback closer to development; decision authority still needs definition. |
| Cross-functional product team | Fewer inter-team handoffs for work within the service team’s remit. | The team is organized to deliver and operate its service. | Relevant skills and responsibilities sit within the product-oriented unit, or connect through reliable platform interfaces. | Build, test, deployment, monitoring, and incident learning can be coordinated in one value stream; controls must be designed into that flow. |
| Platform team | Product teams can avoid repeated requests for common infrastructure tasks. | The platform team provides infrastructure capabilities; product teams use them to deploy and run their services. | Infrastructure is delivered as automated, self-service services for developers. | Reusable interfaces can improve consistency, but platform controls and product-team responsibilities must both be clear. |
Siloed departments: work moves through queues
This model separates application development from infrastructure and operations. It can preserve clear specialist boundaries, but a transfer between teams can also delay deployment or leave operational context disconnected from the people who built the application.
Classical DevOps: closer collaboration, variable ownership
DevOps brings development and operations into closer collaboration and shared operational work. It is not a single staffing chart or fixed allocation of duties: organizations draw the line differently. Teams should specify who handles deployment, infrastructure setup, on-call work, and service reliability instead of assuming the label answers those questions.
Rank #2
Cross-functional teams: a service has an enduring team
A cross-functional team has the capabilities and remit needed to deliver and operate a product or service. That can reduce coordination across departmental boundaries and let the team use operational feedback during development. It does not mean every specialist must be embedded full time; shared specialists or platform services can provide skills the team does not need constantly.
Platform teams: infrastructure becomes a reusable service
A platform team is an enabling infrastructure layer, not merely an operations department with a new name. It builds highly automated infrastructure services that developers can self-serve to deploy new services. The platform team owns the quality and evolution of those capabilities; product teams remain responsible for using them appropriately and for the behavior of their own services.
How should development and operations share ownership?
Start with the service lifecycle, not a general claim that everyone owns everything. For each service, agree on the team or role accountable for the following work and decisions:
Rank #3
- Build and test: who maintains application code, tests, and release readiness criteria.
- Deployment: who can initiate a release, what automation performs, and where approval is required.
- Infrastructure: which capabilities a product team configures itself and which are supplied through a platform or specialist team.
- Runtime operations: who monitors the service, responds to incidents, and coordinates recovery.
- Reliability and risk: who sets service expectations, accepts residual risk, and escalates unresolved issues.
- Learning and improvement: how incidents and operational signals reach the people who can change the service or its platform.
These boundaries should be visible in team agreements, service documentation, and operational procedures. A useful design principle is to keep decisions with the team that has the context and ability to act, while defining escalation and oversight for decisions that affect wider organizational risk.
How can teams move faster without losing governance?
Automation and decentralized decisions can shorten delivery cycles, but they can also make it harder to show auditors how a change was authorized and controlled. Governance should therefore be part of the delivery system, not a separate approval queue added after a team has been organized.
Free tools Windows power users keep installed
One-click scans. No signup required.
Make decision rights explicit
Document who decides on architecture, release readiness, reliability thresholds, and risk acceptance. Distinguish decisions a product team can make within agreed limits from decisions that require security, architecture, compliance, or business-risk review. Avoid vague shared accountability where no one has the authority to resolve a conflict.
Rank #4
Build evidence into the workflow
Use delivery and operational processes to retain evidence of what changed, who or what authorized it, which checks ran, and whether the change succeeded. Access controls, automated tests, policy checks, deployment records, and incident records can support both reliable delivery and later review. The appropriate controls depend on the service and its risk; not every change needs the same approval path.
Address four recurring tensions
Research on control in development-and-operations collaboration identifies four tensions that teams should surface rather than leave implicit:
- Goal conflict: delivery speed, stability, security, and compliance may pull in different directions.
- Method discomfort: teams may disagree about methods, tools, or how much standardization is appropriate.
- Decision rights: responsibility and authority may be unclear when a decision crosses team boundaries.
- Time rhythm: development cadence and operational urgency do not always align.
Regularly review these tensions with the people affected. A fast release process is not well governed if it leaves teams uncertain about who can stop a risky change or how to demonstrate that required checks occurred.
Best Value
What evidence supports these organizational patterns?
The organizational taxonomy and control findings are grounded mainly in qualitative studies, not broad performance benchmarks. One grounded-theory study reports 37 semi-structured interviews with IT professionals; a 2020 ICSE Companion study reports 27 IT professionals; and an authors’ publication summary for work on organizational structures reports 44 software professionals. These interview samples help describe how work and control are organized; they do not establish a universal performance ranking or quantify the gains any organization should expect.
No broad percentage, revenue result, or benchmark in the available evidence can responsibly be generalized to all cross-functional IT teams. Platform teams have been reported as promising, but the evidence does not establish that they—or any other pattern—are best across company sizes, services, and risk environments.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
