Scaling remote engineering teams like Auth0 with Damian Schenkelman of Auth0

Transcript

Ledge: Hey, Damian. It’s really cool to have you on. Thanks for joining the show.

Damian: Thanks for the invitation. It’s great to be here. Really appreciate it.

Ledge: Would you, if you don’t mind, give an introduction of yourself and your work? My audience is excited to hear from somebody with a platform that we love so much.

Damian: Sure. Thanks for that.

My name is Damian. I’m from Buenos Aires, Argentina. I have a typical XES background. Went to systems engineering school.

I’ve been working at Auth0 now for five years doing all sorts of of things. I worked as a software engineer, mostly in our backend teams at scale, authentication, billing. Then, over the past three-and-a-half years, I’ve been a Director of Engineering here and I’ve had the pleasure and have been lucky enough to work with all of our teams, almost. With our product teams, our infrastructure team. I’ve been all over the place.

Ledge: That’s cool. So much to talk about. You guys have grown so much and scaled so much.

Just in case somebody in the audience doesn’t know what Auth0 is, why don’t we just give them a product introduction, so the context is there when we start talking about deeper topics?

Damian: Definitely. Auth0 provides Identity as a Service. You pay a monthly subscription, you get to use our APIs, our SDKs, to make authentication and identity access easier in your application.

Let’s say you’re developing a mobile app, you’re developing a web app, any type of application, you want your users to log in. You want to know what they can do. We make that easy. We make it easy to enable identity providers like social providers, like Facebook, Google, enterprise databases like SAP, Oracle, Active Directory. We do all of that for you and we make sure that you have a very pleasant developer experience. Developers are our focus and that’s what we do.

Ledge: Yeah. I’ve heard it described as, you’re the Stripe of logging in.

Damian: We definitely strive to be that, yes. Again, the experience aspect is great. We also love Stripe. We use it in our product as well for our self-service offering, and that’s something that’s always big on our minds when we’re doing anything.

Ledge: You’ve seen a lot of growth in the company. You’ve been there a long time, and I’m interested – all of our listeners really like to know about scaling engineering teams, working remote so scaling remote teams, scaling products.

I know you talked a little bit off-mike how those are your passion areas and happens to be your job. Break it down a little bit on how that fits in your day-to-day.

Damian: As a director, scaling engineering teams is the biggest focus. You want to make sure that you have the right people on the boat. That they are on the right seats. That they have read the security manual. That they know how things work.

Especially, remote brings a whole set of challenges around creating informal communication environments, how you establish trust, awareness about how things are going. At the same time, of course all of the benefits around, you can hire for talent and not necessarily you are restricted to just one location. People get a lot more freedom in terms of how they work, where they work from and things like that.

There’s a balance there and putting together the right processes, the right practices, and more importantly as a base of all of that the right culture, is key.

Ledge: How do you do the culture thing remote? There’s so much interest from companies now that are trying to say, hey, we need to convert ourselves to at least remote-friendly and hybrid. That there’s not enough talent locally.

This is a global phenomenon. We’re seeing that everywhere. That people want to work in a remote fashion. I think companies want to get there but there’s a lot of confusion about, how do you make a great culture and how do you keep people productive from a remote context? What can you suggest there?

Damian: I think there’s that cliché phrase where, culture is what you do every day. That’s the reality. In our case it’s true.

When Auth0 was founded, our two founders were from remote locations. They lived, I think, four or five hours apart time zone-wise. They lived thousands of miles apart. The way they communicated, the way they worked – especially as we brought in the first set of employees – it was always remote first. There wasn’t a moment when you were on-site, at a meeting, talking out something and then you had people on your team missing out on stuff. That starts to spread.

The other big part is, again, sharing that culture in your processes, but also the most important thing, who you bring into the team.

There’s always a huge importance of trust whenever you’re bringing another person into your team. Especially in a remote environment, you don’t want to be getting people in that don’t want to be working there because there’s lot of instructions when you’re remote, and it’s important that people understand that it’s on them to make sure that they get the results done within their timeframe.

