New Developments is a series about internal tools and the people building them. This week, we talked to Soledad Pano, a developer, PM, and team lead at Auth0. Sole walked through how Auth0 approached internal tools for their support team, what the stack looks like, and how they thought about success.
I'm Sole Pano, I'm a product manager working at Auth0 in the service management and administration experience team. Auth0 is an identity platform for application builders – we basically make your login box awesome. Auth0's main headquarters are in Seattle, but we are a very distributed team. There are headquarters in like six countries. And I'm actually based in Buenos Aires, Argentina. There's an office here as well.
I have a technical background. I've been working in software development for almost 20 years and I joined Auth0 back in 2015 as a software engineer. It was a very small org at that moment, and it was small startup that was growing super fast. And in a couple of years, I was leading a team of like six, seven engineers that were part of the customer success org, and we're building both customer facing and internal tools to help customer success basically. By the time the team changed, my role also changed as I say that now I'm a produdct manager, working on a team that's not exactly the same, but we still own some of those internal tools that we built those early years, and we still maintain them too, of course.
When we started building these tools we were a much smaller company, and so there were things super important, like to automate as much as possible. We were part of customer success so these tools in particular were trying to help the customer success team make sure that our customers can adopt the platform and keep building on top of it. So there was a lot about automation for onboarding, helping in different parts of the customer lifecycle, maybe things related to subscription management, automation of internal tasks, a lot of visibility of what the customers were doing and essentially making sure that our customers can adopt the platform.
A lot of different tools, some related to customer subscription management, as I said, so a lot of integration with other systems like Stripe or Salesforce and managing the customer's environment provisioning and managing containments, like quotas, depending on their subscription plans. And in general other parts also of the lifecycle, like maybe onboarding, tools for helping our customer success team onboard enterprise customers. And then there were things related to automations, like trying to automate their workflows as much as possible.
We also tried to provide visibility. That's a big part of what we were building, for example: the support team needed to help customers with ticketing and make sure they have a way that's secure and compliant to see what's the configuration of a customer's environment is in order to help them.
In this particular case we were using NodeJS, MongoDB, HapiJS for the API and there's PostgreSQL, Rabbit, Elasticsearch, Redis, and then TypeScript, and on the frontend, React. We were also using Heroku for hosting the applications.
Not having enough bandwidth. We still maintain these applications. And we also own customer facing areas of the product, and it's hard sometimes to prioritize the internal tools. And, and also once you build it, you need to maintain it. And so, so that's definitely a challenge.
There's a lot of repetitive things, right. It's mainly, I don't know, sometimes depending on the obligation, sometimes there are things that are more like integrations with other systems and sometimes it's just okay :)
As we are not a fully focused internal tooling team, the bandwidth or the focus that we put and we can dedicate on each of them varies. For example, there are things that are non-negotiable, right? We are a security company, so security and compliance for us is super important. So in that sense, both internal and customer facing are the same in terms of meeting all the requirements from the security team. And compliance.
But then for the UX – for customer facing tools, we dedicate more time to usability tests and validate the solution. But maybe for internal tools, we build the minimum, whatever we can do fast to solve the issue. We maybe don't have the time as we wish for trying different options, testing, modulating, etc.
I think it depends on the company stage, right? Because maybe in the beginning you don't have the budget to build a lot of things that would solve the same problem. Also at the beginning, you have fewer requirements. Maybe you just need to send the customer a notification. You don't need to scale because you don't have a lot of customers. And so you just do it and you build it yourself and it's easy, fast, whatever.
But then as you scale, and as you grow, you have more requirements. Especially now related to security and compliance. There are many more customers you need to consider, more volume, right? And then your solution that worked stops working at some points. Should I refactor and rebuild everything or just pay? Now we can afford to buy these other products that will do it 10 or 100 times better than us.
And so I guess at that point, it's better to buy unless you need something very specific, but in general, I think as long as the product or the tool that you're buying is customizable, you're usually able to achieve the same results.
In this case, out customers are our own internal teams, right? It's like the feedback loop works perfectly because they just Slack you or tell you, hey, I have this issue with your tool or this looks great. So in that sense, it's better. I mean, you have a faster feedback loop.
And then on the other hand, how are we measuring success? Well, sometimes the success metrics are actually the same, right? Especially in our case, we are not a hundred percent internal or dedicated to internal tooling. So the success metric is always like tied to something we want to achieve for our customers or for the business. The success metric might be get a better NPS or customer acquisition, etc. And then for related initiatives, their solution might be internal or customer facing, depending on the case. And the success metric is the same.
Or maybe you need to do both: you'd build the tool, and as part of that is providing the support for our internal teams to support the customer. Otherwise the solution is not complete, right? That's the way we work. But there are things related to more specifically these things that I was saying like their workflow for managing subscriptions internally, etc.
So a customer success metric in this case is related to efficiency. And how much time our customer success team spends on the tool. And of course they might imagine there's more we can automate or ways to allow them to do their job faster and better.
We are hiring at Auth0! There are a lot of open positions in engineering, design, data and marketing. Go to auth0.com/careers and you'll find a lot of opportunities. We are remote first!
Reader
