Asher's Blog

Many companies do not fail because nobody knows what to do. They fail because the people who know what to do cannot move together.

Product understands what must be built, engineering knows what is technically possible, marketing knows what must be communicated, sales knows what customers are asking for, finance knows what the company can afford and customer success knows where the product is disappointing people. Each team may be intelligent, hardworking and successful by its own measures, while the company as a whole continues to miss the outcome.

This is why many problems that appear to be product, sales or execution problems are actually coordination problems. The knowledge exists, and the people exist, but responsibility is divided in a way that allows everybody to complete their work without ensuring that the result is achieved.

Silos make local success look like company success

People naturally pay attention to the work for which they will be evaluated. If a marketing team is measured only by leads, it can celebrate a large number of enquiries that sales considers unqualified. If engineering is measured only by features shipped, it can release work that customers do not adopt. If sales is measured only by contracts signed, it can bring in customers the product cannot serve profitably.

Each team has evidence that it performed, yet the company inherits the gap between their definitions of success.

This is what makes silos dangerous. They do not always look like conflict. The teams may be polite, attend the same meetings and submit impressive reports. The separation becomes visible only when an important outcome depends on several teams and nobody owns the spaces between them.

An employee may say, correctly, that their own task was completed. The design was delivered, the campaign was launched or the integration was coded. However, if another team could not complete its work because the output was late, incomplete or unsuitable, the business result still suffered. Task completion cannot become a defence against shared failure.

Your score should include what your work made possible

One of the models I have developed is based on a simple principle: if your work affects another team’s deliverable, your performance score should reflect whether that dependency was successfully delivered.

This changes behaviour because it removes the ability to optimise for a local score while creating a problem elsewhere. If product needs information from sales, sales cannot claim full success while withholding it. If marketing depends on product assets, the product team’s work is not complete merely because the feature exists. If engineering requires a timely decision from leadership, leadership must accept that delay as part of its own performance rather than treating the resulting engineering delay as somebody else’s failure.

The purpose is not to make everybody responsible for everything. Diffuse responsibility can create even more confusion. The purpose is to make interdependence visible and attach accountability to the handoff.

For every major objective, teams should know which other people depend on them, what must be delivered, in what form and by what date. They should also understand what company outcome will be weakened if the dependency fails. Once that relationship is explicit, leaders can evaluate contribution more honestly.

Do not own tasks; own outcomes

I tell my leaders that I do not want them merely to own KPIs or tasks. I want them to own objectives and results. The distinction can feel uncomfortable because tasks are easier to control and easier to report.

A person can prove that ten meetings were held, five campaigns were launched and several product requirements were written. An outcome asks a harder question: what changed because of the work?

This does not make KPIs useless. Metrics help us understand performance, and activities often provide leading indicators of progress. The problem begins when the metric becomes detached from the outcome it was supposed to serve. A team may increase the number efficiently while making no meaningful contribution to the objective.

Owning an outcome requires judgment. If the original plan is not working, the owner cannot continue executing it and later explain that all assigned tasks were completed. The person must identify the obstacle, ask for help, revise the approach and continue searching for a path to the result. This is a significant challenge for leaders who have been trained to equate obedience with performance.

The company needs people who solve problems, not people who become extremely organised around a failing plan.

Coordination requires a common definition of reality

Teams cannot move together if they are working from different facts. Sales may believe a product is ready because it has seen a demonstration, while engineering knows that the system has not been tested at the volume being promised. Finance may believe a campaign is profitable because it sees booked revenue, while operations knows that the cost of serving those customers is still rising.

Good coordination begins with shared visibility. Leaders need access to the same critical measures, a common understanding of the current objective and an honest view of the risks. Meetings should not merely provide opportunities for each department to present its achievements. They should expose contradictions between teams before those contradictions become customer problems.

This is one reason I prefer leadership discussions in which problems are not isolated inside a department. If an issue affects the company, the leadership team should understand it well enough to contribute. The product leader may see an operational implication, the finance leader may identify an unsustainable cost, and the customer-success leader may explain how the decision will be experienced by users.

Collective visibility does not remove individual ownership. One person should still be responsible for driving the resolution, but that person should not have to discover and manage every interdependency in private.

Handoffs are where strategy becomes fragile

