Have you ever seen A League of Their Own (1992)? I’m thinking of the quotable part where Tom Hanks confronts a crying Bitty Schram—or one of the other blondes, I don’t remember—and, flabbergasted, chides her “There’s no crying in baseball!” Clearly, there is crying in baseball. She’s crying, and they’re in a baseball diamond playing baseball. There’s crying in baseball. We all can clearly see it.
If you have not seen A League of Their Own, what are you doing with your life? It’s a classic.
Anyway, me, the manager of a publishing team, anyone else in publishing that there are no emergencies in publishing, is parallel to the manager of a baseball team telling a crying baseball player that there’s no crying in baseball while the audience watches. We’ve all experienced publishing emergencies, Catherine. What are you talking about?
I guess it depends on how you define emergency. Merriam-Webster says, “an unforeseen combination of circumstances or the resulting state that calls for immediate action.” By that definition, yes—publishing has emergencies. Unforeseen circumstances arise constantly and often require immediate action to respond or correct. However: Many other definitions of the word emergency—including Cambridge—include the key word dangerous. That in order for an urgent event to rise to the level of emergent, danger must be involved. That is, danger to health, life, property, or the environment.
If danger to the environment qualifies, then maybe all of publishing is an emergency. Do you know how many trees are cut down to make paper for books? And don’t get me started on fossil fuels for shipping books around.
Urgent situations that arise in publishing are rarely dangerous. The staff working the printing press might experience an emergency: They are working with fast-moving, heavy machinery, which can create a dangerous environment. The staff in the publisher’s office rarely experience a true emergency. A missed deadline or publication date is not an emergency. It might be a problem, but it’s not dangerous.
The ability to distinguish between something important, something urgent, and something that’s an emergency is a valuable skill. For starters, it gives you an edge in planning your response to an unexpected situation. An urgent situation can often wait for business hours, while an emergency cannot. Consider: The urgent care near me is open for walk ins from 8 in the morning till 8 at night. That supposes there are urgent medical cases that can wait for morning. The emergency department at the hospital, on the other hand, is staffed around the clock. A medical emergency cannot wait until business hours begin.
Sometimes, in the course of executing my publishing management responsibilities, I find an editor in my office in tears. Pretty much everyone has a bad, stressful day at work sometimes. I do not judge anyone for crying in my office. I have cried in front of just about every boss I’ve had. Usually this is because an author or a colleague is angry and yelling, or an important deadline is looming, or because something didn’t deliver on time. Editors, by and large, are some of the most accountable people I’ve known. They like to meet deadlines and take missed deadlines hard. When someone crying in my office starts to wind down, I hand them a tissue and I say, “You’re not a heart surgeon.” This is not to say that only heart surgeons and other life-or-death professionals can experience stress, but to ask: Did anyone die? Is anyone in danger?
No? Then we can set it right, whatever it is.
I believe that every problem has a solution. At least one solution (usually many solutions). I have high confidence, because I’ve never encountered a problem I couldn’t solve. Solving doesn’t necessarily restore the situation to the state it was in before the problem occurred (nice when it happens), but rather that there’s always a way to repair the situation to a state that all stakeholders can agree to be satisfied with.
What types of things are usually considered publishing emergencies, and how do you solve them? Again, as long as no one has fallen headfirst into the printing press, then publishing emergencies tend to fall into two categories.
Missed Deadlines/Late Deliverables
Something is late—and not at the beginning of the publishing process where we could have made up the time, but at the end when it actually matters. This could mean something like:
A textbook is not available in the school bookstore when classes start.
A novel that has been comprehensively promoted misses its publication date.
A magazine misses its mail date and will arrive late to customer mailboxes.
A meeting program didn’t ship on time and didn’t arrive at the meeting—so attendees have no programs.
To be clear: None of these situations are great. All of these situations mean lost revenue, and lots of it, as well as wasted resources. A textbook that misses its adoption window is dead and may not sell until the next semester, or year—or may never sell. A novel that misses its publication date wastes the funds spent on its marketing campaign and, further, cannibalizes the sales of whatever book’s pub date it barges into. Magazines, journals, and meeting programs are, in essence, disposable—they’re publications with a limited lifespan of usefulness. Advertisers pay good money to be featured in those products and expect them to be in the end user’s hand at the beginning of that lifespan so they can make their full impact.
Errors in Published Content
Your publication came out and something is wrong: It contains an error of some kind. Not all errors are created equal, and the more visible the error the more serious it is. Author’s name spelled wrong on the cover? Visible. Political map mis-colored with the Dem states red and the Repub states blue? Very visible. Your Public Policy Guide is billing itself as a “Pubic” Policy Guide on the spine? Hilariously visible.
When a product comes out in print, your options are limited and they suck. Sticker over the mistake, let it stand, or destroy the run and reprint. Digital content is more forgiving—the online publication can be taken down, fixed, and replaced—but there’s nothing you can do about the users who already saw the error.
Missed deadlines, late deliverables, and errors in published content: Did anybody die? Is anybody in danger? Lives at risk? Usually, the answer is no.
Full disclosure: I once presided over a publication in which the Greek letter μ dropped out of a PDF and was replaced by the Latin letter m, changing a medication dosage by an order of magnitude. Did anybody die? No. Could somebody have died? Yes. Fortunately, this was fixed quickly and no harm was done.
The problem with not really having true emergencies in publishing is that we, the publishing industry, get to decide what constitutes a publishing emergency. We’ve already established that, for the most part, urgent and unforeseen situations that arise do not pose a danger to life and health. Instead of celebrating our good fortune that we work in an emergency-free environment, some parties will elevate urgent-but-non-emergent situations to the level of an emergency.
This is how you wind up with staff stomping around, threatening heads to roll, demanding accountability, claiming that the sky is falling—and I wind up with editors in my office in tears. But did anybody die? So far, nobody’s died.
How to Handle a Publishing “Emergency”
Assess the Impact
You can’t know whether you have an emergency on your hands until you know the range of impact your unforeseen situation may cause. Whatever the problem is, make a list of the potential downstream impacts. For instance, consider that a broken binder at the printing press caused a meeting program to miss its ship date. The meeting attendees will now not have programs onsite. What are some of the impacts?
Companies who paid to advertise in the print program will not receive what they paid for.
Meeting attendees will not receive part of the value of what they paid for the conference.
Attendees will have difficulty locating the sessions they want to watch, lowering session attendance.
All resources devoted to producing the program have been wasted.
Unless you understand all the potential impacts of the situation, you can’t begin to mitigate them.
Keep a Cool Head and a Modulated Voice
Maybe this is just, you know, my opinion, man: Being stressed out yourself, or yelling at someone and causing them to become stressed, doesn’t make it easier to mitigate impact and carry out an action plan.
Remaining calm in a high-pressure, high-stress situation is not an ability some people naturally have and others don’t. It’s a skill that anyone can build up over time through practice and study. By study, in this case, I mean observing and contemplating others’ responses to urgent and emergent situations.
And while you’re at it, refrain from blame assignment. There will be an opportunity later in the process to provide feedback to those who could use it. Feedback is helpful. Blame is not helpful.
Make an Action Plan
I suggest making your action plan before informing stakeholders, so that you may include your action plan in the information you share. Your action plan should describe:
What will we do to fix the problem itself?
What will we do to mitigate the downstream impacts?
Sometimes the fix itself can mitigate the downstream impacts. In the example of the broken binder delaying shipment of a meeting program—can you find another printer that can step in, print the program, and deliver it on time (even at a premium cost)? If so, then you may negate the downstream effects completely.
Typically, the fix will leave some downstream impacts for which you will need to account. Maybe you saved the day, but at a dollar cost that blew the budget. Maybe there was no way to get print programs delivered on time, but your team was able to make the program available to attendees as a download—this may mitigate some of the attendees’ experience but the advertisers will still need to be placated.
Inform Stakeholders
Once you have your action plan, inform the internal stakeholders—all of them. Make sure you understand who all those folks are. It’s a bad look when a stakeholder is left off the distribution and finds out through the grapevine that something has gone sideways.
Conversely, make sure you’re informing your internal stakeholders only unless you are sure it’s your responsibility to reach out to external stakeholders. Leave that to their account representatives or other handlers. Don’t take it upon yourself to reach out to Widget Co. and tell them the bad news if Brenda from Sales handles all the communication with Widget Co. Let Brenda do it. Just make sure you got Brenda informed.
Execute
As part of my memo to stakeholders outlining my action plan, I make a point to tell them when I am going to execute the action plan. This way, they know how much time they have to give me feedback on the action plan, if they would like to.
The follow-through on the action plan is as important as the planning. The plan itself is nothing without execution. Follow it through—and then report back to those who need to know once it has been done.
Retrospect
As in the verb retrospect (or retrospectate, if you prefer, which I just made up). If hindsight is 20/20, use it. After the situation has been put to bed, that is, resolved to the degree it can be resolved, and the emergency situation is behind you, give everyone a week or two to process and then schedule a retrospective to discuss.
How could we have prevented this from happening?
Once it was happening, could we have better mitigated the damage?
What fallout have we experienced since the incident?
What steps are we taking to ensure this doesn’t happen again?
If you have questions that you'd like to see answered in Shelf Life, ideas for topics that you'd like to explore, or feedback on the newsletter, please feel free to contact me. I would love to hear from you.
For more information about who I am, what I do, and, most important, what my dog looks like, please visit my website.
After you have read a few posts, if you find that you're enjoying Shelf Life, please recommend it to your word-oriented friends.
There's got to be a solution to the μL to mL issue
Unfortunately spelling out μ to mu just makes it worse.
Also wish I could have named my first internet server μ.mae.cornell.edu , it's nuts that internationalized domain names didn't become a thing until 2003