There's a quiet anxiety in many leadership conversations. Someone hears how another company runs its teams and thinks, "I want to try that." Then immediately: "But isn't that just copying?"

The stigma is misplaced, and the reluctance it creates is genuinely costly.

Most great ideas in business are not invented. They are observed, adapted, and transplanted. Borrowing best practices from other organizations is one of the highest-leverage things a leader can do.

Some examples…

OKRs, the goal-setting framework Google credits with scaling them from 40 people to tens of thousands, weren't invented at Google. Larry Page learned them from John Doerr, who built them from Andy Grove's system at Intel. Grove was drawing on Peter Drucker's Management by Objectives from the 1950s. One idea traveled across decades and industries before becoming the scaffolding of some of the most valuable companies in the world.

In 1979, Steve Jobs visited Xerox PARC and saw the graphical user interface and the mouse. Xerox had invented them. Xerox did nothing with them. Jobs took both, refined them, and built the Macintosh around them. He didn't apologize. He said the quiet part loud: "We have always been shameless about stealing great ideas." The entire Apple design language traces to a German appliance company from the 1960s. Nobody called it theft. They called it taste.

The pattern holds across generations of leaders. Musk borrowed first principles from physics and applied them to battery manufacturing. Jensen Huang built CUDA around what researchers were already doing with NVIDIA's hardware. The idea didn't come from inside the roadmap. It came from watching users closely enough to see what they were trying to build.

Good ideas don't belong to their inventors. They belong to whoever uses them best.

Translation is the skill

Copying a practice without understanding it is not borrowing, it's cosplay. The real discipline is translation. When you see a practice working somewhere else, three questions matter:

  1. Why does this work there? What are the underlying conditions: team size, trust levels, incentive structures, type of work? What problem was this invented to solve?
  2. What is the analogous problem in my organization? Not "can I implement this?" but "what would success look like if I adapted this to my context?"
  3. What would need to be true for this to work here? Sometimes the answer reveals a missing prerequisite. Sometimes it reveals you're closer than you thought.

When you do this work rigorously, you're not copying. You're doing original synthesis.

Satya Nadella's transformation of Microsoft is the highest-stakes proof of this. When he became CEO in 2014, the company was widely written off. Stack ranking had created a culture so toxic that engineers would deliberately sabotage peers. The most talented people were leaving. The stock had been flat for a decade. Microsoft had missed mobile, was losing cloud to Amazon, and was oriented entirely around defending Windows.

Nadella's diagnosis was that Microsoft had a culture problem, not a strategy problem. His solution was to borrow a framework from a Stanford psychology professor. Carol Dweck's research on fixed versus growth mindsets had been popularized in her 2006 book.

The core idea: organizations that believe abilities are fixed avoid challenges, hide failures, and compete destructively. Organizations that believe abilities develop through effort take risks, learn from failure, and collaborate.

Nadella gave the book to his entire senior leadership team and made it the explicit operating model. He cited Dweck by name in interviews, in internal communications, and in his own book. He reframed Microsoft from "know-it-alls" to "learn-it-alls," eliminated stack ranking, and restructured performance reviews around learning rather than relative comparison. Microsoft's market cap went from roughly $300 billion to over $3 trillion in a decade. A company that had genuinely lost its way was rescued not by a new product or strategy, but by a CEO willing to take an idea from a psychology textbook and bet the organization on it.

How to actually do it

The failure mode I've seen repeatedly is the wholesale rollout: leadership announces that the organization is adopting some new practice and then watches it collapse or get quietly ignored after the mandate fades.

The problem isn't the practice. Adoption without enrollment is just imposition.

Start with a small, willing team, one chosen for their ability to conduct rigorous experimentation and credibility with the rest of the organization. They run the experiment for a defined period with explicit hypotheses about success. They share findings, not just outcomes but texture: what was hard, what surprised them, what changed. If it works, you have a proof point and a story.

Stories travel. Mandates don't.

How fast a practice propagates depends on how much translation it requires. Some spread through peer networks once there's a visible success case. Others need a workshop. Structural changes need a phased rollout with active coaching. One counterargument worth taking seriously: some practices only work at a critical mass, and starting small can actually undermine them. When a practice is network-dependent, think carefully about the minimum viable adoption threshold before the benefits materialize.

The framing also matters more than most leaders think. "We've decided to do it this way" creates factions. "We're trying this, here's why, here's what we're learning, here's how you can engage" keeps the experiment open. The organizations that do this well treat experimentation as a shared practice, not a leadership prerogative.

The compounding organization

The organizations I most admire are genuinely curious about how other organizations work. They benchmark obsessively, read broadly, and send people to visit companies in adjacent industries where analogous problems are being solved differently. They treat every conference talk, every published case study, every conversation with a leader from another company as potential raw material.

They've also built the muscle to translate what they find. They don't implement things wholesale. They ask why it works, find the analogous problem, and run the experiment.

Take the good ideas. Try them. Make them yours. That is how organizations compound.