A company’s organisation chart shows who reports to whom, but it rarely shows where work is most likely to fail. Failure often occurs at handoffs: when a lead becomes a sales opportunity, when a signed customer enters onboarding, when a product decision becomes an engineering requirement or when a completed feature becomes a market launch.

At each handoff, information can be lost, assumptions can differ and urgency can change. The team delivering the work may believe it has finished, while the receiving team discovers that the output cannot yet be used.

The solution is not simply more meetings. Excessive coordination can consume the time required for execution. What teams need is a clear contract around each important dependency. What exactly is being handed over? What makes it complete? Who confirms acceptance? What should happen when it is late or inadequate? Which decision-maker can resolve disagreement quickly?

A strong handoff has an owner on both sides. The delivering team remains responsible for usefulness, not merely delivery, and the receiving team is responsible for raising concerns before the deadline rather than silently allowing failure to accumulate.

Coordination is a leadership responsibility

When teams repeatedly conflict, leaders sometimes tell them to collaborate better as though collaboration were a personality trait. In reality, coordination is partly a design problem.

If incentives reward departments for competing outcomes, goodwill will eventually fail. If nobody has authority to resolve a cross-functional disagreement, the problem will be escalated endlessly. If priorities change without being communicated consistently, teams will make rational decisions using outdated information.

Leadership must create the conditions for alignment. This includes choosing a small number of company objectives, showing how team objectives contribute to them, identifying dependencies, resolving trade-offs and ensuring that performance systems reward shared outcomes.

It also requires leaders to model the behaviour they expect. A leader who protects departmental information, takes credit privately or blames other teams publicly teaches the organisation that self-protection is safer than cooperation. A leader who shares context, asks for help early and accepts responsibility for a failed handoff creates a different norm.

Culture is formed through these repeated decisions. People learn whether the organisation values the appearance of individual competence or the reality of collective progress.

The customer sees one company

Customers do not experience your organisational chart. They do not care whether a delay belongs to product, finance, engineering or a third-party provider. They bought from one company, and they expect that company to coordinate itself.

When an employee tells a customer, “That belongs to another department,” the sentence may accurately describe the internal structure but does nothing to resolve the customer’s problem. Somebody must remain responsible for the outcome while the organisation coordinates internally.

This is particularly important in trust businesses. A payroll customer should not have to manage the relationship between the software team, payments partner, compliance team and customer-support unit. The value of the company is partly its ability to absorb that complexity and present the customer with a coherent service.

The same principle applies to employees inside the business. People should not need personal relationships and repeated escalation to obtain the contribution another team has already committed to provide. A mature organisation makes coordination part of the system rather than depending on individuals who are unusually persuasive.

Measure shared outcomes without creating confusion

Cross-functional accountability must be designed carefully. If everybody’s score depends vaguely on everybody else, employees may feel powerless and performance discussions may become political. The dependency should therefore be specific and limited to work the person can meaningfully influence.

A useful model includes a primary owner for the objective, contributing owners for defined dependencies and a shared measure of the final outcome. Each person knows what they control, what they influence and when they must escalate a blocker.

For example, an objective to activate a certain number of payroll customers may require marketing to generate suitable demand, sales to qualify and close it, onboarding to complete implementation, product to remove recurring obstacles and customer success to ensure early usage. These teams should retain their functional measures, but none should describe success in a way that ignores activation.

The review should examine both the result and the quality of coordination. Did people share information early? Were dependencies honoured? Were obstacles escalated with enough time to respond? Did a team protect its metric at the expense of the company objective?

This makes performance evaluation more demanding, but also more truthful.

Progress belongs to the system

As companies grow, individual brilliance becomes less sufficient. A founder can coordinate a small team through constant personal involvement, but that approach eventually turns the founder into the connection between every department. The company must learn to move without every dependency returning to one person.

That requires clear objectives, shared information, explicit handoffs and leaders who understand that their work includes enabling other people’s success. It requires replacing the language of “I completed my part” with the question “Did the outcome happen, and what must I do next if it did not?”

Most coordination problems will not be solved by asking people to work harder. They are solved by aligning incentives, clarifying ownership and making the spaces between teams visible.

The company wins only when the result is achieved. A department cannot be truly successful inside a business that is failing, and a leader cannot claim excellence while their completed work prevents another team from delivering. The point of coordination is not to make everybody busy together. It is to make intelligence, effort and responsibility converge on the same outcome.