We don’t have any fixed schedules. We don’t do anything like that. It’s just a matter of managing expectations as a member of your team, and making sure that you deliver the important outcomes that need to be delivered.

Ledge: As a manager there, what are the best practices? You’ve got people all over the world, not even necessarily online with them exactly at the same time. How do you manage that, to show that the organization is moving forward and all align to the same objectives? It seems like that might be difficult in a context where you’re just not face-to-face with people.

Damian: Yes. Especially as you grow, and as you grow very fast, that become harder.

One thing that’s very common today, and I know lots of companies are using, are OKRs. That’s something that we’ve started using and it’s been very positive for us. It’s something we’ve been using for a year-and-a-half almost, and you see the improvements of how we are doing that every quarter.

Our executive team gets together, defines goals for a year at the beginning of the year. Then, each quarter, we cascade those down and we try to make sure that we are aligned to those goals. Whatever we’re doing, whenever we’re planning to do something, we try to keep those things in mind – make sure those are there.

Then it’s about repetition and using the right tools for the right job. In our case, we use Slack for communication. There is a lot of communication there but over time realized, especially for more technical matters, that it’s not a very good design decision tracking tool. So we would be like, hey, why did we do X, why did we do Y with this component? No idea. Some people might remember a message from like two years ago and link to it.

We started putting some processes and tools in place to help with that. For example, there’s a very good set of blog posts from Juan Pablo Buriticá, who is VP of Engineering at Splice, about using RFCs internally within your companies – similar to what you’d in an open source model – to model design decisions and keep traceability for that. We encouraged that because it’s very good for remote collaboration.

There’s also another huge thing we do which is, again, not hard to do, it’s just very important and has a lot of impact, which is doing one-on-ones. Each manager does one-on-ones frequently with their reports. They talk about things. Not a status update – that’s the important thing. They talk about things like their career. How things are going to the team. How we can get better concerns, things that are coming from the company. You put in this both async and sync communication channels that try to maintain that alignment and make sure that people understand why we’re doing things, what’s our base, what are our values, and not just being told what.

Ledge: Right. Now, that’s a bunch of cultural and team stuff that seems like it’s really the foundation. I imagine you’ve had to do those things, and do them well, because your product has grown so tremendously over the last few years. I think I read it’s some billions and billions of logins that run through your system.

You’re a critical upstream provider and people are literally saying, hey, no one can get into my app or my business at all unless Auth0 is up. That’s a lot of pressure.

Damian: Yes, it’s a lot of pressure. It’s also the very interesting part of the job. You know you have to be up, and we build things with that knowledge in mind. It brings, of course, lots of very interesting challenges about how we do things, how reliable we have to be.

Not only that. As you were saying, lots of customers use us, all of them have different use cases. Auth0 is a platform, an extensory platform even. That means that different customers have different usage patterns. They use us for different use cases, different things. We just have to make sure that we can account for all of them and we can be up for.

Ledge: What do those practices look like? Are you arranged in product teams, or with a value chain or particular kind of objectives that tie together there? Everybody can’t work on everything, so how have you broken down that critical service that you provide into human units that can get stuff done?

Damian: That’s a great question. This is something that we joke about internally because we revisit this, whether things are going well or not, every nine months more or less. Mostly because of the nature of our growth.

We’ve been doubling the amount of people in our product engineering over the past few years, and you just can’t do the same things you used to do.

At this point, what we’re doing is we have different what we call domains, which are multiple teams grouped together under the same single umbrella or idea. We have, for example, identity and access management as a domain, and that has multiple teams under that. One of them that deals with the API protocol part. Another one that deals with the whole login flow from a visual perspective. Another one that deals with authorization aspects.

We have a model where each team has a product manager. It has a designer. Then there’s a group of engineers or a manager – a tech leading general of engineers under that. We try to keep them as autonomous as possible. That’s why we form those teams like that.

