Using Rhetoric to Amplify Your Message

I really enjoyed this article from Eugene Wei about the power of rhetoric. He cites the perennial question:

Walk up to anyone in the company in the hallway and ask them if they know what their current top priority or mission is. Can they recite it from memory?

He provides examples of how Jeff Bezos uses rhetoric to emphasize his mission and vision at Amazon. His continued use of the phrase “Day 1” is a prime example. You can read about it in his latest letter to shareholders. “Day 1” is so familiar to readers and team members at Amazon that it needs no explanation. Bezos has boiled a way of thinking and acting down to one expression.

Eugene elaborates on why it’s important to think about phrasing when discussing your mission.

Why Remote Work Can’t Be Stopped

Automattic and a few of my colleagues were recently featured in an article on the Wall Street Journal titled “Why Remote Work Can’t Be Stopped”:

“…data indicates that the remote-work trend in the U.S. labor force is inexorable, aided by ever-better tools for getting work done anywhere.”

I’m a huge proponent of remote work, and I do think it’s the future of work in many industries (not just tech). The tools are improving at a lightning pace removing the disparities between in-person and remote collaboration.

One piece of the article I disagreed with is this quote from Steve Price, chief human resources officer at Dell:

“Engineering, leadership, R&D, sales and customer support—those are roles that don’t lend themselves very well to remote work.”

I lead a remote customer support team so I check two of those boxes. I think there are many processes you can put in place to solve the leadership piece for remote work. In no particular order:

  • A consistent approach to one-on-ones that encourage accountability for both parties. I just switched to using Lighthouse for managing these.
  • Weekly all-team hangouts with rotating call lead responsibilities. Longer team calls every quarter to cover goals and reevaluate how we work as a team.
  • A consistent process for tackling feedback including feedback for the manager/lead from the team (I wrote about leadback surveys here).
  • Non-work related hangouts to encourage team bonding and camaraderie. I wrote about how we do this here.

By the way, we’re hiring. Come work with me!

The Irrational User

Alvin Hsia breaks down some of the most popular cognitive biases and how they can play into product development:

Cognitive biases arise when a mental shortcut generates an incomplete or inaccurate judgement.

He references Kahneman’s Thinking Fast and Slow, which I would highly recommend. Things like loss aversion and negativity bias (he covers both)are important to think about in terms of user experience.

Pairs well with an old post I wrote: How to use science to make better decisions

Hierarchy of Engagement

I recently came across a presentation from Sarah Tavel at Greylock Partners titled The Hierarchy of Engagement. It’s a talk she gave at the Habit Summit. The purpose of the hierarchy is simple:

As companies move up the hierarchy, their products become better, harder to leave, and ultimately create virtuous loops that make the product self-perpetuating.

A photo of the hierarchy of engagement

She provides a great breakdown of each step. I found it very interesting to read and then think about the products we’re building at Automattic.

In particular, I’m thinking more and more about step 2—retaining users. Sarah lays out two elements key to getting users to stick around:

  1. Accruing benefits – The more you use the product, the better it gets.
  2. Mounting Loss – The more you stay with a product, the more you have to lose by leaving.

She uses Evernote and Pinterest as examples of both accruing benefits and mounting loss. Another I would throw in that mix is Spotify. The personalize Spotify with things like custom playlists, the harder it is to switch to another service like Apple Music. I have to believe that “Creating a playlist” is in Spotify’s “Day Zero” strategy.

Day Zero: A new way to define customer success

Day Zero is the minimum set of tasks a user must complete before they realize the full value of your product. Customers that don’t reach Day Zero are more likely to churn because it is harder for them to see success.

I’ve been thinking quite a bit about churn recently and how it relates to customer support. This article on the Intercom blog broke down a pretty interesting concept—Day Zero.

The underlying idea is to identify a handful of actions that are crucial to a customer’s success on your product or platform. Once customers complete these actions, they’re much less likely to churn. Once you’ve identified these crucial actions, your goal is to get each new customer to complete them as quickly as possible after signup.

day_zero_inline_01
Photo credit: Intercom

For anyone interested in building products and minimizing churn, I’d highly suggest giving this article a read!

