Technical Hospitality
This post explores how at Sanctuary Computer, we’re building an empathetic technology company through hospitality learnings and thoughtful client experience.
—
Since our inception, we’ve been passionate about designing a style of client relationships/workflow that is inherently different to what people have come to expect when working with technical shops & contract developers.
We run Sanctuary Computer more like a Restaurant than a Development Shop. We carefully curate every aspect of the client experience, down to our comfortable email style, non-technical change logs and friendly metaphors.
Of course, we’re super passionate about open source, and for that reason, we want to talk openly about our style of business, and hopefully learn from the response of our community.
In 2016, we’re still selling snake oil
—
At Sanctuary, we’re all really excited about all of the great things happening in web development these days. Between React Native, Ember CLI, Elm, Redux, Elixir Phoenix and Hapi.js, there’s a lot of fantastic new tools to use, and interesting new coding styles to explore.
The fabric of the web is changing rapidly, and it’s important for the shared success of our clients & company that our work is of a high visual and technical quality. As the tech moves forward, it’s clear to designers and coders why a project might benefit from a modern tech stack.
When discussing your work with clients (prospective or current), it’s tempting to explain the technical minutiae in great detail! After all, you want the client to fully appreciate your work, right?
With the talk of Single Page Applications, Universal Rendering and Tree Shaking Build Tools, it’s virtually impossible for a non-technical client to actually know what you’re doing.
The code world of 2016 is more alienating for a client than ever before.
We’re responsible for guiding our clients through this confusing world, and for that reason, we should be doing everything we can to make that journey as simple as possible.
Technical Hospitality for Dummies
—
Communication with our team is effortless for the client.
Our emails are short & as simple as possible, light and breezy, and use images to explain complicated notes. In discussions, we listen more than we talk. When we talk, it’s mostly on high level strategy, direction and big picture stuff.
We communicate delays as early as possible, we give our clients a simple process for reporting bugs, and respond quickly about when (not how) they’ll be fixed.
Our clients feel like we can solve their problems with simplicity, rather than complexity.
When we explain how we’ll approach a project, it’s most useful to talk about other work we’ve done in the space. Giving a client social proof that you’ve solved a similar problem paints a clear and relevant picture for everyone.
We find that when we have a tactile example of a similar problem, the conversation yields richer information sooner. At that point, we’re not convincing a client we can solve their problem — instead we’re talking about details that really affect their business.
We ensure that our technical language is accessible, digestable, and easy to understand.
It’s easy to forget that even the more simple things in your workflow can sound foreign & alienating. Whenever we use a technical terminology, we take care to explain the more confusing parts.
When explaining those abstract pieces, metaphors and whiteboard squiggles go a long way. When that detail makes a big difference to the outcome of the project, our clients really appreciate our patience.
Of course, we work with a sliding scale of curious clients. If they have a developer-friendly designer, or just like to know how stuff works, then we’re down! Some people see working with us as an escape to what they’re used to doing day to day, and in those cases, we’re happy to really go deep. That style of collaboration really brings great results.
We work to lower the amount of organizational work our client needs to do on their end.
Our clients pay us to work with them. However, when working with us becomes a brain drain, our clients won’t remember the experience as simple and painless.
To keep the cognitive load down, we batch up our questions, and ask them once. Our client on-boarding is always in person. We ask them to speak out loud, and we take a lot of notes. We let the client send through information in their own format, and we structure it on our end.
When our client is talking, we listen, and listen hard. Our job is to read their mind, not steer the conversation.
When our customer is presenting their ideas, we encourage them talk. Not only do humans love to talk, we’re able to get a fuller understanding of what they really need the more we listen.
This piece is really important.
The better our understanding of the subtleties in the problem space, the more we can “read our client’s mind”, and thus ask less questions throughout the build.
When we’re able to perfectly execute on a client’s vision (and hopefully then some!), without nagging them with little questions during the process, they’re going to think our team is pure magic.
The magic moment, when a client realizes that we knocked their project out of the park, is what we’re working to achieve every day.
It’s a big deal.
If we’re speaking your language, and you’re looking for a great technical partner, say hi! We’re at Grand & Bowery in Manhattan, http://sanctuary.computer online, and hello@sanctuary.computer on email!
