Lesson 1: communication is intentional and takes energy -- from both sides.
Lesson 5: sometimes the action is "think about it".
Actionable information is great. However, one of our goals is to think better as a group than any one of us can as an individual. Doing this requires sharing partial thoughts. "Brainstorming", in other words. (This concept is emphatically Not New!)
One thing that can make both these kinds of communication (actionable and brainstormish) better is identifying which one you're attempting to engage in. Never skip this. Both can be constructive, but if your counterparty in communication mis-guesses which one you're performing, they'll allocate the wrong kind of attention themselves for responding to it, and it's very likely to result in suboptimal outcomes (if not outright negative ones, e.g. when one party only has brainspace for actionables and the other party volunteers not those, which can result in impatience and negative evaluation on one side and simultaneously a feeling of being unheard on the other side).
Lesson 5 corollary for executives and leaders: You will be very likely to develop a bias in preference of 'actionable' (rather than 'brainstormish') communication as your own time grows scarcer. Be mindful of this and build compensations for this -- it's both natural and yet can be a severe weakness if not mitigated.
Some simple, helpful tips:
- Improve your own skills on guessing whether your counterparty in communication is attempting 'actionable' or 'brainstormish' communication.
- Remind your counterparty to be more explicit about this themselves!
- Be careful not to be overly harsh on brainstormish communication without explaining why. As a leader, you should expect that people may mirror your behaviors -- and it's important that you don't accidentally lead your entire team to always prefer 'actionable' and discard 'brainstorm': that way lies franticness and a general failure to collaborate effectively.
- Reserve some time to do brainstormish communication with team members. Doing brainstormish communication well is a skill like any other, and can atrophy like any other; don't let it. Moreover, there are some kinds of ideas that simply can't appear fully-formed in an instant, but rather require synthesis of concepts from several people. If one of those people with a key part of the concept is you, you don't want to deprive your team of that simply because you've formed an overly-strong preference for actionable-only communication!
Lesson 8: Discussion vs Dissemination.
As with most of the lessons, the key thing is "know about it". Simply being aware of the difference will result in huge increase in your personal effectiveness, both in consuming information, propagating information, and generating new information.
Lesson 8 corollary for executives and leaders: if you're going to push something in dissemination mode without having taken it through a discussion mode phase, be prepared to also disseminate a reason why you're doing that.
It might be fine. Not everything needs discussion at every level (indeed, for some situations, devoting this much sheer time to every topic, rather than just the ones that matter, would be paralytic). But some things do.
If using a tiered system where some discussions took place to generate the now-dissemination-mode content, simply disseminating information about how, when, and where those discussions took place can be a big help. Ideally those pointers come before completion of the process; and ideally, there's also some documents after the process of what was raised and how the concerns were balanced. This takes work, but it's worth it: it avoids (potentially massive) time spent later re-litigating the details in smaller sessions which can crop up after-the-fact to insert discussion mode if people feel they weren't included enough and their concerns might not have been considered.
Lesson 6: leave -- and make -- room for serendipity.
We saw an example of this in the Lesson 5 Corollary ("Reserve some time to do brainstormish communication"), but the principles go for everyone.
It's very difficult for the correct information to reach the correct people in all cases if we only have bottom-up reporting and top-down dissemination. Serendipitous connections makes it possible for messages to take shorter routes between more topic-attuned people. This process involves some luck -- but it's better to make room for the possibility of good luck than to squeeze situations until those possibilities disappear.
Lesson 9: YAGGIRTFT -- You Ain't Gonna Get It Right The First Time / Drafting is Important
When doing any kind of knowledge work or communications (from writing poems to writing computer code and everything in between), drafting is an essential process. Make room for it. Make workflows for it. Draft.
Small iterations permit faster work. Drafts are easier to share earlier than finished works.
And marking things as drafts has all sorts of other communication benefits: it's easier to edit drafts without attachment. It's clearer that the existence of a draft isn't a final product and other planning shouldn't depend on it simply because a draft has become available.
Drafts and small iterations make it possible to get more work done, faster, and collaborate with fewer blocks and lower communication overhead. The artifacts of this kind of a process are also valuable in themselves: they're great discussion focuses if you need to pull in others on more focused subsets of the work before making the final draft; and they're likely to produce useful documentation in the future; and also, they're just plain proof-of-work in the event that a task ends up being harder than you thought and it becomes important to demonstrate progress to teammates (even if it just ends up being a list of what was tried but didn't work).
Think of it like a ratchet: by making small drafts, iteratively, you make sure your work goes forward, even by small amounts -- and isn't prone to slipping and unwinding unexpectedly even when one of the steps forward turns out wrong.
How exactly to go about this effectively varies based on what kind of work you're doing. Consider gists, or collaborative documents, for sharing -- but it's not even necessary to start with something shareable. Simply working on a private file on your localhost is a fine way to start (then, figure out how to share it later).
Lesson 9 applied to programming: git is not inherently good at supporting drafting.
Drafting as a workflow and a user experience is not equally well supported by all tools -- and you should avoid getting caught in the trap of assuming any tool will encourage good practices around drafting! Intentionality is required.
Git branches are actually remarkably bad at supporting drafting. A key element of drafting is that sometimes you put the draft down (or at least, archive it, and procede from a new begining eilsewhere rather than proceding directly). Git branches can't be "put down". The only obvious way to do so is to... keep the branch forever. This conflicts with both the utility of branches as a whole (they're supposed to be an enumeration of active points of progress!) as well as not being a good mechanisms for archiving (branches are not searchable or meant to be collated in large numbers and long terms).
Version control encourages us to keep everything; but keeping branches forever isn't good. Your experiments and early iterations are useful to persist, so that they can be used as reference in the (possibly distant) future if questions about "why didn't we do X?" come up, but branches aren't a good way to do it.
// FUTURE: expand on what is good. but this would need larger articles, probably deserving another page. more than one answer.
Lesson 9 applied to programming: github is not inherently good at supporting drafting.
Github provides a workflow tool called "Pull Requests". Pull Requests are not inherently good at supporting drafting.
In the same ways that git branches aren't a great conduit for drafting, neither are PRs, which build upon the model of branches. PRs can only be created by phrasing the change as a suggested merge -- this is already the wrong mental model for a draft. And once a PR is launched, it's not natural or well-supported by the UI to take steps such as abandoning one PR and launching another with the same intentions but a different approach. And yet, given YAGGIRTFT, this is a flow that we should often do!
// FUTURE: honestly reconsider if these 'applied' Lesson 9 bits belong in this doc or factored out.