A company decides to become easier to work with. Sales proposes more flexible contracts, Product prioritises a simpler interface, and Support wants authority to resolve common account problems without escalation. Engineering begins work to reduce interruptions to the service.
Each proposal could help a customer. They are not automatically incompatible, but they compete for some of the same time and may imply different promises. A flexible contract could create exceptions the interface cannot support, while an expanded support role could require permissions not included in the technical plan.
The company now needs to turn a broad direction into related decisions. Interpretation is unavoidable because different teams contribute different expertise. The problem is an interpretation that changes a consequential assumption without making that change visible to the people affected.
A useful strategy gives local judgment a common basis. It explains the intended customer outcome, relevant evidence, constraints, and decisions already made. Teams can then propose approaches, test them against that basis, and identify where the original direction needs further work.
Identifying the Question Hidden Inside a Broad Priority
?Easier to work with? could refer to purchasing, setup, routine use, or recovery after a problem. The company should establish which customer group and interaction it wants to improve first, and why that improvement matters.
If the immediate problem is that customers repeatedly contact Support to change account details, a faster sales process addresses a different need. It may remain worthwhile, but its relationship to the current priority should be examined rather than assumed.
The discussion needs evidence about the actual experience. Support cases can show recurring problems, while interviews and workflow observation can explain what customers were trying to accomplish. Technical records may reveal waiting or failure conditions customers cannot describe precisely.
These sources can change the initial diagnosis. A request that looks like an interface problem might be delayed by an unclear approval policy. Conversely, staff may attribute delay to policy when the required information is difficult to find.
Defining the question should therefore focus the investigation without prescribing its answer. The organisation can retain a broad ambition while making a bounded improvement specific enough to assess. Other valuable ideas can be considered as separate commitments instead of being forced under the same label.
Using Examples to Test Whether Teams Mean the Same Thing
The company can examine a representative customer case with the relevant teams. Suppose an administrator needs to transfer responsibility for an account after a colleague leaves. Sales, Product, Support, and Engineering can each explain what their proposed approach would do.
The walkthrough should include the conditions that make the case difficult. Who can verify the new administrator? What happens to existing access? Which agreement or billing record changes, and what does the customer see if one update fails?
Different answers can expose a missing decision rather than poor understanding. Product may assume the customer can make the change directly, while Support expects to verify it first. The teams need to resolve that difference before building or promising the workflow.
The exercise should also examine acceptable boundaries. The organisation might delegate routine changes while retaining independent review for a sensitive case. That is more actionable than a general instruction to empower staff or remove friction.
A numerical target can support this discussion when its definition is clear. A precise number without an agreed event, population, or time period can create apparent clarity while people still measure different things.
The result should be a shared account of what is expected, including unresolved cases. It does not need identical wording in every team’s plan. It needs consistency where one team’s choice affects another’s work or the customer’s outcome.
Preserving Local Expertise Without Making Every Choice Central
A strategy that tried to specify every action would be difficult to maintain and could prevent teams from using knowledge the planning group lacks. Engineering may identify a safer implementation, while Support may know an exception absent from the initial requirements.
The organisation should distinguish those contributions from changes to the intended offer. A team can choose how to implement an agreed permission rule within technical standards. Changing which customers are entitled to an exception may require another decision.
Clear authority gives local interpretation a workable scope. It should identify which choices are delegated, which require consultation, and which go to a sponsor or specialist owner. The boundary should be understandable through actual examples.
The receiving team also needs the reasons behind earlier choices. If the company rejected a direct self-service route because verification was unresolved, engineers should know that context before proposing it again. New evidence may justify reopening the choice, but the earlier rationale should not disappear.
Handoffs should preserve this reasoning in an accessible current record. A presentation alone may leave the relevant explanation dependent on a manager’s memory. An extensive repository without a clear indication of the current decision creates a different access problem.
Interpretation becomes more dependable when staff can find the context and challenge it through an agreed route. That lets the strategy benefit from specialist knowledge rather than treating every question as a failure to understand the message.
Checking That Different Contributions Form One Workflow
The teams should compare their proposed work as a connected service. Support’s revised authority may depend on identity information Engineering does not yet provide. The new interface may assume a billing change Finance cannot make through the existing system.
Coordination requires agreements about those dependencies. Each should specify what capability or information is needed, who can supply it, and how readiness will be confirmed. A shared statement of intent does not establish that capacity is available.
The work may need a sequence. The company could clarify the approval rule, expose a supported account operation, trial it with trained staff, and then consider customer self-service. A different sequence may be appropriate, but its assumptions should be explicit.
The programme should also examine what each measure would encourage. Faster Support handling could be helpful or could shift unresolved work to customers. More contract exceptions could win deals while increasing operating costs. Teams need evidence about the complete result rather than assume local improvement always combines into a better service.
Atlassian’s goals, signals, and measures guidance offers a way to discuss the connection between an intended outcome and the evidence used to assess it. The company should use that conversation to identify which measures explain its own workflow, rather than adopt a generic set because it is easy to report.
A review of the combined plan can reveal whether the apparent difference was a genuine conflict or a complementary contribution. The purpose is to make the relationship visible before commitments turn the disagreement into rework.
Making Exceptions and New Findings Explicit
A customer may present a case outside the agreed scope. Sales might judge it commercially important, while Support believes the standard route cannot handle it. The company needs a way to consider the exception without silently changing the whole service.
The proposal should identify the customer benefit, additional work, operating exposure, and effect on existing commitments. An authorised decision can then permit a bounded exception, revise the standard offer, or decline the request.
A repeated exception can provide strategic evidence. If several suitable customers need the same capability, the original scope may be too narrow. If every request is different and expensive, the company may be moving towards a service model it has not deliberately chosen.
Strategic decisions should review that pattern alongside the stated direction. Neither automatic compliance with the original wording nor automatic acceptance of every local opportunity provides a sufficient response.
The record should show what changed and who is affected. An approved exception to support policy may require new permissions, customer communication, and a financial check. Calling it a local interpretation does not remove those dependencies.
Some ambiguity can remain appropriate while an opportunity is being investigated. The organisation should state which question is open, who will investigate it, and what the next commitment will require. That is different from presenting an unresolved choice as a settled instruction.
Reviewing Understanding Through Results
The company should return to the customer case after the changes reach use. Can an administrator complete the account transfer with fewer contacts? Are access and billing records correct? Can staff resolve the exceptions without recreating an informal process?
The findings may show incomplete delivery, a mistaken assumption about the problem, or a useful improvement. A lack of progress should not automatically be attributed to teams interpreting the strategy badly. The original direction may have been too broad or the selected intervention may not address the principal delay.
Feedback should reach the people who can revise those choices. The report needs to explain the observation and its implications, not merely present another status colour. A revised decision should then reach the plans and procedures affected.
The organisation can also review where understanding diverged. Did teams use different definitions? Was an important condition inaccessible? Was a decision changed without notice? These findings suggest specific improvements to the next planning or handoff process.
For this company, shared understanding is visible in related decisions that produce a workable customer experience. Interpretation remains part of the work, supplying expertise and adaptation. It becomes a problem when people cannot see where their assumptions differ or obtain an answer to the choice those differences create.
