Category: General

Metrics, Means, and Maps

As a younger man, I spent a lot of time reading and discussing philosophy.

In the end, I was most attracted to modern moral theorists like Rawls and Nozick, but like all Philosophy majors at the State University of New York at Binghamton, I spent some time with all of the greats: Plato, Aristotle, Kant, Descartes, Marcuse, Arendt, and so forth.

(In fact, in the forward of Anarchy, State and Utopia, Nozick describes what I think is the most perfect description of all professional academia, not just Philosophy. I’m away from my copy, but I’ll post the passage when I get home!) edit: I gave it its own Post!

I’m bringing this up because one of my least favorite philosophers to read was Immanuel Kant. I struggled with Kant, like I suspect many 20 year olds do, as his writing is so incredibly dense, and translated from the original German. One piece of his moral philosophy that stands with me is this: to behave morally, a moral agent must treat other humans always as ends in themselves, and never as means.

To be more philosophically precise, Immanuel says never to treat other humans merely as means, but always as ends as well.  So, it’s not necessarily immoral to treat another human as a means, so long as you keep them in mind as an end also. It’s a tricky bit that’s easy to forget. Kant, he’s dense.

One thing that we need to bear in mind, whatever department we’re working in, is that our metrics are necessarily abstractions, a means to a larger end. In this way our mindset needs to be like Kant’s – some things are ends, some things are means, and we should be intentional about which is which, and remind ourselves that the distinction is important.

A quote that came up a number of times at the Growth Hackers convention this year was this: “Be careful what you optimize for,” and that, too, points at what I’m getting at here.

Our metrics, our measurable indicators of success, must necessarily be abstractions from real life. 

By this, I mean, reducing churn by 10% is only a means to a larger end, and has to be considered in that larger context. What’s the real reason? Why do you, personally and as an organization, want to reduce churn? Maybe it’s because you believe you have a product that can genuinely make peoples’ lives better, so the more folks who use it, longer, the better off they’ll be. That’s great! Maybe it’s to make more money – that’s OK too. 

In either of these cases, churn reduction is itself only a means toward a larger end. Success with this metric points to a larger success, something that you’re maybe not equipped to measure, something like Customer Happiness or Success of the Business. We need to keep this in mind.

Another quote that’s on my mind a lot these days: “The map is not the territory.”

Our metrics are only maps upon which we build our assumptions and beliefs – the underlying terrain, the real territory of your customers and your business, is far more complex, far more nuanced. Remember that we use metrics because they are abstractions, because they take our complex world that is impossible to understand all at once, and break it into easier-to-understand chunks.

Our metrics are by design not the whole truth. They’re reductive because they must be – because only by reducing a complex concept can we hope to make meaningful decisions. If our metric were the whole truth, if the map were a perfectly accurate representation of the whole territory, it would be perfectly useless.

Measuring our work, and our companies, and our success or lack of success, is absolutely vital to the success of any enterprise in 2016. Choosing the right metrics, and bearing in mind that our metrics only represent one part of the truth, is the hard part.

 

Exposure Therapy and Building Expertise

Do you follow me on Instagram?

It’s not professionally very interesting (I try to save that for Twitter, and, of course, this blog).

In the description of my Instagram profile, I mention:

I live with The Doctor (a doctor), Mango (a baby) and Elmira (a cat).

The Doc is, more specifically, a clinical psychologist. We met in college – I was in graduate school for philosophy, and she was finishing her PhD. Our relationship is rich: we’ve moved across states, have a second kiddo on the way, and have successfully kept a Maine Coon alive (and very sassy) for almost a decade.

I count myself lucky because I learn things from the Doc all the time – she’s the closest thing to a genius that I’ve found, and has a gift of being able to share complex ideas in a way that overlaps with and takes on the character of the experience of the person she’s sharing with.

One idea that she and I have discussed at great length is an approach to treating anxiety disorder, called exposure therapy. Broadly, the big idea behind exposure therapy is that exposing a person to small amounts of something that makes them anxious (or stressed, or afraid), starts a process that can eventually help that person overcome the anxiety or fear at a larger level.

