A customer asks why orders from its online store are getting stuck before they reach the ERP. In this hypothetical project, the integration developer can trace the request, the finance consultant understands the tax mapping, and the support lead sees the complaints. All three join the same call. The developer still needs a separate approval to change the mapping, and support has to ask again before telling the customer what happened.
Before adding someone to the call, look at what the team has to wait for.
What Amazon puts inside a two-pizza team
Amazon uses two pizzas as a rule of thumb for a small team with a defined product or service. AWS’s account puts particular weight on ownership throughout the lifecycle. The people who build the service stay responsible for how it runs and how it serves customers. The account also describes potential duplication and silos when autonomous teams split up. AWS Executive Insights, Amazon’s Two-Pizza Teams
For the ERP connector, a workable scope might be getting a valid online order into the ERP, telling support why an order failed, and owning the retry process. Give that team the people and access it needs to handle those outcomes. Keep company-wide accounting policy with finance. Agree on the tax mapping and the conditions under which the connector team can apply it, so routine fixes can proceed and exceptions still reach the people authorized to decide.
Waiting for a handoff and waiting for someone to volunteer
Both can produce a quiet queue. The handoff case may be a consultant who has evidence ready and is waiting for a decision. In the second case, everyone can see the failed-order queue and nobody is explicitly responsible for inspecting it.
Steven Karau and Kipling Williams used social loafing to describe a tendency to expend less individual effort when contributions are pooled. Their 1993 meta-analysis covered 78 studies. Whether individual contributions could be evaluated and whether the task felt meaningful were among the factors that influenced the effect. The paper studies effort on collective tasks. It gives us a reason to make contributions visible and meaningful, with no basis for treating an ERP ticket queue as a test of anyone’s motivation or prescribing a team size. Karau and Williams, 1993
On the connector team, have a named person on rotation inspect the queue and explain what they found. Have another person ready to cover. Explain who uses that work. Support can reply with evidence, and finance can distinguish a tax mapping issue from a missing order. A shared queue can still be a team responsibility when the first action is clear.
Draw the route of one ticket
Take a recent connector problem and write down who handled each step, where it waited, and what permission would have shortened the wait. Pick a single change for the next two weeks. The integration team might take over the first response for failed orders within an agreed scope, while finance keeps authority over policy changes.
Compare the median time from detection to a named owner and from a named owner to a decision. Count handoffs that actually blocked progress and check how many tickets reopened. Keep the ticket count and mix beside those figures. Faster assignment during a week of easy fixes tells you less than a comparison between similar issues.
If the same approval still stalls most tickets, revisit the team’s authority before changing the seating chart.