📗Book Review: Nine Lies About Work — part 2

Photo of №11 Group Operations Room in the “Battle of Britain Bunker” at Uxbridge, UK.

In this second part of my review, I take a look at Lie Number 2.

Lie #2: The best plan wins.

After looking at Lie Number 1, this chapter is much more compelling. It happens to be the least original part of the book, since it is mostly a summary of Stanley McChrystal et al.’s book Team of Teams, which recounts the challenges the US Army faced in the war in Iraq and how, by relying primarily on efficient intelligence sharing rather than planning, they were able to improve the success rate of their missions. The authors also reference how the Dowding system helped the RAF in their fight against Nazi Germany during World War II.

The core idea of the chapter is that the best intelligence wins, not the best plan. Frequent and unfettered intelligence sharing helps teams and organizations deal with ever-changing contexts, whereas plans always lag behind reality. The authors provide two pieces of advice for team leaders to foster intelligence. They also make a key claim along the way. In this article, I will take a closer look at all of this.

Core idea: The best intelligence wins, not the best plan

The lie that “the best plan wins” is one I’ve encountered a lot in one form or another. The scenario the authors describe where the top executives go to their yearly retreat and come back with “The Strategic Plan” which will then be cascaded down into smaller and smaller sizes is typical. What’s even more mindboggling is that modern methods still seem to replicate this to some degree. Modern product management best practices continue to advise starting with some sort of vision, then breaking that down into strategy, and then into specific projects and actions. Simon Sinek says to Start with Why. Radhika Dutt recommends we be vision-driven. Discovery Discipline starts with the Frame phase where you select an outcome, perhaps using a method called Vision-Project Connection. There’s the Lean Canvas, Business Model Canvas and a slew of other canvases that invariably do similar things. Rarely do these methods push people to go out and get user data, or what Alberto Savoia calls YODA (Your Own DAta), before making a decision. Managers ask instead for multi-year linear roadmaps that must align with their strategy and must be concocted without research of what users will actually buy and use. As a consultant, I have often been confronted with the awkward position where a customer deems me The Expert and is baffled when I can’t come up with all the risks and mitigation plans upfront.

On the flip side, Lean and product management do push for teams to be data-driven and hypothesis-driven. UX designers are called upon more and more. There is an upwards trend of intelligence gathering and many teams seem to have put this to good use. User Journey Maps and analyses of them can help find areas of improvement.

While intelligence is useful, plans and planning aren’t without merit. Plans don’t have to be linear or separate from intelligence. In fact, some plans start with ways to gather more intelligence followed by a decision point and multiple options from there. Real Options is a concept which carries strategies in the financial market over to business or product decisions. One key heuristic is that you never commit early unless you know why. Options have value. Deciding on what to do with an option should depend on the relative values of holding it or exercising it. These strategies can be built into a plan.

The authors refer to the Mission Control at NASA as another example of intelligence. They fail to mention the fact that NASA never embarks on a mission without some sort of plan. The plan includes projected flight paths because you want to have made the calculations for the trans-lunar injection ahead of time. The plan also sets out the various data that should be monitored and the alarm conditions. It provides abort procedures in case of foreseeable failures as well as unforeseeable ones. Ahead of a launch, many unpredictable things can require delaying the launch, such as bad weather. The planning process allows for quickly recalculating the plan to adjust to emerging conditions. So it’s really a combination of intelligence and planning.

I agree with the authors that rigid plans are too often preferred and intelligence flows are too often overlooked. However, I think the authors go too far trying to contrast the two when in reality they should very much be linked.

Claim: Plans scope the problem, not the solution

During the explanation of the chapter’s core idea, the authors make this passing claim towards the end of a paragraph that attempts to explain why planning isn’t “utterly useless.”

Creating space to think through all of the information you have in your world, and trying to pull that into some sort of order or understanding, has some value. But […] your plans are necessarily abstract understandings of the recent past. Plans scope the problem, not the solution.

When I first read the last sentence of this paragraph, I was extremely surprised. The claim seemed to come out of nowhere. It doesn’t advance the chapter’s core idea and the authors’ arguments are insufficient. Also, it just isn’t true, at least not in all contexts. For example, we can be grateful that civil engineers can plan for many things otherwise we should be fearful of driving over bridges or walking into buildings. I wonder what the authors thought they were doing in maths or science classes calculating the length of the hypotenuse or the work output of a steam engine, if they were just scoping the problem and not finding the solution. In Cynefin terms, it seems that the authors are assuming that everything is complex, overlooking the fact that some things are complicated or clear.

Advice 1: Information sharing

The first piece of advice given to team leaders is three steps to help create an intelligence system.

• “liberate as much information as you possibly can”
• “watch carefully to see which data your people find useful”
• “trust your people to make sense of the data”

These steps seem to be a perfectly reasonable and coherent approach. You don’t try to determine/guess what is needed in advance. You adopt a safe-to-fail approach of changing the constraints and monitoring what emerges. Set up a garden, observe the desire paths that form, and pave paths where needed.

In the old model, suborinates provided information and leaders disseminated commands. We reversed it: we had our leaders provide information so that subordinates, armed with context, understanding, and connectivity, could take the initiative and make decisions.

—McChrystal et al. Team of Teams.

I would have a few caveats. Firstly, trust doesn’t mean working without a net. I’m not talking about the Russian proverb “trust, but verify”. As a team leader steps back and lets a team self-organize more, they still should monitor for beneficial coherence and adjust if things derail. It may turn out that resources such as training and mentoring are necessary. Secondly, this advice only deals with information and data. What about knowledge? In particular, tacit knowledge is sticky and does not transfer as easily as information. This is why information should flow easily so as to get to the people with the applicable knowledge. It’s still important to stimulate knowledge flows because this is what will provide context to teams. Information and data may not be sufficient to understand the context. For instance, data about user interactions are very useful, but they are not a complete substitute for ethnography, that is first-hand observations of a user.

Advice 2: Weekly one-on-ones and span of control

The second piece of advice given to team leaders is that they should be having a one-on-one with each team member every week. These check-ins may be very short: 15 minutes for instance. The authors recommend covering two topics in these meetings:

• “What are your priorities this week?”
• “How can I help?”

These check-ins are another part of allowing intelligence to flow through the organization. The authors justify the frequency by referencing data that allegedly shows that “while team leaders who check in once a week see, on average, a 13 percent increase in team engagement, those who check in only once a month see a 5 percent decrease in engagement.” I have yet to find the referenced data. The footnote cites it as “Cisco data, as presented at the annual conference of the Society for Industrial and Organizational Psychology (SIOP), 2017. This data still has the bias of coming from a single organization, no matter how big it is. Despite this, the advice seems fairly sound.

As part of this advice, the authors also recommend limiting the number of direct reports by the number of people a team leader can have these weekly check-ins. The authors call this number the “span of control”. Different leaders have different spans of control. This can be due to the amount of time they have because of other responsibilities. The span of control can also be limited by the will or energy. That’s fine. We all have different skill sets. It’s important not to go into leadership if you’re not willing to do these weekly check-ins.

I definitely agree with this advice. I would add that during check-ins, it’s important to give time for informal discussions. Not everything discussed should be linked to priorities or help. Otherwise valuable intelligence will be left out.

Conclusion

The authors continue their penchant for Manichaeism. Real-time intelligence is important. But so is planning, especially planning that takes into account uncertainty and intelligence gathering. The authors do offer advice to team leaders on two pragmatic ways of getting information to flow through an organization: sharing information instead of hiding it from teams, and doing weekly one-on-one check-ins. All in all, this is probably the best chapter of the book, which is a shame since it’s the least original.