(I’m very likely butchering this concept by working in broad strokes – read the Wikipedia page, it’s good, and short.)

If, like me, you have an unhealthy obsession with Nassim Nicholas Taleb’s work Antifragile, you may have already identified that there’s a parallel here between exposure therapy (exposing someone to a small amount of what makes them anxious in order to help them become less anxious) and hormesis, the concept in medicine and (since Antifragile) economics, that shows us that benefits do not always follow a linear or even exponential path – but rather many inputs have a hyperbolic curve, where limited benefits can be found in one particular application, but then the downside becomes infinitely worse as the input is continued to be applied.

One example is water – in too-small amounts, lack of water will kill you. A somewhat narrow band of water application is ideal, enough so you’re not thirsty and are able to operate in a healthy biologically appropriate way. Once you exceed that healthy space though, any additional water will have more and increasingly horrible effects – pretty quickly leading to death and only death on down the line.

The mental model of hormetics is controversial: it’s not universally accepted nor is it universally applicable. In this case, it’s a helpful way to think about a bigger model for our otherwise more specific cognitive behavioral exposure therapy.

The reason all of this is meaningful is because it ties into a bigger question that I have about my life, and I figure some of you all do, too – how do we build expertise? How do we get better at a skill or practice?

The answer is, like in exposure therapy and in hormesis: with a little bit at a time. You don’t go from being horrified of public speaking to a keynote lecturer overnight: you have to create a plan, exposure yourself to the stressor in small amounts, building over time, and move toward your goal.

One point that I want to make very clear here is that executing this idea necessarily means pushing yourself out of your comfort zone – pushing a little into that uncomfortable place, and sitting there, working there, allowing yourself to survive and thrive though that low level discomfort. That’s how we get better. That’s possibly the only way we get better.

Recognize that both exposure therapy and the hormesis model agree: large jumps are not productive. Too much water will kill you. Start small, and recognize that you have to climb a ladder from the bottom – small steps, building on one another, is where change comes from and what makes things stick.

Once I started to think about exposure and hormetics in this way, as a mental model, it’s the type of idea that is very sticky, and has started to map onto my work in many other interesting ways. You can see how exposure therapy has clear parallels to things like delegation, helping your team build expertise, and even in customer relationships.

The next time you want to build your skills or hone your practice, ask yourself: what part is the scariest for me? What looks like it’s the hardest, most out of reach bit? Then, break off the smallest chunk you can, and attack that, and only that, until you’re comfortable. Then, get started on the next chunk.

 

Risk and Support in Leadership

Not long ago I had the pleasure of hosting an old friend in Saratoga (where I live).

Rob and I became colleagues first, by working together in high end coffee in New England, and then eventually friends.

Rob had worked in coffee longer than I had when I joined that industry, and is still a big part of the community in Providence. He was in my neck of the woods visiting clients of his – he’s a coffee trader these days, and sells green unroasted coffee to folks who turn that coffee brown and sell it to the general public.

Over wine and Hatties’ fried chicken, we talked. We talked a lot! We talked about family and career and what it means to live a good life. It was an excellent visit with a great friend.

One of the things that he introduced me to was the idea of thinking about leadership in terms of risk and support. You can imagine these two ideas as different dimensions on a field, like so:

Screen Shot 2016-07-12 at 7.53.10 PM.png

In a leadership position, the decisions you make will tend to fall into one quadrant most of the time – the way that we can think about these dimensions are in terms of how we work with our team.

Support here means, how well do you as a leader back up the members of your team?

When someone falls down, when something doesn’t work as planned, do you step in, do you take responsibility for the team? Or do you allow the individuals to face scrutiny and take the blame themselves?

If a member of your team tells you that they have a bold career plan, as their lead do you find ways to help move them along that journey, finding or manufacturing opportunities for them? Or do you nod, ask about their day, and let them try to find their own way with neither help nor hindrance from you?

These are both different ways that we can compare high support and low support.

