Friction R Us

Too many internal services have heavy onboarding processes

(Like this article? Read more Wednesday Wisdom!)

Here is one of my bigger frustrations in life: Internal services that have a high-touch and complicated onboarding procedure that takes too much time and effort.

The still increasing popularity of micro-services means that every piece of code that does something, anything, useful, typically depends on lots of other services. During the design phase you identify these and during implementation you need to do the needful to make sure that you can call them. That last process is not seldom fraught with unnecessary friction.

My ideal method for calling another service is that I go to their internal Wiki page, read up on the service, find a pointer to their API specification in the repository, download a sample client program in my favorite language, use a self-service tool to set up an account or a client ID or something, and then start calling them.

My second favorite method for calling another service is like the above, but instead of a self-service tool to configure the needful, I write a configuration spec for my client and then send that change to the owning team for a code review, after which I merge it into the repository and off I go.

My least favorite method (by far) for calling another service is when I have to file a ticket with the team that owns the service and then I have to submit documents, answer surveys, create more tickets, have meetings with product managers, wait for them to do whatever it takes to "onboard" me, and only then can I maybe start calling their service.

If that last method is your service’s method for letting new customers call you, your service is not very good, and the only reason people are using you is because they have to and there is no alternative. If there were an alternative that did not force the callers to jump through all sorts of hoops with your team, they’d use that every day and you’d be in the same spot as the dodo (meaning: An extinct flightless bird).

In Dutch we have a fantastic phrase for this phenomenon: "Gedwongen winkelnering" (forced patronage, akin to the Truck System which uses this concept to exploit and defraud workers). With “gedwongen winkelnering” you are forced to buy your wares from a particular (internal or external) seller. It is a common problem in many big companies. For instance I used to consult with a big bank and obviously we had to use their internal networking team for providing our Internet connection, despite the fact that they were not very good and did not understand basic things like DNS or SSL.

As is the case with monopolies, “gedwongen winkelnering” is not a recipe for quality. If your customers have no other place to go, it does not matter how bad you are. And since people are always ready to meet a low bar, your service will not be as amazing as I want it to be. “Gedwongen winkelnering" takes away the most important driver for quality and innovation: Competition. Why does Google Search rock? Because there are enough other search engines waiting to take their customers and it takes only one click to switch and never move back. Why does the DMV typically suck? Quite simply because there is nowhere else for you to go to get a driver’s license or to register your car. It does not matter how bad they are, either you deal with them, or you are not driving, which in the US means you are not going anywhere.

The question though is why the Swiss DMVs rock so much? This can probably only be attributed to the overall Swiss dedication to quality, which is probably caused by the general feeling that they are the last bulwark against the entropy that is raging south of the Alps. Also, even in Switzerland there are quality differences between DMVs. The fact that most Swiss rental cars are registered in the idyllic farm kanton of Appenzell-Innerrhoden is because the administrators there have decided to create a set of services that makes it very easy for rental car companies to register cars en masse.

In absence of competitive pressure, organizations often try to find a substitute through some form of synthetic pressure. In some companies I worked for, "Customer Obsession" is an important leadership principle and teams were constantly obsessing over the customer and worrying how to provide them with “delightful” experiences. However, being synthetic, that pressure is mostly meaningless and typically misguided. How can you be obsessed with the customer in absence of an actual customer? Sure you can talk about the customer a lot, write lots of documents with the word "customer" in it, and congratulate yourself with your customer focus, but customers don't fill out surveys, customers vote with their feet. Chop off their feet and you don't have any customers left; they have become beneficiaries of your benevolence. They are the ultimate captive audience.

You know what is an awesome customer experience? One where the customer doesn't have to talk to you if they don't want to.

Heavy duty onboarding processes are the wrong sort of customer obsession. You can maybe sell it as "white glove service", but it is just friction and a full employment plan for junior associate product managers to boot. Awesome service don't need it and don’t require it.

One of my previous employers sells a data streaming solution in the cloud (based on Apache Kafka). If you want to start using them, it takes about five clicks to get a URL to feed into your Kafka client and you are off to the races. If you like them and you want to scale up, it takes a few more clicks, and the input of a credit card number, but now you can start streaming in gigabits per second with full zonal redundancy. Want regional redundancy on top of that? Sure, just a few more clicks and we are there. You can turn their service into the backbone of your real time data processing without even emailing with them once. Eventually they might start noticing you and you might get an email from someone saying: "Hey, it looks like you're doing awesome stuff, can we help you with anything?" If you know what you’re doing you can safely ignore that email, though at that point I suggest you respond because there could be a nice trip with VIP experience to a data streaming conference in it for you.

That's how you do that. Confluent spent a considerable amount of time to come up with a new client onboarding process that has as few barriers as possible. You don’t even need to provide a form of payment to start streaming! That's how services get big: By providing an amazing and frictionless experience to their (future) customers.

Full transparency: I hold CFLT.

Confluent can offer that experience because their service has good documentation and a good internal architecture that was designed to withstand the random things that random (new) customers do.

What is true for external services is also true of internal services: If you need a high-friction onboarding experience, your service is probably not very good. My guess is that have not thought about SLOs, classes of service, rate limiting, billing, configurable dashboards, a cell strategy, your configuration structure, authentication, authorization, or really just about anything beyond the core functionality of your APIs.

You don't really need to know your average customer. You need to understand them, as a group, and you need to be obsessed with providing them a great service, but really the only way to know if you are providing them a great service is if they come back in the face of lots of credible competitors that they could go to without too much hassle. Everybody who is in a really competitive market knows this.

If the customer does want to talk to you, by all means, roll out the red carpet, but don't get in their way when they just want to start using your service.