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?

 

 

Pies and Waffles: Delicious Charts

I’m trying to catch up on my massive Pocket back scroll, and in surveying the massive and diverse landscape of its contents, noticed a few pieces all from the same site,  eagereyes, and all on the same topic, pie charts.

So, naturally, I read them. 

(As a sidebar, am I the only person who struggles with this with Pocket, or other content saving services? Am I coining the term “Pocket Zero” right now? Am I the next Merlin Mann? )

Here are the pieces – they’re all quite short, less than ten minutes reading, even if you do take in the discussion with Hadley Wickham in the comments section:

A Pair of Pie Chart Papers
Ye Olde Pie Chart Debate
Pie Charts
One thing I was surprised to learn was just how long the Great Pie Chart Debate has been going on – over a hundred years! And yet,  the pie chart lives on. 

It’s also interesting to me that,  despite their ubiquity in popular media, we don’t have a great sense of how or why we perceive pie charts the way we do – it makes me consider firing up the Doc’s eye tracker, just to see how eye patterns map onto different visualizations.

In this series of posts I was also introduced to the Waffle package for R, which makes it easy to put together a pie chart alternative which I quite like – like this:

It strikes me as easier than a pie chart to compare each of the pieces to one another, and indicates that each point is part of a continuous whole in the same sort of way that a pie chart does. 

I’m excited to play around with this package some in the coming days. I’ll have to dig a bit and see if it’s supported in Shiny yet!
 

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?

SaaS Companies: Stop Putting Support in a Silo

I get it – you’re busy. I’m busy. We’re all busy. We can all spend too much time praying at the altar of hustle. 

Here’s a quick tip from me to you: take ten minutes, stop reading the top stories on Hacker News or Growth Hackers. Stop scrolling through Quora questions. They’re all going to tell you the same thing:

Listen to your customers.

This message might come in different shapes and flavors:

“Find product market fit.”

“Conduct customer interviews.”

“Get out of the office.”

It all boils down to one simple necessity for any software company – but especially for recurring revenue Saas companies.  That necessity is this: gaining and maintaining a deep understanding of your customers, their problems in the world, and their problems with your product.

Don’t hire a consultant to do this for you.

You already have this understanding in your company, and it is entirely likely that you’re sitting on a gold mine of potential information. What’s blocking you from that information, that almost-guaranteed revenue boost, is not financial or technological.

It’s cultural.

When was the last time one of your Product folks sat down and asked your support team about their work?

You have an entire team of people who talk with your customers all day, every day.

It doesn’t have to be a formal process. It doesn’t have to be some sort of support veteran embedded in your Product teams  – although I’d recommend that.

Just go talk to them. Go ask them what customers are struggling with. They won’t necessarily be able to solve your problems, but I promise you they’re going to reveal to you points of friction, trouble areas, and parts of your product that aren’t even on your radar as costing you customers.

Because the fact of the matter is, if you have a large enough customer base, and you’re relying on them for recurring revenue, even small problems, small sticking points, semi-irritating workarounds, these are going to cause churn. Maybe not a lot of churn – but some. Imagine eliminating all of those tiny pain points. They add up.

First, you have to find them.

The good news is, someone in your company already has. Go ask them about it.