Risk here means, how much risk do you allow or encourage your team to take on? Do you fully insulate them from the winds of your organization’s politics, content with their low amplitude day to day work? Or do you allow them to wander outside your team’s safest places and experience both the opportunity for great work and the chance of failure?

Risk and Support are not always absolutely good or absolutely bad – you can imagine a lead who exposes their team to great risk could create a terrible environment to work in. You can also easily imagine a leader who fully supports her team in all they do, but never offers up any Risk, which means the support isn’t ever really needed.

This is why truly great teams balance the two, and achieve a state of both High Support and High Risk – offering opportunity (and the accordant risk) when appropriate, and doing all they can to also provide support for the decisions made in pursuit of that opportunity.

As far as a guideline for leadership and leadership decisions go – I like this one a lot. I’ve been asking myself, “Am I allowing for some risk? Am I supporting bold choices?” 

This is pretty half baked on my end – there’s a lot here to consider (how much risk is appropriate? Can one over-support? What does high-risk low-support look like? What about low-risk high-support?

Have you heard of this kind of structure before? How does this gel with your own experiences, as a team lead or as a team member?

 

 

Collaboration Post with Help Scout

THx4YotnAO.png

Following my presentation at SupConf I had the opportunity to chat with some folks from Help Scout, a popular support software startup. They were great! They sponsored the photo booth, which is always a treat.

Since the event, I’ve had the chance to work with Emily, one of the members of the writing staff at Help Scout, and they’ve been kind enough to help me translate my presentation and following blog posts into a single friendly bite-sized bit of content. Plus – check out that illustration!

You can check it out here – Create Value With the Support Data You Already Have

Huge thanks to Emily and the whole crew at Help Scout – it was a treat to work with you all!

Support Folks: Don’t Confuse Your Problems For Your Customers’ Problems

I was talking with my lead, Andrew, about how software companies provide customer support – a standard topic for our conversations.

We ended up on a topic I hadn’t considered much, but it has resonated with me since.

The topic is the important distinction between your customer’s problems and your support team’s problems. 

Or, put another way: the difference between a hard product to use and a hard product to support. 

It’s very easy to ask a member of your support team: “What’s your biggest problem right now?”

They’ll likely reply with some combination of particular features of the product, maybe something to do with billing or receipts, and possibly something about internal communication (which virtually every support team has a 100% legitimate problem with, since virtually no tech companies communicate value well from the support team to the rest of the company).

Especially when we’re leveraging support teams to build more value into the product, the problem is: it’s easy to confuse support’s problem with the customer’s problem.

At the end of the day, the result should be the same: more value for the customer, right? If you solve a problem and it results in better support for your customers or a better product for your customers, well, everybody wins!

The bigger issue is that these two categories of problem have to be solved in different ways.

Consider this: if you’re running a web host, and you ask your support folks to list the biggest problem areas they encounter day to day. The number one reply across the board is “Domains.” 

You might be tempted to direct some UX or Product folks to run through the domain purchase flow, to check on accessibility or mobile friendliness of that particular part of your product – but the right move would be to ask more questions. Specifically:

“Are domains the biggest problem for our customers, or are they the biggest problem for our support team?”

You can see why it is so important to hash out the difference here, yeah?

If customers are struggling to purchase domains, or are struggling to use them correctly, that will take a particular approach – build some better flows, test them, deploy them, circle back to see if things improve.

If support folks are struggling to support domain customers, then you have a whole different job on your hands. Now you need to get into the thick of it – OK, what part of that support process is challenging? Where do you need more information but don’t have it? What tools can we build to make this process easier, faster, more user friendly?

These are questions that good support organizations need to ask themselves, too.

Too frequently we fall into the easy answer, to blame the edge cases, to throw our hands in the air as though our customers are mysterious beings with whom we have nothing in common.

What if the problem isn’t on the customer’s end? What if you struggle to support some part of your product because your tools aren’t good enough? The problem is not always with the customer, it’s not always with the product. Sometimes our own processes and approaches are what’s causing friction.

Next time you say to yourself, “Ugh, classic problem x with customers/our product” – take a minute, step back, and ask yourself: what’s the real problem here?