Start with a decision, not a new tool
A coordination problem is a moment when people cannot move shared work forward with the information, authority, or working agreement available to them. The useful question is not which team communicates badly. It is what decision or handoff failed, what the participants needed at that moment, and what would have enabled the next action. This guide proposes a way to separate three possible contributors: ownership and authority, the procedure for moving work, and the systems that carry information. The categories are prompts for investigation, not a diagnostic score.
Begin with one recent event that the people involved can reconstruct. A release waiting for approval, a request returned for clarification, or a customer implementation delayed by missing access is more useful than a general complaint that collaboration is poor. Write the expected action and the actual action in two sentences. Identify the people directly involved by their working roles. Then ask what evidence is available without collecting private conversations or evaluating individual employees. The purpose is to improve the conditions around the work.
The output should be a small experiment with an owner and a review point. It may be a clearer decision boundary, a better acceptance agreement, or a change to where a decision is recorded. It should not automatically be a software purchase, another recurring meeting, or an organizational redesign. Those changes can be appropriate, but the evidence must support them. A useful investigation can also conclude that the problem is not yet understood and specify the next observation needed. That is a better result than a confident but unsupported diagnosis.
Define the three lenses
The structure lens concerns who may decide, who is accountable for an outcome, and how competing priorities are resolved. For this guide, structure includes temporary ownership agreements as well as formal team boundaries. A structural question might be whether a shared platform team can decline a request or whether two managers are making incompatible commitments for the same person. A visible task owner does not necessarily possess the authority needed to resolve either situation. Record the actual decision right rather than inferring it from a job title.
The process lens concerns what people agree to do as work changes state. Examples include when a request becomes ready, what counts as acceptance, how a changed date is acknowledged, and what happens when the receiving team cannot proceed. A process may be written down but understood differently by its participants. It may also work well in ordinary cases and fail when a dependency changes late. Describe the procedure people actually follow, including exceptions, before proposing a replacement.
The tooling lens concerns whether the agreed information can be created, found, accessed, updated, and connected to the relevant work. A working agreement might be clear while the recipient cannot open the linked artifact. A decision might exist but remain detached from the task it changes. These are candidates for a tooling intervention, but access controls may be intentional. The goal is appropriate access through the approved route, not making every document visible to everyone. Several lenses may apply to one event. There is no universal rule that one category must always be fixed first.
Build an event record you can inspect
Choose a bounded interval around the event. Identify the last point when the participants agreed on the next step, the first observable sign that the agreement failed, and the decision that eventually moved work forward. Use dated records where available. If someone remembers a conversation but there is no record, mark that entry as recollection. If two accounts differ, keep both accounts visible until the difference is resolved. Do not fill gaps with a story that happens to fit your preferred explanation.
Separate observations from interpretations in the record. An observation might be that the receiving owner requested a revised file on Tuesday and the supplying team first acknowledged the request on Thursday. An interpretation might be that the sender did not prioritize the work. The dates alone do not establish the reason. There may have been a permission problem, an absence, a conflicting commitment, or uncertainty about which file was authoritative. Each explanation requires different evidence and would lead to a different intervention.
Collect the smallest set of material needed for the investigation. A link to an approved project artifact, a concise description of the requested decision, and the relevant timestamps may be enough. Avoid exporting entire chat histories or customer records merely because they are convenient to search. Agree who can see the working notes and when they will be removed or archived under your organization's policy. A public case study should use a fictional example or separately permissioned material; an internal incident record is not automatically suitable for publication.
Test ownership and authority
Ask the supplying and receiving roles independently who could have made the blocked decision. Compare the answers before introducing a new responsibility chart. If they name different decision owners, identify the specific disputed boundary. One person may own technical readiness while another owns the launch date. Both answers can be reasonable if the decision itself was never separated into parts. Rewrite the decision so that each part has an accountable role and an explicit route for resolving disagreement.
Next, test whether the named owner had the capacity and authority to act. A person assigned to coordinate a handoff may not be permitted to change scope or reallocate work. Giving that person another reminder will not create the missing authority. Ask what options they could actually choose, which options required approval, and who could decide between competing commitments. If no permitted option existed, document the constraint and take it to someone who can change it. Do not label an impossible commitment as an individual follow-through problem.
A small structural experiment could delegate one bounded decision for a limited period. Define the decisions covered, the decisions excluded, the conditions requiring escalation, and the review date. Avoid changing reporting lines merely to test whether clearer ownership helps. Look for contrary evidence too: if all participants named the same authorized owner and that person acted promptly, the ownership explanation may be weak. Move to the process and information checks rather than forcing the event into a structural category.
Test the working agreement
Reconstruct what the sender believed they were handing over and what the receiver believed they were accepting. Compare the deliverable, the condition of readiness, the date needed, and the action that acceptance would enable. A file being uploaded is different from a deliverable being usable. A task marked complete is different from the next team agreeing that its conditions have been met. Write down the observable checks that distinguish these states for this particular piece of work.
Examine changes as carefully as the original agreement. When a date, dependency, or acceptance condition changed, who needed to know? Where was the change recorded? Was notification sufficient, or was acknowledgement required before another team could safely replan? A process can fail because everyone followed a different reasonable rule. The improvement may be a short agreement about changes rather than a larger workflow. Start with the transition that failed and keep unrelated stages outside the experiment.
Test the proposed procedure with an ordinary case and an exception. For example, rehearse a handoff that meets all conditions, then rehearse one that arrives on time with an unresolved access requirement. The second case reveals whether the procedure supports conditional acceptance, rejection, or a fallback. Name the decision owner for the exception. If the only available instruction is to escalate, explain to whom, with which information, and by when a decision is needed. An escalation path without an actionable decision can become another queue.
Test the information path
Use an approved sample artifact and ask a receiving team member to find the current decision, its rationale, and the work it changes. Observe the path without coaching them through every click. Record where the route becomes ambiguous: multiple documents, an outdated task description, a broken link, a permission request, or a decision stored only in a meeting recording. Do not convert the exercise into a speed contest. The point is to discover what makes the information usable or unusable.
Check the same path after a realistic change. Update a sample assumption or delivery date and ask where the receiver would see it. Does the task link to the decision? Does the decision identify affected work? Can the team distinguish the current version from a superseded one? A search result proves that text exists somewhere. It does not prove that the person making the next decision can recognize its authority, understand its scope, or know whether it still applies.
Only then describe a tooling requirement. A precise requirement might be that a receiving owner can open the approved specification from the handoff record and see its last confirmed version. Another might be that changing a commitment produces a visible acknowledgement request for affected owners. Evaluate any proposed system against that concrete journey. Include migration effort, permissions, maintenance, and failure recovery in the comparison. This guide does not claim that a particular product supports those behaviors; verify them directly in the environment you intend to use.
Compare explanations before choosing an intervention
Create a short explanation table in your team document. For each candidate explanation, record the observation supporting it, an observation that would weaken it, and a small test. For an ownership explanation, the supporting observation could be conflicting answers about who can approve a scope change. For a process explanation, it could be incompatible definitions of ready. For a tooling explanation, it could be an agreed decision that the receiving owner cannot locate through the normal work record.
Treat category labels as working hypotheses. A broken link does not prove that tooling caused the delay; the required decision might never have been made. A missed acknowledgement does not prove the team needs a new process; the recipient may not have had permission to view the request. A repeated escalation does not necessarily justify a reorganization; a limited delegation might address the specific bottleneck. Ask what would have happened if the suspected condition had been different while the other conditions stayed the same.
Choose an intervention that is proportionate to the evidence and possible to reverse. Define the expected behavioral change rather than promising a performance percentage. For example, the next receiver should be able to identify the accepted version without contacting the sender. Name a counterexample that would make you reconsider. If several explanations remain equally plausible, improve the event record or run a narrow observation exercise first. There is no benefit in attaching a numerical confidence score that the available evidence cannot justify.
A worked example: a release that could not move
The following example is fictional. A product team expects to release a new reporting view on Thursday. The data team delivers a schema file on Tuesday and marks its task complete. On Wednesday, the product team discovers that a required field has a different meaning from the one assumed in the interface. The teams exchange messages, but neither knows who can approve the interpretation change. The release waits while a manager collects the history. No actual company or customer is represented here.
The event record contains three separate observations. First, the acceptance agreement describes a file format but does not describe the meaning of the disputed field. Second, the task links to an earlier decision while the later discussion is stored elsewhere. Third, the teams name different owners for approving a change to the field definition. Calling the event a communication failure hides these differences. The team writes three hypotheses instead: acceptance was incomplete, the decision path was fragmented, and authority for semantic changes was unclear.
The chosen experiment covers only the next reporting handoff. The receiving owner adds one example record and an interpretation check to the acceptance conditions. The supplying owner links the current decision from the handoff task. A named product and data decision pair agrees who makes the final choice if interpretations differ, with an escalation route for changes outside their authority. At the review, the team examines whether these steps were used and whether unresolved questions surfaced before acceptance. It does not claim that one successful release proves the experiment caused a general productivity improvement.
A counterexample: the team already knew what to do
Consider a second fictional case. An implementation team has a clear receiving owner, explicit acceptance conditions, and an agreed fallback. The work still waits because the recipient's account lacks access to the approved artifact. The access request is sent to a former administrator and receives no response. An investigation that begins with the assumption that ownership is always the root problem might redesign the handoff agreement and add a meeting. Neither action repairs the access route.
Here the immediate test is to follow the approved permission workflow with the responsible administrator. Confirm which role should grant access, what authorization is required, and how the recipient can track the request. The process may need a small correction if the ownership of access requests is outdated. The system may need a visible status or a maintained contact. The appropriate remedy does not require distributing the artifact outside its intended audience or bypassing security controls to make the handoff appear faster.
Compare this case with the release example before adopting a standard solution. Similar symptoms can arise from different conditions, and a single event can involve several conditions. Keep a small set of contrasting examples in your team review so that a familiar narrative does not become the only explanation you consider. When a proposed intervention would not have changed the sequence of the actual event, explain why it is still relevant or remove it from the experiment.
Write the experiment agreement
An experiment agreement should fit into a document the participants can read during their normal work. Start with the event being addressed and the observable condition you intend to change. Name the participating roles and the kind of work included. State the exact action each role will take, the record where it will be visible, and the exception that should trigger a different decision. Specify when the team will review the result and who can end the experiment early.
Add a practical success observation and a burden observation. A success observation might be that both parties can point to the same accepted version and explain the next action. A burden observation might be the additional time required to maintain the agreement or the number of times people copied the same information into different places. Do not assume that more documentation is automatically better. A proposed procedure that removes one ambiguity while creating several maintenance obligations may need to be simplified.
Keep the commitment small enough that the team can honor it. Use a named review date or a named set of upcoming handoffs rather than an indefinite trial. Write the fallback if the experiment cannot be used during an urgent situation. Decide where observations will be collected and limit access appropriately. Before starting, ask each participant to explain the procedure in their own words. Differences at this stage are useful: they are cheaper to resolve than differences discovered after another blocked handoff.
Review outcomes without manufacturing proof
At the review, compare the agreed procedure with what actually happened. Begin with adoption: was the new step used, and could the participants access the agreed record? Then examine the decision or handoff it was intended to improve. If the work moved sooner, ask whether scope, staffing, urgency, or dependency conditions also changed. A small operational experiment can support a practical decision without establishing a causal result that applies to other teams. Keep those two claims separate.
Use observations with clear definitions. If you record waiting time, define its starting and ending events and distinguish working time from calendar time. If you count clarification requests, distinguish a useful early question from avoidable rework after acceptance. Do not combine unlike events into an impressive average. Keep a note of missing data and exceptions. A simple event comparison that participants can inspect is more useful than a composite score whose meaning is unclear.
Choose among continuing, simplifying, changing, or stopping the experiment. Record why. If the procedure was not used, first ask whether it was practical rather than concluding that the team resisted improvement. If it was used but the problem persisted, revisit the original hypotheses. If it helped in one kind of handoff but not another, narrow its scope. Preserve the resulting working agreement in the place where the next team will look for it, and retire superseded instructions so that the experiment does not leave conflicting versions behind.
Adapt the method to your situation
For a small team, combine roles only when the decision remains explicit. One person may supply work and coordinate its acceptance, but the receiver still needs a way to disagree or identify missing conditions. Keep the record short and focus on a consequential event. The method does not require a dedicated operations function. It does require enough separation between the proposed explanation and the evidence to allow someone to challenge the explanation without challenging a colleague's intentions.
For distributed teams, identify which steps can happen asynchronously and which decision needs simultaneous discussion. Give participants a clear question and a place to record their answer. Time zones and working schedules should shape the checkpoint. Do not treat lack of an immediate response as lack of commitment. For teams using external partners, distinguish the working agreement from contractual obligations and involve the appropriate owner before changing commitments that reach beyond the internal team.
For urgent or regulated work, follow the established incident, approval, and recordkeeping procedures. Use this guide afterward to investigate coordination conditions, or adapt it with the relevant operational owner. It is not a substitute for incident command, professional advice, or formal controls. Where trust is low, start with a jointly chosen fictional rehearsal rather than extracting a disputed incident. Where the evidence is too sensitive to share, record the decision and its permitted summary instead of copying the underlying material into a broader workspace.
Turn the diagnosis into a reusable team habit
A useful habit is a short check whenever an important handoff becomes blocked: identify the next decision, the authorized owner, the acceptance condition, and the current record. Use the answer to choose the next action. Do not require every small task to pass through a formal diagnostic session. Reserve the deeper investigation for repeated or consequential ambiguity. The goal is to make shared work easier to move, not to create a parallel reporting system.
Over time, keep an index of the agreements that remain useful. Organize it by situations the team recognizes, such as a scope change, an access request, or a dependency that arrives with unresolved conditions. Link to the current procedure and explain when it applies. If several guides repeat the same decision rule, merge them. If an old agreement no longer matches the way the team works, update or retire it. A smaller maintained library can be more usable than a large collection of contradictory instructions.
The interactive checklist below is a rehearsal aid. Checking an item means you believe you can point to the relevant agreement; it does not validate the diagnosis or certify team performance. Copy the checklist into your approved workspace and add the evidence you are permitted to share. Use the experiment brief to make the next action concrete. The material is an AI-assisted editorial proposal developed from a research draft, with fictional examples and practical extensions. It contains no measured improvement claim and no guarantee of a particular outcome.