Three rules of maintenance

The condo building I live in has a property management company. This makes sense. The building is 120+ units across 12 floors with retail and office space. What doesn’t make sense is this same company’s poor communication. They are consistently unclear and underwhelming, particularly when it comes to maintenance.

Today they were servicing the fire safety system. This also makes sense. Fire is an existential threat to a 12-floor building and maintaining that safety system is key. But during this maintenance the alarm system speaker in our unit continually blipped on and off. Imagine the sound of plugging headphones in-and-out, in-and-out. Just a little blip. But that blip emanates from a unit typically used to signal a fire alarm or emergency. So let’s call this a disconcerting blip.

You’d imagine that ahead of maintenance like this a property management company would notify homeowners, right? Wrong. You’d also imagine that after being alerted to this disconcerting blip that company would acknowledge the impact, right? Nope. And you’d imagine that, even though a vendor was performing the maintenance, the property management company would take ownership of the mishap, right? Not really.

In thinking about this snafu it solidified some ideas in my mind around support and maintenance. I think they apply to software systems and physical infrastructure alike.

Provide awareness
It’s vital that you provide awareness for customers ahead of maintenance. Either passive awareness (like a status page they can check) or active awareness (like an email notification) can be successful. What counts is that you communicate somewhere, someway to your customers.

My property management company didn’t do this. At all. There was no email, letter in our mail, or notice on a bulletin board that this was happening. So when that disconcerting blip started I was just confused. That sucks. To resolve that confusion I went downstairs and talked to the on-site building manager (who is fantastic). He cleared things up instantly. But that’s not really his job.

When you don’t provide awareness for your customers you’re rolling the dice. Maybe everything goes well. If so, that’s great. But a single success does not signal a resilient process. Because when things don’t go well your failure to provide awareness amplifies your customers’ frustration. Now they’re angry at the impact of this maintenance and they’re angry at you. Best to avoid that.

Acknowledge impact
I know the maintenance plan calls for your customers to be fine. The maintenance won’t impact them. But, well, it might. And when it does you have to acknowledge that impact. That doesn’t necessarily mean you have to apologize. Things change. They don’t go according to plan. That’s life. Your customers will understand. Your first step has to be acknowledging that your work impacted their time.

My property management company didn’t do this. After talking to the on-site manager I sent the management team a short email explaining what happened and asking for a heads up next time there’s maintenance. A reasonable request, I think. Instead of any real acknowledgement, though, I got back this:

I spoke to Name (copied) and he said the speakers should not have sounded in your unit. There may be a problem in the system. He needs more information and will contact you to get this resolved.

That’s…factual? Nowhere in that do I hear an acknowledgement of impact. No, “Thank you for letting us know. This maintenance work wasn’t intended to impact homeowners and I’m sorry it did. We’ll improve our notification process going forward.” It’s nice to at least know the impact wasn’t intended. But when writing to your customers try and be a little less…cold. Acknowledge that, despite your best intentions, your work may have adversely impacted their day.

Accept ownership
Maintenance can be tricky. Maybe you’re dealing with third-party vendors. Maybe your data center’s backup generator ran out of fuel. Maybe you just didn’t account for weird edge cases. But here’s the thing: it’s your maintenance and they are your customers. Own that.

My property management company, again, didn’t do this. After getting that coldly factual email I replied to say, essentially, “That’s nice but my point about proactive communication stands.” Had they followed the previous rule and acknowledged their impact then we wouldn’t have gotten to this step. Instead they said:

Sorry Andrew. We were assured by the testing vendors that no units would be affected and therefor did not send out a notice.

Well that’s nice. Didn’t end up meaning much, did it? Passing off the impact you have on customers to a third-party doesn’t divorce you of responsibility. When you avoid taking ownership you convey to customers that you’re not really invested in their success. You know you had an impact on their work. But you’re choosing to just sort of go, “Eh, but it wasn’t really our fault.” When you do this you offer no reassurance that this maintenance problem won’t happen again. And again.


When it comes to maintenance, communication is key. You need to keep your customers aware. You need to acknowledge when you have an unintended impact on their day. And you need to own your role in causing that. When you don’t do these things your customers are just pissed off. And worse, they’re doubting you. Because if you can’t communicate well around routine maintenance then why should they trust you to communicate well around more important matters? They shouldn’t.

Stop apologising

When there has been a deliberate change though—one that is important for future development and that almost certainly won’t be changing back—then that sort of apology can be counter productive. If you know that a feature has been removed and is gone for good, it’s unhelpful to offer false hope to a customer of “recording your feedback” and “voting for that to be returned”. It will probably never happen.

Stop apologising to customers and start leading them – Mathew Patterson.

On certainty in support

People turn to customer support for help, expertise, and reassurance. However, in my experience customer support teams too often respond with uncertainty.

I find a core cause of this to be one particular way of phrasing written replies. It stems from how we try to make replies conversational and relatable. We throw around words like “should” or “looks like” without understanding what they convey to someone confused and frustrated with your product.

In certain cases WordPress.com users have to rely on Happiness Engineers to manually transfer their blog to another account. A couple years ago I found we frequently wrote back to those customers to say, “That blog should now be under your other account.” Should. If you are on the receiving end of that sentence your first question could rightly be, “Well is it?!”

It takes one step and one word change to improve that. First, trust that you did things correctly but verify to be sure. Second, rewrite the above example to, “That blog is now under your other account.” Simple, yes, but a much greater sense of certainty.

In support we are frequently the ones making a change behind the scenes. In some cases we manually fix something vexing the user. In others we let someone know we fixed an earlier bug. In all cases we should be certain in our language. Certainty and expertise is what builds trust.

If you write a support reply and find yourself unsure of something, do the work necessary to be sure everything is working properly. The extra time will build trust with the user by removing doubt. Removing doubt and illustrating that someone can trust you as an expert is one surefire way end up with happier users.

Publishing and producing texts

What is the business of literature?, by Richard Nash, is one of my all-time favorite essays about authorship and publishing. The entire piece is phenomenal and this bit was perhaps my favorite:

It was a sign, almost one hundred years ago, of the book beginning to achieve what most technology will never accomplish—the ability to disappear. Walk into the reading room of the New York Public Library and what do you see? Laptops. Books, like the tables and chairs, have receded into the backdrop of human life. This has nothing to do with the assertion that the book is counter-technology, but that the book is a technology so pervasive, so frequently iterated and innovated upon, so worn and polished by centuries of human contact, that it reaches the status of Nature.

Add that to Instapaper and settle in for some thought-provoking reading.

Bonus link on a related note is Fetishizing the Text, by Kieran Healy.

Making the WordPress fullscreen editor the default

A couple weeks ago Patrick Rhone mentioned that:

It is kind of sad that, in 2012, I have yet to see a blogging engine with a post editor designed for doing the very thing we online writers go there to do… Write.

Shawn Blanc mentioned that WordPress has a built in fullscreen editor that is pretty minimal. He’s right, the fullscreen editor is one of my favorite additions from the past couple years. The new media improvements are even better.

I decided to take a crack at making a plugin to automatically enable the fullscreen editor. Turns out it was actually pretty easy to do. 6 lines of PHP and 3 lines of JavaScript later the plugin is live. I tested it in WordPress 3.5 with a few other things installed but the testing was by no means extensive. If you find any bugs feel free to open an issue on GitHub.

The code is hosted over on GitHub in case you want to give the plugin a spin. I’m positive the plugin isn’t for everyone, that’s fine. 🙂