At the same time, there’s the opposite part of that which is the responsibility. You are autonomous. You have freedom. You can decide. You get the goals and you figure out how you’re going to contribute to them, but teams are on call for their own services. Teams are responsible for hitting their SLAs. That’s how you balance that freedom with that level of accountability that we need to bring a service like Auth0 to.

Ledge: I love that you said that. Balancing freedom and autonomy, also with performance, because autonomy can be a double-edged sword. If you have everyone being fully autonomous and not aligned, you’re going to end up with a lot of stuff that’s incompatible. You’re going to introduce technical debt. Even service-to-service and team-to-team, they’re not going to be able to communicate. There’s going to be a lot of organizational friction there.

Particularly as you’re growing, if you’re doubling your headcount, there’s just so much communication that needs to happen. What have been some best practices there that you’ve had to change as you have gone through that doubling and redoubling?

Damian: I think there are two big aspects to this, and they’re somewhat intertwined. One of them is, a lot of this is the job of management. Team managers, directors who managers report to, even our VP of Engineering, there’s constant communication happening.

For example, our VP of Engineering sends weekly or bi-weekly – depending on the week or the month – communication to everyone, hey, these are things that are going on. Then we meet together as all directors from product, from engineering, from design to say, hey, these are the things that are happening, let’s make sure we cascade this.

It’s about repeating the message. Making sure that people understand. Keeping the communication channels open. A lot of what’s happening is about moving fast, adjusting to learnings and aligning. It’s not necessarily about having a plan and just sticking to that plan.

Then there’s another huge aspect which is the standardization, not just through process but through tooling shared practices, common infrastructure. What many refer to as a . How do we maximize our component reusability, our speed, by using components built by one team in multiple teams so that we don’t have to, as you said, reinvest in the same things, increase the amount of duplication in our code, increase our tech debt or risk in our code base as it is?

This is where that nine-month figure changes things over time, because things change and you have to adapt to the new challenges. It used to be, hey, we could handle this with this different org structure, but now the needs have changed. We need to make sure we can adapt so we’re going to do some reorgs, make some changes, and get ready for Auth0 next .

Ledge: It’s interesting you’ve come up with that nine-month number on your own. I recently interviewed Will Larson from Stripe, and in his new book he talks about the six-month number. The pace at which you’re doubling the size basically means that every six months you are planning for another organization. The flipside of that is that we now don’t have any plans that will work for the company six months from now either.

You’re constantly on this treadmill where you’re trying to figure out, who are we going to be, which is different than now, which is different than who we were before? Making processes that are at least durable enough and flexible enough to get there.

It’s a huge challenge to organizationally engineer that, and that’s before you ever wrote a line of code.

Damian: Yeah. That’s why the key, at the end of the day, is people. If you are successful, you’re always going to be catching up. Be that the quality of the code you wrote is no longer holding it because that algorithm you wrote a couple of years ago now has thousands of customers instead of ten, so now it’s not working. The same thing for the org. You’re going to put processes in place, communication practices in place, but you need good people. People that are aware of the need for change but also can adapt so that they can always bridge that gap between your current process, your current situation, and your actual needs.

Ledge: Absolutely. What have been some of your personal best practices when you sit in the seat? You mentioned moving up from software engineer to now a director. I’ve talked to a lot of leaders who came through the engineering path, which is reasonable, and yet being a leader in the engineering org is so different than being a line engineer.

Some people love that and some people don’t. How has that experience been for you?

Damian: That’s a very interesting topic. I’ve seen people do it differently and I haven’t myself said, oh, this is a better way because of this, or this is a worse way because of that. It’s just people have different styles. They process different types of information more effectively.

In my case, because I like the technical aspects of what we do a lot, because I’m very much interested in the scale of our systems, I like to stay in touch a lot with how we’re doing things day-to-day. I keep a very open channel with people on the specific teams to figure out, hey, how are things going. I read a lot about what’s going on. Try to write as little as possible, because as a leader you have lots of influence and what you say might be taken as the thing to do, and that’s what we want to avoid.