Management in Ten Tweets

Mark Hedlund dropped some thoughts on Twitter that I’ve seen re-shared quite a bit. It’s titled Management in Ten Tweets and contains a lot of awesome, actionable pieces for leaders.

Reiterating the first tweet, “Management is hard. Doing it well matters.” I would also add that investing in yourself and learning how to improve as a leader matters as well. Leadership is not some innate skill you don’t have to work on. It takes work. Read about it. Learn from others. Share what you’re learning.

Sidenote: It was also my first real exposure to Moments on Twitter. Seems like a pretty interesting concept (WordPress supports embeds automatically—awesome).

How I’ve Managed to Grow My Career Without Managing People

So I kind of just made it up as I went along. Instead of trying to map out a career path and worrying about where I was going to be in five or ten years, I followed my interests and tried not to worry too much about measuring my success in traditional ways such as title changes and promotion announcements.

I enjoyed this read by Pamela Vaughan on career progression. This sounds similar to how career progression works at Automattic as well. Team lead positions are not viewed as promotions, just a different type of work. Teammates can step down from a lead position without it being viewed as a demotion. There also isn’t a corresponding decrease of pay.

Bots versus humans in support

There’s a lot of talk about using computer bots for customer support at the moment. Bots and A.I. are the new thing and garnering quite a bit of media attention. This article from Paul Adams on Intercom summarized many of my thoughts:

Bots have serious limitations, but it is exciting to think that bots can help in win-win situations. Sometimes we don’t want to talk to a human – we just want a quick answer to a simple question. For example, bots can deal with all the repetitive questions sent to customer support teams, which frees up support staff to answer much higher value queries. The effect of this will be that support teams will shift from being perceived as cost centers, to being seen as increasingly strategic assets to successful companies.

Paul lays out some pretty sound reasoning why bots won’t put humans out of business for customer support in the near future. Humans excel in areas where bots fall short, namely empathy. Humans know what it’s like to feel upset or frustrated and when to go the extra mile for a customer.

Bots are going to get better, far better than they are now. Down the road, a bot could be indistinguishable from a human in chat conversation. The future that Paul outlines, where bots and humans work together to provide amazing customer support, is one I can subscribe to. Rather than building bots to replace humans, build them to amplify what humans can do in the context of support.

Want more?

Photo credit: Intercom

Know Thy Time

Although the title of this post is influenced by Drucker (again), I actually want to share two articles I’ve come across recently on time management and “time reflection” (if that’s a phrase).

The first is by Julie Zhou on Medium—What do I do at work all day? I always enjoy reading about how other individuals manage their time and get things done.

If you asked me What does a normal day look like for you? I’ll probably rattle off some vague answer about spending half my time on product and half of my time on operations (recruiting, 1:1s, etc.)

I have no idea if this is actually true, so I decided to do an audit of my calendar.

The second is from Chris Bowler about a process for consistent weekly reviews.

A good weekly review should less about what your overall list of responsibilities and more of a review of what you’ve just accomplished in the week past and how you’re going to get closer to your most important goals in the week to come.

I’m going to incorporate a good bit from Chris’ post in my own weekly reviews this week.

Write Code Every Day

This was a cool experiment to read about by John Resig and something I’ve definitely struggled with myself:

There were a few major problems with how I was working on my side projects. I was primarily working on them during the weekends and sometimes in the evenings during the week. This is a strategy that does not work well for me, as it turns out. I was burdened with an incredible amount of stress to try and complete as much high quality work as possible during the weekend (and if I was unable to it felt like a failure). This was a problem as there’s no guarantee that every weekend will be free – nor that I’ll want to program all day for two days (removing any chance of relaxation or doing anything fun).

I particularly appreciated this comment about the GitHub code streak. I’ve often used that as an outward indicator of success in the past, which has proven to be more stressful than helpful:

I think that’s the most important take away from this experiment: this is about a change that you’re making in your life for yourself not a change that you’re making to satisfy someone else’s perception of your work.

Something I’m thinking about more this month as I move towards the goal of hitting 20 hours coding.

Featured illustration credit: Steven Resig