A team can hit its targets, close tickets, finish planned work, and report steady progress while the company itself struggles to deliver anything meaningful. From the outside, everyone appears productive. Inside the organization, however, projects are waiting on dependencies, decisions are stuck between departments, and employees are spending more time coordinating work than moving it forward.

If you have ever heard a colleague say, “We can't deliver because we're waiting on another team,” it is worth paying attention to how often that complaint appears. An occasional dependency is normal in software development. When the same explanation becomes a recurring excuse across the organization, the problem may not be the teams themselves. It may be the way their performance is measured.

The distinction matters because a company can make every individual team more productive without making the company itself more effective. When each group is rewarded for maximizing its own output, helping another group can feel like falling behind. People protect their schedules, prioritize their own targets, and delay work that does not contribute directly to their performance reviews.

The result is a workplace full of busy people who are doing exactly what the system encourages, yet struggling to achieve the outcome the business actually needs. Fixing that problem requires looking beyond individual productivity and examining how work moves across the entire organization.

Imagine that three teams are working on a new product feature. One team develops the customer-facing interface, another builds the supporting service, and a third manages the data integration. Each group has its own backlog, deadlines, and delivery targets.

The interface team finishes its work ahead of schedule. The service team meets its sprint commitments. The data team closes the planned tasks for the month. Every team can point to a successful performance report.

But the feature still cannot launch, because the service depends on a data integration that has not been completed. The data team, meanwhile, is committed to another project with its own deadline. Nobody is necessarily underperforming. Each group is simply prioritizing the work it has been told matters most.

This is the difference between optimizing a team and optimizing the whole organization. Local optimization improves the performance of an individual part. System-wide optimization improves the flow of work needed to achieve the final result.

In software delivery, the distinction is especially important because meaningful outcomes often depend on several teams completing connected pieces of work in the right sequence. Finishing one component does not automatically create customer value if another essential component remains unfinished.

A team can therefore improve its internal numbers while contributing little to the company's overall delivery speed. In some cases, it can even create additional work for other teams by producing components that are not ready to integrate, documenting decisions poorly, or prioritizing local deadlines over shared requirements.

The lesson is not that individual teams should stop caring about their own performance. Teams still need clear responsibilities and reasonable expectations. The problem appears when local targets become more important than the outcome those targets were originally meant to support.

Tip: When reviewing a delayed project, examine the complete path from the initial request to the finished customer outcome. Identify where work is waiting, which dependencies remain unresolved, and whether each team's priorities support the same delivery goal. A collection of successful team reports is not enough if the final product remains unfinished.

Performance measures are not neutral. They influence how people allocate their time, which tasks receive attention, and what employees believe their managers value.

Suppose a team is evaluated on the number of completed tasks or its delivery throughput. A neighboring team encounters a difficult technical dependency and asks for help. One of your engineers understands the problem and could resolve it in a few hours.

Helping would probably benefit the company. It might prevent a project delay, reduce duplicated effort, or allow several other engineers to continue working. Yet those hours may not contribute to the engineer's own team's targets. If the team is already under pressure to meet its commitments, the manager may reasonably worry that lending someone out will hurt the team's performance rating.

Now imagine the same situation happening every week. Each request for help creates a small conflict between what is best for the organization and what is rewarded locally. Employees learn to protect their own commitments, even when they understand that the wider organization would benefit from cooperation.

This is a practical example of Goodhart's law: when a measure becomes a target, it can stop being a reliable measure of the result that actually matters. A metric such as completed tasks may initially help leaders understand activity. But once rewards, promotions, and performance judgments depend heavily on that number, employees have stronger reasons to optimize the number itself.

The measure becomes particularly misleading when it excludes the work required to make other teams successful. Unblocking a colleague, reviewing a shared architectural decision, explaining a business requirement, or helping resolve an integration problem may have substantial value without producing an obvious increase in the helper's own output.

That creates a dangerous incentive. Employees are not necessarily choosing to be uncooperative; they are responding to the consequences the organization has attached to their choices.

Telling teams to collaborate will have limited impact if the performance system continues to penalize them for doing so. The stated expectation and the actual reward are sending conflicting messages, and employees will eventually pay more attention to the reward.

Tip: Audit the measures used in performance reviews and delivery dashboards. Ask whether employees can help another team succeed without appearing less productive themselves. If collaboration consistently makes a team's numbers look worse, adjust the evaluation process rather than relying on reminders to work together.

Every organization has people who naturally work across boundaries. They understand why a business request matters, know which technical teams are affected, and can translate a problem from one group's language into another's. They may not hold the most senior titles, but they often understand how the pieces fit together.

These employees provide more than informal assistance. They help preserve the context that allows a company to turn business requirements into a coherent product.

Consider a customer request that appears simple at first: make account setup faster. The actual solution may involve changes to the user interface, identity verification, backend services, security controls, customer support procedures, and data reporting. Each team understands its own responsibilities, but someone must also understand how those responsibilities combine to create the customer experience.

The person who connects the teams can identify dependencies before they become expensive delays. They can spot conflicting assumptions, clarify which requirements are essential, and make sure that one group's technical decision does not create an unexpected problem elsewhere.

