An insurer creates a cross-functional team to improve its customer claims portal. The group includes product, engineering, design, operations, and a part-time specialist who reviews claims handling requirements. Everyone agrees that customers should be able to submit the necessary information with less assistance.
The difficulty appears when the team makes its first release plan. The specialist is needed by another programme. Operations wants a change to the information collected. Engineering identifies an integration risk. The product lead has been asked to deliver the outcome, but the team has no agreed route for resolving these competing commitments.
It would be easy to describe the result as everyone being accountable and nobody being in control. That description misses the responsibilities people do have and the choices that remain unresolved. Cross-functional accountability works through connected commitments. It does not require one person to possess every kind of authority, and it cannot remove uncertainty about the outcome.
Distinguish the Shared Outcome From Specific Responsibilities
The portal team shares an aim, but its members contribute different knowledge and work. Product can clarify which customer problem the release addresses. Designers can test whether people understand the questions. Engineers can assess implementation and integration. Claims specialists can explain handling constraints and challenge an interpretation that would create problems downstream.
Accountability needs to make those contributions reviewable. A shared outcome can guide collaboration while named roles remain responsible for particular decisions, evidence, and follow-through. Saying that the whole group owns everything makes it difficult to identify who should resolve a missing requirement or correct an inaccurate statement.
The Scrum Guide offers one explicit design: a cross-functional, self-managing team with shared accountability for a useful increment and distinct accountabilities for Developers, the Product Owner, and the Scrum Master. That is a framework-specific example of shared and differentiated responsibilities coexisting. It does not establish that every cross-functional team should adopt Scrum or use its role definitions.
For the insurer, a short account of responsibilities should be concrete enough to use. Who determines the release scope? Who assesses a disputed claims requirement? Who confirms operational readiness? Which changes need a wider organisational decision? These questions are more useful than arguing over who has overall ownership without defining what that ownership permits.
Obtain Capacity Commitments That Match the Plan
A specialist’s name on the team list does not establish their availability. The release may depend on two reviews at particular points, while the specialist’s manager understands the allocation as occasional advice whenever time allows. Both parties can act reasonably and still produce an unworkable plan.
Agree on the work and timing needed, including preparation and follow-up. A part-time contribution can work well when the required involvement is bounded and the person can meet it. Full-time allocation may be appropriate where decisions are frequent and context changes quickly. Neither arrangement guarantees success.
Record how a resource commitment can change. If another programme needs the specialist urgently, someone must assess the effects on the portal release rather than silently expecting both plans to hold. The appropriate response might be a different sequence, qualified replacement support, or a revised date. The cost of the change should reach the people authorised to accept it.
The product lead does not need hiring and firing authority over every contributor to make this arrangement credible. They need a reliable way to secure relevant capacity and resolve competing demands. Functional managers can retain responsibility for development and employment matters while making clear commitments to delivery work. The cost of matrixed accountability becomes relevant when those commitments cannot be reconciled.
Give Different Decisions Appropriate Routes
Cross-functional work does not mean every choice requires a consensus meeting. The designer can resolve many interface details through agreed research and design practice. Engineers can choose an implementation within established technical constraints. The product lead can order work within the agreed scope and resources.
Other questions have consequences that cross those boundaries. Removing a field might simplify submission but leave claims handlers unable to assess the request. A release date might be commercially attractive but depend on an integration that has not been tested. These choices require the relevant evidence and an authorised decision, sometimes involving more than one role.
A specialist’s objection should be specific enough to assess. What requirement or risk does the proposed design fail to address? Is the issue a mandatory constraint, a professional recommendation, or an unresolved interpretation? This distinction protects legitimate review while allowing alternatives to be considered. It also avoids treating all disagreement as a veto or as obstruction.
Where the team cannot resolve the choice, define who can. That could be a service owner, a designated sponsor, or a collective governance body with a clear mandate. Specify the question and the interim action. A request for help should not require the entire organisation to reopen the team’s settled decisions.
The related discussion of accountability and decision access examines why being able to reach an appropriate decision can matter as much as personally holding final authority.
Make Handoffs and Changes Visible Within the Team
Bringing functions into one group can shorten handoffs, but it does not abolish them. A prototype still needs an agreed interpretation before implementation. A completed integration still needs evidence before operational use. A decision made by two members may affect someone who was absent.
Keep a usable shared record of the few commitments that others depend on. For the portal, that might include the agreed customer journey, outstanding claims questions, integration assumptions, and release conditions. It should distinguish a proposal from an accepted change. People should not have to infer the current requirement from a long discussion thread.
When the team changes direction, identify the affected work. If research shows customers misunderstand a question, revising its wording may be straightforward. If the new interpretation changes the underlying data, claims guidance, and reporting, the change needs broader coordination. The size of the visible edit does not determine the size of its consequences.
Include external dependencies in this account. A team can be cross-functional without containing every skill or system it will ever need. A shared platform group, supplier, or independent reviewer may remain outside it. Establish how their contribution will be obtained and what happens if it is unavailable. Otherwise the team can appear autonomous while depending on commitments nobody has actually made.
Agree how the customer outcome will be assessed before making release activity the main evidence of success. The portal team might examine whether customers can complete a submission, whether claims handlers receive usable information, and how much subsequent clarification is required. A shorter form could improve completion while shifting substantial work to the handling team. That result needs discussion across the functions involved.
Define the observation period and the conditions of the comparison. A new release may initially serve straightforward claims, while the older route continues to handle more complex cases. Comparing completion rates without that context could encourage the wrong conclusion. Operational experience and customer research can help explain patterns that a headline metric leaves ambiguous.
The team also needs an agreed response when evidence is disappointing. It may be authorised to revise wording and sequence within the release, while a change to the information required needs specialist assessment. Deciding this in advance gives the shared outcome a practical effect after launch. It also avoids declaring the cross-functional responsibility finished when the software is deployed but the customer problem remains unresolved.
Agree who maintains the outcome evidence and who can access it. Customer submissions may contain sensitive information, so a shared team objective does not imply unrestricted access to every record. The team needs an appropriate way to investigate problems while respecting the boundaries that apply to the data.
Review Performance Without Inventing Complete Control
A missed release needs a fair examination of decisions and conditions. What had the team agreed? Which commitments changed? Was a material risk raised in time? Did someone with authority respond? What did the available evidence reasonably support when the decision was made?
The product lead can be responsible for surfacing a staffing conflict without being responsible for the organisation’s refusal to resolve it. An engineer can be responsible for reporting an integration uncertainty without being able to predict every defect. A functional manager can be responsible for changing an allocation and communicating the consequences. Specificity makes accountability more useful than attaching the whole outcome to a single name.
Individual conduct and capability still matter. Repeatedly failing to complete agreed work or concealing a known problem warrants attention through an appropriate process. Examine workload, clarity, support, and the person’s actions rather than assuming either that every failure is systemic or that a different person would have solved it.
Performance evaluation should recognise contributions to the shared work as well as professional standards. Functional quality and team delivery need not be competing goals. Where they conflict, people need a decision about the actual trade-off, not an instruction to satisfy incompatible expectations privately.
The insurer’s team becomes more accountable when it can explain what it is trying to achieve, who has committed to each contribution, and how unresolved choices will be settled. Its members still depend on one another. The organisational task is to make that dependence workable enough that commitments can be made, challenged, revised, and reviewed fairly.
