At Increase, we open a shared Slack Connect channel for each new customer (and prospective customer). Our engineering team is a part of the channel and whoever is on-call responds to customer questions directly. We don’t have a traditional support team; the same engineers who build the system also operate it and support it.

A customer recently asked us about adding support for voided checks to our API to help demonstrate account ownership. At most companies, that request would have gone to someone in Support or Customer Success, then added to a queue of potential feature requests. In this case, the engineer who owns our Check Transfers product was able to gather additional context in real-time, iterate on the request with the customer, and push the new API to production the following day.

“With Increase, we have high confidence that systems are running smoothly. And if something goes wrong, we can quickly drill down into the issue and act before it affects payroll. This level of control has been critical for us.” - Andrew Brown, CEO at Check

This is a natural extension of our model of empowered owners, where the person responsible for a given feature (usually an engineer) is responsible for the full stack of ownership and decision-making, from the underlying network integration to the product design to the sales and support of that feature. We believe in giving our employees the context and the agency to fix, tinker, and build.

When you send us a note in our joint Slack channel about something that’s broken, needs improvement, or needs to be built, you’ll talk directly to an Increase engineer. We think this matters for a few reasons:

Lack of translation

When customer feedback travels through layers of support, account executives, product managers, and engineers, each step adds latency and subtracts fidelity. Talking directly to the owner gets our customers faster, better answers, and lets us move more efficiently as an organization. When a traditional support team is receiving questions and bug reports, they’re often incentivized to find workarounds for defects and bugs in the name of closing tickets. When the engineering owner is receiving them, they’re incentivized to fix the bugs and improve our documentation.

Tight feedback loops

Our product spans complex systems and serves demanding customers. Feedback is oxygen to us. If we ship a feature that generates pain or confusion for our customers, the person responsible for it will feel that pain viscerally and immediately. This acts as a self-regulating mechanism - engineers can’t afford the support burden that shipping subpar work will cause them.

Nuanced conversations

In many cases, the questions we receive involve a lengthy back-and-forth. The US depository system is powerful and complex. If you’re not talking to someone with a deep understanding of the systems at play, you may not get the answers or resolutions you need. It helps to talk to experts who operate in complex systems because they can connect the ways your use case fits into those systems.

“I appreciate your decision to have an engineer serve as the equivalent of an account manager. I know it’s not an easy decision, but it makes a big difference for us. There’s no customer <> AM <> engineer loop, and it feels like the answers come straight from the source of truth.” - Perry Zheng, founder and CEO, Cash Flow Portal

Ultimately businesses come to Increase for access to speed, transparency, and reliability. We feel that should be as true when working with our team as it is when working with our machines.