This work is difficult to capture through conventional output measures. It may involve a short conversation that prevents weeks of rework, a technical review that exposes an overlooked dependency, or a discussion that helps several teams agree on the same definition of success.

Because these contributions are often informal, they can disappear from delivery reports. The person who prevents a problem may have no completed task to show for it, while the consequences of not providing that help might never become visible.

When the organization consistently rewards isolated output, these employees face two risks. They may stop investing time in cross-team work because it threatens their own performance assessments, or they may continue doing it until the extra responsibility becomes exhausting and unsustainable.

Either way, the organization loses an important source of coordination and shared understanding.

There is also a business consequence. When the people who understand customer needs and technical dependencies lose the time to connect the work, teams may deliver components that function individually but fail to produce a consistent overall experience.

Tip: Identify the people who repeatedly resolve cross-team dependencies, clarify shared requirements, and prevent duplicated work. Make those contributions part of their recognized responsibilities, and ensure they have enough time and authority to perform them. Do not wait until a key connector leaves or burns out to discover how much the organization depended on them.

Keeping every person fully occupied can look like responsible resource management. If everyone has a full schedule, every team appears to be making good use of its available capacity. Empty calendar space may look wasteful, particularly when the organization has more requests than people available to complete them.

But a system operating at full utilization has very little room to respond when conditions change.

Software development is rarely a perfectly predictable sequence of independent tasks. Requirements change, defects appear, dependencies take longer than expected, and teams discover problems that were not visible during planning. When everyone is already committed to planned work, even a small disruption can create a queue.

A team that needs an engineer's help may have to wait until the next sprint. A technical question may remain unresolved because the relevant specialist has no available time. A promising improvement may be postponed because nobody can investigate it without missing an existing commitment.

This is why deliberately preserving some capacity, often called slack, can improve delivery rather than reduce it. Slack gives an organization room to respond, experiment, and handle the work that cannot be scheduled neatly in advance.

The important distinction is between unused capacity that has no clear purpose and available capacity that allows the organization to adapt. The latter makes it possible to respond to urgent dependencies, investigate uncertainty, support other teams, and prevent small problems from becoming major delays.

This does not mean that every team should maintain a fixed percentage of idle time regardless of its work. The appropriate amount depends on the level of uncertainty, the number of dependencies, the urgency of the work, and the cost of delays. A team performing predictable, independent work may need a different capacity model from one responsible for shared infrastructure or critical integrations.

The principle is to avoid planning every available hour as though the future will unfold exactly as expected. A schedule with no room for unexpected work may look efficient on paper while making the overall delivery system fragile.

Tip: Review how much time teams can realistically devote to unplanned dependencies, technical support, and cross-team problem-solving. Leave room for this work in capacity planning, and examine recurring interruptions before adding more commitments. If every unexpected request automatically causes a missed target, the plan may be too tightly packed to support reliable delivery.

Organizations often say they value collaboration, shared ownership, and teamwork. But employees learn what those values mean by watching which behaviors receive recognition and which behaviors create professional consequences.

If a manager praises a team for meeting its own targets but overlooks the people who helped another team recover from a delay, the message is clear even if it was never stated explicitly. The measured result matters; the unmeasured contribution does not.

The reverse is also true. When a leader openly recognizes someone who temporarily set aside planned work to unblock a critical dependency, the organization receives a visible example of what good collaboration looks like.

That recognition matters because cross-team work can be difficult to demonstrate. The engineer who resolved a shared technical problem may have prevented a delay rather than completed a clearly defined deliverable. The product specialist who clarified an ambiguous requirement may have saved several teams from building the wrong thing. These contributions deserve to be discussed in the same concrete terms as other meaningful work.

Recognition should not be limited to praise during meetings. It can influence how managers discuss performance, assign responsibilities, plan workloads, and decide who is ready for broader opportunities. When employees see that collaborative behavior is considered in these decisions, they have stronger reasons to make it part of their normal work.

Leaders must also avoid turning collaboration into another superficial metric. Counting the number of meetings attended, support requests answered, or messages sent could simply create a new target for employees to optimize. The goal is not to manufacture activity. It is to recognize contributions that demonstrably improve shared outcomes.

The most useful recognition connects the action to its impact. Instead of saying that someone was helpful, explain how their intervention resolved a dependency, prevented duplicated work, clarified a requirement, or allowed a customer-facing feature to move forward.

Tip: During project reviews and performance conversations, include specific examples of cross-team contributions and the outcomes they enabled. Recognize the people who improve delivery across boundaries, not just those whose work is easiest to count. Make sure the praise is supported by real impact rather than the appearance of being busy or cooperative.

In an office, some coordination happens naturally. An engineer overhears a conversation, a product manager asks a quick question in the hallway, or two people discover that their teams are solving related problems while getting coffee. These informal interactions can reveal dependencies before they become formal project blockers.

Remote and distributed teams cannot rely on the same incidental contact. When people work across time zones or communicate primarily through scheduled meetings and written updates, opportunities for spontaneous clarification may become less frequent.

