In 2017, consumers were frequently on the receiving end of bad news: Wells Fargo continued to grapple with the fallout from fake accounts. Equifax compromised data. Apple slowed down phones.
And to kick off 2018, there are vulnerabilities in computer chips that will affect “almost all computers, servers, cloud operating systems, and cellphones made in the past two decades.” Disheartening, no?
I’ve been thinking about the nomenclature employed in this case. Calling the two vulnerabilities “Spectre” and “Meltdown” accomplishes a couple things. Taken together, the names seem appropriately technology-adjacent, but I was most interested in Spectre, which evokes something elusive, ghostlike, and therefore understandably difficult to detect—which explains how the vulnerability went undiscovered for more than 20 years.
Time is an important variable in the consumer reaction to the other cases above. An LA Times investigation first uncovered the Wells Fargo fake accounts in 2013, but Wells Fargo didn’t admit culpability until September 2016. With Equifax, the breach was discovered on July 29, 2017 but not reported to the public until September 7, 2017. And Apple? The iOS update that included the slowdown was released about a year ago, but it was only after enough users compared notes to discover what was happening that the company acknowledged the issue and offered solutions.
In my role as a system administrator for a platform our university uses, communication timing is a factor I consider in two ways:
Time between identification of a problem and communication about that problem
Some of the more frustrating instances of the past year have occurred when we’ve reported that something seemed amiss, only to find out that the platform folks were aware of the issue but hadn’t sent out any communication yet. I understand that it’s tricky to determine the right time to send a “something’s wrong” message—you want to be sure something’s actually wrong before you send it, and it seems unhelpful to send a message about a problem that offers no solutions.
But another platform that we work with does just that, and it works. At the first sign of a spike in tickets or error messages, they send out a note to all system admins (not to the wider population of users) that says, “We’re seeing something odd. We don’t know what it is yet, but we’re looking into it. If you something weird, send it to us, since that’ll help us solve the problem.”
Those messages are so helpful to the “middle people” like myself, who are fielding questions from users but don’t have the ability to investigate or fix the problem. Even if there isn’t any helpful information, just knowing that the issue is on someone’s radar is so helpful.
Time between an impending update or change and when users are informed
Even though I just described feeling frustrated by lack of communication, I have some empathy—because deciding when and how to communicate is complex. Communicate too early and people will forget. Communicate too late and people will feel that you didn’t respect their time. Communicate too frequently and you become white noise. Communicate too little and appear opaque.
Even when you think you’ve found the sweet spot, you’ll hear from people who wish they’d known about the change sooner, or who wish you’d sent out more reminders.
I know, I know—these reactions sound remarkably similar to the frustrations I voiced above. In my defense, communicating about future changes/updates is a bit different from communicating about a problem that’s happening right now.
But still, considering how the communication timing factored in to the reactions Wells Fargo, Equifax, and Apple received, I’m rethinking where the communication sweet spot is, and leaning towards “more of it might be better, no matter the context.” Luckily, the communication scenarios I deal with are generally on a much smaller scale and don’t carry the weight of potential litigation—or at least I hope they don’t! Even so, 2017’s failures to consumers are a cautionary tale for how important the timing of communication can be.