The "Minto Pyramid Principle" looks interesting, unfortunately it appears to be out of print ($60+ on Amazon) do you have any recommendations for similar, perhaps cheaper books?
You want an answer, but people don't necessarily want to give you one. So how do you make them want to answer you?
The answer is: sitcom + question = Answer.
Situation (We need to)
Complication (But ...)
Question (So how / what / when / where / can / could ...)
Answer (This is what you want from them).
I think there's a lot of other good communication advice in it, but most looks pretty generic (cut out the crap, use appropriate language, have some structure, etc). You've read Strunk and White right?
(Note, I've just scanned a summary, so that might not be all there is to it).
When pitching a new product, I detailed the observations, product hypotheses, experimental design, results and conclusion in that order. The discussion focused mainly on the experimental design and the biases in the results and the implications for the conclusion.
I've had trouble putting into words how different mis-communications of mine have occurred, and this sums it up rather nicely. I think many developers I know do this: we're so excited about all of the sound reasoning we placed around our conclusions and the processes that got us there that the actual conclusion is an afterthought tacked onto the end (oddly enough, the conclusion of the communication).
But that's not why you're telling someone something. You're telling them so that they take away what you put all of that work into arriving at, not how you did it (unless they want details later, of course).
Some similar advice I heard recently (I think possibly in another HN discussion thread) was to not be scared of "spoilers" when communicating. I have a tendency to try to make my presentations a nice linear development, like a story, which naturally dissuades you from revealing the "ending" before you reach it. However, it's a lot easier to keep people's attention if they know where your story is heading, it gives them the answer to the ever-present implicit question: why do I care?
This is the part the I had to break myself. I have always enjoyed telling stories, and they work great in a causal setting but they are not useful (except as illustration) in some contexts.
I did a power point once which was essentially the inverted pyramid in a deck, the first slide was the conclusion, the next two where the problem statement and the conclusion, the next 5 were the problem statement, some constraints on the shape of the solution and the conclusion. Down to about a 22 point presentation on the problem, the constraints, the different paths tried, the lessons learned and fed back into the process, and then the solution.
It was a bit gimmicky but some folks really liked it as they felt they always knew what I was getting at.
It's fascinating to me that our profession is so hung up on the format of the scientific paper. A presentation rarely is that.
Instead, you're telling a story. And part of _any_ good story is a "hook", something that reels the audience in at the first sentence and has them (hopefully) wanting more.
My recommendation to _anybody_ giving presentations is, look at storytelling practices. Make it a fun experience, not a dry list of fact, or a chain of evidence. Reserve that for the actual paper ;)
If you think of communication as a tool, something to keep in mind is that sometimes we use communication in lieu of having a better tool. Once you've made your persuasive argument and have to get to work...
An example, when Wave was still an going concern at google, I ran a team doing Enterprise Architecture designs. As an experiment on one project, we decided to use a very structured Wave/Google Docs approach (I don't remember all of the details). But it cut the communication requirements down to a small percentage of what we typically had been up to. A hundred emails a day might turn into 5-10. Project assets were magically organized and Wave became a simple place to capture the work, ask a couple questions, see where each member was with their portion of the work, offer help etc.
I'm finding similar things with Trello (I'm pretty new to using it) when used for things-other-than-agile-development-management. Emails/IMs/PhoneCalls are way down, assets are already organized, everybody knows where everybody else is at a glance (eliminating the need for most syncing communications/meetings).
For what it is worth looks like they just released an iOS app as a companion for the book. $15 is the price. It appears to capture the methods of the book plus contains videos teaching the method. No reviews yet.
The inverted pyramid method seeks max efficiency under the condition of not knowing how long your audience is going to stick around. That's why it's so prominent in journalism - you never know when the reader might just move on, so get the important parts out first. Outside of that condition, its efficiency breaks down and you'd be better off structuring a presentation within the allotted time.
And if that's the kind of relationship you have with your coworkers, someone's probably being overpaid.
20 comments
[ 0.24 ms ] story [ 57.7 ms ] threadThe answer is: sitcom + question = Answer.
Situation (We need to)
Complication (But ...)
Question (So how / what / when / where / can / could ...)
Answer (This is what you want from them).
I think there's a lot of other good communication advice in it, but most looks pretty generic (cut out the crap, use appropriate language, have some structure, etc). You've read Strunk and White right?
(Note, I've just scanned a summary, so that might not be all there is to it).
http://www.gazhoo.com/upload/document/2011/05/07/20110507170...
http://rtphoto.co.uk/tomflaherty/pyramid.pdf#best-memo-youll...
I've had trouble putting into words how different mis-communications of mine have occurred, and this sums it up rather nicely. I think many developers I know do this: we're so excited about all of the sound reasoning we placed around our conclusions and the processes that got us there that the actual conclusion is an afterthought tacked onto the end (oddly enough, the conclusion of the communication).
But that's not why you're telling someone something. You're telling them so that they take away what you put all of that work into arriving at, not how you did it (unless they want details later, of course).
I did a power point once which was essentially the inverted pyramid in a deck, the first slide was the conclusion, the next two where the problem statement and the conclusion, the next 5 were the problem statement, some constraints on the shape of the solution and the conclusion. Down to about a 22 point presentation on the problem, the constraints, the different paths tried, the lessons learned and fed back into the process, and then the solution.
It was a bit gimmicky but some folks really liked it as they felt they always knew what I was getting at.
Instead, you're telling a story. And part of _any_ good story is a "hook", something that reels the audience in at the first sentence and has them (hopefully) wanting more.
My recommendation to _anybody_ giving presentations is, look at storytelling practices. Make it a fun experience, not a dry list of fact, or a chain of evidence. Reserve that for the actual paper ;)
An example, when Wave was still an going concern at google, I ran a team doing Enterprise Architecture designs. As an experiment on one project, we decided to use a very structured Wave/Google Docs approach (I don't remember all of the details). But it cut the communication requirements down to a small percentage of what we typically had been up to. A hundred emails a day might turn into 5-10. Project assets were magically organized and Wave became a simple place to capture the work, ask a couple questions, see where each member was with their portion of the work, offer help etc.
I'm finding similar things with Trello (I'm pretty new to using it) when used for things-other-than-agile-development-management. Emails/IMs/PhoneCalls are way down, assets are already organized, everybody knows where everybody else is at a glance (eliminating the need for most syncing communications/meetings).
And if that's the kind of relationship you have with your coworkers, someone's probably being overpaid.