Incrementally Changing

There’s a lot to be said for making huge, swathing changes.

Just getting stuff done. Finished.

It’s a little like quickly peeling a bandaid. In that doing it fast gets it out of the way.

Ripping away a bandaid limits the longevity of the immediate pain. And it gets you to at least one of your desired outcomes far quicker than the alternative. The downside is it can cause some collateral damage. A few peeled hairs, or perhaps something worse 😬

On the other hand, the slow steady peel causes less collateral damage, sure. But it takes a long time. And with that, the pain lasts longer. Sometimes you still get the collateral damage anyway. So you might as well’ve ripped the bloody thing off.

Over the past couple of months, we’ve made some huge, bandaid rip-type changes to our software. And there was definitely some collateral damage. I wonder, would it have been better to peel slower?

The content dashboard and text editor overhaul. The settings dashboard too. Two fast tears that led to some mixed responses. Some users loved the changes. Others not so much.

Some users were pretty vocal. It bruised us a little. While we might appear stoic, it still hurts. Deep down.

The thing is, I do get it. Massive, sweeping changes aren’t our usual thing. Not really. We tend to peel the bandaid definitely, but slowly.

Don’t get me wrong, we add new features on the regular. Some of them bring their own set of massive changes to the workflow. Like getting to the last bit of slowly ripping off the bandaid. Ok fine! I’ve destroyed that analogy.

But the point is, day-to-day we tend to ship incremental changes. And when I say day-to-day, I mean pretty literally!

Shipping Fast But Peeling Slowly

If you’ve ever heard me talk or write about our shipping culture, you might be a little confused here. Because I’ll often talk about how fast the product team ship features and fixes.

It’s true. It’s just they’re not always the big, showy things.

Now and again we ship bigger little things like a new integration or a change to a workflow. But it’s usually many many smaller things. Additions to features. Tweaks to the UI. Fixes turned around within hours of being reported. Frequent small but impactful changes.

Most of them are things that most people will never notice but make the user experience that little bit more special. And they take a bucket load of work from an already stretched team.

I think that’s one of the clearest parts of the HelpDocs mindset. To do things because they need doing, and they’re the right thing to do.

We don’t do grand gestures or make a song and dance out of things we ship either. Because we’d be singing and dancing all the time. And while a never-ending conga of HelpDocs announcements sounds fun, it’d get pretty old pretty quick.

We place pride in consistency. Consistently doing little things to make the experience a little better. Doing things carefully, but with purpose. Chipping away until we’ve transformed the experience without people actually noticing the changes.

It’s kinda cool when you think about it.

When the Little Things Take Their Toll

On the education and support side of things, doing the right this has led to a natural inclination to go above and beyond.

Thing is, I’ve come to realise when you consistently go beyond expectations, going beyond becomes the expectation.

And most of the time that’s unsustainable. 🙈

You see a lot of the support requests we get are to work on custom code of some description.

It could be anything from a line of CSS that hasn’t been formatted correctly, right the way through to a script that the user wants to make some massive change to their knowledge base.

Whatever it happens to be, I nearly always try to figure it out. Whether the user has asked us to or not.

And this is what’s unsustainable.

You see, I’m not a developer. Not really. I can find my way around CSS. I know enough HTML to be dangerous. And I can just about string together a half decent function that does not very much—all while making clever puns!

But a full-blown developer I ain’t!

What I am is constantly interested. Always have been. Eager to find the the answers to a problem. A solution that does a good job in a way that looks like it’s supposed to.

And not letting my inability to actually do it get in the way! 🙈

But that takes a lot of time. A lot of effort. And a lot of trial and error. Time spent researching. Trying out different methods and lines of code. Trying to cobble together some way of doing it that fits the customer’s unique use case.

Like I said, it’s unsustainable as we scale.

In fact it’s already unsustainable now, since we’re serving around 42 million requests a week.

42 million.

That’s 4,166 requests. Every. Single. Minute. Quick maths!

🤯

Luckily nobody told the support queue! Or maybe we’ve just got a kickass knowledge base 😄

The question is, how do we (I) replicate that level of going above and beyond as we scale?

The Question Has No Answer 😩

I’d like to say I have all the answers for this right now. The truth is I don’t.

As I find my way with the all the Customer Education stuff I can’t tell whether it’s becoming harder or easier to figure it out either.

Just when I think I’ve got a handle on what customers want and need us to bring them, we get a curveball.

No. Actually not a curveball. A barrage of curveballs. Like someone’s supercharged one of those tennis ball firing machines and set it loose. Vomiting tennis balls at a horrendous speed and my job is to catch them and make sure they’re not broken.

It’s difficult when you’re the only one responsible for tackling tickets. The only one with a direct link to customers. A responsibility to talk with them and learn from them, so that you can educate them the right way.

I’m hopeful that as we eventually grow the education team—for which we’re now looking for specialists, check it out!—the answer to this conundrum will become clearer. 🤞