The opportunity to work with Atlas’ User Operations folks has been one of the highlights of my career at Stripe.

Some things that I think are worth stealing for other companies: https://twitter.com/theannagat/status/1323348428462661633

Organizationally: we did things a bit differently for Atlas. All team members, regardless of role or org, were in a virtual Atlas team. We sat together, met together, planned the product together, reported to same management most of the time, etc.

There was a real team identity.

This extended to User Ops, which tech does a lamentably poor job in many places in treating as serious professionals like e.g. engineers and lawyers. (User Ops is what Stripe calls the org that is generally called Support.)

Atlas would be unrecognizable w/o UO members’ work.

We set our aspirations very, very high. The internal bar was approximately “If a founder asks any question to [email protected] we get them a high quality answer unless we are legally forbidden from doing so.” (The tension in not providing legal advice at Atlas is a real one.)

This leads to many sticky wickets like founders needing handholding when a cofounder leaves the company, not because they need lawyerly advice but because they feel like they just got gut punched.

We spent many months together rolling with it, workshopping answers, trying things

A good deal of the product and offering development at Atlas was spearheaded by the UO team, from some of our work around taxes to the processification of YC app review to quite a few of the random delight moments.

(Some Atlas users may remember cakes for major company milestones. The overwhelmingly most likely thing that happened was a UO teammate saw your news or heard it from you and took to Slack with “I think this deserves a cake / card from the team.”)

The day to day of support roles is too-often unsung relative to the need for high bar and consistent execution. We tried to empower UO to do what was necessary to help users, which often involved going to bat behind the scenes with various parties.

“Find the backdoor and, if there is only a brick wall, a brick wall is also a backdoor if you’re sufficiently motivated” described some of the hijinx reasonably well.

I think we did a good job of waiting on standardization until we had a clear understanding of likely issues, true causes of load, etc, which kept up the quality bar for standardized responses and (importantly) got us lots of real time with community in early days.

(Standardization is one way to square circle of “Everyone wants to get a bespoke artisanal response from an expert to every inquiry, but nobody enjoys paying in 6 minute increments for it.”

People have great dislike for it done poorly, and most implementations are suboptimal.)

We still have our challenges with this, particularly with things like career progression for UO folks.

It’s rough saying things like “You can apply empathy, judgement, and operational agility to many problems in tech, but most advancement will not come from the ticket queue.”

(A central challenge in the tech industry for support roles is how do you square “If all you’ve ever done is tickets, you’re considered not useful for non-ticket things” and “There are a LOT of tickets to be done; mgmt counting.” Not solved anywhere; some improvements in places.)