2018 in books

Last year was the first year in which I kept a more organized list of what I read. I had a loose goal to read a book a week and ended the year having read 48 books. Given that a few of the books were significantly denser academic ones I consider that close enough.

The two best work books I read were Management Lessons from Mayo Clinic and Freedom from Command and Control.

Management Lessons from Mayo Clinic is an in-depth look at how Mayo Clinic works and the service mentality that’s embedded within their operations. I posted some high-level notes over here. If you work in any kind of service team it’s a worthwhile read. It captures in a more structured and easy-to-name way some aspects of effective service that you likely already intuit.

Freedom from Command and Control covers how to apply ideas from Toyota’s production system to service teams of all types. John Seddon is a consultant and covers a bunch of case studies and models for how to evaluate service team performance. Reading it got my mind working more than any service industry book in recent memory. As an aside, it’s $50 on Amazon so I’d generally recommend reading it only if you can find it at a local library. The first two-thirds of the book are fantastic. The last third is more of a rant by Seddon against certain standards bodies.

On the fiction side of things my favorite reads were when I branched out from the science fiction I typically read. Pachinko, Into the Distance, and The Sympathizer were three great ones.

I also refreshed my main reading list to start logging things as I go through 2019. I have a vacation coming up over the next week and a half so that list will grow quite a bit by the end of the month.

Thinking in bets

As a kid I’d occasionally watch World Series of Poker events on ESPN. During the broadcast they’d show the percentage likelihood each player had for winning the hand. I remember thinking, “How in the world do players remember all of this information…”

It certainly didn’t occur to me that some of the betting strategies players applied would also be effective in the business world. That’s part of why I found Annie Duke’s Thinking in Bets a worthwhile read. Duke is a professional poker player and her book is a guide to making decisions within uncertain environments.

She views a bet as, essentially, a decision about an uncertain future. To make effective bets we have to learn how to separate outcome quality from decision quality. The quality of our decisions is all we’re able to control. Yet we tend to evaluate our decisions by their outcomes; if the outcome is good then we made a good decision. The problem is it doesn’t work that way. A bad outcome can stem from a logically sound and effective decision.

Duke doesn’t advocate that we try to change this cognitive tendency through willpower alone. She holds that our capacity for deliberative decision-making is already maxed out. Instead she frames it this way:

The challenge is not to change the way our brains operate but to figure out how to work within the limitations of the brains we already have.

A path toward better decisions is to leverage our competitive drive to change our routines. We can change the features by which we compare ourselves (e.g. work to be the best credit giver rather than work to receive the most credit).

If we approach the decisions we make as bets then we can explore alternative reasons for why a given outcome came to pass. If we dismiss another’s good outcome as simply luck then we close down opportunities to learn from their expertise and skill. And it’s those lessons that we can apply to our own decisions.

A big part of what helped Duke in her career was having a decision group to deconstruct and debug situations with. It’s the Mertonian values of such a group that matter most. As she writes:

As a rule of thumb, if we have an urge to leave out a detail because it makes us uncomfortable or requires even more clarification to explain away, those are exactly the details we must share. The mere fact of our hesitation and discomfort is a signal that such information may be critical to providing a complete and balanced account.

Support Operations Webinar

At Automattic we recently started building a support operations team. We’re wrapping up hiring for a Director-level position and will add a handful of roles within the team after that. Formalizing this work will help us strengthen many of the behind-the-scenes processes that power our support. It’s been a great learning process to go through as well.

Later this week I’m joining the fine folks at Help Scout along with pros from SmugMug and FreshBooks to chat about how we’ve built our various operations teams. We’ll cover how we structure our teams, why we started building them, and more. It should be a great conversation!

You can find all the details for the webinar on Help Scout’s site. It’ll also be recorded, so if you can’t make it live they’ll send you the recording if you sign up.

New Hampshire

Last month Leah and I spent a week in Plymouth, New Hampshire. It was more of a work trip than a vacation. But we did take advantage of some perfect fall weather to hike the Welch and Dickey Loop Trail. A great trail with some views over the surrounding valleys.

Stressful customers

In support we often write to confused and frustrated people. After all, they likely got in touch with us because they’re confused and frustrated with our products. That’s okay, we’re expert communicators. We can help them get set up.

One thing we can do as part of that is not presume a customer is “abusive” or “rude” or “unreasonable” at the first mention of profanity and frustration. We want to resist our first impulse, which can often be to admonish the customer on their tone. This will more often than not aggravate their frustration.

Instead, when confronted with a profanity-laden message, our first instinct should be to give the customer the benefit of the doubt.

We must treat their frustration as a signal that we should invest more in our understanding of their situation. We need to pause, step back, and focus on the issue at hand. That means fully understanding the history of their interactions with us and their issues with our product.

It also means keeping the conversation focused on resolving their issue. We can recognize their emotion without condemning it nor playing into it. Every person we interact with is, well, a person. We all have moments when our frustration gets the better of us and we’re harsher than we mean to be with a company.

I believe our role in support is to help people be successful. And to see every conversation as an opportunity to change someone’s impression about our business and our product. Even the angry, profane, and ALL CAPS people deserve our help. After all, it’s typically our product or our missteps which have pushed them to frustration. That’s alright, our world-class communication can turn things around.

Replacing Instapaper with Pinboard

After Instapaper’s odd GDPR-related decision to (temporarily) block EU access I decided to re-evaluate what tool I use for my reading list. I’ve used Instapaper every day for the better part of a decade but something about their recent decision didn’t sit right with me.

I’ve had a Pinboard account since 2009 and decided to try it as a read-later tool. So far so good. If you’re interested you can see what I’ve recently read here.

The import process to Pinboard was a bit of a pain. It’s supposed to be automatic but for some reason my export files weren’t importing. I didn’t have that many articles in my backlog, so I ended up migrating these manually.

On the settings side Pinboard has a bookmarklet you can add to your browser for one-click article saving. I also set it up to mark everything as private by default. That gives me a private to-read list and a public already-read list.

iOS is where Pinboard is the least competitive with Instapaper. What’s worked well enough for me is the Pinner app (on both iPhone and iPad). That makes it easy to read articles through Safari’s reader mode. Plus it’s then much easier to turn articles into bookmarks. The main downside is that there’s no offline storage, though I rarely used that with Instapaper.

The bonus feature is that Pinboard has, for a fee, built-in archiving. For $25/year it will crawl every bookmark you add and save a cached version for as long as you have an active, paid account. It’s a nice protection against link rot.

Kauai

Allerton Gardens.

Leah and I just got back from 9 days in Kauai. This was our second trip to the island and we enjoyed it just as much as the first. On the activities side of things we went for a hike along the south shore, did two intro SCUBA dives, and more. Plus, this was our view for the week. No complaints.

I also read my way through 5 books: Leonardo da Vinci by Walter Isaacson, Museums: A Visual Anthropology by Mary Bouquet, The End of Average by Todd Rose, A Guide to the Good Life by William B. Irvine, and Anathem by Neal Stephenson.

I recently joined Fletcher Richman on his new Support Leaders podcast to talk about Automattic’s support team. The episode is live now. It’s a quick 38-minute listen where we talk about how I came to work in support, how we work at Automattic, and some of my favorite books.

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.

Lisbon rooftop

View this afternoon from the rooftop terrace at TheHouse in Lisbon.