Tag: buffer

Documentation, Support, and Customer Success


I’ve had a bunch of conversations recently around the role of documentation in hospitality on the internet. My friend and colleague Andrew posted about documentation recently, and of course my love for Buffer requires I point out their approach to documentation – documentation is such a big deal in support communities that we even have a conference dedicated to it.

When it comes to documentation, I am of two minds. Software development, especially code languages and learning code languages, involve a lot of documentation, and a lot of referring to documentation, and so forth. We need to recognize, though, that when we use code to build really awesome things, we are building those things for an audience who is perhaps not as steeped in a documentation-heavy culture.

Working in support for WordPress.com, I am grateful every day for the documentation that we have – for little things that folks can work out for themselves if they have a guide (like, say, a custom menu or static front page), and certainly for big things that are challenging even for me (intricate Theme setups especially).

Lately, though, I have been shifting my thinking on documentation. Part of this comes from doing some deep dives in our Google Analytics account for our docs, finally getting a real bite of how huge our docs base is, and seeing for the first time how much traffic they really get (about 60,000 visitors per day). Recently I’ve started to see documentation as a psychological band-aid, and as a sidestep to improved products. Here’s what I mean:

Docs as a Psychological Band Aid
When a member of our staff recognizes that we have a flow, or a feature, or some other piece that requires additional education, and they invest their time and brainpower in creating documentation for that flow or feature, we can breathe a sigh of relief, right? Now, when a customer asks about that flow or feature, we have a resource for them. That problem is solved. Here you go – read this. We’ve scaled. We can check that box.

The problem here, is that when ever we feel like that box is checked, we calcify our thinking on that issue – we think it’s taken care of. A question about X? Here’s our documentation about X. Especially in a company where staff feels overworked and understaffed (ie, all of them), this becomes the path of least resistance, which then becomes habit. A habit of deferring replies to documentation has two unfortunate psychological consequences: first, it calcifies us in a place where critical thinking no longer takes place. More on this in the next point.

Second, it (inappropriately!) shifts the responsibility from us, as hospitality professionals, onto our customers. It is no longer our job to create an excellent environment where they can accomplish their goals – now it is the customer’s job to read the documents we created for them – time spent in documentation is time spent not accomplishing their goals.

Docs as Sidestepping Product Improvement
Every support document is an admission that a flow or feature doesn’t Just Work. When we create a long series of nested documentation on how to accomplish something is an indication that something is hard to do. A great company makes its customers feel smart, safe, and powerful. Taking someone out of your features, out of your flows, out of the path to their success, to refer to documentation represents a point of friction, an obstacle.

If you want to take the principles of Growth Engineering and apply them to doing hospitality right at your company, take a look at the top search terms in your Support page. Take a look at how people use those documents. Those are break points, those are places where a document is acting as a band aid to a better UX, or a better product (in this, we could learn a lot from modern computer and video games, but that’s a post for a different day).

So What Then?
I don’t hate documentation. I think for a lot of use cases it’s necessary, and it can be done really, really well. I do think that serving our customers to the very best of our ability, however, means reducing our documentation, approaching problems with ownership and a critical mindset – not “Well why don’t they read the guide?” but rather “Why does embedding this require a guide?”

Documentation can be a great tool in the Internet Hospitality Toolbox, but it’s only a temporary stopgap – Docs should be the clamp that holds two boards together while the glue cures, not the permanent solution.

5 Arguments Against Salary Transparency


Or, SAO Thinks About Buffer, Part Two. Here’s Part One.

In chatting with folks about Buffer’s approach to salary (making not just the process of assigning a salary, but the final number for each employee) transparent both internally and externally, there have been some common arguments against it. I’d like to talk about them a little, and discuss my thinking about each.

You’ll recall from Part One that I think that the transparent salary system is a great one, though I would impress upon the skeptical reader that my primary philosophical approval is for the transparency of the process – the actual visible list of salaries at the end is, in my view, a pleasant side effect of a much bigger, and more important, piece. The process being transparent is really the lynch pin here, I reckon.

Here are some arguments I’ve heard against salary transparency, and my thoughts on them:

“I think salaries are a private and personal thing.”
I’d suggest that this is a cultural artifact that holds us back. Seeing how salaries are assigned takes something that is currently invisible, and makes it visible. The final numbers are much less important than the fact that the process that results in those numbers is visible and accountable – making the actual salaries visible is simply a check on that process, a verification that it works as intended and displayed. Invisible salaries (and salary assignation processes) open the door for unjust practices that have become endemic, and are likely often simply the result of unknowing implicit biases – women being paid less, minorities being paid less.

I think transparency around salary processes and final salaries may place some tension on our traditional ideas of what should be private, that is certainly true. But, I think that making them public and visible is much better for us, as workers and as a society that desires equity, in the long run.

“I trust our HR department to take care of that.”
That’s great! I also am lucky to work in a place where I truly believe that our HR department has the best interests of the employees in their hearts, and I trust them completely. That being said, I don’t have to trust anyone else I work with – because their work is visible and available and under review from the rest of the company. This black-box nature of salary assignation is not only bad for non-HR employees, it’s bad for folks in HR – it means that they can’t have open and frank conversations about issues that might concern them, it means they’re denied the usual diversity of perspective and insight from their comrades with particularly tricky issues.

As well, it’s worth noting that the Buffer system is entirely self-contained – the questions of salary exist entirely within a box of particular questions and qualifications. During interviews and salary discussions, it becomes much easier and less stressful for the HR staff – no more fuzzy edges or uncomfortable conversations. It’s all in the spreadsheet.

“This is a non-issue. If you’re happy with your own salary, then stay where you are. If you aren’t happy with your salary, then find a new job.”
This mistakes the final result for the process – the question isn’t about the particular salaries of employees, or my salary specifically, but rather visible assurance that everyone’s being compensated fairly. That’s it – whether or not I’m happy with what I’m paid has no impact here. In a more transparent system, I’d at least be able to ask questions about why I’m paid what I’m paid, and how to make moves in the right direction (“So, how can I move from Rookie to Journeyman?” etc).

“I have absolutely no interest in seeing salaries.”
I don’t think anyone’s suggesting that it would be mandatory reading – I’d be curious to know how many folks actually do review the pay sheet, internally, at Buffer.

“Public employers have had transparent salaries for a long time, and they’re famous for being inefficient and having stagnant promotion patterns.”
True as this may be, I think we can acknowledge that there is an essential and important distinction between government employees and folks working at cutting edge tech companies. New companies doing business in new ways bring all sorts of interesting iterations on longstanding traditions that can often bear excellent organizational returns – I’d argue that transparent salary assignation processes is a great example of this. Just because transparent salaries are a property of a class of organizations we do not want to emulate does not mean that it won’t really shine when we try it in a new class of organization. So, let’s do it!

What do you think? Do you have an argument against fully transparent salaries and salary assignation processes?

Buffer and Transparency: 5 Reasons Why this is Awesome


There’s this company, Buffer. They do some pretty awesome stuff; they help folks to take control of their social media presence, they operate fully remotely (just like we do at Automattic!) and they offer $1000 for employees who go on vacation – I obviously like that idea.

Buffer recently announced that their approach to radical transparency will also apply to salaries, and the process that defines them. I am very excited about this idea, and I think this is an awesome way to approach salaries. Here’s why:

Continue reading “Buffer and Transparency: 5 Reasons Why this is Awesome”