Assumed audience: Other folks interested in thinking seriously about business effectiveness—both in general, and specifically in the context of software.
Of the past few years, I have read a number of the by-now-standard “adopt this set of practices and your business will be awesome” books about business practices, especially in technology — most notably the much-cited Accelerate. Last year, I read a book that put paid dto a lot of the nonsense that I took those books to be peddling:1 Phil Rozenweig’s The Halo Effect. What follows are some of the most incisive and salient quotes from the book.
Despite our best efforts, the ways that people and processes work together in complex organizations are very hard to untangle and even harder to transplant elsewhere with the same results. Even if we set out with the best of intentions to improve operational effectiveness, we can never predict exactly how a given set of practices will shape a company’s performance. Which helps explain why the explanatory power of the study by Nick Bloom and Stephen Dorgan, reviewed in the previous chapter, was rather modest. They found that adopting certain business practices could explain about 10 percent of the variance in company performance. Why not more than 10 percent? Because those same practices will lead to somewhat different results depending on a whole host of factors: an organization’s people, their skills, their expectations, and the organizational context in which those practices are used. None of this suggests that some practices aren’t, on balance, better than others, nor does it mean that they won’t be generally useful for most companies much of the time. It means only that execution, like strategy, doesn’t lend itself to predictable cause-and-effect relationships. Our best efforts to isolate and understand the inner workings of organizations will be moderately successful at best…
It’s always easier to bang the drum about execution than to address fundamental questions of strategy. It’s always easier to insist we’re going in the right direction but just need to run a little faster; it’s far more painful to admit that the direction may be flawed, because the remedies are much more consequential…
It may be true that if we pick a group of highly successful companies, we can find some that grew by organic expansion and others by acquisition, some that offered low prices and others that emphasized innovation, but it doesn’t follow that one strategy is just as good as another provided it’s well-defined and clearly communicated. All we’ve done is grab the wrong end of the stick.
Strategy is about performing different activities from those of rival companies, or performing similar activities in different ways. A strategy is not a goal or an objective or a target. It’s not a vision or mission or a statement of purpose. It’s about performing different activities from those of rival companies, or performing similar activities in different ways. A strategy is not a goal or an objective or a target.… [Strategy is] being different from rivals in some important way. In turn, execution is all about carrying out those choices…
Rather than merely state the importance of flawless execution — after all, who could be against flawless execution? — managers would do better to identify those few elements of execution that are most important to deliver on the chosen strategy. For one company, it could be the reduction of manufacturing cycle time. Or lowering defect levels. For another, it could be improving speed to market for new products. Or achieving higher levels of customer retention. Or improving the rate of on-time delivery. Of course, it’s tempting to say that everything is important, but that’s too easy. The key is to ask: For our company, at this time, competing against our rivals, which of the many dimensions of execution are most important? Which ones are most vital for us at this time? That’s a tougher question, but it’s necessary…
Notes
“Nonsense” might seem to be a particularly strong word to use here. I stand by it. Accelerate, for example, is a book which has some valuable insights but whose thesis is fundamentally unfalsiable; whose authors perpetually engage in “no true Scotsman”, attribution failure, and selection bias fallacies; and which ends up making frankly-absurd claims like this for their favored approach:
Burnout can be prevented or reversed, and DevOps can help.
It is not a serious book, and it does not deserve its reputation — which it gets, I think, because its authors are good at selling their narrative and because everyone would like there to be a silver bullet solution to the challenges of building sustainably high-productivity software teams. As ever, though, there is not: for the reasons elucidated by the Rozeinweig quotes in the rest of this post! For a more thorough fisking of Accelerate, see Keunwoo Lee’s review. ↩︎