Which Way Is Downhill?
A better theory of cross-functional work
The Gradient
The operations team was in disarray. A handful of customer orders were getting corrupted every day. Some were fulfilled twice, others not at all, and customer service was feeling it.
The Vice President of Engineering convened his team to find a fix. After a week of investigation, they traced the corruption to an upstream system owned by the shop team. The proposed solution was to detect and repair the errors as they happened. Then the estimate came back: three months of engineering work.
The sheer level of effort and risk of this plan led an engineering manager to ask a simple question. If the problem was upstream, why not ask the shop team to fix it at the source?
The VP didn’t hesitate. “I didn’t ask because they never do anything we want.”
The engineering manager paused. “Have you ever asked them what they want?”
The room went quiet. People looked around, unsure how to react. The VP seemed genuinely puzzled. After a long moment, it was clear there no answer was forthcoming.
“Pause the project,” the engineering manager said. “Give me a week.”
He spent the next day talking with people on the shop team to understand their goals. It didn’t take long to find a lever: fixing the fulfillment issue would help them hit one of their own OKRs. He took the proposal to their leader, framed in their language.
The shop team resolved the problem in three days.
Three days instead of three months.
What the engineering manager did was simple, at least conceptually. They asked what the other team was trying to accomplish, then positioned their request so it traveled in the same direction.
Think of every team as sitting on a slope defined by their goals, metrics, and incentives. Requests that align with that slope travel downhill: easy to say yes to because they help the team get where they’re already going. Requests that cut against the slope require the other team to push uphill: spending effort on something that doesn’t advance their goals, or actively competes with them.
The VP’s three-month fix wasn’t avoiding the slope. It was pushing straight uphill and everyone could see it. The engineering manager’s move was to read the slope and find the path where the request traveled downhill. Same problem, wildly different cost.
The Theory of Mind You Already Have
Every team already has a theory of mind about the other teams around them.
It may not be written down and it may never have been examined. However, it must exist, because without a theory of why other people behave the way they do, coordinated action would be impossible.
“They never do what we want” is a theory of mind. It’s also a dead end. It models the other team as difficult, selfish, and adversarial. It explains their behavior through character. Once that story takes hold, collaboration failures become self-fulfilling: don’t bother asking, just work around them.
The gradient lens is a more useful theory. It’s the same behavior with a different explanation. They’re refusing because the request is uphill for them. It’s a more accurate interpretation that opens up moves that blame forecloses.
When you see the system compelling behavior, you stop directing anger at the humans inside it. Not because anger is ungenerous, but because it’s useless. Where do you go from “they’re difficult”? You work around them, escalate, or give up. The adversarial frame forecloses every move except force. “The system makes this uphill for them” opens a question: is there a path that’s downhill?
People behave rationally within their systems. When their behavior looks irrational, you don’t understand the system yet.
This is where compassion and effectiveness turn out to be the same thing.
The Progression
Once you see gradients, new moves become available that offer progressively more leverage:
Navigate: Position your requests downhill. Understand what the other team is optimizing for and frame your ask so it travels in the same direction. This is what the engineering manager did. Same request, different framing, three days instead of three months.
Design: Identify initiatives that naturally align teams. Instead of clever positioning on each request, design work so cooperation is the path of least resistance. When the gradients point the same direction, coordination becomes straightforward.
Reshape: Recognize when the incentive gradient, yours or theirs, is driving the wrong behavior. Then do something about it. This is the most difficult move because it requires admitting that the system you’re part of might be the problem. It’s also the highest leverage because you’re no longer navigating the slope; you’re reshaping it.
The diagnostic question at every level is the same: before you design an intervention, ask which way is downhill for the people you need to move. This is a bedrock requirement for understanding the system well enough to choose actions likely to succeed.
A Slingshot to Heaven
If this is so straightforward, why don’t more people do it?
The VP wasn’t trying to avoid the slope. Three months of engineering effort was evidence they were pushing a boulder up the Matterhorn, but that felt like the responsible move. It was a plan fully within their control. It didn’t require depending on a team that “never does anything we want.”
The engineering manager’s move looked riskier: pause everything, give me a week, let me go talk to people. One path looked like engineering rigor. The other looked like a long shot.
This brings us to the deeper problem: complex systems are counterintuitive. People reach for simple, intuitive fixes because they’re easy to understand and create the immediate sensation of forward movement, but these fixes are almost always fragile or counterproductive.
Donella Meadows spent her career studying where interventions actually work. Her insight was that there’s a hierarchy of leverage and most people never look past the lower rungs.
At the bottom are parameters: the numbers we adjust. Headcount, budgets, targets, OKRs. Easy to change, rarely transformative.
Above those are feedback loops: what gets rewarded and punished. These shape behavior over time regardless of what anyone intends. A team that gets celebrated for shipping features will ship more features, whether or not those features solve problems.
Higher still are goals: the why underneath—what the team believes they exist to accomplish. Not the metrics that proxy for success, but the underlying outcome the system is trying to produce. The engineering manager operated here. He didn’t change what the shop team was rewarded for. He understood what they believed they existed to accomplish and aligned their request with it.
At the top are paradigms: the patterns of thought that shape what goals seem legitimate, what gets measured, what questions are even askable. The paradigm underneath “they never do anything we want” might be something like: cross-functional work is zero-sum, or other teams’ motivations are unknowable, so don’t bother trying. These assumptions are so deep they become the air you breathe.
Most organizations spend most of their energy at the parameter level. Not because leaders are unsophisticated, but because parameters are visible. You can point at them, measure them, take credit for changing them. The higher levels require understanding dynamics that play out over longer time horizons and across organizational boundaries.
Deeper, system-level fixes feel riskier even though they’re the interventions that drive stable, significant improvement. They provoke resistance and often worsen symptoms short-term before things improve. Much like pulling a slingshot backward, you have to briefly move farther from the target to generate the force that reaches it.
The Independence Bargain
The structures that make teams efficient day-to-day also cause cross-functional capability to atrophy.
Small, autonomous teams have become a bedrock organizational principle. Amazon’s two-pizza teams, Airbnb’s EPD teams, and similar structures integrate functions into compact, end-to-end units, curtailing alignment problems and enabling rapid iteration. Communication overhead scales with the square of team size. Small teams are a direct response to this reality.
These structures work precisely because they minimize the need for cross-team coordination. Minimizing a need, however, is not the same as eliminating it. Teams that rarely need to coordinate risk losing the ability to do so effectively when it matters.
By the time the operations team faced their fulfillment crisis, autonomous operation had become so habitual that no one had practice in understanding how another team saw the world. “They never do anything we want” was less a fact about the shop team and more a foreseeable outcome of an organization optimized for independence.
Behnam Tabrizi’s research found that 75% of cross-functional teams are dysfunctional, driven by systemic organizational problems rather than problems internal to the teams.
When facing cross-functional problems, people reach for the tools at hand like steering committees, RACI matrices, and weekly syncs. These tools share a common assumption: coordination is a compliance problem to be managed through structure. They fail because they treat alignment as a process problem while ignoring the underlying issue: teams don’t have a model of each other’s reality.
I Want to Break Free
If this pattern is both costly and well-known, why does it persist?
The VP’s “they never do anything we want” wasn’t learned from careful empirical study. It was the residue of a few failed interactions that felt explanatory enough to stop asking questions. Once that story hardens, it stops being a hypothesis and starts being doctrine, and doctrine changes behavior. People stop learning because certain questions no longer seem reasonable to ask.
This is why the engineering manager’s move was disorienting. Not because it was actually risky; three days of talking to people is cheap. It was disorienting because it broke the frame. If you’ve accepted that cross-functional work is a battle of wills, “go ask what they want” isn’t just unusual; it’s folly.
The irony is that, in retrospect, the “safe” path was objectively far riskier. Three months of engineering work meant more resources, more complexity, and more ways to fail. This approach also leaves the underlying dynamic intact to produce the next crisis. It felt safe because it was familiar.
The scarcity trap isn’t really about time or resources. Higher-level interventions like designing around incentives feel risky because they are never tried. They are never tried because they feel risky. It’s about the feeling of risk being uncalibrated from actual risk, and the miscalibration becomes self-reinforcing.
Organizations caught in this loop can’t think their way out. The only way to recalibrate is to act: to generate evidence that the “risky” path is actually more reliable than the familiar one. The engineering manager didn’t argue that understanding the shop team’s incentives would work. He asked for a week and demonstrated it.
The only way to break a self-reinforcing story is to stop talking and run the experiment.
Shaping the Gradient
Everything so far has been about reading existing gradients. Understanding what other teams are optimizing for and positioning requests accordingly is a skill anyone can practice, regardless of their level.
Senior leaders have a unique opportunity and responsibility because they are empowered to reshape incentive gradients rather than just navigating them. Every goal a leader sets, every metric they choose, and every behavior they reward or punish shapes the slope that everyone navigates. They determine which requests will travel downhill by default and which will require people to push uphill.
The VP in our story wasn’t the one who created the misaligned incentives between teams, but someone was responsible. Someone decided what each team would be measured on, and either didn’t consider or didn’t prioritize how those metrics would interact at the boundaries. The three-month workaround and the three-day fix were both downstream consequences of that original design choice.
The highest-leverage work available to leadership is designing systems where good outcomes are the path of least resistance rather than requiring heroic effort or clever positioning every time.
The question isn’t whether you’re shaping gradients. If you’re a leader, you already are. The question is whether you’re doing it intentionally.
The Trade
Autonomous teams are necessary because coordination overhead is real. You cannot run a company at scale without them.
But cross-functional capability requires teams to carry models of each other’s reality, to invest attention in things that aren’t their core job. That’s inherently less autonomous. The moment you ask teams to understand each other’s incentive gradients, you’re asking them to do something that autonomous operation trained them not to do.
These two things are in genuine tension. There is no organizational design that resolves it.
The only thing you can do with an unresolvable tension is manage it.
Someone has to remember the other teams are real. Not structurally; psychologically. Teams stop carrying models of each other’s incentives because they don’t need them most of the time. When the need arises, they reach for the adversarial frame because it’s all they have.
Cross-functional work has to happen often enough to stay fresh. Capability decays without use. When the rare crisis arrives, everyone is rusty and, under pressure, interprets that rust as evidence of bad intent.
Someone must own the boundary, not just the team. A human, not a committee. Cross-functional problems die because they fall between charters. When no one owns the seams, everyone is locally rational and globally stuck.
Leaders must treat misalignment as a design flaw, not a people flaw. If misalignment gets blamed on personalities, nothing upstream changes. If it’s treated as signal, leaders get permission to reshape the system.
Organizations don’t fail at cross-functional work because they lack the right structure. They fail because they forget that autonomy is a trade, not a free lunch.
Autonomy buys speed, focus, and accountability. What it sells off is shared understanding. Incentive gradients don’t disappear. They just become invisible until a crisis forces teams to collide.
The work, then, isn’t to eliminate the tension. It’s to remember it exists. To notice when teams have stopped carrying models of each other’s reality. To treat misalignment as a signal, not stubbornness. To recognize that coordination, like any capability, decays without use.
The gradients are always there. Someone is always walking downhill.
The only real question is whether the system is designed so they’re all walking in roughly the same direction, or whether alignment depends on the rare appearance of someone willing to stop, look around, and ask what the terrain actually looks like.