Radical Focus

This isn’t a book I would have been interested in earlier in my career, but it’s the sort of thing I’m increasingly drawn to out of necessity, trying to solve a particular set of management problems that I see over and over again in fast growing software companies. Another influence nudging me in this direction was In Defense of the Repetitive Business Book by Camille Fournier, which argues that this kind of material is worthy of much more respect than we often give it.

Radical Focus is a brilliantly helpful and concise little book that I read in one sitting. Through telling the story of a struggling startup, it introduces the process of managing a business using Objectives and Key Results, otherwise known in Silicon Valley as OKRs. I rolled my eyes at the first chapter when the narrative of the two founders is introduced, but as the story develops, I became more and more engaged, mostly because the situations described were so familiar to me, coming close to describing various real situations and relationships in startups I’ve been associated with.

At a more abstract level, it was amazing how closely the book mapped to the exact problems I face in my day to day work (basically: “How do you inspire a diverse team to work together, going all out in pursuit of a single, challenging goal?”).

I’ve been a bit of a cynic about ‘capital-A Agile’ for a long time, based on various observations and reflections on failed software projects and dysfunctional team situations. One characteristic shared by all of these failing projects and unhappy teams is a deep disconnect between the methods of structuring and planning software work and the impact and value generated by the work. The agile community inadvertently encourages and reinforces this disconnect through its deliberate emphasis on ceremonies focused on delivery of user stories and features rather than anything tied to actual business results. Read the original agile manifesto carefully and you’ll find the whole document is infused with the subtle assumption that working software and running code is inherently valuable.

Entrepreneurs, CEOs, and business leaders are partial to getting up in front of the whole team and stressing the importance of ‘shifting the needle’. In my experience, one of the most difficult challenges to solve in this context is to get software and product teams to collaborate directly with the leaders to define and agree on what the needle actually is, what it’s measuring and what success looks like.

It’s my belief that many companies are too quick to adopt agile methods wholesale, based on FOMO or a desire to feel competent and process-driven rather than being guided by evidence and situational awareness. There are a lot of valuable insights and useful practices associated with agile, but it’s really best suited for mature teams with a high degree of self-discipline.

So how do we develop the necessary maturity and self-discipline to develop products effectively using agile (or lean) methods? OKRs are a proven method that could contribute towards this, by setting success criteria for the entire organisation as a baseline for guiding day-to-day decisions on what to work on and how to work on it.