So this chapter heading is not a pattern (or is it?), which breaks the pattern of the chapter headings. Inside, it introduces two patterns ("Agree how you’re using your comms tools"; "Introduce new tools with care"). One of these is presented as a section within the chapter, the other is presented as a chapter head on its own. This makes the first one invisible at the level of the Table of Contents. It also is quite jarring as a reader to be reading through the section on the first pattern and then find oneself in a whole new chapter--first asking, "wait--weren't there two patterns?" and then asking "wait--why is this one in a chapter on its own, when the other was just a subheading?" So I would be comfortable with two chapter heads that were both patterns, and incorporating the preamble into the first. Otherwise, I think you have to demote the second pattern to another subhead. It's what the reader's brain is expecting.
The concept of the three different comms spaces is breathtakingly simple and blessedly useful. Suddenly the tower of babel is an architecture of managed communication. And the Map suggests that a pretty crowded basket of tools could actually function as a complex and fluid web of communication support. Which suggests flexible, decentralized power. Which is very stimulating to think about.
Yeah I 100% felt the same way as I was writing it. Thank you for pointing out that this bit is smelly, now I'm motivated to fix it!
In fact, your response made me go back to the section that now begins "make a map together. add your meetings" (p. 34) and ponder it for a while. The complexity of the map you offer as example (which is amplified by the hidden component of the pop-up instructions, and by the missing components that you mention--"e.g.
“monthly strategy meeting”, “annual retreat”, “Friday drinks”") suggests that this element of the process is potentially quite significant. And helpful, if done well. That's almost a dozen tools on that map, which is a bigger number than we humans can keep in our head at any one time. So a way to navigate it successfully and consistently is indeed important. Which got me thinking that if you ever felt inspired to invest more time in this section, a more detailed walkthrough of the construction of this or a similar hypothetical map--perhaps drawing on your experience with the big sheets of paper--would be quite worthwhile and valuable to an audience. It's a complex artifact, and in such cases worked examples are extremely helpful to novices. It would provide an opportunity to elaborate on the relationships between the tools, and between the tools and the group processes/events, which would give an audience more inspiration and more to go on when they attempt it on their own. Also it gives you a chance to wax on, which is always nice when you have a lot of tacit knowledge.
But this guy will have to be changed: "With a shared understanding of the tools, they all fit together beautifully". "They" is ambiguous, and syntactically indicates that it is the tools that have the understanding. I think you have two ideas here, each of which could support a little elaboration--about shared understanding (what forms can that take? is it necessary or better that it be recorded? are there processes that specifically support it?) and about tools fitting together (what does that look like in practice? what are some examples of the inter-tool workflow? what do you use Facebook for, and how does that support/relate to the use of Gmail?). If you were so inclined.