It’s rare to find a short, well written paper than nails a subject popular books get wrong. If you agree, and care about breakthroughs and managing innovation, especially on software projects, this is the paper for you.

It’s called Managing for breakthroughs in productivity, by Allan L. Scherr (PDF).

The article comes from his experience as a manager of various projects at IBM and focuses on the patterns that make breakthroughs possible. What was most striking for me is how little jargon and theory he requires to make his points.

He identifies:

• Breakdowns. Often something has to go wrong for the opportunity for breakthroughs to happen. It’s at the moment where a project faces a challenge, whether by design or by circumstance, that the opportunity for a breakthrough surfaces. How a manager responds to a breakdown creates, or denies, a potential breakthrough (Do I blame people all day, or use it to create an opportunity?)
• Assertion vs. Declaration . He identifies the difference between work a programmer can prove they can do (Assertion), vs. what they believe they can do (Declaration). For breakthroughs to occur, people must be given a chance to do work than can not be proven: ambition and risk are necessary for breakthroughs. If individuals are not trusted to take risks, breakthroughs are unlikely.
• Team commitment . He identifies that failure on one part of a breakthrough project must be aided by other people on the project. A group where everyone only cares about their own component is unlikely to make a breakthrough, as the high risk guarantees some component of the project will fall behind and how the rest of the team responds (support, aid, advice, blame?) decides the fate of the entire project.

It might be the best 15 pages I’ve read on managing breakthrough projects in a year, much better than most of the books and other commonly referenced sources. The first 3 pages are dry but I promise it gets better.

Managing for breakthroughs in productivity, by Allan L. Scherr (PDF). (Hat tip to Gregg Gordon @ SSRN).