I’ve given my share of presentations over the years. I am under no illusions that I am anything more than a marginal presenter. My presentations are information dense, a function of how I learn. Many years ago, I realized that I learn when I’m drinking from the fire hose, not when content is spoon fed to me. I am focused and engaged with the prior; I become disinterested and disengaged with the latter. Of all the recommended presentation styles I’ve been exposed to over the years, I find the “tell them what you’re going to tell them / tell them / tell them what you just told them” pattern intellectually insulting. I prefer to treat my audience with respect and assume they are intelligent, so I err on the side of content density.
For this style to be effective, the audience has to also want to drink from the fire hose. If they do not, you won’t get past the first couple of paragraphs. But in over 30 years in the tech business, I find tech audiences generally respond to high-content-density presentations.
As the person leading a briefing or presentation, it is your responsibility to connect with the audience. However, there are limitations. The content as prepared is only as good as the guidance you’ve received to shape the subject and depth of detail. A presenter with subject matter expertise isn’t (or at any rate, should not be) wed to the content and can generally shift gears to adjust when there is a fidelity mismatch between content and audience. But being asked, even demanded, to explain even a moderately advanced concept in a limited amount of time to an audience lacking in subject matter basics is going to fall flat every single time.
People buy things - large capital things - for which they have little or no qualifications to purchase other than the fact that they have money to spend. Few people who buy houses are carpenters, plumbers or electricians. Few people who buy used cars are mechanical engineers.
This expertise disconnect plagues the software business. There are, unfortunately, times when contracts for custom software development are awarded by individuals or committees who have (at best) limited understanding of the mechanics of software delivery. And there are times when contracts for software product licenses are awarded by individuals or committees who have (at best) limited understanding of the complexity of the domain into which the licensed product must work.
An egregious, although not atypical, example is an 8-figure custom software development contract with payouts indexed to “story points developed”. Not “delivered”, not “in production.” The delivery vendor tapped the contract for cash by aggressively moving high-point story cards to “dev complete”. Never mind that nothing had reached production, never mind that nothing had reached UAT. By the time I got a look at it (they were looking - hoping - for process improvements that would yield deployable software rather than deplorable software), every story had an average of 7 open defects with a nearly 100% reopen rate. And yes, smart reader, ignore the fact that the apparent currency was “story points,” because it was not. The currency was the cash value of the contract; story points were simply a proxy for extracting that cash. Ironically, the buyer thought the arrangement was shrewd because it tied cash to work. Sadly it failed to tie cash to outcomes. In the event, the vendor had the buyer hostage: there were no clawbacks, so the buyer would either have to abandon the investment or have to sign extension after extension in the hopes of making good on it.
Licensed software products are no different. I’ve seen too many occasions where a buyer entered into a license agreement for some product without first mapping out how to integrate that product into their back office processes. When the buyer doesn’t come to the table prepared with a detailed understanding of their as-is state, they default into allowing the vendor to take the lead in designing solution architecture for the to-be state based entirely on generic and simplistic use cases, with disastrous outcomes to the buyer. Licensed products tend not to be 100% metered cost, and the vendor sales rep has a quota to meet and a commission to earn, so the buyer commits to some minimum term-based subscription spend with metered usage piled on top of that. In practice this means the clock is ticking on the buyer to integrate the licensed product the second the ink is drying on the contract. Finding out after the contract is signed that intrinsic complexity of the buyer environment is many orders of magnitude beyond the vendor supplied architecture is the buyer’s problem, not the vendor’s.
To level this information asymmetry between buyer and seller, buyers have independent experts they can call on to give an opinion of the contract or product or vendor or process. But of course there are experts and there are people with certifications. An expert in construction can look beyond things like surface damage to drywall and trim and determine whether or not a building is structurally sound. Then there are the “certified building inspectors” who look closely at PVC pipe covered in black paint and call it “cast iron plumbing.” All the certification verifies is that once upon a time, the certificate bearer passed a test. What is true in building construction is equally true in software construction. Buyers have access to experts but that doesn’t do them a bit of good if they don’t know how to qualify their experts.
Of course there’s a little more to it than that. Buyers have to be able to qualify their experts, want their expertise, and be willing and able to act on it. I’ve advised on a number of acquisitions. No person mooting an acquisition wants to hear “it’s a bad acquisition at any price”, especially if their job is to identify and close acquisitions. Years ago, I was asked to evaluate a company that claimed to have a messaging technology that could be used to efficiently match buyers and sellers of digital advertising space. They had created a messaging technology that was different from JMS only in that (a) theirs was functionally inferior and (b) it was not free. Instead of expressing relief at avoiding a disastrous deployment of capital, the would-be investor was desperate for justification that would overshadow these… inconveniences. As the saying goes, “you cannot explain something to somebody whose job depends on not understanding it.”
I have been fortunate to have worked overwhelmingly with experts and professional decision makers over the years, people who have been thoughtful, insightful, willing to learn, and who in turn have stretched me as well. I sincerely hope I have done the same for them.
Unfortunately, I have had a few brushes with those who fell irreconcilably short. The CTO of a capital markets firm who requested an advanced briefing on the mechanics of how distributed ledger technology could change settlement of existing and open the door for new complex financial products, but had done nothing before the briefing to learn the basics of what “this blockchain thing” is. The mid-level VP leading a RFP process who derailed a vendor presentation because she simply could not fathom how value stream mapping of business operations exposes inefficiencies that have income statement ramifications.
When we fail to connect with an audience, we have to first internalize the failure and look for what we might have done differently: what did we hear but not process at the time, what question should we have asked to clarify the perspective of the person asking. What is spoken is less important than what is heard.
At a certain point, though, responsibility for understanding lies with the listener. The audience member adamantly demanding further explanation may be doing so for any number of reasons, ranging from simple neglect (a failure to have done homework on the basics) to a deliberate unwillingness to understand (i.e., cognitive dissonance).
Which is where the title of this blog comes in. It’s a comment Ed Koch, the 105th mayor of New York, made to a constituent who demanded to know why the mayor’s office was introducing policy to lighten taxes, some time after New York had financially imploded and was still hemorrhaging high-income earners and businesses. “I can explain it to you” he told this constituent, “but I can’t comprehend it for you.”