That does not mean remote work automatically causes poor collaboration. It means organizations need to design their communication practices so that important connections do not depend on physical proximity.

Without deliberate coordination, teams can become isolated even when they use the same tools and participate in the same planning processes. One team may make an architectural decision without knowing that another group is planning a related change. A requirement may be documented in one channel but remain invisible to the people who need it. A small question can sit unanswered for hours because nobody knows who owns the decision.

The solution is not to fill every calendar with cross-team meetings. Excessive coordination can create another burden, taking time away from the work teams need to complete. The objective is to make relevant information and expertise accessible when they are needed.

Clear ownership, shared technical documentation, visible dependency tracking, agreed communication channels, and predictable opportunities for cross-team discussion can all help. Teams should also know where to go when a dependency becomes urgent and how decisions that affect several groups will be made.

Remote organizations may need to be especially intentional about protecting the time of people who connect teams. These individuals often serve as informal information networks, helping important context travel beyond formal reporting lines. If their schedules are completely filled with planned work, that connective function becomes harder to sustain.

Tip: Establish lightweight ways for teams to discover shared dependencies and reach the right people quickly. Use documentation for decisions that need to persist, direct conversations for complex or ambiguous problems, and recurring coordination sessions only where they provide clear value. Design the system around the work that needs to move, not around the number of meetings people attend.

Team-level measures can still be useful. They help identify workload trends, understand delivery patterns, and reveal where a team may need support. The mistake is treating any single measure as a complete picture of organizational performance.

A better approach is to combine local measures with indicators that show whether work is moving successfully through the whole system. For example, leaders can examine how long a request takes from the moment work begins until it is delivered, how long tasks wait between teams, how frequently dependencies delay delivery, and how much rework occurs when components are brought together.

These measures help distinguish between a team that is struggling to complete its own work and a team that is ready to proceed but waiting for a decision or dependency elsewhere.

It is also important to interpret metrics in context. A long delivery time may result from technical complexity, changing requirements, approval delays, or work that was repeatedly reprioritized. A team with lower task throughput may be handling difficult maintenance work or supporting several other teams. Numbers can reveal where to investigate, but they rarely explain the entire situation on their own.

Leaders should also pay attention to whether completed work produces the intended outcome. Delivering a feature on schedule does not guarantee that customers will use it, that it solves their problem, or that it supports the business objective behind the request.

The point is to connect measurement to the result the organization actually wants. If the goal is reliable product delivery, the performance system should help explain how quickly useful work reaches customers, where it gets stuck, and what prevents teams from completing it.

No metric can capture every valuable contribution. Good measurement requires judgment, conversation, and a willingness to examine the behaviors the numbers encourage.

Tip: Pair team-level delivery data with end-to-end measures such as cycle time, waiting time between teams, dependency-related delays, rework, and customer outcomes. Use the results to identify bottlenecks and improve the system, rather than ranking teams without considering the type of work they handle or the dependencies they face.

When teams repeatedly blame one another for delays, it is tempting to look for the group that is not cooperating or the manager who is failing to coordinate priorities. Sometimes those explanations are accurate. But before treating the problem as a matter of individual performance, examine the conditions in which the teams are operating.

Are they rewarded for completing their own work even when another team's progress depends on them? Is every person's schedule so full that helping creates an immediate penalty? Are the employees who understand cross-team requirements recognized for their contribution, or are they expected to handle that work in addition to everything else? Can teams make shared decisions, or must every dependency pass through a long chain of approvals?

These questions reveal whether collaboration is genuinely supported by the organization or merely expected from employees without giving them the time, incentives, or authority to deliver it.

The distinction is important because people generally respond to the environment in which they work. If an organization consistently rewards local output, employees will naturally prioritize it. If it values only visible activity, the less measurable work that keeps projects moving will struggle to survive. And if every team is expected to operate at full capacity, the organization will have little room to respond when teams need one another.

A company does not become effective simply because every department has a good performance report. It becomes effective when the departments can combine their work into outcomes that matter.

The next time a project stalls because one team is waiting on another, look beyond the immediate delay. Find out what is blocking progress, whether the teams share the same priority, and what the performance system encourages each group to do. Then make the necessary changes to capacity planning, recognition, coordination, or measurement.

Tip: Treat repeated cross-team delays as a signal to investigate how the organization operates, not as automatic evidence that one team is underperforming. Start with one delayed project, map its dependencies, identify where work waits, and agree on one change that improves the flow of work across the teams involved.

The goal is not to keep everyone occupied every minute of the day. It is to make sure the right work moves forward, the people doing it can help one another, and the organization can turn individual effort into results.

When a company rewards only what each team produces independently, it should not be surprised when collaboration becomes difficult to sustain. The strongest delivery system is not the one in which every team is constantly busy. It is the one in which teams can work together to finish what matters.

Hit reply and tell me: what is one metric your teams are measured on that quietly discourages them from helping each other? I read every answer.

One more from today's sponsor, which helps keep Tiny Big Spark free:

Keep going, one small spark at a time.

Erwin