Steve Lipner walked into the office of the manager of Microsoft’s Windows team “half expecting to get thrown out.” His proposal was to stop Windows development. Every developer would go through security training, then go back into the existing code to hunt for holes.
Windows, a colleague recalled, was “this 9,000-person supertanker.” Business leaders first pushed for a two-day pause. Lipner’s team asked for a month.
In February 2002, by Microsoft’s own account, the whole Windows division stopped. The goal, Lipner said, was “getting all 8,500 rank-and-file developers up to speed on security.” The biggest room the company could use for proprietary work was the Microsoft Briefing Center, which held 950 people. It filled twice a day for five days. “We did the training 10 times,” Lipner said.
Count what that cost: the push that followed lasted two months. Now count what went into the room. In a later article, Lipner said the team had compressed what developers needed into a four-hour course, taught by three people.
The hours that travel
Andy Grove, Intel’s president, had a word for that second count. In High Output Management, published in 1983, he called it leverage: “the measure of the output generated by any given managerial activity.”
A manager’s hour can shape hundreds of other people’s hours, for better or worse.
Grove listed three ways it happens. One manager’s work reaches many people. A brief, well-focused set of words changes how one person works for a long time. Or one person supplies a key piece of knowledge a whole group depends on. His own example of the first was a two-hour talk he gave in Intel’s orientation course to about two hundred new employees. His example of the second was the performance review, a few hours of preparation that can change a subordinate’s work “enormously.”
He did the arithmetic for one-on-ones. Ninety minutes every two weeks, he wrote, “can enhance the quality of your subordinate’s work for two weeks, or for some eighty-plus hours.”
Microsoft’s course fits the first kind. Three instructors gave ten four-hour sessions, and what they taught went back to thousands of desks. Afterward Microsoft built tools, an internal security audit group and, by 2004, a mandatory process called the Security Development Lifecycle.
When the lever pushes the wrong way
“Leverage can also be negative,” Grove wrote. Arrive unprepared as a key participant in a meeting, and you waste everyone’s time in the room. Take over a subordinate’s problem with your superior knowledge, and after enough of it they stop solving problems and start bringing them to you. Put off a decision that others are waiting on, and “no green light is a red light, and work can stop for a whole organization.”
A course has the same edge. Grove’s example was an Intel engineer training salespeople on the product line: done well, they sell better; “if she does it poorly, great and obvious damage is done.”
Leverage also isn’t a guarantee. In July 2003, Microsoft rated a flaw in the Windows component that handles remote procedure calls critical for several versions of Windows, including Windows Server 2003, the system whose code the push had combed. And Grove’s leverage is a way of thinking that he drew from running Intel, not a measured law. There is no meter for it. You estimate.
The file every agent reads
Coding agents now come with their own version of Grove’s orientation talk. Many teams keep a context file, often called AGENTS.md or CLAUDE.md, that the agent reads before each task. Write it once and it shapes every run.
In 2026, researchers at ETH Zurich and LogicStar.ai tested whether those files help. They ran several coding agents on tasks from popular repositories with files written by an AI, and on 138 tasks from 12 less-known Python repositories with the files their own developers had committed.
The agents did what the files said. When a file mentioned the tool uv, agents used it 1.6 times per task on average, against fewer than 0.01 times when it didn’t. But in this study, the files didn’t significantly change how many tasks the agents solved, and they made runs costlier; the authors put the rise at over 20% on average. The repository overviews that guides recommend didn’t help agents reach the right files faster. The authors suggest that human-written files include only what an agent needs and can’t find in the README, such as specific conventions, and that any change be tested before it’s adopted.
That is Grove’s leverage in both directions. Every line reaches every run, the useful ones and the unneeded ones alike.
You can measure your own file. Pick five recent tasks your agent handled. Run them on a copy of the repository with the file and without it, a few times each, since runs vary. Compare whether the tests pass, how many steps it took and what it cost. Then read the lines the runs actually followed.
The vendor call you waited for
Imagine your team of six is waiting for you to pick a payment provider. The two options are close, and you’d like one more call with each vendor. The calls are next week.
Your engineers don’t wait. Two of them build an adapter so the code can take either provider. A third writes test fixtures for both. Nobody calls it waste, because nobody knows yet which half is.
Nine days later you choose the provider you leaned toward on day one. The calls changed nothing. The adapter now wraps a single provider, and one set of fixtures gets deleted.