Trying to stay aware of what’s happening with the teams you work on but, more importantly, building those relationships, those awareness channels that feed you, hey, this is what’s happening with other things.

My job now, at the end of the day, is providing the right context. So I need to build relationships with my director peers across of engineering. I need to build relationships with people outside of our organization, like security org and product and sales and marketing.

Making sure that we are constantly, as leaders, giving the people in our organizations the latest on what’s happening. A lot of that is like, hey, we’re looking at this thing that we haven’t reviewed in five years, to see if we can do it differently. So far there haven’t been any changes, but let your teams know about this. Let us know if you have any thoughts.

Taking a step back, especially as you’re going from an individual contributor to a manager, is hard but over time you learn to realize what a productive day looks like, and that doesn’t mean writing lines of code.

Ledge: I’ve also talked to people who have tried the management and leadership track and have said, this is not for me and I really want to go back and just commit code all day. I think it takes a lot of self-awareness and evaluation to say, hey, what’s the right seat for me for the organization to move forward?

Recently, I talked to a guy who just demoted himself from CTO to line engineer, and he’s ten times as happy. There has to be that personal reflection. I think organizations have gotten better recently, in the last few years, at honoring the engineering path. Not just saying, a promotion means you have to leave now.

Damian: Yes. Absolutely. One of the things that always existed but I think is becoming more mainstream in our industry is that notion of the engineering ladder. People are sharing it. What does it mean in their company to be a senior engineer and a manager?

That’s very good for providing clarity to people that come in, to manage expectations, but at the same time one of the things you start seeing – and going back to that, hey, moving to manager seeing it’s not for you – is realizing that going into management is not a promotion. Going into management is just like you’re changing tracks. It’s a different skillset, and you might not like it. Just as it’s not a promotion to go in one direction, coming back and saying, hey, this is not for me, is also not a demotion. It’s not a bad thing. It’s just you experimented, you took a risk, you went outside of your comfort zone and you decided that was not for you today.

There’s a really good blog post, or set of blog posts I think, from Charity Majors on this topic. I think they’re very good because, as the leader, it helps take some of that fear of, hey, I’m going to be stuck there forever, I took a risk and it didn’t play out. How will that look in other’s eyes? I think it’s quite the opposite.

Ledge: Absolutely. Damian, great insights. Thanks so much.

Before I let you go, we have this super important lightning round. Are you ready? This is critical stuff.

Damian: Sure.

Ledge: Star Wars or Star Trek?

Damian: Star Wars.

Ledge: What are you reading right now?

Damian: I am reading, Getting to Yes.

Ledge: Excellent book. What can’t you live without?

Damian: Oh, the NBA. Every time the season’s over I get really sad.

Ledge: What is the last thing that you Googled for work?

Damian: I don’t remember. Let’s see. It was… Oh, yes I remember, it was actually the Charity Majors blog post because I had the conversation today about someone potentially trying out for a manager position, and I sent them that clip. So that’s the last thing I did.

Ledge: Great. We’ll have to get you a share of that for the show notes.

I don’t know if you’re familiar with The Office, US version of The Office, but there’s a classic episode where Jim is the office protagonist and then Dwight is the office heel that everybody gives a hard time. Jim is sending Dwight faxes from future Dwight and he’s warning him of things like, “The coffee is poisoned today,” and messing with him about different stuff.

I like to ask people, if I gave you a piece of paper and a big, thick black Sharpie and today you are future Damian, you get to send that paper back to yourself in the past, what would you write on that piece of paper and why?

Damian: That’s a good one. I’d say that, you are going to get many things wrong but don’t worry, most of them will be fine and not something you can’t change. The important thing is learning from them, not just taking them as if it’s the worst thing in the world.

Ledge: Excellent. Well, Damian, thanks so much for joining us. Big fans of Auth0 over here, so we’re going to keep tracking your growth over there.

Damian: Thank you. Really appreciate the invitation, Dave. Again, thanks again to everyone and everyone who’s listening.